If your order confirmations are landing in spam, the cause is almost always one of three DNS records. Here is what each does, in plain terms.
SPF — “these servers may send as me”
SPF is a list, published in your DNS, of the servers allowed to send email using your domain. A receiving mail server looks up that list and checks whether the message came from one of them.
What it proves: the message came from an approved server. What it does not prove: that the message was not altered, or that the visible “From” address is genuine.
The common mistake: SPF has a hard limit of ten DNS lookups. Teams add each new sending tool to the record and silently blow past it, at which point SPF fails for everything. If you have collected more than a handful of include: entries, you are probably already over.
DKIM — “this message was not tampered with”
DKIM attaches a cryptographic signature to each message. The receiving server fetches your public key from DNS and verifies the signature. If the message was altered in transit, verification fails.
What it proves: the message is intact and was signed by someone holding your key. What it does not prove: anything about the “From” address a human actually sees.
DMARC — “and here is what to do when the first two fail”
DMARC ties SPF and DKIM to the visible From address, and tells receiving servers what to do when neither passes: nothing, quarantine, or reject. It also asks them to send you reports.
This is the record most teams skip, and it is the one that makes the other two matter. Without DMARC, a failure is advisory. With it, a failure has a consequence you chose.
The order to do this in
- Publish DKIM first. It is the hardest to get wrong and it does not break anything.
- Fix SPF second. Audit what is actually sending on your behalf and remove what is not.
- Publish DMARC at
p=nonethird. This changes nothing about delivery but starts the reports flowing. - Read the reports for two weeks. You will find senders you forgot about.
- Move to
p=quarantine, thenp=reject. Only after the reports are clean.
Skipping straight to p=reject is the classic self-inflicted outage: every legitimate sender you forgot to authorise stops being delivered, and you find out from customers.
Where a sending platform helps
A decent provider will host the DKIM key for you, tell you exactly what to put in SPF, and parse DMARC reports into something readable. What it cannot do is decide your policy — that is a call about your own domain, and it should stay yours.