Start with the authority and the question
An email-authentication library should help a reader select the right primary document, not merely collect links. Protocol rules, parameter registries, provider requirements and product observations answer different questions. This curated guide records the scope and status of key sources reviewed on 8 November 2026. Its entries have stable reader anchors; they do not establish that a tenant, receiver or EmailAuth implementation conforms to those sources.
For each operational requirement, retain the issuing authority, document identifier, version or revision date, affected population, accountable owner and acceptance evidence. A publication date is not automatically a provider enforcement date. A working library also needs maintenance: changed links, new updates and unresolved source conflicts must be visible rather than hidden behind an old reviewed badge.
DMARC core RFC 9989
RFC 9989 is the May 2026 core DMARC specification, covering authenticated identifiers, alignment, policy discovery and assessment-policy semantics. Its RFC Editor information record identifies it as Proposed Standard; the document is Standards Track and obsoletes RFCs 7489 and 9091. Use it for current core rules, while separately testing legacy implementation differences. The policy version remains DMARC1, not a version invented from the new RFC number.
Aggregate reporting RFC 9990
RFC 9990 is the separate May 2026 aggregate-reporting specification. The RFC Editor record identifies Proposed Standard status. It addresses report structure, processing, external destinations, duplicates and privacy/security considerations. It should support a report parser's acceptance cases, not be treated as evidence that every receiver sends complete reports or that a dashboard's totals are correct.
Failure reporting RFC 9991
RFC 9991 is the May 2026 Standards Track failure-reporting specification, updates RFC 6591 and participates with the other two documents in replacing RFC 7489. Its focus is message-specific diagnostics, reporting format, external destinations and privacy. The separate information-page read was rate-limited during this review; the successfully read RFC text supports the stated category. Do not confuse failure reports with aggregate statistics or assume that publishing ruf guarantees reports.
SPF RFC 7208
RFC 7208, published in April 2014 on the Standards Track, defines SPF identities, policy record selection, evaluation and result handling. It is the primary starting point for explaining a permerror or the DNS-querying-term limit. Read the relevant section and its dependencies rather than reducing SPF to a list of permitted IP addresses or assuming every DNS operation counts identically.
DKIM RFC 6376 and algorithm updates
RFC 6376, published in September 2011 on the Standards Track, defines DKIM signatures, selectors, keys and verification. Read its cryptographic provisions with RFC 8301, January 2018, and RFC 8463, September 2018. The former prohibits RSA-SHA1 and strengthens RSA key requirements; the latter defines Ed25519 use. An older base document remains useful without making every original algorithm recommendation current.
SMTP DNS and explicit no mail
RFC 5321, October 2008, supplies SMTP transport and target-resolution rules. RFC 1034 and RFC 1035, November 1987, provide foundational DNS concepts and record structure. Use RFC 2308, March 1998, for negative-answer distinctions rather than an obsolete negative-caching shortcut. These references are starting points with later updates, not a complete modern DNS implementation specification.
RFC 7505, June 2015, defines null MX for a domain that explicitly accepts no mail. Its sender guidance cautions against using a null-MX domain for either MAIL FROM or visible From identities: receivers may refuse that traffic. Keep that sender guidance distinct from SPF and from SMTP's null reverse-path. A deliberate no-mail record is not a missing or malfunctioning MX.
Authentication result provenance RFC 8601
RFC 8601, May 2019, defines the Authentication-Results header and its trust considerations. Use it when evaluating who made an authentication assertion and whether that assertion belongs inside the receiving system's trusted boundary. It does not turn an arbitrary header copied from a message into authenticated evidence, nor does it establish inbox placement from a pass token.
IANA parameter registries
The DMARC parameter registry, updated 22 May 2026 in the retrieved record, connects tags to references and active or historic status. It marks pct, rf and ri historic and includes active tags such as np, psd and t. The DKIM parameter registry identifies registered signature tags and associated definitions. Registration is a vocabulary reference, not proof that a deployment supports a parameter correctly.
Status and implementation are separate evidence
An Internet-Draft is a working document, not a published RFC merely because it resembles one. RFC 2026 section 2.2 explains that distinction; later process updates mean its historical standards ladder should not be treated as the complete current process. Also distinguish Standards Track from Informational, Experimental and Best Current Practice documents. Cite the actual status record rather than assuming every numbered RFC has the same authority.
For a provider rule, record the product, route, cloud environment, affected senders, announcement and enforcement dates separately. A conflict between official pages belongs in the requirement register until an applicable current source or controlled observation resolves it. A synthetic parser result can test local interpretation but cannot prove remote adoption.
The exact catalogue requirement remains open: A requirement register with authority, scope, effective date, owner and acceptance evidence. The curated map below supplies source entries and proposed ownership, not completed organization-specific acceptance. The intake also asks for working functionality and testing. Static anchors and primary links are delivered, but functioning-tool acceptance, applicability, technical review and publication approval remain outstanding.