Why Do My Emails Go to Spam? A DNS-First Checklist for SPF, DKIM, and DMARC

When someone says "our email goes to spam," the instinct is to rewrite the email. Change the subject line, strip the images, remove the word "free." That almost never fixes it, because the message usually was not judged on its content at all. It was judged on whether the receiving server could confirm that your domain actually authorised the send.

That confirmation happens in DNS, before a human ever sees the message. So the fix starts in DNS too. Here is the order we work in when a domain suddenly starts landing in spam folders, and what each record is genuinely doing.

Why does authentication decide whether you reach the inbox?

Every inbound message arrives with two claims attached: an envelope sender (what the sending server told the receiving server during the SMTP conversation) and a From header (what the recipient sees in their mail client). Nothing in the protocol forces those to match, and nothing forces either one to be true. That gap is the entire reason phishing works.

SPF, DKIM, and DMARC exist to close it. SPF answers "is this IP address allowed to send envelope mail for this domain?" DKIM answers "was this message cryptographically signed by a key published under this domain?" DMARC answers "do either of those checks line up with the domain the recipient can actually see, and what should you do if not?"

A receiving server that cannot answer any of those questions is left with an unverifiable message from an unknown sender. Spam foldering is the polite outcome.

What does a correct SPF record look like?

An SPF record is a single TXT record published at the root of your domain. It starts with a version tag and ends with an "all" mechanism that says what to do with everything the record did not explicitly authorise.

The three things worth checking, in order:

• There is exactly one. Two SPF records on the same domain is not "more coverage" — it is a permanent error, and conformant receivers treat the whole check as failed. This is the single most common misconfiguration we see, and it usually happens when a marketing tool and an IT team each add their own record without looking.
• It ends in a real qualifier. A record ending in -all tells receivers to fail anything not listed. A record ending in ~all asks them to accept but mark it. A record ending in ?all tells them essentially nothing, which defeats the point of publishing it.
• It stays inside the lookup budget. SPF evaluation is capped at ten DNS lookups. Every include:, a, mx, and redirect spends from that budget, and includes nest — a single vendor include can quietly consume four or five on its own. Blow the budget and the record hard-fails regardless of how correct the rest of it looks.

Why does SPF break silently as a business grows?

Because SPF is a list of everyone allowed to send as you, and that list grows every time someone signs up for a tool. Helpdesk software, invoicing, e-signature, calendar invites, the CRM, the newsletter platform, the recruiting system — each one wants to send from your domain, and each one hands you another include: to paste in.

Nobody removes the old ones. Three years later the record has eleven includes, two of which point at services that were cancelled, and the whole thing silently exceeds the lookup limit. Mail that worked yesterday fails today with no change on your side, because a vendor expanded their own include upstream.

This is why SPF deserves monitoring rather than a one-time setup. The record you validated at launch is not the record that is being evaluated this morning.

What does DKIM actually sign, and why does it survive forwarding?

DKIM adds a signature header to outbound mail, computed over the message body and a chosen set of headers, using a private key held by the sending platform. The matching public key lives in DNS at a selector-specific hostname — which is why you publish records at names like selector1._domainkey.yourdomain.com rather than at the domain root.

The practical advantage over SPF is that the signature travels with the message. When a recipient forwards your email to a colleague, or a mailing list relays it, the connecting IP changes and SPF alignment is lost. The DKIM signature is still in the headers, still valid, and still tied to your domain. For any organisation whose mail gets forwarded — which is all of them — DKIM is the more durable of the two.

Two failure modes are worth knowing. First, a selector published in DNS but not actually enabled on the sending platform produces no signature at all; the DNS side looks perfect while nothing is signed. Second, rotating a key at the platform without republishing the new public key breaks every message signed after the rotation. Both look identical from the outside: mail that used to authenticate suddenly does not.

What does DMARC add on top of SPF and DKIM?

Alignment and instructions. SPF and DKIM can both pass for a domain the recipient never sees — the envelope sender and the signing domain do not have to match the From header. DMARC closes that by requiring at least one of them to align with the visible From domain, and then tells receivers what to do when nothing aligns.

It also turns on reporting, and that is the part most people underuse. A DMARC record with a rua address causes participating receivers to send you daily aggregate reports listing every IP that sent mail claiming to be your domain, along with whether SPF and DKIM passed and aligned. Before you have that data you are guessing about your own sending footprint. After a fortnight of it, you have an inventory.

How should you roll out DMARC without losing mail?

Slowly, and in this order:

• Publish p=none with a rua address. This changes nothing about delivery. It only starts the reports flowing.
• Read the reports until they stop surprising you. Every legitimate sender should be identifiable and should be aligning on SPF, DKIM, or both. If a system you rely on is failing alignment, fix that system before tightening the policy — not after.
• Move to p=quarantine, optionally with a percentage. The pct tag applies the policy to a fraction of failing mail, which lets you watch the effect on a slice rather than the whole stream.
• Move to p=reject once quarantine has been quiet for a full business cycle. Quiet means no legitimate sender appearing in the failure column, across a period long enough to include your monthly and quarterly sends.

The mistake that costs real money is jumping straight to reject because it looked like the "secure" option. Reject on a domain with an unmapped sender does not fail visibly on your side — it fails at the recipient, silently, and you find out when someone asks why they never got the invoice.

What order should you fix things in?

If mail is currently going to spam and you need a sequence rather than a survey:

• Confirm there is exactly one SPF record and that it resolves within the lookup limit.
• Confirm DKIM is signing in practice, not just published in DNS — check the headers of a real message you sent.
• Publish DMARC at p=none with reporting, and read the first week of reports.
• Only then look at reputation: are you on a public blacklist, are complaint rates climbing, is a shared IP dragging you down.
• Content last. It matters, but it is the smallest lever of the five.

Once all three records are correct, the remaining work is keeping them correct. Records drift because vendors change, keys rotate, and DNS gets edited by people who are not thinking about mail. Continuous checks catch that within hours instead of within a quarter.