Brief of email anti-spoofing technologies: SPF, DKIM, DMARC, SIDF, DK, ADSP

For a few years unhurriedly I have been discovering features to protect emails from spoofing. Here I briefly collect information about all current standards, their functionality and an example with one main domain and two subdomains. It is not a complete guide, please read the RFCs and special guides for each standard.

Standards

Acronym	Definition	Official website	RFC	IETF Status	Short description
SPF	Sender Policy Framework	http://www.open-spf.org/	RFC4408 RFC7208	Standards Track RFC	Defines who (which servers) could send emails from domain and what to do with “bad” emails. Works with «RFC5321.MailFrom» and «HELO» identities.
DKIM	Domain Keys Identified Message	http://opendkim.org	RFC6376 RFC4871	Standards Track RFC	Sign an email by private key to identify the sender.
DMARC	Domain-based Message Authentication, Reporting, and Conformance	https://dmarc.org	RFC7489	Informational RFC, Working Group	The policy that unites the SPF and DKIM to define what should do receivers with «bad» emails.
SIDF	Sender ID Framework	-	RFC4406 RFC4407	Experimental (2006)	Analog SPF, but works with «RFC5321.MailFrom» and «RFC5322.From».
ADSP	Author Domain Signing Practices	-	RFC5617	Historic (2014)	Extension to DKIM allowing domain owner to specify whether or not they signed all outgoing mail.
DK	DomainKeys	http://domainkeys.sourceforge.net	RFC4870	Historic	Analog of DKIM. This standard was superseded by DKIM (RFC4871).

Email: Eliminate confusion between the concepts of «MAIL FROM» and «From»

Looking through various articles I was confused by different names of From-headers of email. Now I want to put all aliases of FROM and TO headers into one table.

First of all it is necessary to understand that email consists of two parts: «envelope» and «content». Quotation from RFC5322:

«In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [RFC5321] for a discussion of the envelope.)  The contents comprise the object to be delivered to the recipient.  This specification applies only to the format and some of the semantics of message contents.  It contains no specification of the information in the envelope.»

Each of parts contains its own FROM and TO headers/fields. In fact, there are many other headers (sender, cc, bcc and etc.), I will not consider them all, so read the RFC.

A content part consists of two sections: «header» and «body». Quotation from RFC5321:

«The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section consists of a collection of header fields, each consisting of a header name, a colon, and data, structured as in the message format specification (RFC 5322 [4]); the body, if structured, is defined according to MIME (RFC 2045 [21]).»