SPF, DKIM and DMARC: how email authentication actually works

The problem in one sentence

By default, the email protocol lets anyone claim to be anyone. SPF, DKIM and DMARC are three separate mechanisms that together give a receiving mail server enough information to decide whether a message claiming to be from your domain is plausible.

They are not interchangeable, and implementing one without the others is a common way to feel protected without being protected.

SPF: which hosts may send

SPF is a TXT record at the domain apex that lists the hosts authorised to send mail for that domain. A receiving server checks the connecting IP against that list.

The important detail is the qualifier at the end. v=spf1 include:_spf.example.net -all means "reject anything not listed". A trailing ~all means "mark it suspicious but accept it", which is a soft policy that many receivers treat generously. No all mechanism at all means the record expresses no opinion.

SPF also has operational limits. It breaks when mail is forwarded, because the forwarding server is not in your list. It breaks at scale: RFC 7208 caps DNS-querying mechanisms at ten, and exceeding that produces a permerror, which is worse than a simple strict record. Publishing two SPF records is also a permerror, not a merge.

This is why the assessment checks SPF validity as a separate control from SPF strength. A weak-but-valid record and an invalid record fail differently in production.

DKIM: a signature on the message

DKIM signs selected headers and the body with a private key held by the sending system. The public key is published at a selector under _domainkey in DNS, and the receiver verifies the signature.

Because the signature travels with the message, DKIM survives forwarding in many cases where SPF does not. Key length matters: 1024-bit RSA keys are still seen, 2048-bit is the sensible baseline, and shorter keys should be rotated out.

A practical caveat: DKIM is only useful if you know your selectors. Selector names are not discoverable by design, so an external assessment can only check the selectors it is told about or can reasonably guess. That limitation is stated rather than hidden.

DMARC: what to do when authentication fails

DMARC is the policy layer. It is published at _dmarc.yourdomain.com and tells receivers what to do when a message fails SPF and DKIM alignment: nothing (p=none), quarantine it (p=quarantine), or reject it (p=reject).

It also introduces alignment, which is the subtle part. SPF can pass for a domain that is not the one in the From header. DMARC asks whether an authenticated identifier aligns with the visible From domain. adkim=s and aspf=s require strict alignment; relaxed mode allows organisational-domain matching.

sp= sets the policy for subdomains, and it is routinely forgotten. A domain with p=reject and no sp= inherits the reject policy for subdomains, which can break legitimate mail from a subdomain you forgot about. Publishing sp=reject deliberately is the safer, more explicit choice for domains that do not send from subdomains.

Reporting addresses (rua=) are how you find out what you are breaking. Turn reporting on before you turn enforcement on.

The order to fix it in

First, inventory every system that sends mail as your domain — including the website, the CRM, the invoicing tool and the printer that nobody admits to. Second, configure SPF and DKIM for each. Third, publish DMARC at p=none with reporting enabled and watch the reports for a few weeks. Fourth, move to quarantine, then to reject.

A useful sign you are ready for enforcement: your reports show aligned SPF or DKIM passes for all legitimate traffic, and the failures are things you can name.

How to check it yourself

Query the records directly: dig TXT yourdomain.com, dig TXT _dmarc.yourdomain.com, and dig TXT selector._domainkey.yourdomain.com. Read the qualifiers and the policy values rather than trusting a green tick from a third-party checker.

SMB Scanner Lite evaluates SPF strength, SPF validity, DMARC enforcement, DKIM presence and MX posture as five separate controls. The recorded assessment shows the evidence strings for the ones it covered, and the catalog documents the rest.