SPF, DKIM, DMARC, Explained for Business Owners (Not Just IT People)

Email was built with no way of checking that a sender is who they claim to be. That was a different era rather than an oversight, but the consequence is still here: anyone can send a message claiming to be from any address they like, and nothing in the protocol objects. SPF, DKIM and DMARC are the three records bolted on afterwards to deal with it.

They are usually explained as three layers of the same thing. They are not. They answer three different questions, and understanding which question each one answers is what makes the difference between publishing records and being protected.

SPF, the list of who is allowed to send

SPF answers one question: did this message come from a server I authorised? You publish a list in your DNS naming the mail servers allowed to send for your domain, and when somebody receives a message from you their server reads that list and checks.

A record looks roughly like v=spf1 include:spf.protection.outlook.com -all. The include pulls in Microsoft’s servers, and the -all at the end says everything not covered above is unauthorised.

On Microsoft 365 the record has to include Microsoft’s mail servers. It also has to include everything else that sends in your name, and that is where most records go wrong. The invoicing software, the newsletter platform and the booking system all send as you, and all of them get forgotten by whoever set the record up two years ago.

Two details cause most of the trouble. The ending matters: -all is a hard fail and tells receivers to drop unauthorised mail, while ~all is a soft fail and asks them to deliver it anyway. Records get left on the soft version during setup and never moved. And there is a limit of ten DNS lookups, which counts every include your record walks through rather than the ones you typed. A short-looking record can quietly need seventeen, at which point SPF fails for everything you send and nothing tells you.

SPF also has a structural weakness worth knowing about. It describes the server that delivered the message, so it breaks when a message is forwarded, because the forwarding server was never on your list. Legitimate mail failing SPF after forwarding is normal and expected.

DKIM, the signature that travels with the message

DKIM answers a different question: was this message actually written by the domain it claims, and has anything changed since? It signs each outgoing message cryptographically using a private key, and publishes the matching public key in your DNS so any receiver can check the signature.

On Microsoft 365 you turn it on by publishing two CNAME records and enabling it in the Defender portal. The two records exist so keys can be rotated without an outage.

Because the signature travels inside the message, DKIM survives forwarding where SPF does not. That is the main practical reason to have both rather than picking one. Plenty of tenants have never had DKIM switched on at all, and where that is true every message the business sends is unsigned, leaving the whole thing resting on a check that breaks whenever a recipient forwards your mail to their accountant.

DMARC, the policy and the reports

DMARC answers the question the other two cannot: what should a receiver actually do when the checks fail, and how does the domain owner find out it happened?

It publishes a policy, which is your instruction to receivers, and a reporting address, which is where they send a daily summary of everything they saw claiming to be from you. Without the reporting address the record still sets a policy, but receivers are told not to generate reports at all, so you get the instruction without any of the visibility that would tell you whether the instruction is safe.

The policy has three settings. At none, receivers report and take no action, so failing mail is still delivered. At quarantine, failing mail goes to junk. At reject, it is refused at the door. None is where everyone starts and reject is where the domain should end up.

Alignment, which is the part that makes any of it work

This is the piece almost every explanation skips, and it is the reason DMARC exists at all rather than being a tidy wrapper around the first two.

SPF and DKIM both check a domain. Neither of them checks the domain your reader actually sees. The address in the From line of the message, the one displayed in the mail client, is a completely separate field, and an attacker is free to put your domain there while passing SPF and DKIM for a domain they control. Both checks come back green and the message is a forgery.

Alignment is the rule that closes that gap. DMARC requires the domain that passed SPF or DKIM to match the domain in the visible From address. That single requirement is what turns two technically valid checks into a statement about the name your customer is reading, and it is why a domain with immaculate SPF and DKIM and no DMARC record is still wide open.

Why you need all three

None of them is enough alone, and they fail in different directions. SPF vouches for the server and breaks on forwarding. DKIM vouches for the message and survives forwarding but says nothing about what should happen if it fails. DMARC ties either of them to the address your reader sees and decides the outcome, but it has nothing to work with unless at least one of the other two is correct.

DMARC passes if either SPF or DKIM passes and is aligned, which means the two underneath it are not redundant. They are two independent chances for a legitimate message to prove itself, and having both is the difference between an enforcement policy that is safe to turn on and one that quietly deletes your own mail.

What none of them stop

Worth being clear about, because the gap is where the actual losses happen.

• •A look-alike domain. If somebody registers a name one character different from yours, it is their domain and your records have no authority over it.
• •Display name spoofing. The name shown beside an address is free text, so a message from a random address can display as your managing director. On a phone the address is often hidden entirely.
• •A compromised mailbox. If somebody has the password to a real account, their mail authenticates perfectly, because it genuinely is your mail.
• •Inbox placement. Passing authentication is a requirement for good delivery, not a guarantee of it. Reputation and content still decide the rest.

All four are reasons to have the three records rather than reasons not to bother. Enforcement removes the cheapest and most convincing version of the attack, which is the one that scales.

The order to do them in

Doing these in the wrong order is how a business ends up with an enforcement policy that blocks its own invoices.

• •Inventory what sends as you, including the systems nobody mentions
• •Fix SPF so it names all of them and stays under ten lookups
• •Enable DKIM so forwarded mail still has a way to pass
• •Publish DMARC at p=none with a reporting address
• •Read the reports for several weeks until every sender in them is one you recognise
• •Step to quarantine, watch, then step to reject

Steps one and five are where the time goes. Everything else is a DNS change that takes minutes.

Finding out where you stand

Reading about the three records is one thing and seeing your own is another. It takes seconds rather than an afternoon, and you do not need to log in to anything to do it.