A short history of email authentication: from open relays to DMARC as a standard

History · Published 2026-10-25

Drawing of six envelopes rising along a timeline marked 1982, 1999, 2006, 2011, 2015 and 2026, the later ones with tick marks — Four decades of email, from no checks at all to authenticated mail. Illustration: Plain Hooks.

When WordPress appeared in 2003, a web server could send mail claiming to be from almost anyone, and most of it was delivered. Today the same message is likely to be rejected. The rules changed gradually, one standard at a time.

This history explains where today's requirements come from. For the practical side, see SPF, DKIM and DMARC for WordPress email, which walks through the records themselves.

1982: a protocol built on trust

The Simple Mail Transfer Protocol was specified in RFC 821, written by Jonathan Postel and published in August 1982. It describes how one server hands a message to another, with commands such as MAIL FROM and RCPT TO. Nothing in it verifies that the sender address is genuine. On a network of universities and research centres where administrators knew each other, that was a reasonable choice. The protocol has been revised since, most recently as RFC 5321 in 2008, but the core exchange, and its lack of sender verification, remain.

The 1990s: open relays and the first spam fight

Early mail servers often accepted messages from anyone and passed them on to anyone, a configuration later called an open relay. As commercial spam grew in the 1990s, spammers used open relays to send huge volumes through other people's machines, hiding their origin. Closing relays became a basic duty: RFC 2505, published in February 1999 as a Best Current Practice, set out anti-spam recommendations for mail servers, starting with not relaying mail for strangers.

Closing relays raised a new question: how does a legitimate user on the road send mail through their own server? The answer came in two standards. Message submission on port 587, separate from server-to-server traffic on port 25, was defined in RFC 2476 (December 1998), now RFC 6409. The SMTP authentication extension, SMTP AUTH, followed in RFC 2554 (March 1999), now RFC 4954. This pair is exactly what a WordPress SMTP plugin uses today: it connects to port 587 and logs in with a username and password.

2006: SPF and Sender ID

Authentication protected servers from strangers, but it did nothing to stop a spammer's own server from writing someone else's domain in the sender address. Several proposals tried to let domain owners publish which servers could send for them. Two were published as experimental RFCs in April 2006:

SPF, the Sender Policy Framework (RFC 4408), checks the envelope sender's domain against a list of permitted IP addresses published in DNS.
Sender ID (RFC 4406), promoted by Microsoft, applied a similar idea to the address the reader sees.

SPF won in practice and became a proposed standard as RFC 7208 in April 2014, which obsoleted RFC 4408. Sender ID faded. SPF had a known weakness from the start: forwarding breaks it, because the forwarding server is not in the original domain's list.

This was the period when the plugin that once lived at this address, and many like it, appeared. Web hosts sent WordPress mail from shared servers that no SPF record mentioned, and routing mail through a real, authenticated mailbox was the obvious cure; the old idea survives in today's guides such as WordPress and Gmail SMTP.

2007 to 2011: DKIM signatures

A different approach was to sign messages. Yahoo developed DomainKeys and Cisco developed Identified Internet Mail; the two were merged into DomainKeys Identified Mail. DomainKeys was documented in RFC 4870, immediately classified as historic, and DKIM itself was published as RFC 4871 in May 2007. The current specification, RFC 6376, followed in September 2011.

DKIM's signature travels with the message, so it usually survives forwarding, which complements SPF. But on its own it only proves that some domain signed the message, not that the signing domain is the one shown in the From line.

2012 to 2015: DMARC links it to the From address

DMARC closed that gap. It was developed by an informal industry consortium, DMARC.org, whose participants, listed in the specification's acknowledgements, included mailbox providers, banks and social networks. DMARC lets a domain owner state what receivers should do with mail that fails SPF and DKIM alignment with the From domain, and asks receivers to send reports back. The specification was published as RFC 7489 in March 2015, through the RFC Editor's independent stream rather than as an IETF standard.

Strict policies had side effects. When domains with p=reject policies posted to mailing lists, the lists' modifications broke DKIM and their servers broke SPF, so copies sent to subscribers were rejected and subscribers could even be unsubscribed automatically. RFC 7960 (2016) documented these interoperability problems, and the Authenticated Received Chain, RFC 8617 (July 2019, experimental), gave intermediaries a way to vouch for the authentication results they saw before changing a message.

Encryption and unsubscribe rules

Two other standards shaped the mail a WordPress site sends. RFC 8314 (January 2018), titled "Cleartext Considered Obsolete", recommends TLS for submission and access, including implicit TLS on port 465. RFC 8058 (January 2017) defined one-click unsubscribe headers, which are now expected on newsletters.

2024: the mailbox providers enforce

For years, authentication was recommended rather than required. That changed in February 2024, when Google's sender guidelines began requiring SPF or DKIM from everyone sending to Gmail, and SPF, DKIM, DMARC, alignment and one-click unsubscribe from senders of more than 5,000 messages a day. Yahoo introduced matching rules for bulk senders. Separately, Google has phased out password-only "less secure app" sign-in for SMTP, in 2022 for personal Gmail accounts and in stages since 2024 for Google Workspace, in favour of app passwords and OAuth, a change that broke many older SMTP setups.

2026: DMARC becomes an Internet standard

In May 2026, the IETF published DMARC on the Standards Track as RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. Together they obsolete RFC 7489. The new version replaces the old public suffix list lookup with a "DNS tree walk" for finding the organisational domain, adds tags for public suffix domains and non-existent subdomains, and drops the pct tag in favour of a simple test flag, t.

What it means for a WordPress site

A WordPress site written in 2005 could send mail with PHP's mail() function and expect most of it to arrive. Each step above made that less true. Today the minimum is an authenticated SMTP connection or sending API over TLS, as described in why WordPress mail goes missing, plus SPF, DKIM and DMARC records for your domain. The plugin ecosystem adapted alongside these rules; how WordPress plugins began tells that side of the story.