SPF, DKIM and DMARC: Configuring Email Authentication Properly

Three DNS records govern whether a receiving mail server believes a message came from your domain. They do different things, they are frequently deployed partially, and a partial deployment provides much less protection than the presence of the records suggests.

SPF

A TXT record listing which servers may send mail for your domain. A receiver checks the connecting server's address against it and gets a pass, fail or softfail.

Two limitations matter. It authorises servers, not messages, so anyone able to send through an authorised server passes — which includes other customers of a shared mail platform if the record is written too broadly.

And it checks the envelope sender, not the address the recipient sees. A message can pass SPF while displaying an entirely different From address, which is why SPF alone stops very little of what people expect it to.

The practical constraint is the ten-DNS-lookup limit. Each include mechanism counts, and organizations using several mail and marketing services routinely exceed it, at which point the record fails to evaluate and passes nothing. Flattening the record or reducing the number of services is the fix, and it needs checking rather than assuming.

DKIM

A cryptographic signature over selected headers and the body, added by the sending server. The public key is published in DNS under a selector, and the receiver verifies the signature.

Because it signs the message rather than authorising a server, it survives forwarding — which SPF does not, since a forwarding server is not in the original domain's SPF record. That is the practical reason both exist.

Selectors allow key rotation: publish a new selector, switch signing to it, then remove the old one after messages in flight have been delivered. The mechanics are those under DKIM, with the overlap handling described under key rotation.

DMARC and alignment

The record that ties the other two to the address users actually see, and the reason the set works.

DMARC requires alignment: the domain in the visible From header must match the domain that passed SPF or DKIM. A message passes DMARC if at least one of the two passes and aligns.

That closes the gap. Without alignment, an attacker sends from their own domain with a valid SPF record while displaying your domain in the From field, and both checks pass while the recipient is deceived. Alignment is the mechanism that makes SPF and DKIM protect the thing the user reads.

The policy tells receivers what to do with failures: none monitors and takes no action, quarantine sends to junk, and reject refuses delivery. Alignment can be strict (exact domain match) or relaxed (organisational domain match), with relaxed being the usual choice because subdomains are common.

The step organizations do not take

A DMARC policy of none blocks nothing. It generates reports, which is a necessary first step and frequently the last one taken, and while the policy stays at none, direct spoofing of your domain works exactly as it did before.

The migration is straightforward and requires attention rather than difficulty. Publish with a policy of none and collect aggregate reports for a few weeks. The reports identify every source sending as your domain — and they always reveal services nobody remembered: a marketing platform, a ticketing system, a scanner emailing documents, an application sending notifications.

Bring each legitimate source into alignment by adding it to SPF and enabling DKIM signing for it. Then move to quarantine with a percentage applied to a fraction of mail, increase it, and finally move to reject.

The fear of blocking legitimate mail is why organizations stall, and the reports exist precisely to remove that uncertainty. Stalling at none is choosing not to have the control.

What it does and does not stop

An enforcing DMARC policy stops direct spoofing of your domain — the exact-domain forgery. It does nothing about lookalike domains, which are a different domain entirely and pass their own checks, and nothing about display-name spoofing where the attacker's real address is simply hidden by the client.

Those need the monitoring and user-facing controls discussed under brand impersonation, along with external sender banners. Newer standards add authenticated logos and stricter policy signalling, and they build on DMARC rather than replacing it.

Verify the records with DNS queries rather than trusting the console, using the approach under DNS troubleshooting — a record that looks right in a vendor interface and does not resolve is a common and invisible failure.

Exam angles

Know SPF as authorising sending servers by address with a ten-lookup limit, DKIM as cryptographically signing the message so it survives forwarding, and DMARC as requiring alignment between the visible From domain and the domain that passed SPF or DKIM. Know the policies none, quarantine and reject, that only enforcing policies block anything, and that aggregate reports are how legitimate senders are identified before enforcement. Recognize that DMARC does not address lookalike domains or display-name spoofing.