Most senders treat email authentication as a task they completed once: three DNS records, published years ago, never revisited. That framing is why so many teams with technically valid SPF and DKIM still land in spam. Authentication is not a compliance checkbox — it is the foundation of a layered trust stack that mailbox providers evaluate on every message, and the layers above the basics are where the remaining advantage sits.
This guide covers that whole stack: the identity layer everyone knows, the continuity layer that survives forwarding, the transport layer almost nobody deploys, the visible layer your recipients actually see, and the unglamorous non-protocol signals that quietly shape how you are judged. It also covers what the new DMARC standard changed in 2026, and which of your existing records are now obsolete.
It is worth being precise about what authentication does and does not achieve, because overstating it leads to the wrong investment.
Authentication proves identity. It establishes that a message genuinely originated from the domain it claims, which means a provider can attach a reputation to you at all. Without it, you are an anonymous sender and are treated with the suspicion anonymity deserves.
What authentication does not do is make you trusted. A perfectly authenticated sender with a 0.4% complaint rate will still be filtered — providers now know exactly who is generating the complaints. Authentication is necessary and insufficient, and any vendor implying otherwise is selling something.
That said, the requirement is now hard. Google, Yahoo, Microsoft and Apple all require SPF, DKIM and DMARC from bulk senders, and enforcement moved from temporary deferrals to permanent SMTP rejections in late 2025. Failing authentication is no longer a placement penalty; it is a delivery failure.
It helps to think of the protocols as four layers, each answering a different question a receiving server asks.
The layers are cumulative in a strict sense: each one requires the ones below it to be in place. BIMI is impossible without DMARC at enforcement, and DMARC is meaningless without SPF and DKIM. Build in order.
These three are covered thoroughly elsewhere, so this section focuses on the parts senders get wrong rather than the basics.
SPF is a DNS TXT record listing servers permitted to send for your domain. Its notorious failure mode is the ten-DNS-lookup limit: each include: for a third-party tool consumes lookups, and once you exceed ten, the record returns a permanent error and every message fails SPF. Not some — every one.
This breaks silently, usually months after someone added a new tool. Audit the record whenever you connect a sending service, and flatten it if you are near the ceiling.
DKIM signs the message with a private key held by your platform, verified against a public key in your DNS. Use 2048-bit keys and rotate them periodically. DKIM is the more durable of the two protocols because, unlike SPF, it survives forwarding — which is why alignment via DKIM is generally more robust than via SPF.
Passing SPF or DKIM is not enough. The authenticated domain must align with the domain in your visible From header. A message can pass SPF for your platform's own domain and still fail DMARC, because that domain is not yours.
This is the single most common misconfiguration in the identity layer, and it is invisible unless you look for it specifically. Check a test message's headers for the DMARC result, not just the SPF and DKIM lines.
In 2026 the IETF published DMARCbis as RFC 9989 and its companion documents, replacing RFC 7489 and elevating DMARC from an informational document to a Proposed Standard. The practical consequence for senders is that several tags in existing records are now deprecated.
| Tag | Status in RFC 9989 | What you should do |
| p | Unchanged — none, quarantine or reject | Keep it. This is still the core policy declaration. |
| sp | Retained, but now applies only when np is absent | Review it if you publish one; the precedence order changed. |
| np | New — policy for non-existent subdomains | Add np=reject. Subdomains with no DNS records are a common spoofing vector. |
| psd | New — declares a DMARC boundary directly in DNS | Relevant mainly to public-suffix operators, not ordinary senders. |
| t | New — testing mode; t=y is the equivalent of the old pct=0 | Use during rollout instead of the deprecated pct tag. |
| pct | Deprecated | Remove it. Partial-percentage rollout is no longer part of the standard. |
| rf | Deprecated — report format | Remove it. It was effectively never used. |
| ri | Deprecated — reporting interval | Remove it. Receivers set their own reporting cadence. |
| rua / ruf | Retained | Keep rua pointing at a mailbox or parser you actually read. |
Two changes deserve action. First, if your record still carries pct=, remove it — partial-percentage rollout is gone, and t=y is the replacement for testing. Second, add np=reject. Attackers routinely spoof subdomains that have no DNS records at all, and until now there was no clean way to declare a policy for them.
SPF breaks when a message is forwarded, because the forwarding server is not in your SPF record. DKIM breaks when an intermediary modifies the message, which mailing lists routinely do by appending footers or rewriting subject lines. The result is a legitimate message failing authentication through no fault of the original sender.
ARC (Authenticated Received Chain), defined in RFC 8617, solves this by letting each intermediary record the authentication results it observed and cryptographically seal that record. It adds three headers: ARC-Authentication-Results captures what passed at that hop, ARC-Message-Signature signs the message as that handler saw it, and ARC-Seal binds the chain together so a receiver can tell whether it remained intact.
A receiving server validates the chain in sequence and can then choose to honour the original authentication result even though SPF now fails — provided it trusts the intermediaries in the chain.
The important thing for a marketer to understand is that you do not implement ARC. It is applied by forwarding services and list managers. What you control is choosing a sending platform and internal forwarding setup that participate correctly, and Google and Apple both expect ARC on forwarded mail. If your mail is frequently forwarded — common in B2B — this layer matters more than its obscurity suggests.
Identity protocols verify who sent a message. Transport protocols verify that the connection carrying it was encrypted and that the receiving server was who it claimed to be. Opportunistic TLS — the default — is trivially downgraded by an attacker in the middle.
| MTA-STS | DANE | TLS-RPT | |
| What it does | Tells sending servers to require valid TLS when delivering to your domain | Pins your mail server's TLS certificate in DNS | Sends you reports when TLS delivery fails |
| Defined in | RFC 8461 | RFC 7672 | RFC 8460 |
| What it needs | A DNS TXT record plus an HTTPS-hosted policy file | A DNSSEC-signed zone and TLSA records | A single DNS TXT record |
| Modes | none, testing, enforce | No modes — pinning is absolute | Reporting only |
| Difficulty | Moderate — the HTTPS file is the fiddly part | High — DNSSEC is a prerequisite | Low — a few minutes |
| Adoption (2026) | Roughly 0.3% of surveyed domains | Effectively 0% of surveyed domains | Usually deployed alongside MTA-STS |
| Worth it for you? | Yes if you receive sensitive mail; a differentiator, not a requirement | Only with existing DNSSEC expertise | Yes — start here, it is nearly free |
The honest assessment is that this layer is optional for most senders. Adoption is remarkably low: roughly 0.3% of surveyed domains publish MTA-STS, and DANE is statistically almost nonexistent outside a few technically sophisticated regions. No mailbox provider requires either from bulk senders.
Two qualifications, though. TLS-RPT is nearly free — one DNS TXT record, and you start receiving reports on TLS delivery failures you would otherwise never learn about. There is no reason not to publish it. And if you operate in a regulated sector, or handle mail where interception is a real threat, MTA-STS in enforce mode is a meaningful control rather than a vanity record. Deploy it in testing mode first; enforce mode with a misconfigured policy file blocks your own inbound mail.
Every layer so far is invisible to recipients. BIMI (Brand Indicators for Message Identification) is the exception: it displays your verified logo beside your messages in the inbox, before the recipient opens anything.
The prerequisites are strict, which is the point — BIMI is designed as a reward for enforcement, not a decoration. You need DMARC at p=quarantine or p=reject, a logo in SVG Tiny PS format that is square and simple, a BIMI DNS record, and a certificate.
| VMC (Verified Mark Certificate) | CMC (Common Mark Certificate) | |
| Proof required | A registered trademark for the logo | Evidence the logo has been publicly displayed on your domain for at least 12 months |
| Introduced | The original BIMI certificate type | Added by Google in early 2025 to widen eligibility |
| Provider support | Broadly supported — Gmail, Yahoo and Apple Mail | Active at Gmail; support elsewhere is still emerging |
| Blue checkmark in Gmail | Yes | No — the logo displays without the verified checkmark |
| Best for | Established brands that already hold a trademark | Brands with a consistent logo but no trademark registration |
| Prerequisite | DMARC at p=quarantine or p=reject, and an SVG Tiny PS logo | Identical prerequisites |
The CMC is the significant recent development. Requiring a registered trademark excluded a large number of legitimate brands from BIMI entirely; the Common Mark Certificate, which Google introduced in early 2025, substitutes evidence of at least twelve months of public logo use on your own domain. The trade-off is that CMC logos display without Gmail's blue verified checkmark.
Is it worth it? The certificate carries a real annual cost and the DMARC enforcement prerequisite is weeks of work. But the enforcement is worth doing on its own merits, and the logo demonstrably lifts recognition in a crowded inbox. Treat BIMI as the reason to finish your DMARC rollout rather than as a project in itself.
Alongside the DNS records, providers weigh a set of unglamorous signals that no certificate covers. These cost nothing and are frequently neglected.
None of these will get you into the inbox by themselves. Any one of them missing can keep you out.
Almost every authentication failure in a mature organisation has the same root cause, and it is not technical. Somebody in a department signed up for a tool — a webinar platform, a survey service, a recruiting system, an invoicing product — and configured it to send from the company domain without telling anyone who maintains DNS.
The result is a sending estate nobody has an inventory of. Each unauthorised source fails DMARC, drags down your authentication pass rate, and blocks any move to enforcement, because turning on p=reject would break systems the DNS owner has never heard of.
This is exactly what DMARC aggregate reports are for, and it is the reason step two of the rollout below is measured in weeks rather than hours. Your reports will name every IP and every service sending under your domain. Expect surprises: most organisations running reports for the first time discover between three and ten sources they cannot immediately account for.
The fix is a process rather than a record. Assign one owner for the sending estate, require that new tools sending under the company domain are registered with that owner before launch, and review the aggregate reports monthly rather than only during an incident. Without that, you will complete the technical work once and quietly regress within a year.
The same discipline argues for subdomain delegation. Rather than adding every vendor to your root domain's SPF record — which is how you reach the ten-lookup ceiling — give each significant sender its own subdomain. mail.yourbrand.com for transactional, news.yourbrand.com for marketing, careers.yourbrand.com for recruiting. Each carries its own records, its own reputation, and its own blast radius when something goes wrong.
Sequence matters, because each layer depends on the one below and because the return on effort drops steeply after the first stage.
Publishing a record is not the same as it working. Verify rather than assume.
Email authentication has moved from good practice to infrastructure. DMARC is now a Proposed Standard, enforcement at the major providers is permanent rather than advisory, and the records you published three years ago may contain tags the current specification has deprecated.
The good news is that the work is finite and mostly front-loaded. Get the identity layer right and verify alignment, read your reports for a month, fix the free signals, and push DMARC to enforcement. That covers the requirements and most of the benefit. The layers above — transport security and BIMI — are genuine differentiators precisely because so few senders have bothered, and by the time you reach them the hard part is already done.
Q1. What is email authentication?
Email authentication is a set of DNS-based protocols that let a receiving mail server verify that a message genuinely came from the domain it claims. SPF authorises sending servers, DKIM cryptographically signs the message, and DMARC ties both to the visible From domain and tells receivers what to do when verification fails.
Q2. What DMARC policy should I use?
Start at p=none to collect reports without affecting delivery, move to p=quarantine once your aggregate reports show every legitimate source passing, and finish at p=reject. Reject is the only policy that actually stops exact-domain spoofing, and it is a prerequisite for BIMI. Do not skip the monitoring stage.
Q3. What is DMARC alignment and why does it matter?
Alignment means the domain that passed SPF or DKIM matches the domain your recipient sees in the From line. A message can pass SPF for your sending platform's domain and still fail DMARC because that domain does not align with yours. Alignment is where most misconfigurations hide.
Q4. What changed in the new DMARC standard, RFC 9989?
DMARCbis was published in 2026 as RFC 9989 and companions, replacing RFC 7489 and elevating DMARC from an informational document to a Proposed Standard. It deprecates the pct, rf and ri tags, introduces np for non-existent subdomains, psd for declaring DMARC boundaries in DNS, and t for testing mode.
Q5. Do I need ARC?
You do not publish ARC yourself as an ordinary sender — it is applied by intermediaries such as mailing lists and forwarding services. What matters is choosing a sending platform and forwarding setup that participate in ARC correctly, because ARC is what preserves your authentication results when a message is forwarded.
Q6. What is the difference between a VMC and a CMC for BIMI?
A VMC requires a registered trademark and earns a blue verified checkmark in Gmail. A CMC, introduced by Google in early 2025, requires only evidence that your logo has been publicly displayed on your domain for at least twelve months, and displays the logo without the checkmark. Both require DMARC at quarantine or reject.
Q7. Is MTA-STS worth implementing?
For most senders it is a differentiator rather than a requirement. Adoption sits at roughly 0.3% of surveyed domains, so it is not something providers expect. It is genuinely valuable if you receive sensitive mail and want to guarantee encrypted delivery. TLS-RPT, by contrast, takes minutes and is worth doing regardless.
Q8. Does authentication alone get me into the inbox?
No. Authentication is the entry ticket, not the destination. It establishes that you are who you claim to be, which allows a provider to attach a reputation to you at all. What that reputation looks like still depends on complaints, engagement and list quality.
Every provider requirement, threshold and date in this article was verified against the sources below. Re-check them before publication if more than a quarter has passed, since mailbox provider rules continue to change.
 |
