21 June 2026 · 18 min read
Email authentication has its own dense vocabulary: a single DMARC report can mention SPF, DKIM, alignment, the return-path, the header From, a selector and a policy tag inside one paragraph, and most of those words assume you already know the other ones. This glossary collects the terms you actually meet when you take a domain from p=none to p=reject, when you read an aggregate report, or when you try to work out why a logo is not showing in Gmail. Each entry is one plain paragraph, written in British English, with no jargon left dangling. Where a fuller reference page or a free tool exists, the entry links to it so you can dig deeper or check your own domain straight away.
The list is grouped by theme rather than strictly alphabetically, because the concepts cluster: the three core protocols, then how they fit together under alignment, then the transport-security and brand-logo layers that sit on top, then the report types, and finally the abuse and infrastructure terms that explain why all of this exists. If you only read one thing, read the alignment entry, because it is the idea that ties SPF, DKIM and DMARC together and the one most people get wrong.
The three core protocols
SPF (Sender Policy Framework)
SPF is a DNS TXT record, published at your domain root and beginning v=spf1, that lists which mail servers are allowed to send email for your domain. A receiving server takes the IP address that connected over SMTP, looks up the return-path domain's SPF record, and checks whether that IP is authorised by a mechanism such as ip4, a, mx or include. The record ends with an "all" qualifier that says what to do with everything not listed. SPF only ever inspects the envelope sender, never the address a human sees, and it breaks the moment mail is forwarded, which is exactly why it cannot stand alone. Read the full reference at SPF, see how we manage it on our SPF product page, or test a live record with the SPF checker.
DKIM (DomainKeys Identified Mail)
DKIM attaches a cryptographic signature to each outgoing message. The sending server signs selected headers and the body with a private key, and adds a DKIM-Signature header that names the signing domain (d=) and the selector (s=). The matching public key lives in DNS at selector._domainkey.yourdomain.com. A receiver fetches that public key, recomputes the signature, and if it verifies, knows the message genuinely came from the signing domain and was not altered in transit. Unlike SPF, a valid DKIM signature survives most forwarding, because it travels inside the message rather than depending on the connecting IP. See DKIM, the DKIM product page, or validate a published key with the DKIM checker.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC is the policy layer that sits on top of SPF and DKIM. You publish one TXT record at _dmarc.yourdomain.com containing a p= tag whose value is none, quarantine or reject. That tag tells receiving servers what to do with mail claiming to be from your domain that fails authentication. DMARC also requests reports through its rua= and ruf= tags, which is how you find out who is sending as you. Critically, a message only passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From address. There must be exactly one DMARC record per domain; duplicates void the policy entirely. Read DMARC, browse the DMARC product page, or run the DMARC checker on your own domain.
DMARC policy (p= tag)
The DMARC policy is the instruction carried in the p= tag, and it is the single most consequential setting in the whole record. p=none is monitor-only: receivers report on failures but still deliver the mail, which makes it safe for gathering data but useless as protection. p=quarantine tells receivers to treat failing mail with suspicion, usually by routing it to the spam folder. p=reject blocks failing mail outright at the SMTP layer, which is the only setting that actually stops exact-domain spoofing. Moving up this ladder without first fixing every legitimate sender is what causes outages, so the journey has to be deliberate. See DMARC policy and the practical timeline in how long it takes to reach p=reject.
Subdomain policy (sp= tag)
The sp= tag sets a separate DMARC policy for subdomains, overriding the main p= value for anything below the organisational domain. If you omit it, subdomains inherit the parent policy. This matters because attackers frequently target subdomains that send no real mail, such as marketing.yourdomain.com or invented names, knowing that an unguarded subdomain is an open door for spoofing. A common safe posture is to publish an explicit sp=reject so that any subdomain without its own DMARC record is locked down by default. See subdomain policy (sp).
pct (percentage tag)
The pct= tag tells receivers to apply the DMARC policy to only a stated percentage of failing mail, with the remainder dropping to the next-lower treatment. Setting pct=25 under p=quarantine, for example, means roughly a quarter of failing messages are quarantined and the rest are delivered. It was designed as a gradual rollout lever, letting you dial up enforcement while watching for collateral damage. In practice it is a blunt instrument because the sampling is per-message rather than per-sender, so a properly managed enforcement journey often skips it in favour of fixing senders one at a time. See DMARC pct.
How it fits together
DMARC alignment
Alignment is the concept that makes DMARC meaningful, and it is the piece most people miss. SPF and DKIM each authenticate a domain, but not necessarily the domain a person sees. Alignment requires that the domain SPF or DKIM validated matches the domain in the visible From header. SPF alignment compares the From domain with the return-path domain; DKIM alignment compares it with the signing d= value. Alignment can be "relaxed", where matching the organisational domain is enough (so mail.yourdomain.com aligns with yourdomain.com), or "strict", where the domains must be identical. A message can pass raw SPF and DKIM checks and still fail DMARC because neither result aligned with the From address. See DMARC alignment.
Header From
The header From is the address shown to the recipient as the sender, the one a human reads and trusts. It is entirely separate from the SMTP envelope sender that SPF checks. This gap is the whole reason spoofing works: an attacker can put you@yourbank.com in the visible From while using a completely different envelope sender that passes its own SPF. DMARC closes the gap by insisting that an authenticated domain align with this header From, so the address you see is the address that was actually verified. See header From.
Return-path
The return-path, also called the envelope sender or bounce address, is the address used during the SMTP conversation and the one SPF actually checks. It is where delivery failures are sent. Bulk senders and email service providers commonly set the return-path to a domain they control, which means SPF can pass for that provider's domain while the visible From shows yours. That is fine for deliverability but it produces an SPF result that does not align with your From address, so you then depend on DKIM to carry DMARC. See return-path.
DKIM selector
A selector is the label that lets one domain publish multiple DKIM public keys at once. The DKIM-Signature header names the selector in its s= tag, and the receiver fetches the public key from selector._domainkey.yourdomain.com. Selectors exist so that different senders, or successive key rotations, can each have their own key without collision. If you use Google Workspace and a separate marketing platform, each typically publishes under its own selector. See DKIM selector.
DKIM key rotation
Key rotation is the practice of periodically replacing a DKIM key pair, generating a new private key, publishing the new public key under a fresh selector, switching signing over, and then retiring the old key. Rotation limits the damage if a private key is ever exposed and is considered good operational hygiene. Done carelessly it breaks signing, so the new key must be live in DNS and verified before the switch. See DKIM key rotation.
SPF "all" qualifier
The mechanism that ends an SPF record is the "all" qualifier, and its prefix decides the verdict for any sender not explicitly listed. -all is a hard fail, the strict and recommended setting that says "anything not listed is not us". ~all is a soft fail, treated as a weak negative that receivers often still accept. +all passes everything and must never be published, because it authorises the entire internet to send as you. Under DMARC, a soft fail and a hard fail behave similarly because DMARC makes its own decision, but -all remains the clearest statement of intent. See SPF all qualifier.
SPF 10-lookup limit
SPF evaluation is capped at ten DNS lookups per check. Mechanisms such as include, a, mx and redirect each consume lookups, and nested includes from third-party providers add up fast. Exceed ten and the receiver returns a permerror, which counts as an SPF failure regardless of whether the sending IP was genuinely authorised. This limit is the single most common reason a perfectly reasonable SPF record stops working as a business adds services. See the SPF 10-lookup limit and how to fix a failing SPF record.
SPF flattening
Flattening is the technique of replacing include and other lookup-consuming mechanisms with the raw ip4 and ip6 addresses they resolve to, collapsing many DNS lookups into a static list that stays under the ten-lookup cap. The catch is that providers change their sending IPs without warning, so a flattened record that is never updated will silently start rejecting legitimate mail. Done properly it has to be re-resolved automatically. See SPF flattening and our write-up on automatic SPF flattening.
permerror
A permerror is a permanent error result from SPF evaluation, meaning the record could not be processed correctly rather than that the sender was unauthorised. The usual causes are exceeding the ten-lookup limit, syntax mistakes, or too many void lookups. Because it is permanent, retrying will not help, and under DMARC a permerror means SPF has effectively failed, throwing all the weight onto DKIM. See permerror.
Void lookup
A void lookup is an SPF DNS query that returns no record at all, either an empty answer or a non-existent domain. The specification allows no more than two void lookups during a single SPF evaluation; a third triggers a permerror. Void lookups usually come from include statements that point at domains which have been decommissioned or mistyped, so they are a useful signal that an SPF record contains stale references. See void lookup.
Transport security
MTA-STS (Mail Transfer Agent Strict Transport Security)
MTA-STS lets a domain insist that incoming mail be delivered over an encrypted, authenticated TLS connection, closing a long-standing gap where SMTP would silently fall back to plain text if encryption could not be negotiated. You publish a DNS TXT record at _mta-sts.yourdomain.com and host a policy file over HTTPS at mta-sts.yourdomain.com listing your mail servers and an enforcement mode. In enforce mode, a sending server that cannot establish a valid TLS connection to a listed server will refuse to deliver rather than send in the clear, defeating downgrade attacks. See MTA-STS, our MTA-STS product page, or test a policy with the MTA-STS checker.
TLS-RPT (SMTP TLS Reporting)
TLS-RPT is the reporting companion to MTA-STS. By publishing a TXT record at _smtp._tls.yourdomain.com with a rua= address, you ask sending servers to send you daily summaries of how many connections to your mail servers succeeded or failed to negotiate TLS, and why. Without it, MTA-STS enforcement is a black box, and you would only learn about TLS failures when mail mysteriously stopped arriving. The reports are JSON and let you spot misconfigured servers or expiring certificates before they cause outages. See TLS-RPT and the TLS-RPT checker.
STARTTLS
STARTTLS is the SMTP command that upgrades an initially plain-text mail connection to an encrypted one. It is how the vast majority of email is encrypted in transit today, but on its own it is opportunistic: if the upgrade fails, traditional SMTP simply continues unencrypted, and an attacker positioned in the middle can strip the STARTTLS offer to force exactly that. MTA-STS and DANE exist precisely to make STARTTLS mandatory rather than optional. See STARTTLS.
DANE (DNS-based Authentication of Named Entities)
DANE is an alternative to MTA-STS for guaranteeing encrypted mail delivery, anchored in DNSSEC rather than in HTTPS and public certificate authorities. You publish a TLSA record in DNS that pins the expected certificate or public key of your mail server, and a sending server that supports DANE will only deliver if the presented certificate matches the pin. Because its trust comes from a DNSSEC-signed chain, DANE requires DNSSEC to be in place to be meaningful. It is widely deployed in some regions and by some providers and absent in others, so many domains run MTA-STS, DANE, or both. See DANE.
TLSA record
A TLSA record is the DNS entry that DANE relies on. It pins the certificate or public key that a mail server is expected to present, identified by usage, selector and matching-type fields, and published at a name derived from the port and protocol, such as _25._tcp.mail.yourdomain.com. A sending server compares the certificate offered during the TLS handshake against the TLSA record, and refuses to deliver on a mismatch. Because forged TLSA records would defeat the purpose, they are only trustworthy when protected by DNSSEC. See TLSA record.
DNSSEC
DNSSEC adds cryptographic signatures to DNS so that a resolver can verify a record genuinely came from the zone's owner and was not tampered with on the way. Ordinary DNS has no such protection, which means a man-in-the-middle could forge answers. Several email-security mechanisms, DANE in particular, depend on DNSSEC for their guarantees, and it also strengthens defences against certain spoofing and interception attacks. See DNSSEC and DNSSEC and email security.
CAA record
A CAA (Certification Authority Authorization) record lists which certificate authorities are permitted to issue certificates for your domain. A compliant CA checks the CAA record before issuing and declines if it is not authorised, which reduces the risk of an attacker obtaining a fraudulent certificate from some other CA. It is not strictly an email control, but because TLS for mail transport and certificates for VMCs both depend on the wider certificate ecosystem, CAA is part of a tidy DNS security posture. See CAA record.
Brand and logo
BIMI (Brand Indicators for Message Identification)
BIMI is the standard that lets your verified logo appear next to your messages in supporting inboxes. You publish a TXT record at default._bimi.yourdomain.com pointing to an SVG logo and, for the major providers, a Verified Mark Certificate. BIMI is strictly a reward for getting the fundamentals right: it only displays once your domain enforces DMARC at p=quarantine or p=reject with alignment, so it doubles as a visible incentive to reach enforcement. See BIMI, our BIMI product page, or check a record with the BIMI checker.
VMC (Verified Mark Certificate)
A VMC is the certificate that proves your organisation owns the logo it wants to display through BIMI. Issued by an approved certification authority, it normally requires the logo to be a registered trademark, and it is what Gmail and Apple Mail demand before showing your mark. The certificate is published at the URL named in the BIMI record's a= tag, and like BIMI itself it only helps once DMARC enforcement is in place. See VMC.
CMC (Common Mark Certificate)
A CMC is a lighter alternative to a VMC for organisations whose logo is not a registered trademark. It still involves an approved certification authority verifying the applicant, but it accepts marks that have been in established use rather than formally registered, and it can also cover government and certain other logos. Provider support for CMCs is narrower than for VMCs, so check which inboxes will honour one before relying on it. See CMC.
SVG Tiny PS
SVG Tiny PS (Portable/Secure) is the tightly restricted SVG profile that BIMI requires for logo files. It strips out scripting, external references, animation and other features that could be abused or that render inconsistently, leaving a small, safe, square vector image. A logo that is valid general SVG will usually be rejected by BIMI validators until it is converted to this profile. See SVG Tiny PS.
Report types
Aggregate report (RUA)
Aggregate reports are the daily XML summaries that receiving providers send to the address in your DMARC rua= tag. Each report groups mail by sending IP and tells you how many messages that source sent, and whether they passed or failed SPF, DKIM and DMARC alignment. They contain no message content, so they are safe to collect at volume, and they are the primary evidence you use to find every legitimate sender before tightening your policy. Reading them by hand is tedious because they are raw XML, which is why a parser helps. See aggregate report (RUA), how to read a DMARC aggregate report, or upload one to the DMARC report analyzer.
Forensic report (RUF)
Forensic reports, requested through the DMARC ruf= tag, are intended to deliver near-real-time samples of individual messages that failed authentication, including header detail and sometimes redacted content. In principle they help you investigate specific abuse, but in practice almost no major provider sends them any more, largely because of the privacy implications of forwarding message data. Most domains can rely on aggregate reports alone. See forensic report (RUF).
ARC (Authenticated Received Chain)
ARC is a standard that preserves authentication results across the intermediaries that would otherwise break them. When a mailing list or forwarder modifies a message, it invalidates the DKIM signature and breaks SPF alignment, so genuine mail can fail DMARC at the final hop. ARC has each intermediary add headers that record the authentication results it observed and cryptographically seal them into a chain. A receiver that trusts the sealing intermediary can then honour those preserved results rather than rejecting outright. It is advisory, not binding, it runs mostly behind the scenes at large providers, and there is little to configure on your own domain. See ARC and mailing lists, DMARC and ARC.
Infrastructure terms
SMTP (Simple Mail Transfer Protocol)
SMTP is the protocol that moves email between servers. The terms envelope sender, return-path and the STARTTLS upgrade all belong to the SMTP conversation, which happens before any of the message content a recipient sees is rendered. Understanding that SPF acts on the SMTP envelope, while DMARC alignment cares about the message header, depends on keeping the SMTP layer and the message layer distinct. See SMTP.
MX record
An MX (Mail Exchange) record is the DNS entry that tells the world which servers receive mail for your domain, ranked by priority. It governs inbound mail, not outbound authentication, but it is foundational: MTA-STS and DANE both pin the servers named by your MX records, and a misconfigured MX is a common cause of lost mail. See MX record and the MX record checker.
PTR record
A PTR record provides reverse DNS, mapping an IP address back to a hostname. Receiving mail servers often check that a connecting IP has a PTR record and that it resolves sensibly as a spam-filtering signal. A sending IP with no PTR, or a generic one, is treated with more suspicion regardless of SPF and DKIM. See PTR record and the PTR record checker.
FCrDNS (Forward-Confirmed reverse DNS)
FCrDNS is the check that combines forward and reverse lookups: the IP resolves to a hostname via its PTR record, and that hostname resolves back to the same IP via an A record. Passing FCrDNS is a basic credibility test for a sending server, and many receivers penalise or refuse mail from IPs that fail it. See FCrDNS.
ESP (email service provider)
An ESP is a third-party platform that sends email on your behalf, covering marketing tools, transactional senders, helpdesks and CRMs. Each ESP you use needs to be authorised under your SPF, sign with DKIM using its own selector, and align with your domain to pass DMARC. Unmanaged ESPs are the usual reason a domain cannot reach p=reject, because their mail keeps failing alignment until each one is configured. See ESP.
DNSBL (DNS-based blocklist)
A DNSBL is a list, queried over DNS, of IP addresses or domains associated with spam or abuse. Receiving servers check connecting IPs against one or more blocklists and may reject or downgrade mail from anything listed. Authentication and blocklisting are separate concerns: a domain can pass DMARC and still be blocked because its sending IP has a poor reputation. See DNSBL.
Abuse and threats
Email spoofing
Spoofing is forging the visible sender address so a message appears to come from a domain it did not. It is the core attack that DMARC was built to defeat, because by demanding an aligned, authenticated From address, an enforced policy makes exact-domain spoofing fail at the receiver. Until a domain reaches p=reject, anyone can send mail that displays your address. See email spoofing and why your domain can be spoofed.
Phishing
Phishing is the use of deceptive email to trick recipients into revealing credentials, sending money, or installing malware, frequently by impersonating a trusted brand. Enforced DMARC removes one of the most effective phishing techniques, exact-domain impersonation, though attackers respond by shifting to lookalike domains and display-name tricks that DMARC alone does not cover. See phishing.
BEC (business email compromise)
BEC is targeted fraud in which an attacker poses as an executive, supplier or colleague to authorise a payment or divert an invoice. It often uses a spoofed exact domain, a lookalike domain, or a compromised account. DMARC at enforcement shuts the exact-domain route, which is why it features in cyber-insurance questionnaires and vendor security reviews. See BEC.
Display-name spoofing
Display-name spoofing puts a trusted name in the From field's friendly label while using an unrelated underlying address, for example showing "Finance Team" over a free webmail account. Because the underlying domain is not yours, DMARC on your domain does nothing to stop it; defending against it relies on receiver-side heuristics and user awareness. See display-name spoofing.
Lookalike domain
A lookalike domain is a registered domain crafted to resemble yours, through character swaps, extra words or different endings, so recipients mistake it for the real thing. Since the attacker legitimately controls it, they can publish their own SPF, DKIM and DMARC and pass authentication entirely. DMARC protects your exact domain, not every domain that resembles it, so lookalikes need separate monitoring. See lookalike domain.
Email deliverability
Deliverability is the broad question of whether your legitimate mail reaches the inbox rather than the spam folder or oblivion. Authentication is a large part of it, because Google, Yahoo and Microsoft now require SPF, DKIM and DMARC from bulk senders, but reputation, list hygiene, content and engagement all contribute too. See email deliverability and why email goes to spam.
Where to go next
If a definition above raised more questions than it answered, the sender-side rules are laid out in plain English on the requirements page, which covers what Google, Yahoo, Microsoft and PCI DSS each demand and by when. For the bigger picture of how the protocols connect, start with email authentication for beginners and the email authentication overview. When you are ready to check your own domain, the DMARC checker, SPF checker, DKIM checker and BIMI checker report on each record in seconds, and the DMARC report analyzer turns a raw aggregate report into a readable picture of who sends as you.
DMARC Engine exists to do the hard part for you: taking a domain from p=none all the way to enforced p=reject without breaking a single legitimate sender, then keeping watch with emailed monitoring so the posture you worked for does not quietly regress. The vocabulary on this page is the language of that journey; the platform is what gets you to the end of it.