Guide

SPF, DKIM and DMARC explained: how the three work together

By Adam Sierant, Director of Northstar Infinity Works Ltd · Updated 10 September 2026 · 5 min read

The problem all three solve

Email was designed without a check on who the sender is. Every message carries two sender addresses: the envelope address that mail servers use to deliver it and to return bounces, and the From address shown to the reader. The basic protocol requires neither to be genuine, and the two do not have to match.^[1] SPF, DKIM and DMARC are the standards that add the missing checks, each covering a different part of the problem.

SPF: which servers may send

Sender Policy Framework is a TXT record that lists the servers and services allowed to send mail for a domain. A receiving server takes the domain from the envelope address, looks up its SPF record, and checks whether the server delivering the message is on the list.^[2]

samplefirm.example  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.billing.example -all"

The ending matters. -all states that any server not listed is not authorised, which gives a fail; ~all is a weaker statement that such a server is probably not authorised, which gives a softfail.^[2] The two include entries in the example hand part of the decision to Microsoft 365 and to a billing service.

Where SPF falls short

• It checks the envelope address, not the From address the reader sees, so a message can pass SPF for a criminal’s own domain while displaying yours.^[1]
• It breaks when a message is forwarded, because the forwarding server is not on the original domain’s list.^[1]
• Evaluation may use no more than 10 DNS-querying terms, such as include, a and mx. A record that needs more returns a permanent error instead of a pass, which is easy to cause by adding one more service.^[2]
• Subdomains do not inherit the record; each subdomain that sends mail needs its own.^[1]

DKIM: a signature on each message

DomainKeys Identified Mail adds a digital signature to the message header. The sending system signs with a private key, and the receiver checks the signature with the public key published in the signing domain’s DNS.^[3] If the signed parts of the message were altered on the way, the check fails.

Because the signature travels inside the message, it is not affected when a message is forwarded without being changed, so DKIM can pass where SPF fails.^[1] In Microsoft 365 the public keys sit behind two CNAME records called selectors: one in use, and one kept for the next key rotation.^[3]

Where DKIM falls short

A valid signature proves only that some domain signed the message. The signing domain does not have to be the one in the From line, so a criminal can sign with a domain they control.^[1] Microsoft 365 also signs mail from a custom domain with the tenant’s onmicrosoft.com domain until signing with the firm’s own domain is switched on, and that signature does not align with the firm’s From address.^[3]

DMARC: alignment and a policy

DMARC ties the two together. It takes the results of SPF and DKIM and asks one further question: does the domain that passed match the domain in the From line? A message passes DMARC when SPF or DKIM passes for a domain aligned with the From domain.^[4] Alignment is relaxed by default, so mail from bounces.samplefirm.example aligns with samplefirm.example; strict alignment requires an exact match.^[5]

The DMARC record then states the policy for mail that fails, which is none, quarantine or reject, and where receivers should send aggregate reports.^[4] Those reports are often the only view a firm has of every server sending email in its name, including the ones nobody remembered to mention.

How the three fit together

Microsoft describes the three standards as interdependent building blocks that work together, and warns that anything less than all of them gives substandard protection.^[1]

What usually goes wrong in a law firm

• A third-party service, such as case management, e-billing or a newsletter tool, sends as the firm but uses its own envelope domain and signs with its own DKIM domain. SPF and DKIM both pass for the service, and DMARC still fails, because neither domain aligns with the firm’s.^[5]
• DKIM in Microsoft 365 was never switched on for the firm’s own domain, so the firm’s mail relies on SPF alone and fails DMARC as soon as it is forwarded.^[3][1]
• The SPF record grows past 10 DNS lookups as services are added, and quietly turns into a permanent error.^[2]
• The DMARC record is published at none, with reports going to a mailbox that nobody reads.

None of these is unusual, and each is fixed with settings your IT provider already controls. The work is in finding them, testing each fix and recording what changed. Our guide to why legitimate email fails DMARC goes through the common causes one by one.

Questions to ask your IT provider

• Which services send email as the firm today, and which of them are in the SPF record?
• Is DKIM signing switched on with our own domain, and not only with the onmicrosoft.com domain?
• How many DNS lookups does our SPF record need, and how close is it to the limit?
• Where do our DMARC reports go, who reads them, and what did the last ones show?

If the answers are unclear, that is normal rather than a criticism of anyone. In most firms nobody has been asked to own email authentication, and the records were set up by different people at different times, often for services the firm no longer uses.

Checking your own domain

You can check which records your domain publishes in a few seconds; the check reads public DNS only and does not touch your mail. If your firm turns out to be part of the way there, a 20-minute scope call with you and your IT provider is usually enough to see what finishing the job involves.