DMARC Glossary

Email authentication has a lot of acronyms. This glossary defines every term you'll encounter when setting up or monitoring DMARC, SPF, and DKIM for your domain.

Core Protocols

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

An email authentication protocol that builds on SPF and DKIM. A domain owner publishes a DMARC DNS record that tells receiving mail servers: (1) what policy to apply to messages that fail authentication, and (2) where to send aggregate reports of authentication results.

DMARC was formally published as RFC 7489 in 2015 and is now required by Google and Yahoo for bulk senders. It is the only standard that requests feedback from receiving servers back to the domain owner.

SPF (Sender Policy Framework)

A DNS TXT record that lists the IP addresses and mail servers authorised to send email for a domain. When a mail server receives a message, it checks the sending IP address against the SPF record for the envelope sender domain. If the IP is listed, the check passes; if not, it fails.

Example SPF record: v=spf1 include:_spf.google.com include:sendgrid.net ~all

SPF alone is not sufficient to stop spoofing because it only checks the envelope sender (the MAIL FROM address), not the From header visible to the recipient. DMARC alignment is required to connect SPF results to the visible From address.

DKIM (DomainKeys Identified Mail)

A mechanism that adds a cryptographic signature to outgoing email. The sending server signs the message with a private key, and publishes the corresponding public key in DNS. Receiving servers retrieve the public key and verify the signature — confirming the message was sent by an authorised server and was not altered in transit.

Example DKIM DNS record name: google._domainkey.example.com

The d= tag in the DKIM signature identifies the signing domain. DMARC checks whether this domain aligns with the visible From address.

DMARC DNS Record Tags

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It is made up of tag=value pairs separated by semicolons.

p= — Policy

Tells receiving servers what to do with messages that fail DMARC authentication. Three values:

• p=none — Take no action; just send reports. Used during initial monitoring.
• p=quarantine — Move failing messages to the spam/junk folder.
• p=reject — Block failing messages entirely; they are not delivered.

Most organisations start with none, monitor their aggregate reports for weeks or months, and move to quarantine then reject once they are confident all legitimate senders are passing authentication.

rua= — Reporting URI for Aggregate reports

The email address (or addresses) to which receiving mail servers send daily DMARC aggregate report XML files. Example: rua=mailto:reports@yourdmarcexposed.com

This is the tag you add or update to start sending your aggregate reports to a monitoring service like Your DMARC Exposed.

ruf= — Reporting URI for Forensic reports

The email address to which receiving servers send forensic (failure) reports — individual reports for each message that fails DMARC. These are less commonly supported by receivers than aggregate reports, and many large providers have stopped sending them due to privacy concerns.

sp= — Subdomain Policy

Specifies the DMARC policy to apply to subdomains of the domain. If omitted, subdomains inherit the p= policy. Example: sp=reject will reject failing mail from mail.example.com even if the main policy is p=quarantine.

pct= — Percentage

The percentage of messages subject to the DMARC policy. pct=10 means the policy applies to only 10% of failing messages. Useful for gradually rolling out enforcement. Defaults to 100 if omitted.

adkim= — DKIM Alignment Mode

Controls how strictly the DKIM signing domain must match the From header domain. adkim=r (relaxed, the default) allows subdomain matches. adkim=s (strict) requires an exact match.

aspf= — SPF Alignment Mode

Controls how strictly the SPF envelope sender domain must match the From header domain. aspf=r (relaxed, the default) allows subdomain matches. aspf=s (strict) requires an exact match.

Reports & Data

DMARC Aggregate Report (RUA Report)

An XML file sent daily by receiving mail servers to the address in the rua= tag of your DMARC record. Each report covers a 24-hour period and contains:

• The reporting organisation (e.g. Google, Microsoft)
• The date range covered
• For each source IP: the number of messages, SPF result, DKIM result, and DMARC policy disposition

Aggregate reports contain no message content or personally identifiable information — only authentication counts and IP addresses. Your DMARC Exposed parses these XML files and displays them on your dashboard.

DMARC Forensic Report (RUF Report)

An individual failure report generated for a single message that failed DMARC authentication. Forensic reports may include message headers and partial content, which is why many large providers (including Google and Microsoft) no longer send them. Support varies significantly by receiving mail provider.

Policy Disposition

The action a receiving server actually took on a message, as reported in the aggregate report. Common values: none (delivered normally), quarantine (moved to spam), reject (blocked). The disposition may differ from your DMARC policy if the receiver overrides it or if pct= is set below 100.

Key Concepts

DMARC Alignment

The requirement that the domain in the visible From header matches the domain used in SPF (the envelope sender) or in DKIM (the d= tag of the signature). Alignment is what ties SPF and DKIM results to the address the email recipient actually sees.

A message passes DMARC if it passes SPF and the SPF domain aligns, or passes DKIM and the DKIM domain aligns (or both). It only needs to pass one of the two.

Email Spoofing

Sending email with a forged From address to impersonate a trusted sender or domain. Because email was not designed with authentication in mind, any server can claim to send from any address. SPF restricts which servers can send, DKIM proves the message was signed by an authorised server, and DMARC ties both to the visible From address and enforces a policy against messages that fail.

DMARC Enforcement

The state in which a domain's DMARC policy is quarantine or reject — meaning receiving servers actively filter or block messages that fail authentication. Contrast with p=none, which is monitoring-only and takes no action on failing messages.

Moving to enforcement prematurely can block legitimate email. Best practice is to monitor aggregate reports until you are confident that all legitimate senders (your mail platform, marketing tools, CRM, etc.) are passing SPF and DKIM alignment before tightening the policy.

Envelope Sender (Return-Path / MAIL FROM)

The technical sender address used in the SMTP transaction — distinct from the From header visible to the recipient. This is the address SPF checks. If a message bounces, the bounce goes to the envelope sender. It is often different from the From address, especially when email is sent through a third-party platform.

Business Email Compromise (BEC)

A category of fraud in which attackers impersonate executives or trusted organisations via email to trick employees into transferring funds or disclosing sensitive information. BEC attacks frequently exploit domain spoofing. The FBI's IC3 reported over $2.7 billion in BEC losses in a single year in the US. DMARC enforcement is one of the most effective technical controls against BEC.

BIMI (Brand Indicators for Message Identification)

A standard that allows domain owners to display their brand logo in supporting email clients (Gmail, Apple Mail, Yahoo Mail) next to authenticated messages. BIMI requires DMARC enforcement (p=quarantine or p=reject) and a BIMI DNS record pointing to an SVG logo file. Some implementations also require a Verified Mark Certificate (VMC).

MTA-STS (Mail Transfer Agent Strict Transport Security)

A standard that lets domain owners declare that incoming email to their domain must be delivered over TLS encryption. It prevents downgrade attacks where an attacker tricks a sending server into delivering email unencrypted. MTA-STS is complementary to DMARC but addresses a different attack vector (encryption in transit rather than sender authentication).

TLS-RPT (TLS Reporting)

A reporting standard (RFC 8460) that lets domain owners receive reports from sending mail servers about TLS encryption failures when delivering to their domain. Used alongside MTA-STS to detect and diagnose delivery failures caused by TLS issues.