SPF, DKIM, and DMARC without the jargon

Three DNS records decide whether your email lands in the inbox or the spam folder, and most explanations of them read like an RFC. Here is the version we give clients when we set up their mail and they ask what they actually need. No “cryptographic non-repudiation,” just what each record does and the order to turn them on so you do not blackhole your own newsletter.

Since February 2024 this stopped being optional for anyone sending volume. Gmail and Yahoo now require SPF, DKIM, and DMARC on any domain sending more than 5,000 messages a day to their users, and they quietly raised the bar for smaller senders too. If your invoices or password resets have been going to spam lately, this is usually why.

The one-sentence version of each

SPF is a list of who is allowed to send mail for your domain. DKIM is a signature that proves the message was not tampered with on the way. DMARC is the instruction that tells the receiving server what to do when a message fails the first two, plus a report so you can see who is sending as you. That is the whole thing. Everything else is detail, and the detail is where people lock themselves out, so let us take them one at a time.

SPF: the guest list

SPF (Sender Policy Framework) is a single TXT record in your DNS that names every server allowed to send email using your domain. Your mailbox provider, your CRM, your invoicing tool, the WordPress plugin that fires off contact-form replies. If a server is not on the list, the receiver knows the mail is suspect.

The mistake we see most: more than one SPF record on a domain. You are allowed exactly one. Two records is not extra protection, it is a syntax error that makes the whole check fail, and the second one is usually left over from a tool someone added in 2021 and forgot. There is also a hard limit of ten DNS lookups inside an SPF record. Big senders blow past it without noticing, SPF returns “permerror,” and receivers treat it as no SPF at all.

DKIM: the wax seal

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiving server checks that signature against a public key published in your DNS. If they match, the message is genuinely from you and nobody edited it in transit. If a spammer copies your email, the signature breaks and the receiver knows.

You do not generate DKIM by hand. Your mail provider gives you the key, you paste it into DNS as a TXT or CNAME record, and you switch it on in their dashboard. Google Workspace, Microsoft 365, a Postfix box, cPanel mail, they all hand you the value. The work is in the DNS, not the cryptography.

DMARC: the bouncer, and the part everyone rushes

DMARC ties the first two together and adds a policy. It says: if a message claiming to be from my domain fails both SPF and DKIM, here is what to do with it. Three settings exist. p=none means do nothing, just tell me. p=quarantine means send it to spam. p=reject means bounce it.

Here is where it goes wrong. Someone reads that p=reject is the strong, secure setting, switches it on day one, and finds out a week later that their accountant never got the invoices, because the invoicing tool was never in the SPF record. Now their own policy is rejecting their own mail.

The right order is boring and it works. Publish DMARC at p=none first. Read the reports it sends you for two to four weeks. Those reports show every service sending as your domain, including the ones you forgot about. Fix SPF and DKIM until everything legitimate passes. Then move to p=quarantine, watch for another couple of weeks, and only then go to p=reject. The full ramp takes about a month on a busy domain. Skipping it is how you lose mail.

Why your mail can fail all of this and still be real

One thing the vendor guides skip: forwarding breaks SPF. If a recipient auto-forwards your email to another address, the forwarding server is not on your SPF list, so SPF fails on the second hop. That is by design and there is nothing wrong with your setup. It is exactly why DMARC accepts a pass from either SPF or DKIM, and why DKIM is the more durable of the two. Get DKIM right and forwarded mail still authenticates.

How to check what you have right now

You do not need a paid tool to start. Free checkers like MxToolbox or Google’s Admin Toolbox will read your current SPF, DKIM, and DMARC records and tell you what is missing or malformed. Run your domain through one before you change anything. Half the time the records are there but one has a typo, an old include, or a policy that was set to p=none years ago and never moved, which means it has been mailing reports to an inbox nobody reads.

When to hand it off

If you run a single mailbox on Google Workspace, you can do all three yourself in an afternoon, and you should. Where it gets fiddly is a real mail server. We set up SPF, DKIM, and DMARC on Postfix and panel-based mail as part of our mail setup for self-hosted servers, and when deliverability is already broken and you need it diagnosed fast, that is what the email deliverability fix is for. The broader email deliverability service covers the picture underneath these three records too, including reverse DNS and IP reputation. On Google Workspace or Microsoft 365, our hosted email setup handles the same records on the provider side.

Records aside, the bigger upstream decision is whether to self-host email at all or rent mailboxes from a provider whose IPs already have a reputation.

If you read nothing else: turn them on in order, sit at p=none until the reports are clean, and never jump straight to reject. The records are simple. The rollout is where the patience pays off.

If mail is already failing and you are holding a rejection notice, work backwards instead: our walkthrough on decoding an email bounce back maps each SMTP status code to the record that needs fixing.