DMARC: A Complete Guide to the _dmarc Record, Policies and Rollout
DMARC (Domain-based Message Authentication, Reporting and Conformance, defined in
RFC 7489) is a DNS TXT record that tells receiving mail servers what to do with
messages that claim to be from your domain but fail authentication, and asks them to send you
reports. It builds on SPF and DKIM by adding
alignment with the visible From address, so it is the layer that actually stops attackers
from spoofing your exact domain. This guide explains how DMARC works, what each record tag means,
and the safe path from monitoring (p=none) to full enforcement (p=reject).
By the ShowMyIP Editorial Team
What DMARC is and why it exists
SPF and DKIM each authenticate part of a message, but neither is tied to the
From header that a recipient actually sees. SPF validates the hidden envelope
sender (the MAIL FROM), and DKIM validates the signing domain (d=).
An attacker can pass SPF or DKIM for a domain they control while still putting
your domain in the visible From line. DMARC closes that gap by requiring
alignment: the SPF or DKIM identifier must match the From domain. When a
message fails DMARC, your published policy tells the receiver whether to do nothing,
quarantine it, or reject it - and either way the receiver sends you reports so you can
see who is sending mail as your domain.
The _dmarc TXT record
A DMARC policy is a single TXT record published at the _dmarc subdomain of the
domain you are protecting. A monitoring-only record looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
A full enforcement record with strict alignment looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=s; aspf=s"
The record is a series of tag=value pairs separated by semicolons. v
must come first and there must be exactly one DMARC record per domain - publishing two
invalidates DMARC for that domain.
DMARC tag reference
The table below lists every DMARC tag defined in RFC 7489, whether it is required, what it controls and an example value.
| Tag | Requirement | Meaning | Example |
|---|---|---|---|
v |
Required | Protocol version. Must be the first tag and exactly v=DMARC1. | v=DMARC1 |
p |
Required | Policy for the organizational domain when a message fails DMARC: none (monitor only), quarantine (treat as suspicious / send to spam) or reject (refuse outright). | p=reject |
sp |
Optional | Policy for subdomains. Defaults to the value of p when omitted. Useful to apply a stricter or looser policy to subdomains than to the apex. | sp=quarantine |
rua |
Optional | Address(es) for aggregate (statistical) XML reports, as a mailto URI. The backbone of monitoring. | rua=mailto:[email protected] |
ruf |
Optional | Address(es) for failure/forensic reports about individual failing messages. Few providers send these today, and they can carry message content, so use with care. | ruf=mailto:[email protected] |
adkim |
Optional | DKIM alignment mode: r (relaxed, default) allows the organizational domains to match; s (strict) requires an exact match of the d= domain to the From domain. | adkim=s |
aspf |
Optional | SPF alignment mode: r (relaxed, default) or s (strict), applied to the MAIL FROM domain versus the From header domain. | aspf=s |
pct |
Optional | Percentage of failing mail (0-100) the policy is applied to. Defaults to 100. Lets you ramp a quarantine/reject policy gradually. | pct=25 |
fo |
Optional | Failure-reporting options: 0 (default, report if all mechanisms fail), 1 (report if any mechanism fails), d (DKIM failures), s (SPF failures). | fo=1 |
rf |
Optional | Format for failure reports. The default and only widely used value is afrf (Authentication Failure Reporting Format). | rf=afrf |
ri |
Optional | Requested interval between aggregate reports, in seconds. Default 86400 (one day). It is a request only; receivers commonly report daily regardless. | ri=86400 |
The three policies: none, quarantine, reject
p=none (monitor)
Receivers take no special action on failing mail but still send aggregate reports. This is the mandatory first step: it lets you discover every system sending mail as your domain - including ones you forgot about - with zero risk to delivery.
p=quarantine
Receivers treat failing mail as suspicious, usually delivering it to the spam or junk folder. This is the middle gear: real damage from spoofing is reduced, but a misaligned legitimate source still lands somewhere a user can recover it.
p=reject
Receivers refuse failing mail at SMTP time, so it never reaches the inbox or the spam folder. This is the goal state and the only policy that fully blocks direct-domain spoofing. Reach it only after the reports confirm every legitimate source aligns.
Alignment: relaxed vs strict
DMARC passes when SPF or DKIM passes and aligns with the From domain. Under
relaxed alignment (the default, adkim=r / aspf=r),
a match on the organizational domain is enough - for example, a DKIM d=mail.example.com
aligns with a From of example.com. Under strict alignment
(adkim=s / aspf=s), the domains must match exactly. Most organizations
start with relaxed alignment because third-party senders and subdomains commonly use the
organizational domain rather than an exact match.
Reading rua and ruf reports
Aggregate reports (rua) are daily XML files that summarize, per sending IP, how many messages claiming your domain passed or failed SPF and DKIM alignment. They contain no message content and are the workhorse of any DMARC rollout: you read them to confirm that all your legitimate sources align before tightening policy. Raw XML is hard to read by hand, so most teams feed reports into a DMARC analytics platform.
Failure reports (ruf) are per-message forensic samples of individual failures.
They can be valuable for debugging, but few mailbox providers send them today and they may
contain message content, so many organizations leave ruf unset.
A safe rollout path
- Publish
p=nonewithrua. Start monitoring with no impact on delivery. - Read reports for several weeks. Identify every legitimate source and confirm whether each aligns via SPF or DKIM.
- Fix misaligned sources. Add SPF includes, enable DKIM signing on each platform, or move senders onto an aligned subdomain.
- Move to
p=quarantine. Optionally usepct(for examplepct=25) to ramp enforcement gradually. - Move to
p=rejectatpct=100. Once reports show only aligned, legitimate mail failing, enforce fully. - Keep monitoring. New sending tools appear over time; keep reading
ruareports so you catch them before they break.
Related tools and guides
- DKIM, SPF & DMARC Lookup - inspect your live authentication records.
- Domain Email Health Check - a composite deliverability scorecard.
- Email Header Analyzer - read DMARC results from a real message header.
- How to Check Email Deliverability - the full SPF/DKIM/DMARC/blacklist workflow.
- Why is my email going to spam? - diagnose and fix inbox-placement problems.
Frequently asked questions
What is the difference between p=none, p=quarantine and p=reject?
These are the three DMARC enforcement levels. p=none is monitoring only: receivers take no special action but still send you aggregate reports, so you can see who is sending as your domain. p=quarantine asks receivers to treat failing mail as suspicious, typically routing it to the spam or junk folder. p=reject asks receivers to refuse failing mail outright at SMTP time, so it never reaches the inbox or spam folder. The recommended path is to start at none, then move to quarantine, then reject as your confidence grows.
What does DMARC alignment actually mean?
Alignment is what makes DMARC stronger than SPF or DKIM alone. SPF checks the hidden envelope sender (MAIL FROM) and DKIM checks the signing domain (d=), but neither has to match the visible From header that recipients see. DMARC passes only when at least one of those identifiers aligns with the From domain. Relaxed alignment (the default) accepts a match on the organizational domain (for example mail.example.com aligning with example.com); strict alignment requires an exact match.
Do I need both SPF and DKIM for DMARC to pass?
No. DMARC passes if either SPF or DKIM passes and aligns with the From domain. However, configuring both is strongly recommended. DKIM survives email forwarding (which usually breaks SPF), so a message that fails SPF after being forwarded can still pass DMARC on DKIM alignment. Relying on a single mechanism leaves legitimate mail at risk of failing.
What is the difference between rua and ruf reports?
rua specifies where aggregate reports go. These are daily XML summaries that count how many messages claiming your domain passed or failed SPF and DKIM, grouped by sending IP. They contain no message content and are the primary tool for monitoring and rollout. ruf specifies where failure (forensic) reports go: per-message details about individual failures. Few mailbox providers send ruf reports today, and because they can include message content, many organizations leave ruf unset.
Is it safe to publish p=reject immediately?
It is risky. Jumping straight to p=reject before you have confirmed that every legitimate sending source (your mail platform, marketing tools, ticketing systems, third-party senders) aligns under DMARC can silently block real mail. The safe approach is to publish p=none first, read the aggregate reports until you can account for all legitimate traffic, fix any sources that fail alignment, then tighten to quarantine and finally reject. You can also use the pct tag to apply enforcement to a fraction of mail while you ramp.
Does DMARC stop all spoofing and phishing?
DMARC stops direct-domain spoofing, where an attacker puts your exact domain in the From header. It does not stop look-alike domains (such as exampie.com), display-name spoofing, or compromised accounts that send through your own authenticated infrastructure. DMARC is one essential layer; pair it with SPF, DKIM, user training and, optionally, BIMI for brand indicators.
How this tool works: This tool runs in your browser and on our server in real time. Depending on the tool, results are computed directly from the input you provide or retrieved from live, authoritative data sources at the moment you run a lookup. We do not sell your data, and your lookups are kept private — any history shown here is stored only on your device.