Skip to content
DMARC
← Blog

Email authentication glossary (SPF, DKIM, DMARC, BIMI…)

By Thomas · virtual CISO · August 17, 2026

Email authentication carries a dense jargon: SPF, DKIM, alignment, RUA, Tree Walk, BIMI, VMC… acronyms that overlap, depend on one another, and end up blurring together. This glossary puts each term in its place, in a short, self-contained definition — the kind that can be quoted, pasted into a ticket, or explained to a board without getting it wrong. We move from the foundations to the advanced mechanisms, then to the threats the whole arrangement exists to cut. Each entry links to the article that goes into it in depth.

The foundations

SPF (Sender Policy Framework)

SPF is a DNS TXT record that lists the servers authorised to send mail for a domain. On receipt, the recipient server compares the sending IP address against that list: if it is not there, the message fails the SPF check. It is the first of the three authentication layers, but it has a native limitation — it validates the envelope (MAIL FROM), not the From: address a human actually sees. For the mechanisms and pitfalls, see how sender verification works.

DKIM (DomainKeys Identified Mail)

DKIM attaches a cryptographic signature to each outgoing message: the sender signs with a private key, and the recipient verifies that signature using a public key published in DNS. If the message was altered in transit or forged without the key, the signature does not hold. DKIM therefore proves both the origin and the integrity of the message. The detailed workings are described in the cryptographic signature on messages.

The DKIM private key is a first-rank secret: anyone holding it can sign mail in the domain's name and clear its defences as if they were the legitimate sender. It has no business sitting in a versioned config file, a ticket or a chat channel — its place is a dedicated secrets vault such as Hucency Vault, from cybersecurity specialist Hucency, which centralises this kind of secret under controlled, logged access.

DKIM selector

The selector is a simple identifier that lets a domain host several DKIM keys in parallel. It appears in the DKIM-Signature header (the s= field) and points to the DNS record of the matching public key, at selector._domainkey.example.com. Thanks to it, each provider (mail platform, marketing tool, billing service) can sign with its own key, and those keys rotate without breaking everything at once. Its role is detailed in what the selector actually names.

DMARC

DMARC is the layer that ties SPF and DKIM to the visible domain in the From: field and tells recipients what to do on failure. It is a DNS record (v=DMARC1) that defines a policy — do nothing, quarantine, or reject — and requests reports. Without DMARC, SPF and DKIM protect technical identifiers the user never sees; DMARC is what finally protects the displayed address. The full principles are in the foundation of mail protection.

Alignment

Alignment is the heart of DMARC: it requires that the domain validated by SPF or DKIM match the domain in the visible From:. A message can pass SPF and DKIM on a third party's technical domains while still spoofing the displayed address; alignment closes that gap by demanding they agree. DMARC succeeds as soon as at least one of the two (SPF or DKIM) is aligned. The mechanism is dissected in SPF, DKIM and DMARC explained together.

Policy (p=none / quarantine / reject)

The p tag of a DMARC record dictates the fate of unauthenticated messages. p=none observes without acting (spoofed messages pass, but the reports still come back); p=quarantine files them as spam; p=reject blocks them at the door. Only p=reject genuinely protects a domain — p=none is a diagnostic step, not a destination. The choice between the two enforcement levels is covered in quarantine vs reject.

The reports

RUA (aggregate report)

RUA reports are daily XML summaries that recipients send back to the address declared in the rua= tag. They record, per sending source, mail volumes and SPF/DKIM/DMARC results — without ever exposing message content. This is the radar: they reveal who is sending in the domain's name, legitimately or not, and guide the ramp-up to p=reject. Reading them is explained in reading the daily returns.

RUF (failure report)

RUF reports (or forensic reports) are sent as they happen, message by message, when an email fails authentication. They are far more detailed than RUA — they can include headers and fragments of the message — which raises serious privacy questions, to the point that most recipients no longer emit them. The difference in nature between the two channels is developed in which report type does what.

DMARCbis and the new tags

DMARCbis

DMARCbis is the revision of DMARC published in 2026, replacing the original RFC 7489 (2015) and moving the protocol onto the official standards track. Same principle, same v=DMARC1 identifier: it is not a breaking change, but a rewritten text with new tags (np, t) and a more robust domain-attribution mechanism. Existing records stay valid. What actually changes is detailed in the revision of the standard.

The np tag

The np tag sets the policy applied to subdomains that do not exist. This is a classic spoofing target: an attacker can forge invoice.example.com even if that subdomain was never created, because nothing protects it by default. Setting np=reject closes that door with no risk to legitimate mail, since those subdomains send nothing. Its workings are described in the tag for non-sending subdomains.

The t tag

The t tag replaces the old pct and introduces a binary test mode: t=y signals an experiment in progress and tells recipients not to enforce the policy strictly yet. It is used to observe the effect of a tightening before turning it on for real, relying on the reports rather than a random percentage of messages. Its use is explained in the tag that replaces percentage sampling.

DNS Tree Walk

The DNS Tree Walk is the mechanism by which, in DMARCbis, the organisational domain is determined through a sequence of step-by-step DNS queries (eight at most), climbing the name tree. It replaces the Public Suffix List, an externally hand-maintained list that DMARC previously depended on. The result: more predictability, no dependence on a third-party file. The exact walk is detailed in the DNS Tree Walk explained.

Organisational domain

The organisational domain is the "root" domain under which the subdomains live — for example my-bank.com for mail.my-bank.com. DMARC relies on this notion for two things: deciding whether SPF or DKIM is aligned (relaxed alignment), and knowing which subdomain policy (sp) applies. How DMARCbis now computes it — via the Tree Walk rather than a list — is at the heart of what the revision changes.

Transport and traceability

MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) enforces TLS encryption of the transport between mail servers and stops an attacker from downgrading the connection to cleartext. The published policy (via a DNS record and a file served over HTTPS) requires inbound mail to arrive only over an encrypted, authenticated connection. It is the "transport" complement to the "content" authentication that SPF, DKIM and DMARC provide. Its setup is described in transport encryption, explained.

TLS-RPT

TLS-RPT (TLS Reporting) is the reporting channel paired with MTA-STS: it asks remote servers to report TLS negotiation failures encountered when delivering mail to the domain. An address declared in a _smtp._tls DNS record then collects summaries that surface encryption problems before they silently degrade transport security. The detail is in the transport-reporting standard.

ARC (Authenticated Received Chain)

ARC preserves a message's authentication result when it passes through an intermediary — a mailing list, a forwarding service — that legitimately modifies the content and would otherwise break SPF and DKIM. Each ARC-compliant relay signs a "chain" attesting that authentication was valid on arrival, which lets the final recipient take it into account. ARC does not replace DMARC; it prevents legitimate indirect flows from being wrongly rejected.

BIMI and brand display

BIMI (Brand Indicators for Message Identification)

BIMI displays the brand logo next to a domain's messages in the inboxes that support it (Gmail, Yahoo, Apple Mail…). It is the visible reward for a well-run domain: BIMI is granted only to domains at p=quarantine or p=reject, which makes it a trust signal as much as a marketing lever. A DNS record points to the logo in SVG format. The full setup is in setting up BIMI on Gmail.

VMC (Verified Mark Certificate)

The VMC is a certificate that proves legitimate ownership of the logo displayed via BIMI. Issued by a certification authority after verifying the registered trademark, it is required by Gmail and others to display the logo. It is the piece that stops a fraudster from hijacking the visual identity of a known brand. Its role and cost are detailed in the VMC certificate for BIMI.

CMC (Common Mark Certificate)

The CMC is a more accessible alternative to the VMC, meant for logos that are not registered trademarks (for instance a public body or an organisation without a registered mark). It allows a logo to be displayed via BIMI without the trademark registration a VMC requires, in exchange for other forms of verification. The cases where it applies are set out in the logo without a certificate.

The threats

Spoofing

Spoofing means forging the sender address of an email to make it look as though it comes from a legitimate domain. Technically trivial — the From: address is just a freely editable text field — it is the fundamental threat that SPF, DKIM and above all DMARC exist to neutralise. As long as a domain is not at p=reject, anyone can send mail under its name. The mechanisms and defences are detailed in what is email spoofing.

Phishing

Phishing is an attack that manipulates the victim into surrendering credentials, a payment or a sensitive action, often through an email posing as a trusted source. Domain spoofing is its most effective fuel: a message that truly appears to come from a bank or an employer lowers every defence. Cutting spoofing at the source shrinks the attack surface accordingly, as explained in preventing phishing on a domain.

BEC (CEO fraud)

BEC (Business Email Compromise), or CEO fraud, targets an organisation by impersonating an executive or a supplier in order to order a fraudulent wire transfer or a data leak. It is one of the costliest frauds, because it plays on authority and urgency rather than a technical flaw — but spoofing a legitimate domain makes it fearsomely credible. The modus operandi and the defences are detailed in CEO fraud (BEC).

Where to start

This glossary describes an arrangement; putting it in place always starts with a status check. The fastest way to know where a domain stands — which DMARC policy, which SPF/DKIM alignment, which sources send in its name — is to run it through a free DMARC analyzer. The verdict on the current posture lands immediately, and compares afterwards with the sector's in the DMARC Observatory.

Turning that diagnosis into action — naming every source, generating the DNS to publish, clearing each step from p=none to p=reject without breaking a single legitimate flow — is exactly what Thomas, the virtual CISO, automates. Free domain analysis · exploring the Observatory · getting started with Thomas.

Related guides

About the author

Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.