Email authentication: proving the message is yours
Nothing in the original mail protocol stops a server from claiming any From address it likes. Authentication is the layer added afterwards to close that gap, and it is three separate records doing three different jobs rather than one setting to switch on. This category covers each of them at the level of the actual DNS entry: the syntax, the mistakes that silently break it, and the way receivers combine the three verdicts into a single decision.
Three checks, one verdict
SPF authorises the sending server for a domain. DKIM signs the message so the receiver can confirm it was not altered and that the signing domain vouches for it. DMARC is the policy on top: it asks whether either of the first two passed and matched the domain the reader actually sees, then tells the receiver what to do when neither did.
Alignment is the part that catches people out. A message can carry a valid SPF pass and a valid DKIM signature and still fail DMARC, because both were checked against a domain that is not the one in the visible From header. That single mechanism explains most of the confused reports from senders whose records all look correct in isolation.
The three records
Who may send
One TXT record listing your senders. Its hard limit is the number of DNS lookups it may cost to evaluate, which is what breaks records that keep adding vendors.
SPF syntax and common mistakes
When flattening is the wrong fix
Who signed it
A key pair, a selector per sending service, and a signature added at send time. Several platforms can sign for the same domain at once if each gets its own selector.
What to do on failure
A policy of none, quarantine or reject, plus the reporting address that returns the aggregate data you need before tightening it.
What sits on top
Two later additions build on a passing DMARC rather than replacing it. ARC preserves the original verdicts when a message is forwarded or passes through a mailing list, which is the case where legitimate mail fails through no fault of the sender. BIMI displays a brand logo in supporting clients, and it is the one visible reward for an enforced policy rather than a delivery mechanism in itself.
On the receiving side, every one of these checks is written into a single header the receiver adds. Reading it is the fastest way to find out what actually happened to a message: the guide to parsing Authentication-Results covers the syntax verdict by verdict.
Checking a live domain
Records are easy to write and easy to get subtly wrong, and the failure is silent. Query the published zone rather than the copy in your notes: the SPF record checker, the DKIM record checker and the DMARC record checker each read what a receiver would read. For a domain that is starting from nothing, the DMARC record generator produces a monitoring policy that is safe to publish on day one.
Platform-specific setup differs in the interface rather than the principle; the SendGrid domain authentication walkthrough is the worked example on this site. The standards themselves, including which document supersedes which, are catalogued in the RFC library, and the requirements that now depend on all three records are set out in the compliance guides.
