Why your business email lands in spam (and how SPF, DKIM and DMARC fix it)

You send a perfectly ordinary email — a quote, an invoice, a reply a customer is waiting for — and it lands in their junk folder. Nothing about the message was spammy. What failed was invisible: three DNS records that receiving mail servers use to decide whether you are who you claim to be. This guide explains what SPF, DKIM and DMARC actually do, in plain English, and how to find out whether yours are working.

The problem: email trusts anyone by default

Email was designed in an era when the internet was a few hundred universities. The protocol lets any server send a message claiming to be from any address — nothing in email itself checks the “From” line. That's why criminals can send invoices “from” your domain without ever touching your systems, and why receiving servers have grown deeply suspicious of mail that arrives without credentials.

SPF, DKIM and DMARC are those credentials. They're not features you buy; they're small text records published in your domain's DNS. When they're right, Gmail, Outlook.com and corporate mail filters can verify your mail mathematically — and when they're wrong or missing, those same filters quietly downgrade you to the junk folder. No bounce, no warning. Just silence.

SPF: the list of who may send for you

SPF (Sender Policy Framework) is a TXT record listing the servers allowed to send email for your domain. A typical record for a business on Microsoft 365 looks like this:

v=spf1 include:spf.protection.outlook.com -all

Translated: “Microsoft's mail servers send for us; reject everything else.” The include: pulls in Microsoft's published server list, and the ending matters more than most people realise: -all (a hard fail) tells receivers to treat unlisted senders as forgeries, while ~all (a soft fail) merely raises an eyebrow. There's also a less obvious constraint: SPF allows at most ten DNS lookups per check. Every include: you add — a newsletter tool here, a CRM there — spends from that budget, and once you exceed it, SPF starts failing for everyone.

DKIM: the tamper-proof signature

DKIM (DomainKeys Identified Mail) goes further than a permission list. Your mail server signs each outgoing message with a private cryptographic key; the matching public key is published in your DNS. Receiving servers check the signature and learn two things at once: the message genuinely came from your domain, and it wasn't altered in transit.

On Microsoft 365, DKIM appears as two CNAME records (selector1._domainkey and selector2._domainkey) pointing at Microsoft's infrastructure, plus a switch that must be turned on in the admin centre — publishing the records alone isn't enough, and the forgotten switch is one of the most common gaps we find. The two selectors exist so keys can be rotated without an outage.

DMARC: the policy that ties it together

SPF and DKIM each verify something, but neither tells receivers what to do when verification fails — and neither, on its own, checks that the domain being verified is the one displayed in the From line. DMARC closes both gaps. It's a TXT record at _dmarc.yourdomain.co.uk that says, in effect: “if a message fails both checks for my domain, here's what to do about it — and here's where to send the reports.”

• p=none — observe and report, take no action. The right starting point, and the wrong place to stay.
• p=quarantine — failures go to junk. A sensible resting policy for most small businesses.
• p=reject — failures are refused outright. The destination once you're confident every legitimate sender is covered.

The reporting address (rua=) is quietly valuable: receivers send you regular summaries of who's sending as your domain, which is how you discover both the forgotten newsletter tool and the fraudster in another country trying your name on for size. Increasingly, this isn't optional — Google and Yahoo now require DMARC from anyone sending in volume, and the big filters treat domains without it accordingly.

How to check yours

1. Look up your records directly: nslookup -type=txt yourdomain.co.uk shows SPF, and nslookup -type=txt _dmarc.yourdomain.co.uk shows DMARC.
2. Use a checker such as MXToolbox or Google's Admin Toolbox — paste your domain and it grades all three records with explanations.
3. Send a test to a Gmail address, open the message, and choose “Show original”: Gmail displays a pass/fail verdict for SPF, DKIM and DMARC on that actual message — the ground truth, not theory.

The misconfigurations we see most

• Two SPF records. A second v=spf1 record doesn't add permissions — it invalidates SPF entirely. Everything must merge into one record.
• SPF ending in +all. One character that means “anyone on the internet may send as us”. Rare, and always an accident.
• Blowing the ten-lookup budget. Years of accumulated include:s from tools long since cancelled.
• DKIM records published but never enabled — the Microsoft 365 special, as above.
• A new sending tool nobody told DNS about. The marketing platform works in testing, then fails DMARC in production because it was never added to SPF or given its own DKIM key.
• p=none forever. Installed during setup with every intention of tightening it later. Later never came, and the record now advertises that forgeries carry no consequence.

Do I really need all three?

Yes — and the reason is that each covers a weakness in the others. SPF alone breaks silently when mail is forwarded, because the forwarding server isn't on your list. DKIM alone says a message is genuine but leaves receivers to guess what to do with the forgeries. And without DMARC, nothing connects either check to the From address a human actually reads, and nothing tells you the forgeries are happening at all. Together they close the loop: SPF names your senders, DKIM proves your messages, DMARC sets the consequences and sends you the evidence. The good news is that none of this is a subscription or an ongoing chore — it's three DNS records and one admin-centre switch, done once and reviewed occasionally.

What good looks like

For a small business on Microsoft 365: one SPF record ending -all that covers Microsoft plus each legitimate third-party sender; DKIM enabled and verified for every sending service; and DMARC at p=quarantine or stricter with reports going somewhere a human occasionally looks. Set up in an afternoon, checked twice a year, and your invoices arrive where they were addressed — which is the whole, unglamorous point.