How do I properly set up DMARC records and reporting for email authentication?
Updated on 22 Oct 2026: We clarified DNS publishing and report checks, and revised the enforcement steps for current DMARC standards and receiver compatibility.
Set up one DMARC TXT record for your organizational 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 an authenticated domain that matches the visible From domain under DMARC rules. After legitimate senders pass consistently, move to p=quarantine and then p=reject.
Starting at the organizational domain keeps the setup simple because subdomains normally inherit its policy unless they publish their own DMARC record. The parent record can use sp for existing subdomains and np for non-existent subdomains. A root record keeps policy and reporting destinations easier to manage. 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. This becomes useful when several teams or email providers use the same domain.
DMARC setup in five steps
DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers how to handle mail that fails its authentication checks and requests aggregate reports. The report data gives you evidence to tighten the policy without blocking real mail. DMARC protects the visible From domain against unauthorized use; it does not stop lookalike domains or guarantee inbox delivery.
- Add one TXT record at _dmarc for the organizational domain, such as example.com.
- Use p=none to monitor without requesting DMARC-based blocking. Other spam filtering still applies.
- Add rua=mailto: with a mailbox or reporting address that is actively monitored.
- Confirm every legitimate source passes SPF or DKIM with an authenticated domain that matches the visible From domain under DMARC rules.
- 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"
For DNS publishing and third-party sender checks, Google DMARC guidance recommends a report mailbox and authenticated third-party mail before tightening the policy. A monitoring policy does not replace working SPF and DKIM.
Where the DMARC record goes
Put the primary DMARC record at the organizational domain, not at every subdomain by default. If your visible From domain is example.com, publish the record at _dmarc.example.com. For news.example.com, receivers check _dmarc.news.example.com first. RFC 9989 specifies a DNS Tree Walk to find an applicable organizational-domain or public suffix domain (PSD) policy when that record is absent. Receivers using the older discovery method also support inheritance from the organizational domain.
A separate subdomain record makes sense when the subdomain has a distinct sending program, a different vendor stack, or a different rollout schedule. 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.
DMARC DNS lookup flowchart showing subdomain and parent policy checks before reporting.
Root-only record
This is the default path for most domains. One record controls the organizational domain and inherited subdomain policy.
- One record is easier to review, document, and update.
- One reporting destination keeps report collection easier to manage.
Separate subdomain record
This is useful when a subdomain needs a different policy or has a separate owner.
- A subdomain can stay in monitor mode while the root is stricter.
- A product team or regional team 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, message counts, SPF and DKIM results, the visible From domain, and the receiver's DMARC disposition. RFC 9990 defines aggregate reporting. Reports cover passing and failing mail seen by participating receivers, not every message sent or its inbox placement. Aggregate reports do not include message bodies or subject lines.
Aggregate reports are the baseline for monitoring. Failure reports requested with ruf can include message headers or content, so they need a privacy and security review before use. Not every receiver sends them, which means they cannot replace aggregate reporting. RFC 9991 defines these message-specific reports.
The reporting address can be internal, such as dmarc-reports@example.com. That works for low-volume domains during early testing. For several sending systems, raw report mailboxes become hard to use. Use a platform that parses XML and groups sources for investigation.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped turns aggregate reports into source-level views and authentication issues to investigate. A DMARC report rarely says "your CRM needs a new DKIM selector" in plain language. Suped groups the evidence by sending source and gives steps to check the sender configuration or DNS.
When reading XML, auth_results contains the underlying SPF and DKIM outcomes; policy_evaluated records the results after DMARC domain matching. An SPF pass alone does not prove a DMARC pass. Group failures by known sender, forwarding path, or suspected spoofing, and investigate unknown sources before authorizing them.
Use a dedicated reporting mailbox rather than 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 destination has a different organizational domain, the destination needs authorization in DNS. This prevents anyone from forcing another domain to receive report floods. For rua=mailto:dmarc@reports.example.net in the policy for example.com, the administrator of reports.example.net publishes the authorization record below in the destination's DNS. A reporting provider can publish a wildcard authorization for reports from any domain. See external report DNS for the setup.
External report destination authorizationdns
example.com._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"
Build a valid DMARC TXT record
A DMARC record is a TXT record with semicolon-separated tags. Start with v=DMARC1 as the first tag and publish an explicit p policy. Under RFC 9989, an otherwise valid record without p can be processed as p=none when it has a valid rua tag, but an explicit policy avoids ambiguity. The reporting tag is not required by the base protocol, but treat rua as operationally necessary because it is the feedback loop for finding and fixing 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 raising the policy.
|
|
|
|---|---|---|
v | Protocol version, first tag | DMARC1 |
p | Domain policy | none |
rua | Aggregate report destination | mailto:dmarc-reports@example.com |
t | Policy test mode | Omit for a basic rollout |
sp | Existing subdomain policy | Optional; defaults to p |
np | Non-existent subdomain policy | Optional; defaults to sp, then p |
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 default: the authenticated domain and visible From domain must share an organizational domain. Strict matching, selected with adkim=s or aspf=s, requires an exact domain match. Leave advanced organizational-domain discovery tags such as psd out of a basic setup.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Publish and verify DMARC in DNS
Edit the authoritative DNS zone for your domain, which is not always hosted by your registrar. Check for an existing DMARC record first and update it rather than adding another.
|
|
|---|---|
Type | TXT |
Name or host | _dmarc if the provider appends example.com; otherwise _dmarc.example.com |
Value or content | v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com |
TTL | Provider default or 3600 seconds |
Enter the TXT value without the record name or zone-file syntax; follow your provider's instructions for quotes.
Replace example.com and the report address with your own values. Check that the saved name is _dmarc.example.com, not _dmarc.example.com.example.com. Keep one DMARC TXT record at that name; multiple DMARC records are discarded. Quoted strings within one TXT record are concatenated and are different from separate records.
Look up the published DMARC TXT recordbash
dig +short TXT _dmarc.example.com
Confirm the public lookup returns the intended value after DNS caches expire. Reports are not immediate: allow 24-48 hours after mail reaches a participating reporting receiver. If reports do not arrive, check the published rua address, external authorization, and mailbox filtering. No reports does not prove no abuse.
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 selected mode. A sender can fail SPF and still pass DMARC through DKIM, or fail DKIM and still pass through SPF. Configure both because DKIM usually survives forwarding better, while SPF is sensitive to the path the message takes.
Inventory every legitimate sender, including website forms and occasional billing systems. Publish each provider's custom-domain DKIM records and enable signing at the provider. SPF requires a single record for each domain it checks, so merge authorizations rather than adding separate SPF records for each provider.
SPF path
- The connecting server must be allowed by the envelope domain's SPF record.
- The SPF-authenticated MAIL FROM domain, usually shown in Return-Path, must match the visible From domain under DMARC rules.
- Forwarded mail often changes the sending IP and loses SPF pass.
DKIM path
- The message must have a valid DKIM signature when the receiver checks it.
- The DKIM signing domain in d= must match the visible From domain under DMARC rules.
- A valid signature often survives forwarding, but mailing-list changes to signed content can break it.
For a visible From address of billing@example.com, DKIM signing with d=mail.example.com meets relaxed matching; signing only with d=vendor.example.net does not. Strict adkim=s requires d=example.com for this message.
Before you move a DMARC policy beyond monitoring, check your DNS record and send a real test message. The DMARC checker identifies syntax problems and duplicate DMARC records. 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.
Group failures by source, then inspect the receiving system's Authentication-Results header. Compare smtp.mailfrom for SPF, header.d for DKIM, and header.from for the visible From domain. If a legitimate source has no SPF or DKIM pass that meets DMARC domain matching, fix that sender before tightening policy. For a deeper incident workflow, use the failing DMARC troubleshooting path.
Move safely to quarantine and reject
Treat p=none as a measurement stage. It gives visibility, but it does not ask receivers to quarantine or reject failed mail. Review enough traffic to cover a normal sending cycle, including occasional invoices and automated mail. Once legitimate sources pass consistently, raise the policy in controlled steps and keep watching the reports.
Policy readiness checks
Judge readiness by legitimate sender coverage, not a universal failure percentage.
Advance
Senders verified
Every known legitimate source passes DMARC across its normal sending cycle.
Review
Investigate sources
Unknown sources or forwarding failures still need classification.
Hold
Fix legitimate mail
Known legitimate mail still fails DMARC.
A payroll system with one failing stream deserves attention even when the overall pass rate is high. Spoofing can increase the failure rate without indicating a sender configuration problem. Fix legitimate mail and classify unexplained sources before changing policy.
RFC 9989 defines t=y to request policy testing one level below the published policy. Receivers that do not recognize t ignore it and can enforce the full published policy. Publish only a p value that your legitimate traffic is ready for. The legacy pct tag is historic under RFC 9989; do not depend on it for percentage-based enforcement.
Quarantine policy after sender verificationdns
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; 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"
Keep reviewing reports after enforcement and whenever a sender or DNS configuration changes. Receivers make the final delivery decision, so a published policy is a handling request rather than a guarantee that every failed message is blocked.
Protect parked and non-sending domains
A registered domain that never sends email does not need a monitoring rollout. First confirm that no employee mailbox, website form, appliance, or third-party sender uses the domain in the visible From address. Then publish a reject policy immediately. A domain can still receive email through an MX record while requesting rejection of unauthenticated outbound use.
- Check business systems and vendors before declaring the domain non-sending.
- Publish v=spf1 -all so no sending IP is authorized for the domain.
- Use p=reject with reject policy for existing and non-existent subdomains. Review any separate subdomain DMARC records because their policies override inheritance.
- Include rua if attempted use of the domain should remain visible.
Non-sending domain recordsdns
example.com. 3600 IN TXT "v=spf1 -all" _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"
Do not use this configuration for a domain that sends even occasional invoices, alerts, or password resets. Authenticate that mail first and use the monitored rollout path.
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, provided someone can parse and review the XML. For an active sending domain using multiple email providers, a platform can reduce the manual work of identifying senders and tracking fixes before enforcement.
Suped's DMARC reporting and email authentication platform parses aggregate reports, groups sending sources, and flags authentication issues. Use those results to check legitimate sender coverage before changing a policy and to investigate failures after a configuration change.
Mailbox-only setup
- A shared mailbox can receive reports without extra tooling.
- XML attachments are difficult to compare across receivers.
- Someone still has to identify senders and judge risk.
Suped workflow
- Reports are grouped by sending source and authentication results.
- Issues include steps for checking DNS and sender configuration.
- Hosted records and alerts support staged policy changes.
Hosted records are useful when DNS access is slow or spread across teams. With Hosted DMARC, the DNS provider keeps a stable CNAME at the DMARC record name while policy and reporting addresses are managed in Suped. Follow the supplied CNAME setup instead of publishing a TXT record at the same name.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Common mistakes to avoid
DMARC problems often come from missing sender inventory, report data that nobody reads, or policy changes made before legitimate mail is understood.
- Add p=none before a launch, migration, or IP warmup so reports start flowing early.
- Check inherited policy against marketing and transactional subdomains, including any separate DMARC records.
- Do not rely on SPF alone because forwarding often breaks SPF while DKIM survives.
- Use a dedicated reporting address and assign someone to review reports.
- Move to quarantine or reject only after known senders pass and unknown sources are reviewed.
A strict DMARC policy can block legitimate mail when neither SPF nor DKIM passes with the required domain match. Publish monitoring first, fix legitimate senders, then enforce the policy.
Operational setup checklist
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 legitimate 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 all 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 a shared reporting destination unless domain ownership requires separate collection.
Create subdomain records when a marketing or app stream needs a slower rollout period.
Set p to a policy your senders can tolerate; receivers that ignore t=y enforce the full policy.
Investigate unknown sources before policy changes; never authorize an IP just to clear failures.
Frequently asked questions
No. Start with the organizational domain. Add subdomain records when a subdomain needs a different policy, reporting address, or rollout schedule.
Yes. Use a monitored group or mailbox for low-volume domains and review the XML reports. For active senders, a reporting platform can parse XML and highlight failures.
Start with p=none and rua reporting. Move to quarantine and reject after legitimate sources pass SPF or DKIM with an authenticated domain that matches the visible From domain under DMARC rules.
DMARC needs either SPF or DKIM to pass with the required domain match, but both should be configured. DKIM gives better resilience when forwarding breaks SPF.
Reject is the usual target after legitimate sending and forwarding paths have been assessed. Receiver exceptions and mailing-list behavior still need review. A confirmed non-sending domain can publish p=reject immediately with an SPF -all record.
Reports usually arrive daily after a participating receiver sees mail using your domain. Allow 24-48 hours, then check the published rua address, external destination authorization, and mailbox filtering. Not every receiver sends reports.
