Email Standards – basic and lesser known


What was SMTP, SPF, DKIM, DMARC, SRS and ARC again?

SMTP — Simple Mail Transfer Protocol

The “Simple Mail Transfer Protocol” (SMTP, see Wikipedia) is the standard mail transfer protocol. It is used by users to “submit” new emails to their local email server and for servers to “relay” the users' emails to the destination server. These two roles were historically handled by the same servers (meaning both “hardware” and “software”). Nowadays these roles are usually handled by different servers listening on different ports and – strictly speaking – slightly different protocols.

The “traditional” and “relaying” role(s) are covered by many RFCs describing the core protocol and quite some more RFCs defining extensions. The core RFCs (all titled “Simple Mail Transfer Protocol”) seem to be RFC 788 (1981), RFC 821 (1982), RFC 2821 (2001) and RFC 5321 (2008). RFC 821 is part of STD 10. It is strange, that the newer RFCs have not been elevated to STD 10.

The “message submission” role is described in another set of RFCs with the title “Message Submission for Mail” (RFC 2476 (1998), RFC 4409 (2006) and RFC 6409 (2011) which is STD 72) but the used protocol is still SMTP! The RFC (and the extensions, of course) “only” change the rules how the server can and should modify messages before delivering them, how to authenticate users and more stuff like that.

The following assumes a “relaying server” (aka. Mail Transfer Agent – MTA):

Given an recipient address like the sender will lookup MX records for the domain part of the email address:

> dig +short MX

The number in the MX record is a priority (i.e. lower is better). So the connection will be made to the server with the priority 5. If there is no MX record then a direct connection to domain will be tried. This is called “implicit MX record”.

The connection to the destination MTA (i.e. relaying role) will use port 25. The MX MX record does not support different port numbers.

A minimal SMTP session looks like this:

> dig +short MX
> telnet 25
S:	220 ESMTP software-id
S:	250 Hello
S:	250 ok
S:	250 ok
S:	354 go ahead
C:	From: Alice <>
C:	To: Bob <>
C:	Subject: simple SMTP test
C:	It Works! CU later!
C:	.
S:	250 OK
S:	221 bye
Connection closed by foreign host.

Although this will not work for the big email providers like Gmail and These will require additional headers like Message-ID: and will still reject the message due to missing other stuff like missing PTR records (aka “reverse DNS”, rDNS). Google talks about that here: Prevent mail to Gmail users from being blocked or sent to spam

SPF — Sender Policy Framework

The “Sender Policy Framework” (SPF, see Wikipedia) is an email authentication standard. The receiving MTA can verify that the sending MTA is actually allowed to send emails for the domain given in the MAIL FROM: envelope address within the SMTP connection. In some situations also the domains in the HELO / EHLO greeting handshake are checked. Since the the receiver only sees the IP address of the sender the available tests resolve around different kinds of DNS tests. The policy itself is also in DNS.

The RFCs for SPF are RFC 4408 (2006) and RFC 7208 (2014) having the title “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1”.

Given an alleged sender in the MAIL FROM: envelope the receiver will lookup a TXT DNS record which starts with v=spf1:

> dig +short TXT

Following the redirect (wrapping some long lines) returns:

> dig +short TXT
"v=spf1 ~all"

Digging into one include returns (also wrapped and slightly reformatted):

> dig +short TXT
ip4: ip4: ip4:  ip4:
ip4:  ip4:   ip4: ip4:
ip4: ip4: ip4:
~all" and are structurally similar.

It is interesting that Google uses ~all which means “Soft Fail”.

Some points about SPF:

Nevertheless – a small site might want to deploy SPF records in order to improve their reputation with the big email receivers like Gmail and

DKIM — DomainKeys Identified Mail

“DomainKeys Identified Mail” (DKIM, see Wikipedia) is also an email authentication standard. The sending MTA signs selected headers and the body of the email using a private key. The receiving MTA fetches the corresponding public key from DNS and then validates the integrity of the mail.

The RFCs for DKIM are RFC 4871 (2007) and RFC 6376 (2011) both titled “DomainKeys Identified Mail (DKIM) Signatures”. The later RFC is STD 76. Note that RFC 4870 (2007) is a precursor of DKIM with a slightly different title.

A DKIM signature header from Gmail look like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112;

b the actual signature, bh is the body hash, h the list of signed headers. d is the “signing domain identifier” and s the “selector”.

Using and s=20210112 the public key can be fetched (wrapped):

> dig +short TXT

Some random selectors:

Domain Selector 20210112 pog7p5txl4ruqhixze35ey6av7ivmsea 6gbrjpgwjskckoa6a5zn6fwqkn67xbtw protonmail3 badeba3b8450 s29768273 1662700821

Some points about DKIM:

While both DKIM and SPF perform email authentication they cover disjoint topics. Therefore both are – per se – not enough to reduce spam / spoofing / phishing. But both can impede legit email flows like forwarding and mailing lists. And like SPF – a small site might want to deploy DKIM in order to improve their reputation with the big email receivers like Gmail and

DMARC — Domain-based Message Authentication, Reporting, and Conformance

“Domain-based Message Authentication, Reporting, and Conformance” (DMARC, see Wikipedia) is the third email authentication method.

The RFC for DMARC is RFC 7489 (2015) titled “Domain-based Message Authentication, Reporting, and Conformance (DMARC)”.

DMARC relies on either SPF or DKIM or on both and adds some stuff on top:

So DMARC really connects several loose parts of SPF and DKIM.

Of course DMARC also stores the information in a DNS TXT record:

> dig +short TXT
"v=DMARC1; p=none; sp=quarantine;"

p specifies the policy for the domain (here: please accept even invalid messages), sp is the policy for subdomains (mark as spam). rua specifies the address to which aggregate feedback reports should be sent. The standard defines more fields but uses the defaults for these.

Regarding the address for aggregate feedback report (rua): Since the sender’s domain ( does not match with the one in the rua field ( another DNS record is required to accept these mails:

> dig +short TXT

This means: I myself cannot send the reports for my toy domain to my gmail account because Google will not setup the DNS.

Regarding email forwarding and mailing lists: DMARC mostly makes things worse:

Some points about DMARC:

Overall it’s the same as with SPF and DKIM: A small mailer should setup also DMARC in order to play nice with the big ones.

SRS — Sender Rewriting Scheme

“Sender Rewriting Scheme” (SRS, see Wikipedia) is a method to prevent SPF failures when emails are forwarded. It works by rewriting the MAIL FROM: envelope address.

Contrary to the other standards this is not an RFC but a PDF from the libsrs2 homepage.

SRS works like this: System A sends an email to system B:

From: Alice <>

System B checks SPF, DKIM and DMARC and all checks pass. But Bob had configured a forward rule to Charlie so B forwards the mail to C:

From: Alice <>

It is similar to the example from SPF because the MAIL FROM: envelope address is rewritten to match the forwarders domain. If C accepts the message but wants to send a bounce message later on it will send it to B. B can validate the address using the cryptographic truncated hash HHH and the truncated timestamp TT, reconstruct the original address and forward the bounce back to Alice. The hash and the timestamp prevent spammers from abusing the system.

SRS also contains an SRS1= variant which used when multiple forwards happen: In that case subsequent forwarders don’t extend the address ad infinitum but only twice altogether.

However: This works only as long as DMARC is not enabled. Since SRS does not change the From: header the alignment fails. Wikipedia says:

Please note : Using SRS protocol fails the SPF Alignment check for your DMARC record, and it’s by design. Your DMARC record can still pass with a DKIM check. – Wikipedia – Sender Rewriting Scheme

So why bother with SRS at all? And doesn’t that imply, that any Alice must setup DKIM and no forwarder breaks the signature? Both seem unlikely even considered each on its own.

Some more links to read up more details:

ARC — Authenticated Received Chain

“Authenticated Received Chain” (ARC, see Wikipedia) is also an email authentication method. It tries to address the forwarding issues of the other methods by allowing to override the DMARC policy with a local policy again.

The RFC for ARC is RFC 8617 (2019), titled "(The Authenticated Received Chain (ARC) Protocol)".

ARC builds upon DMARC and – transitively – on DKIM and SPF. The receiving MTA performs the DKIM, SPF and DMARC validation as usual, records the validation results, signs these and puts the records and the signature into headers. The signature also covers any existing ARC headers.

When the email is forwarded the next MTA will apply DKIM, SPF and DMARC again. SPF will fail in almost all situations. DKIM might fail if the forwarder modified the email or some signed headers. If both checks fail or the DMARC alignment fails a strict DMARC policy could call for rejection of the message. A receiver supporting ARC can overrule that policy if the ARC chain and the recorded result are valid and the receiver trusts the forwarder.

[arc-spec - Resources][] shows supporters for ARC. Google supports it with Gmail, G Suit and Google Groups. Microsoft is shown with limited support for Outlook 365.

Example headers of mail from GMX to Gmail:

ARC-Seal: i=1; a=rsa-sha256; t=1665601609; cv=none;; s=arc-20160816;
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;;
    s=arc-20160816;	h=subject:from:to:user-agent:mime-version:date:message-id
ARC-Authentication-Results: i=1;;
	dkim=pass header.s=badeba3b8450 header.b=c+GkZtfO;
	spf=pass ( domain of designates as
	 permitted sender);
	dmarc=pass (p=NONE sp=NONE dis=NONE)

The public key can be fetched like a DKIM key (line wrapped):

> dig +short TXT
z0RgMoPeyp5NRy4l320DPYibNqVMWa5" "iQ2WiImQC0en1O9uhLLvzaSZJ03fvGmCo9jM

Some random ARC selectors:

Domain Selector arc-20160816 arcselector9901


Mail Transfer Agent
Domain Name System
Administrative Management Domain
indirect mailflow
A mailflow with intermediate hops like forwarding, mailing list, … See RFC 7960

  1. Pressing the “Forward To” button in the mail client is still possible, but that creates a new mail. ↩︎