Why your emails go to spam: SPF, DKIM and DMARC without the jargon

Email authentication answers one question for the receiving server: is this message really from the domain it claims? Get it wrong and even genuine invoices land in spam. Get it right and you also stop other people forging your domain, which matters more than most small businesses realise — a convincing invoice from your address is a fraud waiting to happen.

SPF: which servers may send as you

A TXT record listing the servers permitted to send email using your domain. It looks like:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

The ending matters most. -all is a hard fail: anything not listed should be rejected. ~all is a soft fail — treat as suspicious — and is the safe default while you are still discovering which systems send on your behalf. ?all enforces nothing at all and is only marginally better than having no record.

The trap: SPF permits a maximum of ten DNS lookups. Chain four or five include: statements — your mail provider, your CRM, your invoicing tool, your newsletter platform — and you can exceed it, at which point SPF fails permanently and silently. Check the record with the email health tool, which reads it back exactly as a receiver would.

DKIM: a signature on every message

Your mail server signs each outgoing message with a private key; the receiver fetches the matching public key from DNS and verifies it. Unlike SPF, DKIM survives forwarding, which is why mailing lists break SPF but not DKIM. Your provider gives you the record and the selector name; publish it exactly as given. Most breakage here comes from copying a long key with a line break in the middle.

DMARC: the instruction

SPF and DKIM produce verdicts. DMARC tells receivers what to do with them, and asks for reports:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Three policies: p=none (monitor only), p=quarantine (send failures to spam) and p=reject (refuse them outright). Start at none, read the aggregate reports for two to four weeks, and you will discover legitimate senders you had forgotten — the accounts package, the booking system, the old newsletter tool. Add them to SPF, then tighten to quarantine, then to reject. Jumping straight to reject is how a business stops receiving its own invoices.

The things that are not DNS

Authentication gets you considered, not delivered. The rest is reputation:

• Reverse DNS. Your sending IP needs a PTR record matching its hostname. Without one, many receivers downgrade or reject on sight. Check it with the IP lookup.
• Blocklists. A shared or newly allocated IP may carry someone else's history. The blacklist check queries the ten lists that matter.
• List hygiene. High bounce rates and spam complaints damage reputation faster than any missing record. Remove addresses that bounce; never buy a list.
• Consistency. Send from a stable address and domain. Rotating "from" addresses to dodge filters is a technique spammers use, and filters are trained on it.
• Content. A single image with no text, link shorteners, and an all-caps subject line still trigger filters — and always will.

A sensible order of work

1. Publish SPF with ~all, listing every system that sends for you.
2. Enable DKIM at your mail provider and publish the key.
3. Publish DMARC at p=none with a reports address.
4. Read the reports for a month; fix anything legitimate that fails.
5. Move to p=quarantine, then p=reject.
6. Confirm reverse DNS and check your sending IP against blocklists.

Run the deliverability check after each step; it grades the whole setup in one pass, so you can see progress rather than guess at it.