SPF, DKIM, and DMARC are all methods of authenticating email. This guide is a quick overview of each of them. For a comprehensive guide, check out Demystifying DMARC: A guide to preventing email spoofing.

SPF

Published in April 2014 as RFC 7208, Sender Policy Framework (SPF) is an early method of email authentication that is still in use today despite its many shortcomings. There are two email from addresses. One is known as the envelope from address, which is the address used by the sending email server in the SMTP HELO/EHLO commands. This address is used for receiving bounceback emails. The other from address is the message from address, which is in the email message From header. That is the from address that the user sees when they open an email. SPF compares the IP address of the server that sent an email against a list of permitted IP addresses provided in the SPF record at the domain of the envelope from address.

An SPF record is built of mechanisms that describe what IP addresses are allowed. Many of these mechanisms (a, mx include, exists, redirect, and ptr) require additional DNS lookups. Unfortunately, RFC 7208 section 4.6.4 places a hard limit of 10 DNS lookups per SPF record. Although 10 lookups might have seemed like plenty in 2014, it is often hard to stay under that limit today. There are a couple of workarounds to this problem.

• Limit the SPF includes and other lookups to the primary mail service, and services that cannot authenticate via DKIM
• Offload SPF lookups to a server using SPF macros so that only one DNS lookup is ever used

You may have spotted another problem: An attacker could use a domain and SPF record that they control in the envelope from address, but forge (i.e., spoof) an address in the message from address that the user sees.

DKIM

Published in September 2011 as RFC 6376, DomainKeys Identified Mail (DKIM) allows sending email servers to add a cryptographic signature to an email on behalf of a domain. This signature can then be verified by receiving email server using a public key published in a DNS record at the signing domain, which validates the integrity of the email message content and key headers. Unlike SPF, DKIM verification survives message forwarding as long as the signed content has not been altered.

An email can have multiple DKIM signatures, which may or may not be from the domain of the message sender. Here is an example DKIM-Signature header in an email:

    DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/simple; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
    

The d value indicates that the email is signed by example.com, which can be verified using the DKIM key at the s1 selector, s1._dkim.example.com. Selectors are used so that different services can sign as a domain. The service provides the owners of the domain with the DKIM record to add to their domain. including a selector and public key, then the service signs those emails using the matching private key.

DMARC

Published in March 2015 as RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) provides a way for domain owners to stop unauthorized email from address spoofing by requiring that SPF or DKIM pass and that the domain checked (i.e., the envelope from for SPF and signing domain for DKIM) aligns with the message from address that the user sees. DMARC also provides mechanisms for receiving email servers to send reports about email authentication results back to domain owners. Google and Yahoo now both consider DMARC a requirement for bulk sending domains.

There are two types of DMARC reports: aggregate and failure (formerly called forensic reports). Aggregate reports (sometimes called rua reports) contain information about the aggregate number of emails that an email server has received containing the owner's domain in the message from address, including information about SPF and DKIM results and alignment. A domain owner should use these reports to ensure that all legitimate email senders are properly authenticated before moving from the monitor only DMARC policy, i.e., p=none to an enforced policy, i.e., p=quarantine or p=reject. Most receiving email services provide aggregate DMARC reports for domains that have a published DMARC record, with the notable exception of Proofpoint. Most receiving email servers do not provide DMARC failure/forensic/ruf reports for privacy reasons, because these reports contain the headers (and sometimes even the content) of individual emails that failed DMARC alignment. The open source tool ParseDMARC and many commercial services can parse these reports to provide actionable data.

DMARC policy DNS records are TXT records at the _dmarc subdomain, and use tag=value format, separated by semicolons.

Required DMARC policy tags

Tag	Description
v	Version (Required) Must be the first tag. Must be DMARC1
p	Policy (Required) Must be the one of the following: none: Monitor for DMARC failures but do not enforce it quarantine: Treat failed emails as suspicious (e.g., place them in a spam folder) reject: Reject emails that fail DMARC alignment
rua	(Optional) A comma separated list of email addresses prefixed with mailto: to send DMARC aggregate reports to. Only the first two addresses are required to be honored.
ruf	(Optional) A comma separated list of email addresses prefixed with mailto: to send DMARC failure reports to. Only the first two addresses are required to be honored.
sp	Subdomain Policy (Optional; The default mirrors the p value) A separate policy for subdomains. Makes policy enforcement inconsistent.
pct	(Optional; The default is 100) Percentage of messages to which the DMARC policy is to be applied. >Makes policy enforcement inconsistent.
ri	Reporting interval (Optional; The default is 86400) Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations must be able to provide daily reports and should be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best- effort basis.
fo	Failure reporting options (Optional; The default is 0) Provides requested options for generation of failure reports. Report generators may choose to adhere to the requested options. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows: 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result. 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result. d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.
rf	Report format (Optional; The default is afrf) The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both SPF and DKIM. afrf is currently the only valid format.
adkim	DKIM alignment r: Relaxed (Default): Organizational domain match s: Strict: FQDN match
aspf	SPF alignment r: Relaxed (Default): Organizational domain match s: Strict: FQDN match