Email security, RFC by RFC: from SMTP to DMARCbis

Why the status matters#

Every RFC carries a category. Standards Track means the IETF reached consensus that this is how the internet should work. Experimental means it was published to be tried. Informational means it was published for the record, without that consensus. Historic means it has been retired. A protocol’s status tells you how settled it is, and several of the ones email security leans on are less settled than their adoption suggests.

The foundation: moving mail#

None of these authenticates a sender. SMTP carries whatever MAIL FROM and From the sender supplies. Everything below was added on top.

Proving the sender#

SPF: which servers may send

SPF lets a domain publish the servers allowed to use it in the envelope sender. It began outside the IETF and was first published as RFC 4408 in 2006 with Experimental status. It became a Proposed Standard only in 2014, as RFC 7208, which is the version in force.

DKIM: a signature on the message

DKIM grew out of Yahoo’s DomainKeys. Both were published in May 2007: DomainKeys as RFC 4870, now Historic, and DKIM as RFC 4871. The current specification, RFC 6376 (2011), is a full Internet Standard (STD 76). Of everything in email authentication, DKIM is the most settled.

DMARC: tying it to the From line

SPF and DKIM each authenticate some domain, but not necessarily the one in the visible From. DMARC requires one of them to pass for a domain that matches it, and lets that domain publish a policy for failures. It was built by an industry consortium and published in 2015 as RFC 7489, as an Informational RFC, not a standard. For eleven years the protocol every bulk sender now has to deploy was, formally, a document published for the record.

DMARCbis: DMARC becomes a standard#

In May 2026 that changed. Three Standards Track RFCs replaced RFC 7489: RFC 9989 for the protocol, RFC 9990 for aggregate reports and RFC 9991 for failure reports. RFC 9989 also obsoletes RFC 9091, the experimental extension for public suffix domains. Its own Appendix C lists what changed:

• The pct tag is gone. Applying a policy to a percentage of mail is replaced in part by a new t (testing) tag.
• New tags: np, a policy for non-existent subdomains, and psd, marking a public suffix domain. The rf and ri tags are removed.
• No more Public Suffix List. Finding a domain’s organisational domain now uses a “DNS tree walk” instead of a downloaded list.
• Explicit advice on p=reject. Domains that publish it must DKIM-sign and must not rely on SPF alone, and domains whose users post to mailing lists should not publish it. We look at what that means in practice in our post on p=none.

If your tooling still checks pct or talks about RFC 7489 as current, it is describing the previous version of DMARC.

Protecting mail that passes through others#

Forwarders and mailing lists break SPF, and often DKIM, through no fault of the sender. ARC, RFC 8617 (2019), lets each intermediary record and sign the authentication results it saw, so the final receiver can decide whether to trust them. It is still Experimental, and RFC 9989 notes that, so far, no such method has become widely used.

Protecting the connection#

STARTTLS can be stripped by an attacker in the path. MTA-STS, RFC 8461 (2018, Standards Track), lets a receiving domain require TLS with a valid certificate. TLS-RPT, RFC 8460, published alongside it, has senders report when that fails, so the domain finds out.

Unsubscribing, and logos#

RFC 8058 (2017, Standards Track) defines one-click unsubscribe: a List-Unsubscribe-Post header that lets a mail client unsubscribe a user with a single request. Gmail and Yahoo now require it of bulk senders.

BIMI, which shows a brand’s logo beside authenticated mail, is often listed with these standards, but it is not an RFC. It is an individual Internet-Draft with no formal IETF standing (Datatracker). Mailbox providers support it on their own terms.

The stack, in one table#

To see which of these your domain publishes, and whether they agree with each other, run a scan. It reads all of them in one lookup.