M3AAWG Email Authentication Recommended Best Practices (2020)

Whether you send mail, forward it or receive it, the industry expects a specific set of authentication measures from you. The Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) sets them out in its Email Authentication Recommended Best Practices, a checklist of binary technical requirements ("they either are or are not implemented") for authenticating email with SPF, DKIM, DMARC and ARC.

The checklist covers three kinds of actors: senders (originators), intermediaries (forwarders, mailing lists) and receivers (mailbox providers). DMARC explains the underlying concepts.

SMTP AUTH (the credentials presented when a message is submitted, from the MUA or MSA to the MTA) is explicitly out of scope, because it serves a different purpose.

Why it matters: mailbox providers regularly talk about a possible "No auth, no entry" future, in which a message must pass one or more authentication checks to be considered for delivery at all. These guidelines aim to establish trust today, and to meet any such requirement in the future. Throughout, the goal is to protect the organizational domain of the RFC5322.From header (the domain the recipient sees). That means relying on DMARC, which protects that domain in ways SPF and DKIM alone do not.

Protocol scope

Executive checklist

Sender recommendations

A sender is the point where mail originates: brand owners, mailbox providers and ESPs, but not end users sending mail from person to person.

SPF

Publish SPF records for every domain used in the RFC5321.MailFrom (MAIL FROM) command and for every domain used as the SMTP HELO or EHLO identity of any sending server.

• Make sure the record is valid and stays within the DNS lookup limits in RFC 7208 (the 10-DNS-lookup limit).
• Records should end in ~all (softfail). The receiver section below explains why -all interacts badly with forwarding before DMARC is evaluated.
• Authorize no more IP addresses than necessary. Use the smallest possible netblocks for the IP addresses that send on the domain's behalf.
• Domains that do not send email should publish v=spf1 -all (as the M³AAWG Protecting Parked Domains BCP recommends).
• MAIL FROM domains should align with the RFC5322.From domain where possible.
• For more detail, see M³AAWG Best Practices for Managing SPF Records (https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf).

DKIM

Any reputation system based on domains needs a reliable way to confirm the identity of the domain that takes responsibility for a message, and DKIM is the best method available today.

• Sign all outbound mail with a DKIM key whose d= domain aligns with the RFC5322.From domain.
• ESPs should strongly consider also signing with their own domain, so that receivers can build a separate reputation for each domain.
• ESPs should use a different DKIM key for each customer.
• Sign a reasonable set of header fields, using section 5.4.1 of RFC 6376 as the guide.
• For key management, M³AAWG refers to:
  • DKIM Key Rotation Best Common Practices (revised March 2019: https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)
  • Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (revised July 2017: https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf)

DMARC

• M³AAWG recommends p=reject for domains that publish DMARC records. Where that creates operational problems, use p=quarantine.
• p=none, sp=none and pct<100 are only transitional states, and the goal is to leave them as quickly as possible. (Compare the gentler advice to "start at p=none" in DMARC. Both agree that the destination is Enforcement, guided by the report data.)
• Set the policy by weighing the domain's risk profile, for active or potential spoofing and phishing, against the possible loss of legitimate mail because of missing or broken signing.
• Every published DMARC record, even one with p=none, must include at least a rua tag pointing to a mailbox for aggregate reports. Without the ability to receive and process reports, domain owners cannot know whether it is safe to move to a stricter policy, because they cannot tell whether all their legitimate mail authenticates properly.
• ruf (failure reports) is optional. Because of privacy concerns and the redaction of personal data (PII), most receivers do not send failure reports, and they are not very useful to most domain owners.
• Neither the rua mailbox nor the ruf mailbox should send replies (auto-responses) when it receives a report.

Intermediary recommendations

Intermediaries are the Mediators, Relays and Gateways of RFC 5598: forwarding services, mailing lists, discussion-group servers, and any mailbox set to forward all mail to another domain. SPF, DKIM and DMARC are designed in a way that means final authentication checks can fail for mail that passed through an intermediary, even though the same mail would have passed if sent directly. M³AAWG asks intermediaries to reduce that risk:

• Change the message as little as possible in transit. Authentication depends on the content of the headers and/or the body, so any alteration (sometimes unavoidable for mailing lists) should be kept to a minimum.
• Reduce the risk of authentication failures. The standard example is a mailing list that adds a header or footer to each post. It should rewrite the From header when the poster's domain publishes DMARC:
  1. a member posts from john.jones@dmarc.domain.tld;
  2. the list software sees that dmarc.domain.tld publishes a DMARC policy;
  3. the list rewrites From to, for example, john.jones=40dmarc.domain.tld@list.domain, which removes the risk of a DMARC failure.
• Implement ARC. ARC records the authentication results at each hop without changing the message content, which protects against failures further along the path caused by passing through the intermediary. This implies that the intermediary must itself perform the SPF, DKIM and DMARC checks whose results go into the ARC-Authentication-Results header.
• Generate and send DMARC aggregate reports.

Receiver recommendations

Receivers are the domains that accept and store mail for their recipients. The term is broader than "mailbox provider", because much email ends up at domains that are not mailbox providers. These mechanisms are likely to become more and more necessary. Where they are beyond the IT skills of a small domain, M³AAWG asks the cloud hosting services that such domains move to to implement them.

• Perform authentication checks (SPF, DKIM, DMARC) on inbound mail, and use the results to decide on acceptance and filtering. This is best practice for protecting mailbox holders from fraudulent email, whether or not the receiver adopts "no auth, no entry."
• Honor DMARC policies. When a domain publishes DMARC (especially p=reject), recipients expect messages that pass to genuinely come from the domain in the From line. Overrides by local policy should be (a) relatively rare and (b) clearly justified and documented in the policy-override and comment fields of the aggregate report.
• A DMARC pass overrides an SPF fail verdict. DMARC needs only an aligned DKIM or SPF pass, and Return-Path domains often do not align with the From domain. So an SPF fail (the record ends in -all and the check fails) should not cause rejection until DMARC has been evaluated and found not to pass.
  • The only exception is v=spf1 -all, a record that allows no use at all. In that case the receiver (or intermediary) may act on the SPF failure right away.
• Send DMARC aggregate reports. Reports let domain owners tighten their authentication, whether or not they move to p=reject. Without reports, owners cannot identify legitimate streams that fail authentication, or see impersonation attempts and misconfigured vendors. Several large mailbox providers have concluded that sending aggregate reports does not conflict with privacy laws. M³AAWG recommends that report senders consider current legal opinions (for example, the certified-senders.org report on DMARC and the EU GDPR).
• Use ARC headers: take the ARC header sets on arriving mail into account in the final authentication verdict and disposition.

References carried by the document

RFCs: 5598 (Internet Mail Architecture), 6376 (DKIM), 7208 (SPF), 7489 (DMARC), 8617 (ARC).

Related M³AAWG documents (see also the document index):

Related articles

• DMARC, on alignment, record syntax and moving between policies
• M3AAWG Sender Best Common Practices, on the forward DNS, reverse DNS and HELO requirements that SPF depends on, and on DKIM for each customer in shared IP pools
• M3AAWG document index