In this article
A customer completes checkout, clicks “Place order” and waits for the confirmation email. Nothing arrives. Or worse, it does arrive but lands in the spam folder, where they will never see it. A few minutes later you get a message: “Did my order go through?” If that sounds familiar, you are not alone.
Order confirmations, invoices, shipping notifications and password resets are some of the most important emails an online store sends. When they end up in spam, the cause is rarely the wording of the message or a missing plugin. It is the infrastructure: your domain’s DNS settings (SPF, DKIM, DMARC) and the reputation of the server IP that sends the mail.
Why it matters
The confirmation email is the customer’s proof that the purchase went through. Without it, they start wondering whether they were charged, whether the order will ship, or whether the store can be trusted. The result is more calls and messages to support, duplicate orders and, above all, customers who don’t come back.
On top of that, major mailbox providers such as Gmail, Outlook and Yahoo have become much stricter in recent years. Messages without proper sender authentication are either filtered to spam or rejected outright. So a store that “worked fine” yesterday can have a problem today without anything changing on the website.
The real causes: what mailbox providers check
When a message reaches Gmail or Outlook, the receiving server first asks a simple question: is this server allowed to send email for this domain? The answer comes from the checks below.
1. SPF: which servers may send
SPF (Sender Policy Framework) is a TXT record in your domain’s DNS that lists the servers and IP addresses allowed to send email on its behalf. If your store sends from a server that isn’t listed, the check fails. An SPF record looks something like this (example only, do not copy as-is):
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example-mail.com ~all"Common mistakes: two separate SPF records on the same domain (there must be only one), more than 10 DNS lookups inside the record, or the web server missing from the record because only the business email provider was added.
2. DKIM: a digital signature on every message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each email. The receiver checks it against the public key you publish in DNS, confirming the message really came from your domain and wasn’t altered in transit. Example record format:
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(public key)"If WooCommerce emails go out unsigned, or signed by a different domain, you lose one of the strongest trust signals there is.
3. DMARC: the policy that ties SPF and DKIM together
DMARC tells providers what to do when a message fails authentication, and sends you reports on who is sending email using your domain. The record lives at _dmarc.example.com. Example:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Roll it out gradually: start with p=none (monitoring only), read the reports, fix every legitimate sending source, then move to p=quarantine and finally p=reject. Jumping straight to a strict policy without checking first can block your own email by mistake.
4. From-domain alignment
Passing SPF or DKIM is not enough on its own. For DMARC, the domain the customer sees in the From field (for example orders@example.com) must match the domain that passed SPF or DKIM. Very often the store sends with the shop’s domain in From, but the message technically leaves from the server account (for example user@server123.hostname.net). SPF then passes for the wrong domain and DMARC fails.
5. PTR / reverse DNS
The sending server’s IP needs a proper reverse DNS (PTR) record: it should resolve to a real hostname, and that hostname should point back to the same IP. IPs with no PTR, or with a generic provider-style hostname, are treated with suspicion.
6. IP reputation and blacklists
Every IP has a history. If spam was sent from it in the past, or a compromised site on the same server is sending junk, the IP can end up on public blocklists (DNSBLs). On shared hosting the sending IP is shared with other accounts, so its reputation depends on them too. For a store with a steady flow of orders, a separate, controlled sending setup makes sense.
7. WooCommerce sends through PHP mail()
By default, WordPress and WooCommerce send email through wp_mail(), which uses PHP’s mail() on the server. That means no SMTP authentication, often no DKIM, and a bounce address (Return-Path) that doesn’t match your domain. It is the single most common reason order emails land in spam.
How to find out what’s wrong
- Read the headers. Place a test order to a Gmail address and open “Show original”. You’ll see whether SPF, DKIM and DMARC show PASS or FAIL, and which IP sent the message.
- Run an email score test. Services such as mail-tester give you a temporary address; send an email there from your store and get a report covering authentication, blacklists and content issues.
- Check your DNS records. MXToolbox’s free tools check SPF, DKIM, DMARC and PTR, and whether your server IP is listed on known blacklists.
- Watch your Gmail reputation. Google Postmaster Tools shows your domain and IP reputation and spam rate, once you send enough volume.
- Read your DMARC reports. The reports sent to your
ruaaddress show which servers send mail as your domain and whether they pass.
The real fix: get the infrastructure right
- Correct DNS records: a single SPF record covering every real sending source, DKIM enabled for the store’s domain, and a DMARC policy that starts at
p=noneand tightens step by step. - Authenticated SMTP instead of PHP
mail(), from an address on your own domain (e.g.orders@orinfo@), so From, SPF and DKIM all align. - Proper PTR and a clean IP: a server with correct reverse DNS, not listed on blacklists and, where it makes sense, a dedicated setup or service for transactional email.
- Ongoing monitoring: DMARC reports, blacklist checks and test sends after every change to the site or the email provider.
Why plugins alone won’t fix it
An SMTP plugin is simply the connector between WordPress and a mail server. If that server isn’t configured properly, if your DNS lacks SPF, DKIM and DMARC, or if the IP has a poor reputation, the plugin will just send the same emails to the same spam folder. “Anti-spam” plugins or fancier email templates don’t change any of the checks providers run. The problem has to be fixed where it starts: in DNS and on the server.
Quick checklist
- Is there one SPF record that includes your store’s server?
- Are emails signed with DKIM for your own domain?
- Do you have a DMARC record, and do you read its reports?
- Is the From address on your domain and aligned with SPF/DKIM?
- Does WooCommerce send via authenticated SMTP rather than PHP mail()?
- Does the sending IP have a proper PTR and stay off blacklists?
- Do the headers of a test email show PASS across the board?
Frequently asked questions
Is installing an SMTP plugin enough?
Not by itself. It only helps if it connects to a properly configured mail server and your domain has correct SPF, DKIM and DMARC records.
Why do emails go to spam for some customers but not others?
Each provider (Gmail, Outlook, Yahoo, local ISPs) has its own filters and its own level of strictness. A message with incomplete authentication may get through at one provider and be blocked at another.
Should I set DMARC to p=reject right away?
No. Start with p=none, confirm from the reports that every legitimate source passes, then move on to quarantine and reject.
Fix it for good with SmartHost
When a customer doesn’t receive their confirmation, trust in your store drops. At SmartHost we configure your e-shop’s server for maximum deliverability, so your messages end up where they belong: in the inbox.
Take a look at our e-shop development, managed WordPress hosting, shared hosting, VPS hosting and managed servers services. To have your own store checked, get in touch at +30 210 569 8010 or info@smarthost.gr.
