Use definitions that preserve the identity being checked
Email-authentication vocabulary becomes useful when a definition says what is being identified, which evidence applies and what cannot be concluded. The entries below are substantive reference text with deterministic section anchors in this reader. They are not search results, a live validator or claims about EmailAuth functionality. Source review is dated 8 November 2026, and DMARC terminology follows the current published RFCs rather than silently mixing older policy language.
Author domain
The Author Domain is the domain of the message's RFC5322.From identity as defined by RFC 9989. It is central to DMARC alignment, but it is not automatically the envelope sender, login account or inbound mail host. When a diagnostic says the domain passed, ask which identity the statement actually refers to and retain the relevant message evidence.
Envelope sender and reverse path
The SMTP reverse-path is supplied through MAIL FROM and supports delivery-status handling. It can differ from the visible From address and can be empty for appropriate system-generated messages. RFC 5321 defines this transport role. A return-path address that looks unfamiliar is therefore a reason to investigate the sending design, not sufficient evidence that a message is forged.
SPF result
SPF evaluates whether the connecting source is authorized for the applicable MAIL FROM or HELO identity. RFC 7208 defines outcomes including pass, fail, softfail, neutral, none, temperror and permerror. A raw pass does not authenticate the visible From domain unless the relevant alignment requirement is also met. Configuration errors and temporary resolution failures must not be collapsed into a generic failure label.
DKIM signing domain
The d= value identifies the domain taking responsibility for a DKIM signature. Verification checks the signed message using a public key associated with that domain and selector, as specified by RFC 6376. It does not certify that the message's claims are honest or its content harmless. One message can carry several signatures, which need separate interpretation.
Selector
A selector is the s= label used with the signing domain to locate a DKIM public key beneath _domainkey, as defined in RFC 6376 section 3.1. It supports different keys or services without changing the basic signing domain. Its name is not standardized to a universally discoverable list. A missing guessed selector cannot prove that a domain has no DKIM, and a published selector alone cannot prove that messages are being signed successfully.
Identifier alignment
Alignment relates an authenticated SPF or DKIM domain to the Author Domain under the selected DMARC mode. Strict alignment requires the relevant domains to match exactly; relaxed alignment uses the organizational relationship defined by the current specification. RFC 9989 section 4.4 supplies the rules. Visual similarity, a familiar provider name or a matching display name is not alignment evidence.
DMARC result and assessment policy
A DMARC result records whether the message meets the authenticated-alignment conditions in RFC 9989. The published assessment policy communicates the domain owner's handling preference when validation fails; it does not guarantee a receiver's final disposition. A p=reject record is therefore not a universal delivery or security outcome. Review the actual authenticated identifiers, discovery path and receiver context before explaining what a policy accomplished.
Organizational domain and discovery
An Organizational Domain is a protocol-derived boundary used in relevant DMARC decisions, not necessarily the shortest plausible business name. Current RFC 9989 specifies bounded DNS Tree Walk procedures. Legacy implementations may use different discovery assumptions. A glossary should identify that version distinction rather than teaching a fixed string-trimming rule that fails for complex domain structures.
Aggregate report
An aggregate report summarizes authentication observations over a reporting period using the structure in RFC 9990. It supplies statistical evidence from a reporting receiver, not an exhaustive record of every message sent worldwide. Preserve reporter identity, time range, counts and provenance. Duplicate, overlapping or missing reports can distort a trend if the consumer treats every file as new complete coverage.
Failure report
A failure report supplies message-specific diagnostic information under RFC 9991. It may expose headers or message content and is subject to receiver willingness, privacy controls and rate limiting. Requesting it does not promise receipt of every failed message. Treat permission to receive and retain its contents separately from the technical publication of a reporting destination.
Authentication Results
Authentication-Results is a message header for communicating authentication assessments. RFC 8601 requires attention to trust boundaries: a header supplied by an untrusted sender cannot simply be accepted as the receiving system's verdict. Preserve which system added the field and which hop it describes. A pasted header without provenance can be useful context but is not authoritative proof.
MX and PTR
MX identifies receiving exchanges for a destination domain; PTR associates an address with a reverse-DNS name. RFC 1035 defines both record types. They answer different routing and naming questions. An organization's inbound MX does not enumerate all outbound senders, and forward-confirmed reverse DNS does not establish SPF, DKIM, DMARC or a favorable sender reputation.
Historic tags and stable references
The IANA DMARC registry marks pct, rf and ri historic and lists current active tags including t. Historic syntax still encountered in old configurations needs a version-aware explanation; it must not silently define current semantics. Stable entry anchors should remain unchanged when wording is refined, with obsolete terminology explained rather than abruptly redirected to a different concept.
This reader supplies definitions, linked primary references and mechanically checked local anchors. It does not close the catalogue's exact evidence gate: A functioning tool with expected-result fixtures, original inputs, observation time and explained errors. That commissioning requirement remains open for owner interpretation and actual acceptance evidence; a static reference page alone must not be represented as a tested operational tool.