The Modern Email Trust Stack

At a glance

SPF — “Is this server allowed to send for this domain?”

SPF publishes the list of servers authorized to send mail on your domain’s behalf. A receiving server checks the sending IP against that list and returns a result — pass, fail, softfail, neutral.

It’s the first line of defense against basic spoofing, but it has real limits: it says nothing about message content, it commonly breaks when mail is forwarded (the forwarding server isn’t on your authorized list), and DNS lookups are capped at 10 — easy to blow through once you’re stacking several ESPs and internal tools.

DKIM — “Was this message altered after it was sent?”

DKIM signs outgoing mail with a private key; the matching public key lives in DNS. The receiving server validates the signature against the message body and headers. It protects message integrity — tampering, header or body modification in transit — but it doesn’t verify sender identity on its own, and a validly signed message can still come from an unauthorized sender.

DMARC — “If authentication fails, what should happen to the message?”

DMARC is the policy layer sitting on top of SPF and DKIM. It requires that at least one of them pass and align with the visible From: domain, then tells receivers what to do about failures:

• p=none — monitor only, no enforcement
• p=quarantine — send failures to spam
• p=reject — refuse the message outright

DMARC also gives you aggregate (RUA) and forensic (RUF) reports — the main window most teams have into who’s sending mail as their domain, legitimately or not. The standard rollout order is none → quarantine → reject, and skipping the monitoring period is how well-meaning teams accidentally block their own transactional mail.

Where this became mandatory: bulk sender requirements

Since February 2024, Gmail and Yahoo have required anyone sending more than 5,000 messages a day to have SPF, DKIM, and DMARC all in place, keep spam-complaint rates under 0.3% (ideally under 0.1%), and support one-click unsubscribe. Microsoft and Apple Mail have been moving in the same direction. This is the reason most teams end up caring about this stack at all — it stopped being best practice and became a hard floor for inbox placement, transactional email included. Gmail has kept tightening enforcement since the original rollout; as of late 2025, non-compliant bulk mail isn’t just foldered as spam anymore — it can be temporarily or permanently rejected outright.

“One-click unsubscribe” is a specific technical mechanism, not just a footer link. RFC 8058 defines a pair of headers — List-Unsubscribe and List-Unsubscribe-Post — that let a mailbox provider unsubscribe someone with a single click and no login page or confirmation screen in between:

A visible unsubscribe link in the email body is still good practice for the recipient, but it’s the header pair above that mailbox providers actually check for compliance.

APRF — “How did my mail actually perform?”

This is the newest piece of the stack, and worth a closer look since most cheat sheets don’t cover it yet. It isn’t the first attempt at sender-facing feedback, though — ARF (Abuse Reporting Format, RFC 5965) has let mailbox providers send individual spam-complaint reports back to senders via feedback loops (FBLs) for close to two decades. What APRF adds isn’t complaint data, which already existed — it’s aggregate inbox-placement and engagement data, which didn’t.

Aggregate Performance Reporting (the IETF draft’s formal title — you’ll see it referred to informally as APRF, “Aggregate Performance Reporting Format,” in industry writeups) is an individual Internet-Draft published in March 2026 by Alex Brotman (Comcast), Tom Corbett (Iterable), and Emil Gustafsson (Google). It hasn’t been adopted by an IETF working group yet, so treat it as directional rather than settled — but the fact that it’s co-authored by a major mailbox provider, an ESP, and Google is a meaningful signal, and Comcast is already running beta code against comcast.net in production.

Where DMARC reports on authentication — did SPF/DKIM pass and align — APRF reports on outcome: did the message actually reach the inbox, and how did recipients engage with it. That’s a gap every sender currently fills with a patchwork of Gmail Postmaster Tools, Microsoft SNDS, seed lists, and vendor-specific dashboards, none of which talk to each other.

Mechanically, it borrows DMARC’s playbook — discovery via a DNS TXT record, aggregate reports mailed back to you — but keys off your DKIM signature rather than sending IP:

Reports arrive daily as JSON (optionally gzipped) over SMTP, bucketed by inbox-vs-spam placement and engagement signals rather than precise counts. An optional feature called SDI (Signer-Defined Identifier) lets you segment those reports by a custom header — a campaign ID, say — up to four levels deep, though the draft itself flags that over-specific segment names can leak sensitive information back through the report.

If it gains real adoption, standardized inbox-placement feedback could end up being as significant for deliverability analytics as DMARC became for authentication.

ARC — “This message was forwarded — can you still trust it?”

Forwarding is where SPF quietly breaks: the forwarding server isn’t your authorized sender, so a forwarded message can fail SPF even though the original was completely legitimate. ARC lets intermediate systems (mailing lists, Google Groups, Microsoft 365 forwarding rules) attach a record of the original authentication results, so the final receiving server can make a trust decision based on what actually happened at the source rather than what happened at the last hop.

BIMI — “Can I show my logo in the inbox?”

BIMI displays a verified brand logo next to your message in supporting inboxes, conditioned on a strong DMARC policy (usually quarantine or reject) and an SVG logo — and, depending on the mailbox provider, a Verified Mark Certificate (VMC). It’s the most visible standard on this list and the least about security; it’s a brand-trust signal that only works because everything upstream of it (DMARC, DKIM, SPF) is already solid.

A VMC requires a registered trademark, which locks a lot of smaller brands out. As of 2026, Gmail also accepts a cheaper alternative: a Common Mark Certificate (CMC), which trades the trademark requirement for proof the logo has been in public use for at least 12 months. Yahoo, Apple Mail, and Outlook still require the full VMC, so which certificate you need depends on where your recipients actually read mail.

MTA-STS & TLS-RPT — “Is the connection itself secure?”

These two are transport-layer, not identity-layer, and easy to overlook because they don’t affect whether a message gets authenticated — only whether it gets delivered securely.

• MTA-STS requires SMTP connections to use validated TLS, closing the door on downgrade attacks where opportunistic TLS quietly falls back to plaintext.
• TLS-RPT reports back on transport failures — expired certificates, TLS negotiation failures, misconfigured servers — so you find out about a broken encrypted path before it silently drops mail.

How it fits together

It’s easier to hold this as four layers than as eight unrelated acronyms:

• Identity — SPF, DKIM, DMARC. Who sent this, and can I trust it?
• Transport — MTA-STS, TLS-RPT. Was it delivered securely?
• Forwarding — ARC. Can authentication survive an intermediary?
• Performance — APRF. Did it actually reach the inbox, and how did it perform once it got there?

A message clears Identity, travels the Transport layer, optionally survives Forwarding, and — if APRF sees adoption — reports back through Performance. BIMI sits off to the side of all four, a reward for a domain that’s already doing Identity well.

One quiet dependency sits underneath all four layers: DNSSEC. Every standard above is published as a DNS TXT record, and that whole trust model assumes an attacker can’t quietly rewrite what those records say in transit. DNSSEC signs DNS responses cryptographically to close that gap. It isn’t part of any of these standards directly, but it’s the foundation they’re all sitting on — worth deploying on any domain you’re publishing this much trust infrastructure to.

Typical deployment order

If you’re building this out for a domain that has none of it:

1. SPF
2. DKIM
3. DMARC at p=none (monitor only — don’t skip this step)
4. Review DMARC aggregate reports until you’re confident nothing legitimate is failing
5. Move to p=quarantine
6. Move to p=reject
7. BIMI, if brand visibility in the inbox matters to you
8. MTA-STS + TLS-RPT
9. ARC, if your organization forwards mail through lists or internal routing

The big three — SPF, DKIM, DMARC — determine whether your mail is trusted at all. Everything after that is refinement: ARC for forwarding resilience, BIMI and MTA-STS/TLS-RPT for branding and transport hardening, and APRF, still early, for the visibility layer the industry has wanted for years.