Updated on June 11, 2026: We updated this guide for DMARCbis. RFC 9989 defines DMARC and obsoletes RFC 7489 and RFC 9091, RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting. The examples now avoid the historic pct tag and use current DNS Tree Walk policy discovery.
Set up one DMARC TXT record at your root domain first, publish it at _dmarc.example.com, add a rua reporting address, start with p=none, then use the reports to confirm every legitimate sender passes SPF or DKIM with the same visible From domain. After that evidence is clean, move to p=quarantine and then p=reject. That is the practical answer.
I usually start at the root because DMARC DNS Tree Walk lets receivers find an applicable parent policy, and subdomains use that policy unless a subdomain has its own DMARC record or the parent record uses a separate sp or np tag. That keeps the setup simple, gives one reporting stream, and avoids duplicate records that drift over time. Subdomain records are useful when a subdomain has a different risk profile, a separate owner, or needs a slower policy rollout.
Raw DMARC reports are XML files, often compressed, and they become noisy fast. Suped's DMARC monitoring receives those reports, groups sending sources, flags authentication issues, and gives steps to fix the DNS or sender configuration. That is where a reporting platform earns its keep, especially when multiple teams, subdomains, and email providers are involved.
The short answer
A proper DMARC setup has three jobs: tell receivers what to do with unauthenticated mail, send aggregate reports somewhere useful, and give you enough data to tighten the policy without blocking real mail. The DNS record is small, but the operational work around it matters more than the syntax.
- Publish root record: Add one TXT record at _dmarc for the organizational domain, such as example.com.
- Start in monitor mode: Use p=none so receivers report results without changing delivery.
- Add reporting: Use rua=mailto: with a mailbox or reporting address that is actively monitored.
- Fix senders: Confirm every legitimate source passes SPF or DKIM and uses the same visible From domain.
- Raise policy: Move to quarantine, then reject, after the report data shows legitimate traffic is covered.
Starter DMARC TXT recorddns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Gmail and Yahoo bulk sender rules pushed many senders to publish DMARC with at least p=none. Google's own Google DMARC guidance also recommends setting up a report mailbox and checking that third-party email is authenticated before tightening the policy.
Where the DMARC record goes
Put the primary DMARC record at the root domain, not at every subdomain by default. If your visible From domain is example.com, the DMARC record is published at _dmarc.example.com. If your visible From domain is news.example.com and that subdomain has no DMARC record, receivers use DMARC DNS Tree Walk to find an applicable organizational-domain or PSD policy record.
A separate subdomain record makes sense when the subdomain has a distinct sending program, a different vendor stack, or a different rollout schedule. I add one when a marketing subdomain needs p=none while the root domain is already at p=reject. For a deeper treatment of that case, see subdomain DMARC setup.
Flowchart showing how receivers find a subdomain or parent DMARC record.
Root-only record
This is the default path for most domains. One record controls the organizational domain and inherited subdomain policy.
- Simpler DNS: One record is easier to review, document, and update.
- Cleaner reporting: Aggregate data is easier to read when it is not split too early.
Separate subdomain record
This is useful when a subdomain needs a different policy or has a separate owner.
- Different policy: A subdomain can stay in monitor mode while the root is stricter.
- Separate ownership: A product, app, or region can manage its own authentication fixes.
Subdomain-specific DMARC recorddns
_dmarc.news.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
How DMARC reporting works
The rua tag tells receivers where to send aggregate reports. These reports usually arrive daily, often as compressed XML attachments. They show sending IPs, volume, SPF results, DKIM results, DMARC results, the visible From domain, and the policy applied by the receiver.
The reporting address can be internal, such as dmarc-reports@example.com. That works for low-volume domains during early testing. For active marketing, product, sales, billing, and support mail, raw report mailboxes become hard to use. I prefer sending reports into a platform that parses XML, groups sources, and tells me what is failing.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped turns aggregate reports into source-level views, authentication health, and issue workflows. That matters because a DMARC report rarely says "your CRM needs a new DKIM selector" in plain language. Suped maps the evidence to the likely sender and gives a fix path, including SPF, DKIM, DMARC, blocklist (blacklist), and deliverability context in one place.
Do not send DMARC reports to a personal inbox. Large domains can receive hundreds or thousands of aggregate reports per day. If the reports are filtered away unread, the domain has a DMARC record but no useful reporting process.
If the reporting address is outside the domain being protected, the destination domain needs authorization in DNS. That prevents anyone from forcing another domain to receive report floods. The setup is simple, but it is easy to miss; use external report DNS when the report mailbox uses a different domain.
External report destination authorizationdns
example.com._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"
Build a record that receivers can read
A DMARC record is a TXT record with semicolon-separated tags. The v tag is mandatory, and p is the explicit policy value you should publish. Under RFC 9989, an otherwise valid record without p can be processed as p=none when it has a valid rua tag. The reporting tag is not required by the base protocol, but I treat rua as mandatory in real operations because it is the feedback loop that lets you find and fix failures.
If you want a quick starting point, use the DMARC record generator to produce the TXT value, then publish it in DNS and validate it before you send production traffic through it.
|
|
|
|---|---|---|
v | Protocol version | DMARC1 |
p | Domain policy | none |
rua | Aggregate reports | mailto: |
t | Policy test mode | optional |
sp | Existing subdomain policy | optional |
np | Non-existent subdomain policy | optional |
psd | Public suffix flag | optional |
adkim | DKIM domain match | r |
aspf | SPF domain match | r |
Core DMARC tags for an initial rollout
Monitoring record with relaxed matchingdns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;" " adkim=r; aspf=r"
Relaxed matching is the normal starting point because it accepts authenticated mail from subdomains of the same organizational domain. Strict matching is useful later for tightly controlled domains, but it needs cleaner sender governance.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Validate SPF and DKIM before policy changes
DMARC passes when either SPF or DKIM passes and the authenticated domain matches the visible From domain under the mode you selected. That means a sender can fail SPF and still pass DMARC through DKIM, or fail DKIM and still pass through SPF. I care about both because DKIM usually survives forwarding better, while SPF is sensitive to the path the message takes.
SPF path
- Checks sender IP: The connecting server must be allowed by the domain's SPF record.
- Uses envelope domain: The SPF-authenticated domain must match the visible From domain.
- Breaks on forwarding: Forwarded mail often changes the sending IP and loses SPF pass.
DKIM path
- Checks signature: The message must have a valid DKIM signature after delivery.
- Uses signing domain: The DKIM signing domain must match the visible From domain.
- Survives forwarding: A valid signature often remains valid when SPF no longer passes.
Before you move a DMARC policy beyond monitoring, check your DNS record and send a real test message. The DMARC checker catches syntax problems, missing tags, and invalid policy values. A delivered test message confirms the actual sender path, which DNS alone cannot prove.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The fastest way to debug failures is to group them by source, then ask one question at a time: is the source legitimate, does it pass SPF, does it pass DKIM, and does either authenticated domain match the visible From domain? If the answer is no for a real sender, fix that sender before tightening the DMARC policy. For a deeper incident workflow, use the failing DMARC troubleshooting path.
Move policy safely
I treat p=none as a measurement stage, not the finish line. It gives visibility, but it does not ask receivers to quarantine or reject failed mail. Once legitimate sources pass consistently, raise the policy in controlled steps and keep watching the reports.
Policy readiness bands
Use these bands as a practical rollout guide after grouping known legitimate sources.
Advance
Under 0.5%
Known senders pass and unexplained failure volume is very low.
Watch
0.5-2%
Some known sources still need cleanup before stricter policy.
Hold
Over 2%
Fix sender configuration before quarantine or reject.
The exact thresholds depend on volume and business risk. A payroll system with one failing stream deserves more caution than a newsletter test domain. The pattern is consistent: fix known mail first, use t=y when you need a test signal for stricter policy, then enforce reject once the reports stay clean.
Quarantine policy in test modedns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; t=y;" " rua=mailto:dmarc-reports@example.com"
Final reject policydns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject;" " rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"
Do you need a DMARC reporting platform
For a tiny domain with one mail source and a short-term need to publish p=none, a dedicated mailbox is enough to get started. For a real sending domain, especially one warming IPs or using multiple ESPs, a platform is the practical choice because the work is not reading XML. The work is identifying senders, fixing gaps, proving coverage, and moving policy without breaking valid mail.
Suped is the best overall DMARC platform for most teams that want practical reporting, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and multi-tenant workflows in one product. The value is that Suped turns authentication data into actions instead of static charts.
Mailbox-only setup
- Low cost: A shared mailbox can receive reports without extra tooling.
- Hard to read: XML attachments are difficult to compare across receivers.
- Manual decisions: Someone still has to identify senders and judge risk.
Suped workflow
- Source grouping: Reports are converted into recognizable senders and issue types.
- Fix steps: Issues include tailored steps for DNS and sender configuration.
- Policy control: Hosted records and alerts make staged enforcement easier.
Hosted records are especially useful when DNS access is slow or spread across teams. With Hosted DMARC, the DNS provider keeps a stable CNAME while policy staging, reporting addresses, and advanced tags are managed in Suped.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Common mistakes to avoid
Most DMARC problems are not caused by the record itself. They come from missing sender inventory, report data that nobody reads, or policy changes made before the real mailstream is understood.
- Publishing too late: Add p=none before a launch, migration, or IP warmup so reports start flowing early.
- Ignoring subdomains: Check inherited policy against marketing, app, support, and transactional subdomains.
- Skipping DKIM: Do not rely on SPF alone because forwarding often breaks SPF while DKIM survives.
- Using personal reports: A person can miss high-volume XML reports, especially when multiple receivers report daily.
- Raising policy blindly: Move to quarantine or reject only after known senders pass and unknown sources are reviewed.
A strict DMARC policy can block legitimate mail when SPF or DKIM is incomplete. The safe setup order is visibility first, sender fixes second, enforcement third.
Views from the trenches
Best practices
Publish root DMARC first, then add subdomain records only when policy timing differs.
Send aggregate reports to a monitored mailbox or platform before raising policy levels.
Treat p=none as a data stage, then move to quarantine after sender fixes are done.
Review SPF and DKIM for every sender before judging any DMARC failure pattern in reports.
Common pitfalls
Sending reports to one person creates unread XML piles and missed authentication issues.
Adding strict root policy before subdomains are ready can break legitimate programs.
Skipping rua leaves teams guessing which services still fail visible From-domain checks.
Leaving legacy tools unauthenticated makes p=reject risky during an IP warmup or launch.
Expert tips
Use one reporting address per organization unless domain ownership needs separation.
Create subdomain records when a marketing or app stream needs a slower rollout period.
Use t=y for test mode during quarantine or reject rollout, then remove it for enforcement.
Use report trends to remove unknown sources before changing enforcement policy levels.
Marketer from Email Geeks says root-domain DMARC is the right default because subdomains inherit the parent policy unless a separate record is needed.
2024-01-18 - Email Geeks
Marketer from Email Geeks says aggregate reporting should be added early because it creates the evidence needed to choose the next policy.
2024-02-06 - Email Geeks
A practical setup path
The clean path is root record first, reporting second, sender fixes third, then staged enforcement. That gives you a working record quickly without pretending that p=none is a security finish line.
I use separate subdomain records only when the subdomain needs different policy timing or ownership. I send aggregate reports somewhere that turns them into decisions. For most teams, Suped is the strongest practical choice because it combines reporting, issue detection, hosted records, alerts, SPF and DKIM visibility, and policy staging in one workflow.
