Core mechanics · module 3 of 8 · 9 min read
Authentication: SPF, DKIM and DMARC
What are these three records, and what breaks when they are wrong?
- SPF
- DKIM
- DMARC
- alignment
- p=none
- BIMI
Read first: How email actually gets delivered
Three DNS records decide whether mailbox providers believe you are who you say. Get them wrong and nothing else in this guide matters. They look intimidating and are genuinely not — each answers one question.
SPF — which servers may send for this domain
A DNS TXT record listing the servers authorised to send mail for your domain. The receiver checks whether the sending server is on the list.
The practical trap: SPF has a ten-DNS-lookup limit. Each service you add (ESP, CRM, helpdesk, invoicing) consumes lookups, and quietly exceeding ten makes SPF fail entirely. If you have accumulated tools over years, check this.
DKIM — was this message altered
A cryptographic signature added to the message, verified against a public key in your DNS. Confirms the message genuinely came from you and was not modified in transit.
Your ESP generates the key pair and gives you the record to publish. Publish it for every service that sends on your behalf, not just the main one.
DMARC — what to do when the first two fail
The policy layer, and where most senders stop too early. DMARC does two things: it tells receivers what to do with mail that fails SPF and DKIM, and it sends you reports about who is sending as your domain.
The policies:
p=none— do nothing, just report. The starting point.p=quarantine— send failures to spam.p=reject— refuse them outright.
The correct path is publish p=none, read the reports for a few weeks until you know every
legitimate sender, fix anything failing, then move to quarantine and then reject. Jumping
straight to reject will silently destroy mail you did not know you were sending.
Alignment: the part that catches people
DMARC does not just require SPF or DKIM to pass. It requires the passing domain to align with the domain in the visible From address. Mail can pass SPF and still fail DMARC because the SPF check passed for your ESP's domain, not yours.
This is the most common cause of "we set it all up and it still fails".
BIMI — the logo, and the reason it exists
BIMI displays your logo in the inbox. It requires DMARC at quarantine or reject, and usually a verified mark certificate. Modest benefit on its own; the real value is that it forces you to complete DMARC properly.
Why this got urgent
Gmail and Yahoo now require authentication for bulk senders rather than merely preferring it, alongside one-click unsubscribe and a spam-complaint rate kept below their threshold. Requirements, not best practice.
What trips people up
- Publishing SPF and stopping.
- Going to
p=rejectimmediately and losing invoices, tickets and receipts. - Forgetting the tools that send as you — helpdesk, billing, calendar invites.
You have got this when
You can name every system that sends email as your domain, and you have DMARC reports confirming it.
Go to the source
- primaryGmail email sender guidelines
- primaryYahoo sender best practices
- primaryDMARC overview
What has changed since
Stories from the briefs that touch this module.