Email Authentication: A Working Definition for People Who Have to Ship It

Email authentication is the set of DNS-published standards that let a receiving server decide whether a message genuinely came from the domain it claims to come from. In practice it means three records working together: SPF, which names the servers allowed to send for a domain; DKIM, which attaches a cryptographic signature that a receiver can verify; and DMARC, which ties both back to the address the reader actually sees and tells receivers what to do when neither lines up.

It is worth being precise about what that buys, because the word "authentication" invites a stronger reading than the standards support. These records establish that a domain took responsibility for a message. They say nothing about whether the message is honest, wanted, or well written.

The three records, and what each one is actually for

SPF (RFC 7208) is a published list. The domain owner writes a TXT record naming the IP addresses and services permitted to send mail using that domain in the SMTP envelope. A receiver compares the connecting server against the list. SPF authenticates the envelope sender, which is not the address shown in the mail client, and that gap is the single most common source of confusion in this area.

DKIM (RFC 6376) is a signature. The sending platform signs the body and named headers with a private key; the receiver fetches the matching public key from DNS and verifies. DKIM survives a change of sending IP, which SPF does not, and it breaks when a forwarder alters the message, which SPF does not.

DMARC (RFC 7489) is the policy layer that makes the other two mean something to a human reader. It requires that a passing SPF or DKIM result be aligned: the authenticated domain has to match the domain in the visible From: header. Then it publishes an instruction for the failure case, p=none, p=quarantine or p=reject, and an address to send reports to.

1. Step 1SPF checks the path

   Was this IP allowed to send for the envelope domain?

2. Step 2DKIM checks the signature

   Does the message verify against the key published by the signing domain?

3. Step 3DMARC checks alignment

   Does either passing result match the From: domain the reader sees?

4. Step 4Policy applies

   On failure the receiver follows the published policy: none, quarantine, or reject.

The order matters. Passing SPF and DKIM while failing alignment is a normal outcome for badly configured mail, and it produces exactly the situation people find baffling: two green checks and mail in the spam folder.

Alignment itself has two modes, and the default is the forgiving one. Relaxed alignment accepts a match at the organisational domain, so mail.example.com aligns with example.com. Strict alignment demands an exact match. Relaxed is the sensible default for most senders, because it lets a subdomain carry a distinct sending identity while still aligning to the parent, and it is the reason a subdomain strategy works at all. Choosing strict without understanding that distinction is a reliable way to start failing your own mail.

There is also a layer above these three, and it is worth naming so you can rule it out. ARC exists to preserve an authentication verdict across an intermediary that would otherwise break it, and BIMI exists to display a brand logo in the inbox once DMARC is enforced. Neither is part of the floor. If your basic records are wrong, nothing above them helps, and both are answers to problems you only have after SPF, DKIM and DMARC are correct and stable.

Where the textbook definition misleads

Authentication is a floor, not an advantage. Google's sender guidelines require SPF or DKIM for all senders to Gmail, and SPF and DKIM plus DMARC for anyone sending more than 5,000 messages a day. Meeting the requirement means you are eligible to be judged on your reputation. Nobody gets inbox placement for having correct DNS.

The records do not verify the person or the claim. A message can pass all three checks and be a scam, because the domain sending it may be one the scammer registered that morning. Authentication proves a domain is accountable. It is reputation, not authentication, that decides whether accountability is worth anything.

SPF has a hard limit that quietly breaks multi-vendor setups. The specification caps the number of DNS lookups a receiver will perform while evaluating a record. Chain enough include: statements for a CRM, an outbound platform, a helpdesk and a newsletter tool and the record stops evaluating, which is scored as a failure rather than as a configuration error. The SPF record guide covers that limit in detail; the important thing here is that the failure is silent and grows over time as tools are added.

A p=none DMARC record is a monitoring position, not protection. It is the correct place to start, because it turns on reporting without risking legitimate mail, and it is a bad place to stay. Many organisations publish p=none, read no reports, and describe themselves as DMARC-compliant. The quarantine versus reject decision is where the record starts doing work.

Forwarding breaks authentication routinely, and it is not an attack. Mailing lists that append footers invalidate DKIM signatures, and redirection changes the connecting IP so SPF fails. A steady trickle of failures from forwarding sources in your reports is normal. Treating that trickle as evidence of spoofing wastes a great deal of time.

SPFPath-based

• Authenticates the envelope sender domain
• Checks the connecting IP against a published list
• Broken by forwarding and by too many DNS lookups
• Invisible to the reader

DKIMSignature-based

• Authenticates the signing domain in d=
• Survives a change of sending IP
• Broken by any relay that alters signed content
• Also invisible to the reader

DMARCPolicy and alignment

• Ties a passing result to the visible From: domain
• Publishes what receivers should do on failure
• Produces the aggregate reports that show every source
• The only one of the three the reader can be protected by

What this means when you are running outbound

For a programme sending from many domains, authentication stops being a setup task and becomes an inventory property. Every domain needs its own three records, every new platform needs its own DKIM selector, and every record needs verifying at the published DNS rather than inside the tool that claimed to write it. A sending tool showing a green tick is reporting on its own configuration, not on what the world can resolve.

The verification that pays for itself is reading DMARC aggregate reports for a fortnight after any change. They are the only surface that lists every source sending as your domain, including the ones nobody remembers configuring, with pass and fail counts per source. Reading a DMARC report without special tooling is straightforward, and it routinely turns up a legacy sender quietly failing authentication and dragging on the domain.

There is a scale effect worth planning for. Authentication is cheap to set up once and expensive to keep correct across an inventory that keeps changing, because every change is a chance to introduce a record that resolves but does not align. Domains get added, a platform gets swapped, a DNS provider migration rewrites TXT records in a way that drops a quoted segment. None of those produce an error anybody sees. They produce a domain that authenticates slightly worse than it did last month, and the first symptom is placement drift that gets blamed on copy.

The defence is a standing check rather than a one-off audit: resolve every sending domain's three records on a schedule, from outside your own network, and compare the result against what you believe you published. That check is a few DNS queries per domain, and it is the only way an inventory-wide misconfiguration surfaces before the campaign does.

The second habit is to authenticate before the first send rather than after the first problem. A new domain with no records is asking receivers to build a reputation for an identity they cannot verify, which is the slowest possible way to warm a domain. Records first, then volume.

An authentication check that actually proves something

• ✓Yes: An SPF record resolves and stays inside the DNS lookup limit
• ✓Yes: A DKIM key resolves whole at the selector and verifies in a test message
• ✓Yes: A DMARC record exists with a reporting address that someone reads
• ✓Yes: The authenticated domain matches the visible From: domain
• ✓Yes: Aggregate reports have been read at least once since the last change
• ✕No: Calling a p=none record with unread reports a finished job

The short version

A last distinction that saves arguments: authentication is a property of the domain, not of the mailbox or the campaign. Every mailbox on a sending domain shares the same records and the same verdict, so authentication cannot isolate one campaign from another. If two campaigns need to be insulated from each other, that separation is built into the domain inventory, and correct records on a shared domain will not provide it.

Email authentication answers one narrow question: may this domain be held responsible for this message? SPF answers it for the delivery path, DKIM answers it with a signature, and DMARC insists the answer refers to the sender the human being can see. Everything else people hope it will fix, placement, engagement, whether a stranger wants the message at all, sits downstream of it.

Get the three records right once per domain, verify them from the outside, and read the reports. Then spend the remaining attention on the things that actually move placement: list quality, sending volume that matches the domain's history, and messages worth receiving. If placement is still poor with clean authentication, a deliverability audit is a better use of an afternoon than another pass at DNS, and the complete setup guide covers the records in order if you are building from scratch.

RevenueFlow runs cold email and LinkedIn outreach for B2B teams on infrastructure we authenticate and monitor ourselves, one message per campaign. If you would rather that layer were somebody else's job, see how the campaigns work.

Standards and platform requirements verified as of August 2026 against RFC 7208, RFC 6376, RFC 7489 and Google's published sender guidelines. Verify current requirements with the source before relying on them.