Why emails land in spam: SPF, DKIM and DMARC explained
The symptom
Company email sometimes lands in the recipient's spam folder, or doesn't arrive at all — and it's not obvious why. The address is correct, the content isn't suspicious, and the receiving mail server still rejects or hides it.
The reason almost always lives in three DNS records most companies have never looked at: SPF, DKIM and DMARC.
What these three actually do
SPF (Sender Policy Framework) is a list of servers allowed to send mail on behalf of your domain. When someone sends mail pretending to be from you, but their server isn't on that list, the receiving server can see it.
DKIM (DomainKeys Identified Mail) is a digital signature attached to every message, proving it wasn't altered in transit and genuinely came from the domain that signed it.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy that tells receiving servers what to do when a message fails SPF or DKIM — nothing, quarantine it, or reject it outright — and sends the domain owner reports on who is sending mail as them.
Without DMARC, SPF and DKIM are just recommendations a receiving server may or may not act on.
How this actually breaks in practice
- Forgotten records. Over the years a company tries dozens of tools — a newsletter platform, a CRM, a marketing tool — and each adds its own SPF or DKIM entry during setup. The company stops using the tool; the record stays in DNS.
- Duplicate SPF records. A domain may only have one SPF record. Having more than one (a common result of the point above) is explicitly addressed by the spec (RFC 7208) as an error — the check doesn't run at all and returns a permerror, which receiving servers commonly treat as a failure.
- Missing or too permissive DMARC. Without a DMARC record, SPF and DKIM protect less than most companies assume.
- Nobody owns the DNS zone. Tools come and go for years, IT staff turns over, and nobody has cleaned up — exactly the situation in the case below.
A real case
A client with 112 employees (photovoltaics sales and installation) had a DNS zone that had accumulated several times more records than could be read in one sitting — including dead and broken ones left by tools the company had long stopped using. Outgoing mail was landing in spam because of it.
The fix: we went through the whole zone record by record, removed what was dead or contradictory, and set up outgoing mail authentication again, unambiguously. One day of work. Company email has arrived in the inbox, not spam, ever since.
Checking your own domain
No special tool needed — just dig (or any online DNS lookup) and a few minutes:
dig TXT yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short
dig TXT selector._domainkey.yourdomain.com +short
The first command shows every TXT record on the domain — look for ones starting with v=spf1. If there's more than one, that's a problem. The second shows your DMARC policy (v=DMARC1) — if nothing comes back, you have no DMARC at all. The third needs the exact selector name your mail provider uses (Google Workspace, Microsoft 365, and smaller tools all document theirs).
If you're not sure what the result means, or you suspect your DNS zone looks like the one above — tell us what's slowing you down.