Email Authentication Glossary
Definitions for the working vocabulary of email authentication. Each term: what it is, why it matters, and where to read more.
This is the working vocabulary of email authentication. Each term is short by design — definition, one line of "why it matters," and a link to the guide that covers it in depth. If you want a structured reading path through the same material, start with Email Authentication 101.
Terms are grouped: protocols, then SPF specifics, then DKIM specifics, then DMARC specifics, then identifiers, reports, and adjacent protocols.
Protocols
SPF (Sender Policy Framework)
A DNS TXT record listing the IPs and hosts authorized to send mail on behalf of a domain. Receivers check the sending IP against this list. Specified in RFC 7208.
Why it matters: SPF is one of the two authentication mechanisms DMARC checks. It is also the most common source of "I thought I set this up" deliverability problems, because the 10-lookup budget breaks silently. See How to Build an SPF Record.
DKIM (DomainKeys Identified Mail)
A cryptographic signature attached to each outgoing message, verified by a public key published in DNS at <selector>._domainkey.<domain>. Specified in RFC 6376.
Why it matters: DKIM proves the message wasn't forged or modified in transit, and unlike SPF it survives forwarding. See DKIM Standard Explained.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
A DNS TXT record at _dmarc.<domain> that tells receivers what to do when SPF and DKIM fail to align with the visible From: header, and asks them to send aggregate reports. Specified in RFC 7489.
Why it matters: DMARC is the only one of the three protocols that protects the From: header that users actually see. See DMARC Deployment Guide.
SPF Specifics
SPF Mechanism
The tokens inside an SPF record that evaluate to pass, fail, softfail, or neutral: include:, a, mx, ip4:, ip6:, ptr (deprecated), exists:, all. Each is preceded by an optional qualifier (+, -, ~, ?) and evaluated left-to-right; the first match wins.
Why it matters: Building a correct SPF record is a question of choosing the right mechanism for each sender. See How to Build an SPF Record.
SPF Lookup Budget (10-Lookup Limit)
SPF evaluation is capped at 10 DNS lookups total. include:, a, mx, exists:, and redirect= each consume the budget; ip4:, ip6:, and all do not. Exceeding the budget produces a permerror and SPF is treated as failed.
Why it matters: This is the single most common SPF problem. Google Workspace alone consumes 3–4 lookups; add a marketing tool and a transactional tool and you're over. See Fix SPF PermError: Too Many DNS Lookups.
SPF Flattening
A technique for keeping a domain's published SPF record under the 10-lookup limit by resolving include: mechanisms to their underlying IP ranges and publishing the IPs directly. Requires ongoing maintenance because upstream provider IP ranges change.
Why it matters: It is the standard fix when you cannot reduce your sender list. mxio's Managed SPF does the resolution and maintenance automatically. See What Is SPF Flattening?.
all Mechanism
The last mechanism in a well-formed SPF record. -all (hard fail), ~all (softfail), ?all (neutral), and +all (pass — never use this) tell the receiver what to do with IPs that didn't match any earlier mechanism.
Why it matters: Most providers treat -all and ~all the same in practice — both rely on DMARC for enforcement — but -all is the standard choice and the one DMARC reports treat as a clean SPF fail.
DKIM Specifics
DKIM Selector
A label that identifies which DKIM key to use. The full DNS lookup is <selector>._domainkey.<domain>. Each sending service typically uses its own selector (e.g., Google uses google, MailRoute uses mr01/mr02/mr03, Microsoft uses selector1/selector2).
Why it matters: Selectors are how a single domain can have many DKIM keys at once without conflict. They are also how you rotate a key — publish a new selector, switch signing, retire the old selector.
DKIM Signature
The DKIM-Signature: header attached to a signed message. It contains the signing domain (d=), the selector (s=), the canonicalization mode (c=), the signed headers (h=), the body hash (bh=), and the signature itself (b=).
Why it matters: When DMARC reports show DKIM failures, the signature header is what you inspect first. See Email Header Analysis.
DKIM Key Size
The size of the RSA key used to sign messages. 2048-bit is the modern minimum; 1024-bit is still accepted but considered weak and is being warned about by some providers; 4096-bit may exceed DNS TXT record size limits without splitting.
Why it matters: Old DKIM setups often have 1024-bit keys that nobody has rotated. Rotate to 2048-bit when you have an opportunity.
DMARC Specifics
DMARC Alignment
DMARC requires that the domain authenticated by SPF or DKIM align with the domain in the visible From: header. Alignment can be relaxed (organizational-domain match: mail.example.com aligns with example.com) or strict (exact match required).
Why it matters: A message can pass SPF or DKIM for one domain while displaying a From: header for a completely different domain. Alignment is what closes that gap. Configured via the adkim= (DKIM alignment) and aspf= (SPF alignment) tags in the DMARC record.
p= (DMARC Policy)
The action receivers should take when a message fails authentication: p=none (no action, but report), p=quarantine (deliver to spam), or p=reject (refuse delivery).
Why it matters: p=none is for monitoring only. Real enforcement requires p=quarantine or p=reject. The standard deployment journey is none → quarantine → reject. See The DMARC Enforcement Journey.
sp= (DMARC Subdomain Policy)
A separate policy that applies only to subdomains of the published domain. If absent, subdomains inherit the p= policy.
Why it matters: A common pattern is p=reject on the organizational domain and sp=reject on subdomains, so that an unauthorized subdomain (e.g., marketing.example.com) can't be used to spoof from a long-forgotten host.
pct= (DMARC Percentage)
The percentage of failing messages to which the policy applies during rollout. pct=10 means 10% of failures get the p= treatment; the other 90% are treated one step softer (none → quarantine for that 90%, etc.).
Why it matters: It is the safety valve when ratcheting from p=none to p=quarantine to p=reject. Start low and increase.
rua / Aggregate Report
The DMARC tag specifying email addresses that should receive aggregate reports — daily XML summaries of authentication results, sender IPs, and disposition counts. Format: rua=mailto:reports@example.com.
Why it matters: Aggregate reports are the only way to discover senders you didn't know about. mxio's DMARC dashboard parses and groups them. See DMARC Aggregate Report Explained.
ruf / Forensic Report
The DMARC tag specifying addresses to receive forensic reports — per-message redacted copies of failing messages. Format: ruf=mailto:forensics@example.com.
Why it matters: Most large receivers (Google, Microsoft) do not send forensic reports due to privacy concerns. They are largely historical at this point; aggregate reports do the heavy lifting.
Identifiers
RFC5321.MailFrom (Envelope From, Return-Path)
The domain used during the SMTP envelope (MAIL FROM:). SPF authenticates this domain. The user never sees it directly; it appears in the Return-Path: header.
Why it matters: Knowing that SPF authenticates the envelope and DMARC authenticates the From: header is the prerequisite for understanding alignment. See the SPF section of the main guide.
RFC5322.From (Header From)
The domain in the visible From: header — what the user sees in their mail client. DMARC aligns SPF or DKIM results against this domain.
Why it matters: This is the domain attackers want to spoof. DMARC is the only one of the three protocols that protects it.
Reports and Verification Headers
Authentication-Results Header
A header added by the receiving server that records the outcome of SPF, DKIM, and DMARC evaluation. It is the primary surface for debugging "why did this message fail?"
Why it matters: When a customer says "your email landed in spam," the first thing you read is the Authentication-Results: line in the original headers. See Email Header Analysis.
ARC (Authenticated Received Chain)
A set of headers (RFC 8617) that preserve the original authentication results across forwarding hops. A trusted forwarder (a mailing list, a corporate filter) signs an ARC seal vouching that the message passed authentication when it first arrived.
Why it matters: ARC is how DMARC survives mailing lists and forwarders. Most large receivers honor ARC from trusted senders.
Adjacent Protocols
MTA-STS (Mail Transfer Agent Strict Transport Security)
A policy published at _mta-sts.<domain> and fetched over HTTPS that tells sending servers to require TLS when delivering mail to your domain. Specified in RFC 8461.
Why it matters: Opportunistic TLS in SMTP is vulnerable to downgrade attacks. MTA-STS closes that hole. See MTA-STS Explained.
TLS-RPT (SMTP TLS Reporting)
A reporting protocol (RFC 8460) that tells senders where to send daily reports about TLS-delivery failures to your domain. Configured as a DNS TXT record at _smtp._tls.<domain>.
Why it matters: It pairs with MTA-STS — MTA-STS sets the policy, TLS-RPT tells you when senders couldn't comply.
BIMI (Brand Indicators for Message Identification)
A DNS TXT record at default._bimi.<domain> that publishes a brand logo (and, for most placements, a Verified Mark Certificate) for display next to authenticated mail in compatible clients.
Why it matters: BIMI requires DMARC at p=quarantine or p=reject. It is a brand-trust signal, not a security control, but it is a meaningful incentive to finish DMARC enforcement.
DNSSEC (Domain Name System Security Extensions)
Cryptographic signatures over DNS records, validated against a chain of trust rooted at the DNS root zone. Specified in RFC 4033.
Why it matters: DNSSEC defends against DNS spoofing — without it, an attacker who can poison a recursive resolver can serve forged SPF, DKIM, and DMARC records. See DNSSEC Explained.
Result States
PermError vs TempError
permerror means evaluation failed in a way that won't resolve by itself (most commonly: SPF exceeded the 10-lookup limit, or a record is syntactically invalid). temperror means a transient failure — usually a DNS timeout — that may succeed on the next attempt.
Why it matters: permerror is a configuration bug you need to fix. temperror is usually a DNS reliability issue (your DNS host's), not a record problem.
SPF Forwarding Break
When a message is forwarded by an intermediate server, the forwarding server's IP is not in the original domain's SPF record, so SPF fails at the final destination. This is an architectural property of SPF, not a bug.
Why it matters: It is the single biggest reason DMARC was designed to pass on either SPF or DKIM alignment. DKIM survives forwarding; SPF doesn't. See Email Forwarding and Authentication.
Related Articles
A curated reading path through email authentication. Start here if SPF, DKIM, and DMARC are new to you — or if you've been working around them and want to actually understand what's happening.
Understand how SPF, DKIM, and DMARC work together to protect your domain from spoofing and improve email deliverability. A practical guide for email administrators.
Build a correct SPF record for your domain using the mxio SPF Builder. Select your email providers, set your policy, and publish with confidence.
SPF flattening resolves include mechanisms to IP addresses, reducing DNS lookups. Learn how it works, the risks of manual flattening, and when you need automated flattening.
Step-by-step guide to deploying DMARC on your domain. Start with monitoring, identify unauthorized senders, and safely progress to full enforcement.
A practical walkthrough of DMARC aggregate report XML. What the format contains, how to read source IPs, what alignment means in context, and the common patterns to recognize.
A field-by-field walkthrough of the DMARC aggregate XML. Worked example, what each element tells you, what the report does not tell you, and how to turn it into action.
MTA-STS forces sending servers to use TLS when delivering email to your domain, closing the gap left by opportunistic STARTTLS. This guide covers the DNS TXT record, the HTTPS-hosted policy file, testing vs enforce mode, and common deployment mistakes.
Email forwarding breaks SPF and can cause DMARC failures. Learn how SRS fixes SPF, why DKIM alignment matters for forwarded mail, and what domain owners and recipients can do.
Learn how to read email headers to diagnose SPF, DKIM, and DMARC authentication failures. Understand Authentication-Results headers and trace delivery paths.
A section-by-section walkthrough of RFC 7208, the standard that defines SPF. Covers every mechanism, qualifier, the 10-lookup limit, void lookups, ptr deprecation, macros, and security considerations — with practical examples and tool links.
Annotated walkthrough of RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. How signing works, key record format, canonicalization modes, verification steps, and security guidance from the spec itself.
Annotated walkthrough of RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance. Policy tags, alignment, reporting, and security considerations from the spec itself.
A section-by-section walkthrough of RFC 8461, the standard that defines SMTP MTA Strict Transport Security (MTA-STS). Covers the STARTTLS downgrade problem, policy discovery via DNS TXT records, the HTTPS-hosted policy file, enforcement modes, MX matching rules, caching behavior, and how MTA-STS compares to DANE — with practical examples and tool links.