emailmarketing.net

M3AAWG Email Authentication Recommended Best Practices (2020)

The industry checklist for SPF, DKIM, DMARC, and ARC deployment — concrete record requirements for senders, and what intermediaries and receivers are expected to do.

Operationalesp-operatorsender

This M³AAWG document is a checklist of binary technical requirements ("they either are or are not implemented") for authenticating email with SPF, DKIM, DMARC, and ARC. It covers three classes of actors — senders (originators), intermediaries (forwarders, mailing lists), and receivers (mailbox providers) — and it complements the concept-level material in DMARC.

SMTP AUTH (credentials presented at message submission, MUA/MSA → MTA) is explicitly out of scope — it serves a different purpose.

Why it matters: mailbox providers regularly speak of 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 pass muster with any such future mandate. The design goal throughout is protecting the organizational domain of the RFC5322.From header (the domain the recipient sees) — which implies a reliance on DMARC, since DMARC protects that domain in ways SPF and DKIM alone do not.

Protocol scope

Protocol RFC One-line role
SPF RFC 7208 Domain owners publish, via a DNS TXT record, the systems authorized to send email on their behalf.
DKIM RFC 6376 An organization claims responsibility for transmitting a message in a way the recipient can validate.
DMARC RFC 7489 A mail-originating organization expresses domain-level policies and preferences for validation, disposition, and reporting.
ARC RFC 8617 An authenticated chain of custody recording each handler and the authentication assessment at each hop. Not yet an internet standard; adoption increasing.

Executive checklist

Actor Recommended practices
Sender SPF: publish records for MAIL FROM and EHLO domains; end records in ~all; authorize no more IPs than necessary; align MAIL FROM with RFC5322.From where possible; publish v=spf1 -all on non-sending domains. DKIM: sign all outbound mail with a domain aligned with RFC5322.From; follow key-management best practices. DMARC: p=reject where possible, p=quarantine otherwise — p=none, sp=none, and pct<100 are transitional states to be removed as quickly as possible; always include a rua tag.
Intermediary Implement ARC. Generate DMARC reports.
Receiver Perform SPF, DKIM, and DMARC checks. Honor DMARC policies. A DMARC pass overrides an SPF fail verdict — except when the SPF record is v=spf1 -all. Send DMARC reports. Make use of ARC headers in received messages.

Sender recommendations

"Sender" = the origination point (brand owners, mailbox providers, ESPs — not end users sending person-to-person mail).

SPF

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

  • Ensure the record is valid and conforms to the DNS lookup limits in RFC 7208 (the 10-DNS-lookup limit).
  • Records should end in ~all (softfail) — see the receiver section for why -all interacts badly with forwarding before DMARC evaluation.
  • Authorize no more IPs than necessary: use the smallest possible netblock(s) for the IPs sending on the domain's behalf.
  • Domains that do not send email should publish v=spf1 -all (per M³AAWG Protecting Parked Domains BCP).
  • MAIL FROM domains should align with the RFC5322.From domain where possible.
  • Deeper reference: M³AAWG Best Practices for Managing SPF Records (https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf).

DKIM

Any domain-based reputation system needs a reliable method to confirm the identity of the domain taking responsibility for a message; DKIM is the best method currently available.

DMARC

  • M³AAWG recommends p=reject for domains publishing DMARC records; where that presents operational challenges, use p=quarantine.
  • p=none, sp=none, and pct<100 are transitional states only — the goal is to remove them as quickly as possible. (Contrast with the gentler "start at p=none" framing in our DMARC article; both agree the destination is Enforcement, driven by report data.)
  • Set policy by weighing the domain's risk profile for active or potential spoofing/phishing against the potential loss of legitimate mail due to missing or broken signing.
  • Every published DMARC record — even p=none — must include at minimum a rua tag pointing to a mailbox for aggregate reports. Without the ability to receive and process reports, the domain owner cannot know whether it is safe to move to stricter policies, because they cannot tell whether all legitimate mail authenticates properly.
  • ruf (failure reports) is optional: given privacy/PII-redaction concerns, failure reports are neither sent by most receivers nor terribly useful to most domain owners.
  • Neither the rua nor ruf mailbox should send replies (auto-responses) when receiving a report.

Intermediary recommendations

"Intermediaries" = RFC 5598 Mediators, Relays, or Gateways — forwarding services, mailing lists, discussion-group servers, and any mailbox configured to forward all mail to another domain. SPF/DKIM/DMARC are designed such that final authentication checks can fail for mail that passed through an intermediary even though it would have passed sent directly. M³AAWG calls on intermediaries to minimize that risk:

  • Minimize changes to the message in transit. Authentication depends on header content and/or the body; alteration (sometimes unavoidable for mailing lists) should be kept to a minimum.
  • Mitigate the risk of authentication failures. Canonical example — a mailing list that adds a header/footer to each post should rewrite the From header when the poster's domain publishes DMARC:
    1. member posts from john.jones@dmarc.domain.tld;
    2. list software sees dmarc.domain.tld publishes a DMARC policy;
    3. list rewrites From to e.g. john.jones=40dmarc.domain.tld@list.domain, eliminating the DMARC-failure risk.
  • Implement ARC. ARC records authentication results at each hop without modifying message content, protecting against downstream failures caused by transiting the intermediary. Implicit in this: the intermediary must itself perform the SPF/DKIM/DMARC checks whose results are captured in the ARC-Authentication-Results header.
  • Generate and send DMARC aggregate reports.

Receiver recommendations

"Receivers" = domains that accept and store mail for their recipients (a broader term than "mailbox provider" since much email terminates at non-MBP domains). These mechanisms are likely to be increasingly required; where they exceed a small domain's IT skills, M³AAWG calls on the cloud hosting services those domains migrate to to implement them.

  • Perform authentication checks (SPF, DKIM, DMARC) on inbound mail and use the results to inform acceptance and filtering — 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 passing messages to genuinely be from the From-line domain. Local policy overrides should be (a) relatively infrequent and (b) clearly justified and documented via the aggregate report's policy-override and comment fields.
  • A DMARC pass overrides an SPF fail verdict. Because DMARC needs only an aligned DKIM or SPF pass, and Return-Path domains commonly don't align with the From domain, an SPF fail (record ends in -all and the check fails) should not cause rejection until DMARC has been evaluated and found not to pass.
    • Sole exception: v=spf1 -all — a record declaring no allowed use at all. There the receiver (or intermediary) may take preemptive action on the SPF failure.
  • Send DMARC aggregate reports. Reports let domain owners tighten authentication whether or not they move to p=reject: without them, owners can't identify legitimate non-authenticating streams 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 report senders consider current legal opinions (e.g., the certified-senders.org report on DMARC and the EU GDPR).
  • Make use of ARC headers: consider arriving ARC header sets as part of the final authentication verdict and disposition.

References carried by the document

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

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

Document URL
Best Practices for Managing SPF Records (2017-08) https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf
DKIM Key Rotation BCP (2019-03) 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 (2017-07) https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf
Protecting Parked Domains BCP (2015-12) https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf
Trust in Email Begins with Authentication (2015) https://www.m3aawg.org/sites/default/files/document/M3AAWG_Email_Authentication_Update-2015.pdf
Report on the Compliance of DMARC with the EU GDPR https://certified-senders.org/wp-content/uploads/2018/08/Report_DMARC_and_GDPR.pdf

Related

#authentication#m3aawg#spf#dkim#dmarc#arc#alignment#best-practices#forwarding#mailing-lists

Sources