hidekazu-konishi.com

Email Authentication History and Timeline - SPF, DKIM, DMARC, and BIMI

First Published: 2026-08-02
Last Updated: 2026-08-02

This is a non-AWS installment in my history-and-timeline series. This time the subject is email authentication: the set of specifications that let a receiving mail server decide whether a message really came from the domain it claims to come from.

Anyone who has configured a sending domain eventually asks the same question: why are there three separate mechanisms? SPF, DKIM, and DMARC are almost always deployed together, they are described in separate documents written years apart, and none of them replaced the others. The short answer is that each one was created to fix a specific hole left by the one before it, and the sequence in which those holes were discovered is the whole story. BIMI, the newest layer, sits on top of all three.

This article is my attempt at a single reference for that story. It follows the chronology from the era when SMTP had no sender authentication at all, through the competing proposals of the early 2000s, to SPF and DomainKeys, to the merger that produced DKIM, to the alignment gap that produced DMARC, and on to ARC, MTA-STS, BIMI, and the standardization work that is still in progress in 2026. Every row in the timeline links to a primary source, and every specification is labeled with its RFC number and its current status.

One point is worth stating at the outset, because it is the most common misunderstanding in this area: email authentication is not a deliverability mechanism. It establishes that a domain authorized the use of its name. Whether a message reaches an inbox is a separate judgment made by the receiving provider, based on many signals of which authentication is only one. RFC 9989 says this directly - a DMARC pass by itself "does not guarantee that delivery to the recipient's inbox would be safe or desirable". This article describes the authentication layer and deliberately makes no claims about improving delivery rates.

This article covers the lineage of the specifications and the shape of the current stack. It is not a configuration walkthrough; for actual DNS record setup I have a separate article and two tools.

Companion articles and tools on hidekazu-konishi.com:

• Setting up DKIM, SPF, DMARC with Amazon SES and Amazon Route 53 - An Overview of DMARC Parameters and Configuration Examples - the practical configuration walkthrough
• AWS History and Timeline regarding Amazon SES - Overview, Functions, Features, Summary of Updates, and Introduction to Amazon Simple Email Service
• DKIM, SPF, and DMARC Record Builder and Validator (Tool)
• Email Header Analyzer (Tool)
• TLS Certificate Ecosystem History and Timeline - Certificate Authorities, Automation, and Shrinking Certificate Lifetimes - the certificate side of the transport-layer protections in this article

Background and Method of Creating the Email Authentication Timeline

The reason for creating this timeline is that the primary facts in this area are unusually scattered and unusually easy to get wrong. The specifications span more than forty years, several of them were published as experiments before being re-published as standards, some were formally reclassified as Historic years after publication, and at least one widely cited document was replaced in 2026. A great deal of the material written about SPF, DKIM, and DMARC describes the state of the specifications as they stood several years ago.

The most consequential example is DMARC itself. For eleven years the canonical reference was RFC 7489, an Informational document published through the Independent Submissions Editor rather than through an IETF working group. In May 2026 that document was obsoleted and replaced by three Standards Track RFCs - RFC 9989, RFC 9990, and RFC 9991 - which also changed how organizational domains are determined and removed a tag that many published DMARC records still contain. A timeline that records the status of each document, and the obsoletion relationships between them, is therefore more useful here than a simple list of release dates.

Three terms are used throughout this article, and it is worth defining them precisely up front.

• Authentication is the act of establishing that a domain authorized the use of its name on a message. SPF and DKIM each do this for a different identifier.
• Alignment is the requirement that the domain authenticated by SPF or DKIM be related to the domain the reader actually sees in the From: header field. This is the specific gap that DMARC was created to close.
• Policy is what the domain owner asks receivers to do with messages that fail. Publishing a policy is a request, not an instruction; receivers decide for themselves.

To organize this history, I have taken the following approaches.

• Tracking the history of email authentication specifications and organizing the transition of updates.
• Summarizing the current overall picture of SPF, DKIM, DMARC, ARC, and BIMI.

The inclusion criteria are deliberately explicit.

• Included: the first publication of each specification; each subsequent revision; each formal status change (Experimental, Proposed Standard, Internet Standard, Historic); obsoletion relationships between documents; the official sender requirements published by major mailbox providers, with their stated effective dates; and the BIMI specification and its certificate types.
• Excluded: vendor product releases, the adoption status of individual email service providers, individual security incidents, and summaries from secondary media.
• Recorded separately: an announcement and the date a requirement took effect are always separate rows, as are "published as an Experimental document" and "re-published on the Standards Track". Conflating the two is the most common error in writing about SPF and DMARC.
• Date precision: where a primary source gives only a month, the row shows only a month. RFC publication dates are given as YYYY-MM because the RFC Editor records a month of publication rather than a day.

The source policy is primary-only. Specification facts come from the RFC Editor and the IETF Datatracker, where each document's status and its Obsoletes and Obsoleted-by relationships are recorded. Provider requirements come from each provider's own help pages or engineering blog. BIMI facts come from the AuthIndicators Working Group and from the Internet-Draft itself. Where work is still in progress, the row says so and gives the draft name, because an Internet-Draft is not a standard and may change or be abandoned.

This timeline primarily references the following sources.

• RFC Editor
• IETF Datatracker
• Email sender guidelines (Gmail Help)
• Sender Requirements and Recommendations (Yahoo Sender Hub)
• BIMI Group (AuthIndicators Working Group)

There may be slight variations in the dates in this timeline because the RFC Editor records a month rather than a day of publication, and because an announcement date and an enforcement date are often months apart. Where both exist, they are shown as separate rows.
The content posted here is limited to the milestones considered essential for understanding how the current email authentication stack came to have the shape it has.
In other words, please note that the items on this timeline are not all updates in this area, but are representative milestones that I have picked out.

All specification statuses in this article were confirmed against the RFC Editor and the IETF Datatracker on 2026-07-31.

Email Authentication Historical Timeline (Updates from August 1982)

Here is the chronological timeline, from the publication of SMTP through the standardization work still under way in 2026. Each row links to the primary source, and each specification is labeled with its status at the time of the event.

1982 | 2002 | 2003 | 2004 | 2006 | 2007 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2018 | 2019 | 2020 | 2021 | 2023 | 2024 | 2025 | 2026

* You can sort the table by clicking on the column name.

Date	Event
1982-08	SMTP is published as RFC 821, with no mechanism for authenticating the sender. The protocol places no restriction on what a sending host may use as the envelope sender or in the HELO command, which is the root cause that every specification below is responding to. RFC 821 is STD 10 and was later obsoleted by RFC 2821 and then RFC 5321. Source: RFC 821.
2002-12	The RMX proposal introduces the idea of publishing authorized senders in DNS. Hadmut Danisch's Internet-Draft "A DNS RR for simple SMTP sender authentication" proposed a new DNS resource record listing the hosts allowed to send for a domain. The draft expired and was never standardized, but the core idea - authorization published in DNS - carried forward. Source: draft-danisch-dns-rr-smtp.
2003-11	The Designated Mailers Protocol proposes a competing DNS-based scheme. Gordon Fecyk's "Designated Mailers Protocol" draft addressed the same problem with a different record design, and also expired. Several similar proposals circulated at the same time, which is what prompted the IETF to try to consolidate them. Source: draft-fecyk-dmp.
2004-04-02	The IETF charters the MARID working group to standardize a single DNS-based sender authorization scheme. MARID (MTA Authorization Records in DNS) was created to reconcile the competing proposals into one standard. Source: MARID working group.
2004-09-22	The MARID working group concludes without producing a standard. The group was unable to reach consensus, and the competing designs were subsequently published individually as Experimental documents instead. This is why SPF and Sender ID both exist. Source: MARID working group.
2006-04	SPF version 1 is published as RFC 4408, with Experimental status. SPF lets a domain publish, in a DNS TXT record, the hosts authorized to send mail using that domain in the SMTP envelope. It was published as Experimental rather than Standards Track, reflecting the unresolved MARID debate. Source: RFC 4408.
2006-04	Sender ID is published alongside SPF as RFC 4405, RFC 4406, and RFC 4407, also Experimental. Sender ID checked a different identifier - the Purported Responsible Address derived from message header fields - rather than the SMTP envelope sender. It saw far less deployment than SPF. Sources: RFC 4406, RFC 4405, RFC 4407.
2006-09	RFC 4686 documents the threats that motivate a signature-based approach. The analysis of threats motivating DomainKeys Identified Mail set out what a cryptographic signature over the message could achieve that a path-based check such as SPF could not. Source: RFC 4686.
2007-05	DomainKeys is published as RFC 4870 and classified as Historic. Yahoo's DomainKeys was the first widely deployed scheme that signed messages cryptographically and published the verification key in DNS. It was recorded in the RFC series as a historical document because its successor was published at the same time. Source: RFC 4870.
2007-05	DKIM is published as RFC 4871, on the Standards Track. DKIM merged DomainKeys with Cisco's Identified Internet Mail. It signs selected header fields and the message body with a key published at <selector>._domainkey.<domain>, so verification does not depend on the connecting IP address and therefore survives simple relaying. Source: RFC 4871.
2009-04	RFC 5451 defines the Authentication-Results header field. This gave receiving systems a standard way to record the outcome of SPF, DKIM, and later DMARC checks in the message itself, so that downstream filters could see the results. Source: RFC 5451.
2009-08	ADSP is published as RFC 5617, an early attempt at author domain policy. Author Domain Signing Practices let a domain declare that all of its mail is signed, so that unsigned mail claiming that domain could be treated with suspicion. It was the first attempt to connect a signature to the author domain the reader sees. Source: RFC 5617.
2010-08	RFC 5965 defines the Abuse Reporting Format. ARF standardized the message format used for feedback loops and later became the basis for DMARC failure reports. Source: RFC 5965.
2011-09	DKIM is re-published as RFC 6376, obsoleting RFC 4871 and RFC 5672. This is the version in use today. It was published at Draft Standard, then elevated to Internet Standard in 2013 as STD 76, making DKIM the only one of the three core mechanisms to reach full Internet Standard status. Source: RFC 6376.
2011-09	RFC 6377 documents how DKIM interacts with mailing lists. Published as BCP 167, it is the first standards-track acknowledgment that intermediaries which modify messages will break signatures - the problem that ARC would later attempt to address. Source: RFC 6377.
2012-01-30	The DMARC specification is published by a group of senders, receivers, and vendors. After coming together in the spring of 2011, a group whose participants included AOL, Comcast, Gmail, Hotmail, Netease, and Yahoo! Mail on the receiving side and organizations such as Bank of America, Facebook, LinkedIn, and PayPal on the sending side published the specification outside the IETF. Source: DMARC.org History.
2012-04	RFC 6591 defines failure reporting using the Abuse Reporting Format. This is the reporting format that DMARC failure reports build on. Source: RFC 6591.
2012-07	RFC 6686 reports the results of the SPF and Sender ID experiment. The document concluded that SPF had achieved substantial deployment while Sender ID had not, and recommended that SPF advance on the Standards Track. Source: RFC 6686.
2013-03-31	DMARC is circulated as an IETF Internet-Draft. Source: DMARC.org History.
2013-06-04	DKIM is elevated to Internet Standard and becomes STD 76. The IESG approved a status change moving RFC 6376 from Draft Standard to Internet Standard, roughly two years after that document was published. This is the point at which DKIM reached the top of the standards ladder, and it remains the only one of the three core mechanisms to do so. Source: Change the status of DKIM (RFC 6376) to Internet Standard.
2013-11-25	ADSP is reclassified as Historic. The IETF approved a status change moving RFC 5617 to Historic, noting that after four years there was very little deployment and no evidence of the expected benefits. The lesson - that a policy statement about signatures is not useful without alignment to the author domain and without reporting - fed directly into DMARC. Source: Change the status of ADSP (RFC 5617) to Historic.
2014-04	SPF is re-published as RFC 7208 with Proposed Standard status, obsoleting RFC 4408. Eight years after the Experimental publication, SPF became a standards-track specification. The revision also retired the dedicated SPF DNS resource record type in favor of TXT records only. Source: RFC 7208.
2014-04-02	The DMARC specification moves to the Independent Submissions track. Source: DMARC.org History.
2014-09	RFC 7372 adds email authentication status codes and updates RFC 7208. Source: RFC 7372.
2015-03	DMARC is published as RFC 7489, with Informational status. DMARC introduced the missing piece: it requires that the domain authenticated by SPF or DKIM be aligned with the domain in the From: header field, lets the domain owner publish a policy at _dmarc.<domain>, and provides a reporting channel so that domain owners can see what is being sent in their name. Note that it was Informational and published through the Independent Submissions Editor, not a product of an IETF working group. Source: RFC 7489.
2015-08	RFC 7601 revises the Authentication-Results header field, obsoleting RFC 7001. Source: RFC 7601.
2015-10	RFC 7672 defines SMTP security via opportunistic DANE TLS. This is a transport-layer protection - it authenticates the receiving server and protects the connection - and is independent of whether the message itself passes SPF, DKIM, or DMARC. Source: RFC 7672.
2016-09	RFC 7960 documents the interoperability problems between DMARC and indirect mail flows. This Informational document catalogues exactly how forwarding, mailing lists, and other intermediaries cause authentication to fail for legitimate mail. It is the problem statement that ARC was written to answer. Source: RFC 7960.
2018-01	RFC 8301 updates DKIM's cryptographic requirements. The update deprecates the rsa-sha1 signing algorithm and sets minimum and maximum RSA key sizes. Source: RFC 8301.
2018-09	MTA-STS is published as RFC 8461. SMTP MTA Strict Transport Security lets a receiving domain publish a policy requiring TLS with a valid certificate, closing the downgrade gap left by opportunistic STARTTLS. Source: RFC 8461.
2018-09	SMTP TLS Reporting is published as RFC 8460. TLS-RPT gives sending domains a reporting channel for TLS negotiation and policy failures, the transport-layer counterpart to DMARC's aggregate reports. Source: RFC 8460.
2018-09	RFC 8463 adds the Ed25519-SHA256 signing algorithm to DKIM. The shorter keys are easier to publish in DNS than large RSA keys. Source: RFC 8463.
2019-03	RFC 8553 regularizes the underscored DNS names used by these specifications. Published as BCP 222, it covers names such as _dmarc and _domainkey and updates RFC 6376, RFC 7208, and RFC 7489 among others. Source: RFC 8553.
2019-05	RFC 8601 revises the Authentication-Results header field again, obsoleting RFC 7601. This is the current version. Source: RFC 8601.
2019-06	RFC 8616 extends email authentication to internationalized mail, updating RFC 6376, RFC 7208, and RFC 7489. Source: RFC 8616.
2019-07	ARC is published as RFC 8617, with Experimental status. The Authenticated Received Chain lets each intermediary that handles a message record the authentication results it observed and seal that record cryptographically, so that a final receiver can see that a message authenticated correctly before a forwarder modified it. It was explicitly published as an experiment. Source: RFC 8617.
2020-02-07	Sender ID is reclassified as Historic. The IESG approved a status change moving RFC 4405, RFC 4406, and RFC 4407 to Historic, recording that after the experiment reported in RFC 6686 it was clear that SPF remained in widespread use while Sender ID did not. This closes the branch that the MARID working group's failure had left open in 2004. Source: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic.
2021-03-09	The BIMI specification is revised as draft-blank-ietf-bimi-02. BIMI lets a domain publish a logo that participating mailbox providers may display next to authenticated messages. This version of the draft later expired and was replaced. Source: draft-blank-ietf-bimi.
2021-07	RFC 9091 defines an Experimental DMARC extension for public suffix domains. PSD DMARC addressed the case of registry operators wanting policy coverage for domains beneath them. The experiment's registry-based design was not implemented as written, and the document was later obsoleted. Source: RFC 9091.
2023-10-03	Google announces new requirements for bulk senders to Gmail. The announcement set out three requirements for senders of more than 5,000 daily messages to Gmail addresses - strong authentication, one-click unsubscribe for commercial mail, and staying under a stated spam rate threshold - to take effect in February 2024. Source: New Gmail protections for a safer, less spammy inbox.
2024-02-01	The Gmail and Yahoo sender requirements take effect. Gmail's guidelines require all senders to set up SPF or DKIM, publish valid forward and reverse DNS records, use a TLS connection, keep spam rates below the stated threshold, and format messages according to RFC 5322; senders of 5,000 or more daily messages must additionally set up both SPF and DKIM, publish a DMARC policy, align the From: domain with the SPF or DKIM domain, and support one-click unsubscribe for marketing mail. Yahoo states equivalent requirements taking effect beginning in February 2024. Sources: Email sender guidelines (Gmail), Sender Requirements and Recommendations (Yahoo).
2025-04-02	Microsoft announces authentication requirements for high-volume senders to Outlook.com. The announcement covers domains sending more than 5,000 messages per day to Outlook.com consumer accounts and states that SPF, DKIM, and DMARC settings become mandatory for them. Source: Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders.
2025-04-09	The IETF DKIM working group's current charter targets the DKIM replay problem. The charter identifies replay - where a message legitimately signed by a domain is re-sent to recipients outside the original set, with the signature still valid - as a problem the original DKIM design does not address, and names the DKIM2 motivation documents as starting points. Source: DKIM working group charter.
2025-05-05	Microsoft's Outlook.com requirements begin to be enforced. Source: Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders.
2026-04-22	A working group document proposes reclassifying ARC as Historic. The draft calls for concluding the ARC experiment defined in RFC 8617, recommends that ARC no longer be deployed or relied upon between disparate senders and receivers, and states that the lessons from ARC are being incorporated into the DKIM2 work. This is an adopted working group draft, not a published RFC, and RFC 8617 remains Experimental until any such change is approved. Source: draft-ietf-dmarc-arc-to-historic.
2026-05	DMARC is re-published on the Standards Track as RFC 9989, obsoleting RFC 7489 and RFC 9091. After eleven years as an Informational document, DMARC became an IETF Standards Track specification. The revision replaces reliance on the Public Suffix List with a DNS Tree Walk for determining the organizational domain, adds the np, psd, and t tags, removes the pct, rf, and ri tags, and states explicitly that domains used for general-purpose email should not deploy a policy of p=reject. Source: RFC 9989.
2026-05	DMARC aggregate reporting is split into its own Standards Track document, RFC 9990. Aggregate reports are the XML summaries a receiver sends to the domain owner describing authentication outcomes seen across a reporting period. Source: RFC 9990.
2026-05	DMARC failure reporting is split into its own Standards Track document, RFC 9991. Failure reports describe individual messages that failed authentication. The document also updates RFC 6591. Source: RFC 9991.
2026-05-01	The current BIMI Internet-Draft is revised as draft-brand-indicators-for-message-identification-14. BIMI is maintained by the AuthIndicators Working Group and remains an individual Internet-Draft; it has not been adopted by an IETF working group and has not been published as an RFC. Source: draft-brand-indicators-for-message-identification.
2026-07-05	The DKIM2 specification draft reaches revision 04. This is an active IETF working group draft with no RFC number; it is a work in progress and its final shape is not settled. Source: draft-ietf-dkim-dkim2-spec.

There may be slight variations in the dates in this timeline because the RFC Editor records a month rather than a day of publication, and because an announcement date and an enforcement date are often months apart.

Current Overview of Email Authentication

Having followed the chronology, this section summarizes the current picture: what each mechanism actually authenticates, where alignment fits, what happens when mail is forwarded, and what the specifications' status is as of this writing.

How the Three Layers Fit Together

The three core mechanisms answer three different questions about the same message.

Mechanism	What it checks	Identifier it authenticates	Where it is published
SPF	Was this connecting server authorized to send for this domain?	The SMTP envelope sender, and optionally the HELO name	A TXT record at the domain
DKIM	Was this message signed by a key belonging to this domain, and is the signed content unmodified?	The domain in the DKIM signature's d= tag	A TXT record at <selector>._domainkey.<domain>
DMARC	Is an authenticated domain aligned with the domain the reader sees, and what should happen if not?	The domain in the From: header field	A TXT record at _dmarc.<domain>

The reason all three are needed becomes clear when you notice that neither SPF nor DKIM, on its own, says anything about the From: header field - which is the only sender identity most people ever see. A message can pass SPF for one domain, carry a valid DKIM signature for a second domain, and display a third, entirely unrelated domain to the reader. DMARC is the specification that ties the authenticated identifier to the visible one.

What SPF Authenticates, and What It Does Not

SPF authorizes hosts to use a domain in the SMTP envelope. It answers a question about the path a message took. Its limits follow directly from that design.

• It does not check the From: header field the reader sees. SPF evaluates the envelope sender, which is invisible in normal mail clients.
• It breaks when mail is forwarded. When a message is relayed by a forwarder, the connecting host is the forwarder, which is almost never listed in the original domain's SPF record.
• It has a hard processing limit. RFC 7208 caps the number of DNS-querying mechanisms that may be evaluated, which constrains how many third-party senders a single record can include.
• It authorizes hosts, not messages. Any message sent from an authorized host passes, including one sent by a different tenant of the same shared platform.

What DKIM Authenticates, and What It Does Not

DKIM signs the message itself, so the check is independent of the connecting IP address. That is why a DKIM signature survives plain relaying where SPF does not. Its limits are also structural.

• It only covers what it signs. Header fields not listed in the signature can be added or altered without invalidating it.
• It breaks when intermediaries modify messages. A mailing list that appends a footer or rewrites the subject line invalidates the signature over the body or over that header field. RFC 6377 documented this in 2011.
• A valid signature can be replayed. Because the signature does not bind the message to its intended recipients, a message legitimately signed by a domain can be re-sent to entirely different recipients with the signature still verifying. This is the problem the current DKIM working group charter identifies and that the DKIM2 work is intended to address.
• The signing domain need not be the visible domain. The d= tag can name any domain the signer controls, which again is why alignment is required.

Identifier Alignment, the Gap DMARC Filled

Alignment is the concept that makes SPF and DKIM useful for protecting the identity a reader actually sees. RFC 9989 defines two modes.

• Relaxed alignment: the authenticated domain and the From: domain share the same organizational domain.
• Strict alignment: the two domains are identical.

A DMARC pass requires an SPF pass or a DKIM pass, and that the passing domain be aligned with the From: domain. Either mechanism alone is sufficient to produce a DMARC pass, which is precisely why publishing both matters in practice: forwarding tends to break SPF while preserving DKIM, and message modification tends to break DKIM while sometimes preserving SPF. Two independent paths to a pass make a legitimate message far more likely to have at least one of them intact.

Where the Specifications Stand Now

This is the part of the picture that has changed most recently, and the part that most existing material is out of date on. The table below lists the current status of each specification. All statuses were confirmed against the RFC Editor on 2026-07-31.

* You can sort the table by clicking on the column name.

Specification	Document	Status	Relationship
SMTP	RFC 5321	Draft Standard	Obsoletes RFC 2821, which obsoleted RFC 821 (STD 10)
SPF	RFC 7208	Proposed Standard	Obsoletes RFC 4408 (Experimental); updated by RFC 7372, RFC 8553, and RFC 8616
Sender ID	RFC 4406	Historic	Published Experimental in 2006; RFC 4405, RFC 4406, and RFC 4407 were reclassified as Historic in 2020 after the experiment reported in RFC 6686
DomainKeys	RFC 4870	Historic	Obsoleted by RFC 4871
DKIM	RFC 6376	Internet Standard (STD 76)	Obsoletes RFC 4871 and RFC 5672; updated by RFC 8301, RFC 8463, RFC 8553, and RFC 8616
ADSP	RFC 5617	Historic	Reclassified in 2013
DMARC	RFC 9989	Proposed Standard	Obsoletes RFC 7489 and RFC 9091
DMARC aggregate reporting	RFC 9990	Proposed Standard	Obsoletes RFC 7489
DMARC failure reporting	RFC 9991	Proposed Standard	Obsoletes RFC 7489; updates RFC 6591
DMARC (previous)	RFC 7489	Informational, obsolete	Independent Submission; replaced by the three documents above
ARC	RFC 8617	Experimental	Reclassification to Historic proposed in a working group draft
Authentication-Results	RFC 8601	Proposed Standard	Obsoletes RFC 7601
MTA-STS	RFC 8461	Proposed Standard	Transport-layer protection
SMTP TLS Reporting	RFC 8460	Proposed Standard	Transport-layer reporting
SMTP DANE	RFC 7672	Proposed Standard	Transport-layer protection
BIMI	draft-brand-indicators-for-message-identification	Internet-Draft, not an RFC	Individual submission; not adopted by an IETF working group
DKIM2	draft-ietf-dkim-dkim2-spec	Internet-Draft, not an RFC	IETF working group document, in progress

Two practical consequences of the 2026 DMARC revision are worth calling out.

First, the pct tag was removed. Many published DMARC records still contain it, from an era when the recommended rollout was to ramp a policy up by percentage. RFC 9989 removes it and adds a t tag covering part of what it was used for.

Second, organizational domain determination changed. RFC 7489 implementations relied on the Public Suffix List; RFC 9989 replaces that with a DNS Tree Walk. RFC 9989 notes that this can produce a different answer than a Public Suffix List-based implementation for the same domain, and that publishing explicit DMARC records for every author domain, together with strict alignment, avoids the ambiguity entirely.

One further change is likely to surprise readers who have absorbed the common advice that every domain should end up at p=reject. RFC 9989 states explicitly that domains used for general-purpose email should not deploy a policy of p=reject, because such domains carry exactly the kind of correspondence - mailing list posts, forwarded mail - that legitimately fails DMARC. The strict policy is appropriate for transactional and brand domains that do not send that kind of mail.

Indirect Mail Flows and ARC

The single most common support question about email authentication is why a message that passes everywhere else fails after being forwarded. RFC 7960 catalogued the reasons in 2016; the mechanics are straightforward.

1. A subscriber posts to a mailing list from a domain with a DMARC policy.
2. The list software appends a footer and rewrites the subject line, invalidating the DKIM signature.
3. The list re-sends the message. The connecting host is now the list server, so SPF fails for the original domain.
4. Neither mechanism passes, so DMARC fails, and the receiving system may apply the original domain's policy to a message the original domain genuinely sent.

ARC was the proposed answer: each intermediary records the authentication results it observed and seals that record, so a final receiver can see that the message authenticated correctly before modification and can choose to trust that chain. It was published as Experimental in 2019.

As of this writing that experiment is being wound down. An adopted working group draft dated 2026-04-22 calls for concluding the experiment, recommends that ARC no longer be deployed or relied upon between disparate senders and receivers, and states that the lessons are being carried into the DKIM2 work. This is a draft, not a published standard. RFC 8617 remains Experimental, deployed ARC implementations continue to function, and the proposal may change before any status change is approved. It is recorded here because anyone reading older material will find ARC described as the forward-looking answer to forwarding, and the direction of travel has changed.

Transport-Layer Protections Are a Separate Layer

MTA-STS, TLS-RPT, and DANE for SMTP are frequently discussed alongside SPF, DKIM, and DMARC, and they are often configured at the same time, but they answer a different question. Sender authentication asks whether a domain authorized this message. Transport protection asks whether the connection carrying the message is encrypted and whether the right server is on the other end.

Specification	Purpose
MTA-STS (RFC 8461)	Lets a receiving domain publish a policy requiring TLS with a valid certificate, so senders can refuse to fall back to plaintext
SMTP TLS Reporting (RFC 8460)	Gives sending domains a reporting channel for TLS negotiation and policy failures
SMTP DANE (RFC 7672)	Authenticates the receiving server's certificate through DNSSEC-signed TLSA records

Neither set substitutes for the other. A message can be delivered over a perfectly authenticated TLS connection and still be a forgery, and a correctly signed message can be transmitted in the clear.

Two of the three depend on the publicly trusted certificate ecosystem rather than on anything in this timeline: MTA-STS requires the receiving server to present a certificate that validates against the sender's trust store, and its lifecycle is therefore governed by the CA/Browser Forum Baseline Requirements and the browser root programs. That governance, including the schedule now shortening certificate lifetimes, is the subject of my TLS Certificate Ecosystem History and Timeline. SMTP DANE is the exception: it authenticates through DNSSEC-signed TLSA records instead, which is why it does not inherit those rules.

Reading the Reports

The reporting channel is the part of DMARC that domain owners get the most value from and configure the least well. Since the 2026 revision, the two report types are specified in separate documents.

Report type	Document	What it contains	Typical use
Aggregate	RFC 9990	An XML summary of authentication outcomes seen for a domain across a reporting period, grouped by sending source	Discovering which systems send mail in your name, and which of them fail alignment, before tightening policy
Failure	RFC 9991	Details about individual messages that failed authentication	Diagnosing a specific failure; note that these can contain message content and therefore carry privacy considerations

The practical sequence that the reporting channel enables is the reason DMARC succeeded where ADSP failed: publish a monitoring policy, read the aggregate reports until every legitimate sending source is identified and aligned, and only then consider a stricter policy. ADSP had no equivalent feedback mechanism, which is a significant part of why it saw almost no deployment and was reclassified as Historic.

BIMI and Logo Display

BIMI lets a domain publish a logo that participating mailbox providers may display alongside authenticated messages. It is the newest layer and the only one in this article that is not a published RFC.

• Status: BIMI is maintained by the AuthIndicators Working Group. The current specification is an individual Internet-Draft, draft-brand-indicators-for-message-identification, revised to version 14 on 2026-05-01. It has not been adopted by an IETF working group, and the draft itself states that it has no formal standing in the IETF standards process.
• Prerequisite: BIMI builds on DMARC. Per the BIMI Group's own FAQ, most supporting providers require the domain to be at enforcement - a policy of quarantine or reject rather than none - before considering a logo for display, and BIMI requires DMARC alignment at minimum.
• Certificates: providers may require the logo to be backed by a certificate asserting that an independent Mark Verifying Authority confirmed the sender's rights to the mark. Two types exist: the Verified Mark Certificate (VMC) and the Common Mark Certificate (CMC).
• Provider support: support varies by provider and changes over time. The BIMI Group's provider infographic lists Apple, Google, Yahoo, Fastmail, Comcast, and others as supporting BIMI, and lists Microsoft as not supporting it. That page was last updated in 2025-05, so the current state should be checked against the source before relying on it.

The operational point to take from this is that BIMI is not a small addition. It presupposes a working DMARC deployment at enforcement, which - as the section above notes - is not the right destination for every domain. The certificate requirement also adds an identity-verification process and a renewal obligation to the operational burden.

References: BIMI FAQs for Senders and ESPs, BIMI Group provider infographic.

Mailbox Provider Sender Requirements

Since 2024, several major mailbox providers have published explicit requirements for senders. These are provider policies, not standards, and each provider states its own. The summary below reflects each provider's own published page as confirmed on 2026-07-31, and should be re-checked against the source before acting on it.

Provider	Threshold	Stated requirements	Effective
Gmail	All senders	SPF or DKIM; valid forward and reverse DNS records; a TLS connection; spam rate below the stated threshold; messages formatted per RFC 5322	2024-02-01
Gmail	5,000 or more messages per day	Additionally: SPF and DKIM; a DMARC policy; From: alignment with the SPF or DKIM domain; one-click unsubscribe for marketing and subscribed messages	2024-02-01
Yahoo	All senders	SPF or DKIM at minimum; valid forward and reverse DNS records; spam rate below the stated threshold; compliance with RFC 5321 and RFC 5322	Beginning 2024-02
Yahoo	Bulk senders	Additionally: SPF and DKIM; a valid DMARC policy of at least p=none that passes; a functioning one-click unsubscribe header; unsubscribes honored within two days	Beginning 2024-02
Outlook.com	More than 5,000 messages per day	SPF, DKIM, and DMARC settings mandatory	Enforcement began 2025-05-05

The convergence here is the practically important part: the configuration that satisfies all of these is the same one, and it is exactly the SPF-plus-DKIM-plus-aligned-DMARC stack that the timeline above arrives at. The thresholds and the enforcement actions differ by provider, so each provider's own page is the authority for its own requirements. For the actual DNS records, see my Setting up DKIM, SPF, DMARC with Amazon SES and Amazon Route 53 article and the DKIM, SPF, and DMARC Record Builder and Validator tool, and for inspecting the results on a received message, the Email Header Analyzer.

What Authentication Does Not Guarantee

It is worth returning to the point made at the start, because the framing of much of the material in this area invites the opposite conclusion.

Passing SPF, DKIM, and DMARC establishes that a domain authorized the use of its name on a message. It does not establish that the message is wanted, that it is not spam, or that it will be placed in an inbox. RFC 9989 is explicit: a DMARC pass "does not carry an explicit or implicit value assertion about that message or about the Domain Owner", and "does not guarantee that delivery to the recipient's inbox would be safe or desirable". The document also notes that a receiving organization that performs DMARC validation "can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so", and that DMARC is commonly used as one input to more complex filtering decisions.

What authentication does provide is a reliable association between a message stream and a domain, which lets a receiving system reason about that stream's reputation. Reputation, complaint rates, content, and sending patterns remain the receiving provider's own judgment. Any material that presents authentication as a lever for improving delivery rates is describing a correlation - properly authenticated senders tend to be the ones who also do everything else correctly - rather than a mechanism.

Frequently Asked Questions about Email Authentication History

Why are both SPF and DKIM needed when either one can produce a DMARC pass?

Because they fail in different circumstances, and having two independent paths to a pass makes legitimate mail far more likely to keep at least one of them. SPF authorizes the sending host for the SMTP envelope sender, so it breaks when a message is forwarded by a host the domain never listed. DKIM signs the message itself, so it survives relaying but breaks when an intermediary modifies signed content, such as a mailing list appending a footer. A DMARC pass requires an SPF pass or a DKIM pass plus alignment with the From: domain, so publishing both means a forwarded message can still pass on DKIM and a modified message can still pass on SPF.

Why does email authentication break when a message is forwarded?

Because both mechanisms depend on something the forwarder changes. SPF evaluates the host that connected, and after forwarding that host is the forwarder, which is not in the original domain's SPF record. DKIM verifies a signature over selected headers and the body, and mailing lists commonly rewrite the subject line or append a footer, which invalidates it. RFC 7960 documented these indirect mail flow problems in 2016. ARC (RFC 8617) was published as an experiment to let intermediaries carry forward the authentication results they observed, but a working group draft dated 2026-04-22 now proposes concluding that experiment and reclassifying ARC as Historic.

Which RFC defines DMARC now?

DMARC is defined by RFC 9989, published in May 2026 with Proposed Standard status, together with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. These three documents obsolete RFC 7489, the Informational document that defined DMARC from March 2015, and RFC 9989 also obsoletes RFC 9091. The change is not only editorial: DMARC moved from an Independent Submission Informational document to the IETF Standards Track, the Public Suffix List was replaced by a DNS Tree Walk for determining the organizational domain, the np, psd, and t tags were added, and the pct, rf, and ri tags were removed.

Was DKIM ever a full Internet Standard?

Yes. DKIM is the only one of the three core mechanisms to reach that level. RFC 6376, published in September 2011 and obsoleting RFC 4871 and RFC 5672, is an Internet Standard and carries the designation STD 76. SPF (RFC 7208) and DMARC (RFC 9989) are both Proposed Standard, one step below.

What does BIMI require, and is it a standard?

BIMI is not an RFC. It is maintained by the AuthIndicators Working Group and specified in an individual Internet-Draft, draft-brand-indicators-for-message-identification, which states that it has no formal standing in the IETF standards process. It builds on DMARC: per the BIMI Group's FAQ, most supporting providers require the domain to be at enforcement - a policy of quarantine or reject rather than none - and BIMI requires DMARC alignment at minimum. Providers may also require the logo to be backed by a Verified Mark Certificate or a Common Mark Certificate, issued after an independent Mark Verifying Authority confirms rights to the mark. Provider support varies and changes.

Will configuring SPF, DKIM, and DMARC make my email reach the inbox?

No, and no specification claims it will. Authentication establishes that a domain authorized the use of its name; it says nothing about whether a message is wanted. RFC 9989 states that a DMARC pass "does not guarantee that delivery to the recipient's inbox would be safe or desirable" and that a receiving organization is not required to honor a domain owner's requested handling of failures. What authentication does is make a message stream reliably attributable to a domain, so that a receiving system can apply reputation to it. Inbox placement remains the receiving provider's own judgment, based on reputation, complaint rates, content, and sending patterns in addition to authentication.

Summary

In this article, I built a historical timeline of email authentication and summarized the current shape of the stack.

The chronology has a clear logic to it. SMTP shipped in 1982 with no way to authenticate a sender. The DNS-based proposals of the early 2000s and the failure of the MARID working group to reconcile them left SPF and Sender ID both published as experiments in 2006. DomainKeys and Identified Internet Mail merged into DKIM in 2007, republished as RFC 6376 in 2011, and elevated to full Internet Standard as STD 76 in 2013. Each of those mechanisms authenticated an identifier the reader never sees, and ADSP's failure to bridge that gap - it was reclassified as Historic in 2013 - showed that a policy statement without alignment and without reporting does not get deployed. DMARC supplied both in 2012, and SPF finally reached the Standards Track in 2014. Forwarding remained broken, which produced RFC 7960's problem statement and then ARC as an experiment. Mailbox provider requirements from 2024 onward turned the whole stack from a recommendation into a precondition for sending at volume.

The most recent chapter is the one least reflected in existing material. In May 2026 DMARC was re-published on the Standards Track as RFC 9989, RFC 9990, and RFC 9991, obsoleting the RFC 7489 that nearly every guide still cites, and changing organizational domain determination, the available tags, and the guidance on p=reject along the way. At the same time the ARC experiment is being proposed for closure and DKIM2 is being drafted to address signature replay. Anyone maintaining documentation or tooling in this area has a round of updates to do.

By organizing these milestones in one place with a primary source and a current status for each, I hope this article serves as a reference that AI search agents, developers, and mail operators can consult in a single fetch.

This timeline will be updated as email authentication specifications continue to evolve.

In addition, there are related history-and-timeline articles and reference material on this site, so please have a look if you are interested.
AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
AWS History and Timeline regarding Amazon SES - Overview, Functions, Features, Summary of Updates, and Introduction to Amazon Simple Email Service
AWS History and Timeline regarding Amazon Route 53 - Overview, Functions, Features, Summary of Updates, and Introduction
Tool Use and Agent Protocol History and Timeline - Function Calling, MCP, and A2A

References:
RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures (STD 76)
RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
RFC 9990 - DMARC Aggregate Reporting
RFC 9991 - DMARC Failure Reporting
RFC 8617 - The Authenticated Received Chain (ARC) Protocol
RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
draft-brand-indicators-for-message-identification - Brand Indicators for Message Identification (BIMI)
draft-ietf-dkim-dkim2-spec - DomainKeys Identified Mail Signatures v2 (DKIM2)
Email sender guidelines - Gmail Help
Sender Requirements and Recommendations - Yahoo Sender Hub
Setting up DKIM, SPF, DMARC with Amazon SES and Amazon Route 53
Cryptography Glossary for Engineers
DKIM, SPF, and DMARC Record Builder and Validator (Tool)
Email Header Analyzer (Tool)

References:
Tech Blog with curated related content