SPF, DKIM and DMARC: Why Your Email Goes to Spam

Three TXT records control whether Gmail trusts your mail. Two of them fail silently, which is why nobody notices until a customer says they never got the invoice.

Your email works. You send an invoice, the customer says they never got it, and you find it in their spam folder. Nothing changed on your end, nobody reported an error, and your mail server logs show a successful delivery.

Three DNS records decide whether receiving servers trust mail claiming to come from your domain. Two of them fail silently. This is what each one does, in the order you should set them up, and the specific mistakes that quietly break them.

The problem all three solve

SMTP, the protocol that carries email, has no built-in concept of authenticity. Any server on the internet can connect to Gmail and announce that it is sending mail from your domain. Nothing in the protocol stops it.

That is why spam and phishing work, and why receiving providers built a verification layer on top. All three records live in your DNS, because DNS is the one thing only the domain owner controls.

They answer three different questions:

SPF — is this server allowed to send for this domain?
DKIM — was this message altered in transit, and does it carry a valid signature from the domain?
DMARC — what should the receiver do when the answer to either is no, and who should be told?

You need all three. SPF alone breaks whenever mail is forwarded. DKIM alone says nothing about servers that send unsigned mail. DMARC without the other two has nothing to check.

SPF: which servers may send

SPF is a single TXT record at your domain listing the servers permitted to send mail for it.

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

Read left to right: this domain's mail comes from Google Workspace and from Mailchimp, and anything else should be treated with suspicion. Each include: pulls in the sending servers that provider publishes, so you do not have to track their IP addresses yourself.

The last term decides how strict you are:

~all — softfail. Mail from anywhere else is suspicious but should still be accepted. This is the right setting while you are getting things working.
-all — hardfail. Mail from anywhere else should be rejected. This is where you want to end up, but only once you are certain every legitimate sender is listed.
+all — permits the entire internet to send as you. This is never correct and actively harmful.

The two mistakes that break SPF

Publishing two SPF records. A domain may have exactly one. Two records beginning v=spf1 is a permanent error — receivers do not merge them or pick one, they fail the check outright. This happens constantly, because every service you sign up to tells you to "add this to your SPF record", and it is easy to add a second record instead of editing the existing one.

The fix is to merge them into a single record containing every include:. Run your domain through the DNS Checker and look at the TXT row: if you see two values starting v=spf1, that is your problem.

Exceeding ten DNS lookups. Every include:, a, mx, ptr and redirect costs a DNS lookup when a receiver evaluates your record, and the limit is ten. Worse, the limit is recursive — an include: that itself contains three includes costs you four. Go over and the result is permerror, which most receivers treat as a failure.

Four or five providers is enough to hit this. If you are close, remove services you no longer use, and prefer ip4: entries over include: for servers with stable addresses, since a literal address costs no lookup.

The limitation nobody mentions

SPF breaks when mail is forwarded. If someone forwards your message, the forwarding server relays it from its own address, which is not in your SPF record. The check fails through no fault of yours. Mailing lists do the same thing.

This is not a flaw you can fix, and it is the reason DKIM exists.

DKIM: a signature that survives the journey

DKIM attaches a cryptographic signature to each outgoing message. Your mail provider signs with a private key; the public key is published in your DNS. A receiver fetches the key, checks the signature, and knows both that the message came from your domain and that its content was not altered.

Because the signature travels with the message, DKIM survives forwarding. That is its advantage over SPF, and the reason both are needed.

Setup is provider-specific: you enable DKIM in your mail provider, it gives you a record to publish at a hostname like selector1._domainkey.example.com, and you add it. The "selector" part lets you run several keys at once, which is how you rotate keys without an interruption.

Practical points:

Publish the record before enabling signing. If you turn on signing first, mail goes out signed with a key receivers cannot find, and it fails verification.
The record is long. DKIM keys exceed the 255-character limit for a single DNS string, so they are split into chunks and rejoined by the receiver. Some control panels handle this for you and some require you to split it yourself. If the key looks truncated in a lookup, that is worth checking — the DNS Checker rejoins split TXT records, so what you see there is the assembled value a receiver would use.
Verify each sending service separately. Every service that sends as you — help desk, invoicing, newsletter — needs its own DKIM key published under its own selector.

DMARC: the policy, and the reports

DMARC ties the other two together. It states what receivers should do when a message fails both checks, and asks them to report back.

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

Published at _dmarc.example.com. The policy p takes three values:

p=none — do nothing differently, but send reports. This is monitoring only.
p=quarantine — send failures to spam.
p=reject — refuse failures outright.

DMARC also introduces alignment, which is the part people miss. It is not enough for SPF or DKIM to pass; the domain they pass for must match the domain in the visible From address. A message that passes SPF for your bulk mail provider's own domain, while showing your domain in the From field, is not aligned and fails DMARC. This is why mail can pass SPF and still fail DMARC, and it usually means the provider needs configuring to use your domain in the envelope rather than theirs.

Roll it out in stages

Going straight to p=reject will delete legitimate mail from senders you forgot about. The staged approach costs a few weeks and avoids that:

Publish p=none with a rua address. Change nothing else. Reports start arriving within a day or two — XML files listing every server that sent mail claiming to be you, and whether each passed.
Read the reports for two to four weeks. They are unreadable raw; a free DMARC report viewer will parse them. You will almost certainly find a legitimate sender you had forgotten — a CRM, a booking system, an old server. Add each to SPF and DKIM.
Move to p=quarantine, optionally with pct=10 to apply it to a sample first. Watch the reports.
Move to p=reject once reports show only genuine forgeries failing.

The reporting stage is the valuable part. Most domains discover at least one sender nobody remembered, and finding it at p=none costs nothing while finding it at p=reject means lost mail.

Checking your setup

All three are TXT records, so all three are visible in a DNS lookup. Run your domain through the DNS Checker and read the TXT row:

Exactly one value starting v=spf1. Two is a hard failure.
A value at _dmarc.yourdomain.com starting v=DMARC1.
Your DKIM record at whatever selector your provider assigned.

If resolvers disagree about your TXT records, you are mid-propagation and some receivers are still seeing the old values — see how long DNS propagation takes for how to read the remaining TTL.

One caution: DNS is only half the picture. These records tell receivers how to evaluate your mail, but reputation, content and sending volume all affect placement too. Correct authentication is necessary for reaching the inbox. It is not sufficient on its own.

The short version

SPF lists who may send and breaks on forwarding. DKIM signs the message and survives forwarding. DMARC decides what happens on failure and reports who is sending as you. Publish one SPF record, keep it under ten lookups, publish DKIM before enabling signing, and start DMARC at p=none until the reports are clean.