SPF, DKIM and DMARC in plain English (what each one does and how to check yours)

Email was designed without any way to check who sent a message. Nothing in the original protocol stops me putting your address in the From field. That flaw is why spam works, and SPF, DKIM and DMARC are the three patches bolted on afterwards to fix it.

You need all three. Mailbox providers have quietly made them mandatory rather than optional — since 2024, Gmail and Yahoo have required authentication from anyone sending at volume, and "your mail goes to spam for no reason" is very often one of these three missing or misconfigured.

Here is what each does, without the RFC language.

SPF — who is allowed to send

SPF is a list of servers permitted to send email using your domain.

You publish it as a TXT record in your DNS. It looks like this:

v=spf1 include:_spf.google.com include:amazonses.com ~all

Read it as: "mail for this domain can legitimately come from Google's servers or Amazon SES. Anything else, treat as suspect."

When a message arrives claiming to be from you, the receiving server looks up your SPF record and checks whether the machine that actually delivered it is on the list.

Two things break SPF constantly:

You can only have ONE SPF record. Publish two and the whole thing is invalid — not "one wins", invalid. This happens when you add a new sending tool and it tells you to add a record, so you add a second one alongside the first. You merge them instead, into a single record with multiple include: entries.

There is a hard limit of 10 DNS lookups. Every include: costs at least one, and providers nest their own includes inside. Stack up four or five sending tools and you silently exceed it, at which point SPF fails for everything. It fails quietly, and nothing tells you.

DKIM — proof it was not tampered with

DKIM is a cryptographic signature on the message itself.

Your sending provider holds a private key and signs each message with it. You publish the matching public key in DNS. The receiver verifies the signature and learns two things: the message really was signed by someone holding your key, and the content has not been altered in transit.

Where SPF asks "did this come from an approved machine?", DKIM asks "was this actually signed by you, and is it intact?"

DKIM survives forwarding, which SPF does not — a forwarded message arrives from the forwarder's server and fails SPF, but the DKIM signature still checks out. That is one reason you need both.

You will usually add DKIM as a CNAME or TXT record your provider gives you. You do not generate the keys yourself.

DMARC — what to do when the checks fail

SPF and DKIM each answer a question. Neither tells the receiver what to do about a failure, and neither tells you it happened. That is DMARC.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

Two parts matter.

The policy (p=) — your instruction to receiving servers:

• p=none — do nothing, just tell me. Monitoring only.
• p=quarantine — put failures in spam.
• p=reject — refuse them outright.

The reporting address (rua=) — where providers send daily summaries of what passed and failed, including mail claiming to be from you that you did not send.

The part that catches people: alignment

This is the bit almost nobody explains, and it is why mail fails DMARC while SPF and DKIM both pass.

DMARC does not just require SPF or DKIM to pass. It requires the domain they passed for to match the domain in your From address.

Send through a tool that signs with its own domain, and DKIM passes — for the tool's domain, not yours. SPF passes — for the tool's return path, not yours. Both green, DMARC fails, because neither aligns with the address the recipient sees.

That is exactly what verifying a sending domain fixes. When your provider walks you through adding DNS records, the point is that mail gets signed with your domain rather than theirs, so the checks align.

If mail is failing DMARC while SPF and DKIM look fine, alignment is nearly always the answer.

How to roll it out without breaking your email

The mistake is going straight to p=reject. If anything is misaligned, you have just told the world to bin your invoices.

1. Publish p=none with a reporting address. Nothing changes for deliverability. You start receiving reports.
2. Read them for a couple of weeks. The reports are XML and unpleasant by hand; free tools will parse them. You are looking for legitimate mail failing — a newsletter tool, your accounting software, a form on your site.
3. Fix what you find. Usually adding a source to SPF or verifying a domain with a provider.
4. Move to p=quarantine. Failures go to spam rather than being refused. Watch for a couple more weeks.
5. Then p=reject, once nothing legitimate is failing.

Most small senders can do this in a month. Rushing it is the only way it goes badly.

How to check what you have right now

From a terminal:

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com

The first shows your SPF record among any other TXT records, the second your DMARC policy. If the second returns nothing, you have no DMARC — which is the most common situation, and the easiest thing on this list to fix.

If you would rather not use a terminal, MXToolbox checks all three from a web form, and Mail-tester scores an actual message you send it, which catches content problems as well as authentication.

What this does and does not fix

Fixes: mail rejected or spam-foldered for authentication failures, and other people spoofing your domain — which is what p=reject genuinely prevents.

Does not fix: a bad sending reputation, spammy content, or emailing people who did not ask. Authentication proves a message is really from you. It does not make anyone want it. A perfectly authenticated cold blast to a purchased list will still get you filtered, and deserves to be.

Doing it

For the actual DNS records, setting up Resend and verifying your sending domain is the step-by-step version — that walkthrough is where these three stop being theory and become records you paste into your DNS provider.

If you are sending through Gmail rather than a dedicated provider, most of this is already handled for you by Google, and your constraint is Gmail's sending limits and app passwords instead. Worth knowing which situation you are in before you spend an evening on DNS you may not need to touch.

And if you are about to run a campaign or anything else that sends on a schedule, get authentication right first. Deliverability problems compound: a run of filtered messages damages your reputation, which filters the next run.

---

Got a DMARC report you cannot make sense of? Send me the shape of it: blog-email-auth@groundbasecrm.com — I read every one.