Why the vocabulary is confusing
Email has two sender addresses, three overlapping authentication systems and a reporting layer, each defined in a different standard. Vendor setup screens then shorten the terms differently: one calls it a return path, another a bounce domain, a third the envelope sender. They are the same thing.
This glossary uses the names from the standards (RFC 7208 for SPF, RFC 6376 for DKIM, RFC 9989 for DMARC, RFC 8617 for ARC and RFC 8601 for the Authentication-Results header) and notes the common aliases. [1] [2] [3] [4] [5] Every term is placed where you will actually meet it: a DNS record, a header line, or a report.
An annotated header, line by line
Below is an illustrative, shortened set of headers for a newsletter from example.com sent through an email platform. Signatures are truncated and addresses use reserved example domains. To see the real headers of any message in Gmail, open it, choose More next to Reply, then Show original; Outlook, Apple Mail and Yahoo Mail have equivalents. [8]
| Header line (illustrative) | Terms it contains | What it tells you |
|---|---|---|
| Return-Path: <[email protected]> | Envelope from, return path, RFC5321.MailFrom | The address bounces go to and the domain SPF was checked against. Kit, for example, describes the return-path as the machine-visible address. [9] |
| Received-SPF: pass client-ip=192.0.2.25; [email protected] | SPF result, client IP | Received-SPF results can be pass, fail, softfail, neutral, none, temperror or permerror. [1] |
| DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date; bh=...; b=... | Signing domain d=, selector s=, algorithm a=, signed headers h=, body hash bh=, signature b= | Which domain vouches for the message and where its public key lives: s1._domainkey.example.com. [2] |
| ARC-Seal: i=1; cv=none; ... | ARC instance i=, chain validation cv= | A forwarder recorded results here. cv=none on the first set is normal. [4] |
| Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=mail.example.com; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=example.com | authserv-id, method=result, smtp.mailfrom, header.d, header.s | The receiving server's verdicts. Only trust this line when the receiving server you control added it. [5] |
| From: Maya at Fieldworks <[email protected]> | Header from, RFC5322.From, Author Domain, display name | The address readers see. DMARC aligns everything against example.com here. [3] |
Addresses and identities
- Envelope from (MAIL FROM, RFC5321.MailFrom, return path, bounce address): the address given in the SMTP conversation. SPF checks this identity, and DMARC uses only the SPF result for this identity, not for HELO. [1] [3]
- HELO or EHLO identity: the name the sending server announces. SPF can check it too, and RFC 7208 recommends that verifiers check it separately as well as the MAIL FROM identity. [1]
- Header from (RFC5322.From, friendly from): the address in the From line. DMARC calls its domain the Author Domain. [3] Google asks that it contain only one address and that the display name only identify the sender. [6]
- Organizational Domain: broadly, the registered domain a name belongs to, such as example.com for news.example.com. RFC 9989 finds it with a DNS tree walk instead of relying on a public suffix list. [3]
- PTR record (reverse DNS): maps an IP address back to a hostname. Google requires all senders to have valid forward and reverse DNS for sending IPs. [6] Do not confuse it with the SPF ptr mechanism, which RFC 7208 says should not be published. [1]
SPF terms
| Term | Meaning | Example |
|---|---|---|
| v=spf1 | Version tag that every SPF record must start with, published as a TXT record. Only one SPF record is allowed per name; more than one gives permerror. [1] | v=spf1 ... ~all |
| Mechanism | A test of the sending IP: all, include, a, mx, ptr, ip4, ip6, exists. [1] | ip4:192.0.2.0/24 |
| include | Runs SPF on another domain's record; matches only if that record returns pass. [1] | include:_spf.google.com |
| Qualifier | Prefix that sets the result when a mechanism matches: + pass (default), - fail, ~ softfail, ? neutral. [1] | -all |
| all | Always matches, so it goes last; anything after it is ignored. [1] | ~all |
| softfail | A weak statement that the host is probably not authorized. [1] | Result of ~all |
| redirect= | Modifier that hands evaluation to another domain's record if nothing matched. [1] | redirect=_spf.example.com |
| Lookup limit | At most 10 terms that cause DNS lookups; exceeding it gives permerror. [1] | Each include counts |
DKIM terms
- DKIM-Signature: the header a signer adds. Required tags include v=, a=, b=, bh=, d=, h= and s=. [2]
- d= (signing domain, SDID): the domain claiming responsibility for the message. For DMARC, a DKIM pass only counts if this domain aligns with the From domain. [2] [3]
- s= (selector): picks one of several keys a domain can publish. The verifier looks up the key at selector._domainkey.d-domain. [2]
- Key record: a TXT record with tags such as v=DKIM1, k=rsa and p= (the public key). An empty p= means the key has been revoked. [2]
- Key length: signers must use RSA keys of at least 1024 bits for long-lived keys; verifiers must handle 512 to 2048 bits. [2]
- Canonicalization (c=): simple or relaxed handling of whitespace and header case before signing; the default is simple/simple. [2]
DMARC terms
| Term | Meaning |
|---|---|
| _dmarc | The DNS name the policy lives at: a TXT record at _dmarc.example.com. [3] |
| DMARC pass | SPF or DKIM passes for a domain aligned with the From domain. A plain SPF or DKIM pass on an unrelated domain is not enough. [3] |
| Alignment, relaxed and strict | Relaxed: same Organizational Domain. Strict: identical domains. adkim= and aspf= set the mode; both default to relaxed. [3] |
| p= | Policy for the domain: none, quarantine or reject. A record without p= is treated as none. [3] |
| sp= and np= | Policies for existing subdomains and for non-existent subdomains. [3] |
| rua= | Where aggregate reports go, as mailto: addresses. Without it, no aggregate reports are generated. [3] |
| ruf= and fo= | Failure report address and options; fo= is ignored without ruf=. [3] |
| t= | Test mode: t=y asks receivers to apply the policy one level lower. RFC 9989 uses this in place of the older pct tag. [3] |
| psd= | Marks a public suffix domain; most senders never set it. [3] |
ARC and BIMI terms
- ARC (Authenticated Received Chain): an Experimental RFC, not a standards-track one, that lets each intermediary record the authentication results it saw, so later receivers can see the chain of custody. [4]
- ARC Set: three headers sharing one instance number i=, from 1 to 50: ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal. [4]
- cv=: chain validation status in the ARC-Seal: none (no chain before this hop), pass or fail. A failed chain is treated like no chain. [4]
- ARC trust: receivers decide whether to trust a sealer; ARC is not a trust framework and does not dictate delivery. [4]
- BIMI: a TXT record, usually at default._bimi.yourdomain, pointing to an SVG Tiny PS logo with l= and, where required, a VMC or CMC certificate with a=. [7]
- Enforcement: for BIMI purposes, a DMARC policy of quarantine or reject. Most providers that support BIMI require it before showing a logo. [7]
Questions before you decide
What is the difference between envelope from and header from?
The envelope from is the RFC5321.MailFrom address given during the SMTP conversation; SPF checks it and bounces go to it. The header from is the RFC5322.From address the reader sees. DMARC calls the header from domain the Author Domain and requires an authenticated domain to align with it.
What does alignment mean in DMARC?
Alignment means the domain that passed SPF or DKIM matches the From domain. Under relaxed alignment, the default for both adkim and aspf in RFC 9989, they only need to share an Organizational Domain. Under strict alignment they must be identical.
Is the pct tag still part of DMARC?
Not in RFC 9989. Its tag list has no pct; the specification uses a t= test-mode flag instead, which asks receivers to apply the policy one level lower, so reject is treated as quarantine and quarantine as none.
Does ARC make forwarded mail pass DMARC?
Not by itself. RFC 8617 says ARC does not dictate delivery decisions. Receivers may use a validated ARC chain in local policy, including DMARC decisions, and decide for themselves whether to trust the intermediary that added it.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- RFC 7208: Sender Policy Framework (SPF) Accessed 30 Oct 2026
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures Accessed 30 Oct 2026
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Accessed 30 Oct 2026
- RFC 8617: The Authenticated Received Chain (ARC) Protocol Accessed 30 Oct 2026
- RFC 8601: Message Header Field for Indicating Message Authentication Status Accessed 30 Oct 2026
- Google: Email sender guidelines Accessed 30 Oct 2026
- BIMI Group: FAQs for senders and ESPs Accessed 30 Oct 2026
- Gmail Help: Trace an email with its full headers Accessed 30 Oct 2026
- Kit Help: Verify your domain to optimize your deliverability Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.