Email Authentication: SPF, DKIM and DMARC Explained
"Three DNS records decide whether anyone can send email as your company. What each one does, why they break, and how to get to enforcement without losing legitimate mail."
Someone can send an email that appears to come from your domain right now. Not a lookalike domain, not a spoofed display name - your actual domain, in the address bar of your customer's inbox. Unless three DNS records are in place and enforcing, nothing on the internet stops them.
Those three records are SPF, DKIM and DMARC. They are the reason business email compromise works against some companies and fails against others, and they cost nothing but attention.
Why this matters more than it used to
Business email compromise remains one of the highest-loss categories reported to the FBI, and the mechanism is impersonation rather than malware[1]. The human element features in the majority of breaches, and a message that authenticates as your domain gets far more trust than one that does not[2].
The mailbox providers have also stopped treating this as optional. Google requires authentication for anyone sending to Gmail at volume, including a published DMARC policy for bulk senders[3]. Unauthenticated mail increasingly does not arrive at all, which turns a security control into a deliverability one.
The three records, in plain terms
SPF lists which servers are allowed to send mail for your domain. The receiving server checks the sending IP against that published list[4]. It is a guest list.
DKIM adds a cryptographic signature to each message, and publishes the public key in DNS so a receiver can verify the message was not altered and really came from your mail platform[5]. It is a wax seal.
DMARC ties the two together. It tells receivers what to do when a message fails - nothing, quarantine, or reject - and where to send reports about who is sending as you[6]. It is the instruction to the doorman.
SPF and DKIM without DMARC is the common half-finished state: the checks run, the result is discarded, and nobody sees the reports.
The rollout, in order
The rollout, in order
Elapsed working days
Timeline of a DMARC rollout over roughly eight weeks: sender inventory in week 1, SPF and DKIM in weeks 1 to 2, DMARC at p=none in week 2, a four-week monitoring and authorisation period, then quarantine in week 6 and reject in week 8. The monitoring period is the longest bar.
Publish SPF and enable DKIM for your own domainWeek 1-2
Watch the 10-lookup SPF limit on multi-vendor setups
3
Publish DMARC at p=none with a reporting addressWeek 2
4
Read the aggregate reports and authorise the senders you missedWeeks 2-6
The step that decides whether enforcement breaks anything
5
Move to p=quarantineWeek 6
6
Move to p=rejectWeek 8
Almost all of the elapsed time is the monitoring period, not the DNS work.
TechSuit rollout, staged as in NCSC guidance
The order is not negotiable. Publishing `p=reject` before you know which legitimate systems send as you is how a company stops receiving its own invoices, its CRM notifications and its booking confirmations on the same afternoon. NCSC's guidance sets out the same staged progression, and the monitoring period is the part people skip[7].
What usually breaks
1Forgotten senders. Your accounting platform, your newsletter tool, your booking system and your e-signature provider all send as you. Each needs to be authorised, and the SPF record has a hard limit of 10 DNS lookups, which multi-vendor setups blow through easily[4].
2Alignment. A message can pass SPF and still fail DMARC if the domain that passed is not the domain the reader sees. Alignment is what DMARC actually checks, and it is why "SPF is green" is not an answer[6].
3Forwarding. Mailing lists and auto-forwarding rules break SPF by design. DKIM survives forwarding, which is why both records need to be in place rather than one.
4Nobody reads the reports. DMARC aggregate reports arrive as XML. Without a parser or a service to read them, the monitoring phase produces nothing and the rollout stalls at `p=none` for years.
Doing it on Microsoft 365
Microsoft signs outbound mail with a default DKIM configuration, but the published guidance is to enable DKIM for your own custom domain so the signature aligns with the domain your recipients see[8]. That is a two-record CNAME change plus a switch in the security portal.
SPF is a single TXT record naming Microsoft's sending infrastructure plus any third-party senders. DMARC is one more TXT record at `_dmarc.yourdomain.com`, starting at `p=none` with a reporting address.
None of this requires a project. It requires a complete list of who sends mail as you, which is the part that takes the time.
What it does not do
Email authentication stops impersonation of *your* domain. It does nothing about a lookalike domain, a compromised mailbox sending genuinely authenticated fraud, or a supplier whose account was taken over. Those need MFA, conditional access and a payment-change verification process - separate controls that fail separately[1].
Country notes
Israel. Most small businesses here run Microsoft 365 or Google Workspace with a domain registered through a local reseller, and the DNS is often held at the registrar rather than at the mail provider. Confirm who can edit the zone before planning any change.
Europe. NIS2 Article 21 lists risk management measures including basic cyber hygiene; a published DMARC policy is among the cheapest pieces of evidence you can produce for that[9].
Spain. ENS control families cover protection of electronic mail explicitly, and authentication records are the concrete implementation of that control rather than a nice-to-have.
What to do with this
1Check what you publish today. A single DNS lookup for your domain's TXT records tells you whether SPF and DMARC exist and what policy is set.
2List every system that sends mail as you, including the ones marketing set up without telling IT.
3Publish DMARC at `p=none` with a reporting address, and actually read the reports for a few weeks.
4Move to `p=quarantine`, then `p=reject`, once the reports show only sources you recognise.
Questions we get asked
Sources
Every figure in this article traces back to a named source. Where we quote our own numbers, they come from work we have done with small businesses in Israel and across Europe, and we say so.
