Why Your Email Lands in Spam: SPF, DKIM and DMARC in Practice

When mail from your domain starts landing in spam folders, the first instinct is to blame the spam filter. Usually the filter is doing its job. The real problem is that your domain is not proving it is allowed to send the message, and DNS is where that proof lives.

This is a practical walk through the four things that decide whether your mail is trusted: MX, SPF, DKIM, and DMARC. I will keep the explanations plain and point out the mistakes that actually cause failures, because those are more useful than a perfect definition of each record.

Start with routing, because nothing else matters if mail cannot arrive

Before you touch authentication, confirm that mail routes correctly. MX records tell the world where to deliver mail for your domain, and if they are wrong, no amount of SPF or DKIM will save you — messages will not reach a mailbox to be filtered in the first place.

Two details are worth checking. First, MX targets must be hostnames, not raw IP addresses. Second, those hostnames must actually resolve and accept connections. It is surprisingly common to find an MX pointing at a hostname that has no A record, or that resolves to a server which refuses connections on port 25.

Do that check first, every time. I have lost count of the hours spent reviewing DKIM selectors only to find the mail was being routed to a decommissioned host the entire time. Try it on DNS Checkers MX Lookup

SPF in plain language

SPF is a TXT record that lists who is allowed to send mail for your domain. When a receiving server gets a message claiming to be from you, it looks up the SPF record, checks whether the sending IP is on the approved list, and records the result.

A typical record looks like this:

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

Read it left to right. v=spf1 marks the record. Each include: pulls in another organisation's approved senders. The final -all means "anything that did not match is not permitted."

The mechanics are simple. The pitfalls are not.

The first pitfall is having more than one SPF record. If two TXT records both start with v=spf1, receivers treat the domain as misconfigured and fail the check. When you add a new sending service, edit the existing record — do not create a second one. This is, by a wide margin, the most common SPF failure I see.

The second pitfall is the lookup limit. SPF allows at most ten DNS lookups to resolve all those include: and a: and mx: mechanisms. Every include can pull in more lookups of its own, and nested includes add up faster than people expect. Go over ten and receivers return a permanent error, known as permerror, which is worse than a clean fail because it often has no clear owner. There are legitimate techniques to reduce the count — flattening includes, for instance — but they come with their own maintenance burden, so treat them as a last resort rather than a default.

The third pitfall is the tail. -all is a hard fail and is what you want once everything is correct. ~all is a soft fail and is a reasonable staging choice. ?all asserts nothing and provides no protection. And a bare record with no tail at all defaults to neutral, which is effectively no policy. Know which one you published, and why. Try it on DNS Checkers Check TXT / SPF

DKIM: the signature that survives forwarding

DKIM gives each outgoing message a cryptographic signature, and it publishes the public key in DNS so receivers can verify it. The private half stays on your mail server or with your sending provider. The public half lives in a TXT record at a name like selector._domainkey.yourdomain.com.

Two things make DKIM worth the trouble. First, unlike SPF, DKIM survives forwarding, because the signature travels with the message body rather than depending on the sending IP. Second, DKIM is how you prove authenticity when you send through third parties whose IPs are not yours.

The word to notice is selector. You do not publish one DKIM key; you publish one per selector, and the sending service tells the receiver which selector to check. That is a feature: it lets you rotate keys without downtime by publishing a new selector alongside the old one. It is also a frequent source of confusion, because "DKIM is broken" usually means "the selector the sender used does not exist in DNS."

When DKIM fails, check four things in order: that the selector in the signature matches a published record, that the record contains a valid public key, that the key length is at least 1024 bits (2048 is the modern norm), and that nothing in your mail pipeline is rewriting the message body after signing. A signature is invalidated by the smallest edit, including a footNote appended by a marketing tool.

DMARC: the policy layer

SPF and DKIM authenticate. DMARC decides what happens when authentication fails — and it adds reporting, which is where most of its practical value lives.

A DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

p=none means "deliver anyway, just tell me." p=quarantine means "treat failures as suspicious." p=reject means "refuse them." The rua address receives aggregate reports, and the adkim and aspf settings control how strictly forwarded mail must align.

Alignment is the concept people skip, and it is the one that matters. DMARC does not just ask whether SPF or DKIM passed. It asks whether the domain that passed is aligned with the domain in the visible From header. A message can pass SPF perfectly and still fail DMARC if the SPF-approved domain is a different one than the recipient sees. This is why mailing through a third party sometimes passes SPF and still gets flagged: the authentication worked, but it authenticated the wrong identity.

The p=none, then quarantine, then reject ladder

The single most damaging DMARC mistake is publishing a strict policy before you know what you send. If you jump straight to p=reject while some legitimate service sends mail you forgot about, you will block your own invoices.

The safe path is a ladder, and it takes weeks, not minutes:

1. Publish p=none with a rua reporting address and let it run.
2. Read the reports. Every sending source you do not recognise is either a service you must add to SPF, or something spoofing you.
3. Fix the legitimate sources until failures are near zero.
4. Move to p=quarantine, watch for a while, and fix anything that breaks.
5. Move to p=reject once you are confident.

It is tedious. It is also the only reliable way to reach a strict policy without breaking real mail, and the aggregate reports you collect along the way are genuinely informative about who is using your domain.

A debugging order that saves time

When mail is failing, work from the outside in, and do not skip steps.

• Confirm MX is correct and the hosts accept connections.
• Confirm there is exactly one SPF record and that it stays under ten lookups.
• Confirm the DKIM selector in play resolves to a valid key.
• Confirm DMARC exists and that its policy matches your intent.
• Only then look at message content and reputation.

Following that order means you always know which layer is broken before you start changing things. Guessing at content filters while your SPF record is duplicated is a waste of an afternoon. Try it on DNS Checkers Lookup All DNS Records

What the reports actually tell you

The aggregate reports DMARC sends to your rua address are XML files, and they are dense. Most people open one, feel overwhelmed, and stop. That is a shame, because a few fields carry almost all of the value.

The first is the source IP and its reverse DNS name. That tells you which server sent the mail. If the name belongs to a service you recognise, you know it is legitimate and should be covered by SPF or DKIM. If it belongs to a hosting provider you have never used, something is sending as your domain without permission, and that is worth investigating immediately.

The second is the SPF and DKIM result for each message, and crucially the domain that authenticated. A message can show spf=pass while still failing DMARC, because the domain that passed was not aligned with the visible From address. Watching that column is how you discover an unaligned sender before your policy is strict enough to reject it.

The third is volume. A trickle of failures from an odd source is noise. A steady percentage of your real mail failing authentication is a signal that a legitimate system is misconfigured, and it will break the day you tighten the policy.

Read the reports with those three questions in mind — who sent it, did the right domain authenticate, and how much of it is there — and a wall of XML becomes a short, actionable briefing.

The honest summary

Email authentication is not glamorous, and there is no single switch that makes you deliverable. But the mechanism is legible: route mail correctly with MX, list your senders in SPF, sign your messages with DKIM, and publish a DMARC policy that graduates from monitoring to enforcement as your confidence grows.

Do those four things in that order, keep exactly one SPF record, and you will avoid almost every deliverability problem that is actually within your control. The rest — content, reputation, recipient behaviour — is a different conversation, and one you can only have once the DNS layer is right.