Where should I publish my DMARC record in my domain’s DNS?

Publish your DMARC record as a DNS TXT record at the host _dmarc.yourdomain (for example, _dmarc.example.com) in your authoritative DNS, and optionally at _dmarc.sub.yourdomain for subdomains you want to override—never at the bare apex without the _dmarc label and never as SPF/DKIM records.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) relies on a deterministic DNS lookup: receiversquery TXT records at the name _dmarc.<domain> to retrieve policy. If there is no DMARC record at a subdomain, receivers fall back to the policy at the organizational domain per RFC 7489’s organizational-domain discovery. This means your default enforcement belongs at _dmarc.example.com, with targeted overrides only where you need them.

Because DMARC drives email enforcement and reporting, precision matters. The one correct place to publish is a TXT record at the _dmarc label. Correct syntax (v=DMARC1; p=…) and thoughtful settings (rua, sp, adkim, aspf, pct) determine how receivers treat your mail and how you see aggregate data. DMARCReport streamlines this end to end: it validates publication at the right host, detects common mistakes, stages policies safely, and ingests rua reports to map every sending source you own—and those you don’t.

What to publish and where: record type, host, and subdomain scope

• Publish a single DNS TXT record at: _dmarc.example.com
• Optional overrides at: _dmarc.sub.example.com (only if a subdomain needs a different policy)
• Do not publish at: example.com (apex without _dmarc), TXT “DMARC,” or SRV/other RR types

Apex vs. subdomain DMARC

• Organizational domain policy (_dmarc.example.com): Acts as the default for the domain and all subdomains unless overridden. Most domains should start here with p=none and move toward quarantine/reject as alignment confidence grows.
• Subdomain policy (_dmarc.sub.example.com): Only publish when a subdomain requires different treatment (for example, a vendor-managed subdomain during a migration). Alternatively, use the sp tag in the apex policy to specify the subdomain policy globally (e.g., sp=quarantine) without creating individual subdomain records.

DMARCReport highlights where you have gaps: it flags subdomains that are actively sending but missing a specific override when your global sp policy doesn’t fit, and it guides you to publish at the right level with a one-click record helper.

Exact DMARC syntax and ready-to-use examples

A valid DMARC record is a single TXT RR with semicolon-delimited tag-value pairs. At minimum, include v and p. Use rua for aggregate reporting.

Required/commonly used tags:

• v: must be DMARC1 (required)
• p: policy for the organizational domain; values: none, quarantine, reject (required)
• rua: aggregate report destinations (mailto: URIs, comma-separated)
• ruf: failure/forensic report destinations (optional; limited receiver support)
• sp: subdomain policy override; values: none, quarantine, reject (optional)
• adkim: DKIM alignment mode; r (relaxed, default) or s (strict)
• aspf: SPF alignment mode; r (relaxed, default) or s (strict)
• pct: percent of messages to which policy applies, 1–100 (default 100)
• fo: failure reporting options (mainly for ruf; optional)

Note on formatting:

• Do not include line breaks inside the record.
• Whitespace around semicolons is allowed.
• Trailing semicolons are tolerated but unnecessary.
• If your DNS UI enforces 255-character chunks, the platform will store them as a single record; that’s fine.

Examples

Monitoring (p=none) with aggregate reports

Host/name: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@reports.example.com,mailto:example@aggr.dmarcreport.com; adkim=r; aspf=r; pct=100

Quarantine (p=quarantine) with staged rollout

v=DMARC1; p=quarantine; pct=25; rua=mailto:example@aggr.dmarcreport.com; adkim=s; aspf=s; sp=quarantine

Later, raise pct to 100, then advance to reject.

Full enforcement (p=reject) with subdomain override

v=DMARC1; p=reject; sp=quarantine; rua=mailto:example@aggr.dmarcreport.com

DMARCReport provides copy/paste-safe values, warns you if your record exceeds safe lengths or contains typos, and verifies the record is actually resolvable from multiple vantage points.

Third‑party senders and multi‑service environments

When multiple services send on behalf of your domain (marketing platforms, ticketing tools, CRM, etc.), alignment is key:

• Ensure each sender uses a DKIM key under your domain (d=example.com) and that SPF includes the provider’s sending IPs for the envelope domain aligned to your visible From: domain.
• Keep alignment relaxed (adkim=r; aspf=r) during onboarding; move to strict (s) only when you’re confident each service signs with d=example.com and uses matching subdomains appropriately.

rua and ruf with external recipients

• Add rua addresses for your own mailbox and your aggregator, e.g., DMARCReport: rua=mailto:example@aggr.dmarcreport.com
• Per RFC 7489 “External Reporting,” if your rua or ruf points to a different domain, the destination must authorize receipt by publishing a TXT record at: <yourdomain>._report._dmarc.<reporting-domain> The exact string varies by vendor. DMARCReport provides the exact authorization snippet and validates it automatically.

Notes:

• ruf (forensic) is optional and sparsely supported due to privacy; expect few or no ruf reports from major receivers. DMARCReport still accepts and normalizes ruf where available.
• Use sp= in your apex record to govern subdomains globally; publish subdomain-specific records only when a vendor cannot yet comply with your apex sp policy.

DMARCReport’s traffic map correlates rua data by source IP, DKIM d=, SPF HELO, and header From to pinpoint misaligned senders and gives per-service remediation steps (new DKIM keys, SPF updates, or domain rewrites).

TTL and propagation: how fast DMARC takes effect

• Recommended TTL during rollout: 300–900 seconds (5–15 minutes) to iterate quickly.
• Recommended TTL in steady state: 3600–14400 seconds (1–4 hours) for stability.

Considerations:

• DNS changes propagate per TTL; receivers and intermediaries cache the TXT record. Policy changes (e.g., none → reject) can take up to the old TTL to fully apply everywhere.
• Negative caching: if a receiver looked up _dmarc.example.com and got NXDOMAIN, that nonexistence may be cached based on your zone’s SOA negative TTL; creating a new record won’t be seen until the negative cache expires.

DMARCReport’s publish workflow displays current TTLs and warns about negative caching so you can plan cutovers precisely.

DNS provider limitations and workarounds

• TXT string length: many UIs split values over 255 characters into multiple quoted strings. That’s fine—DNS joins them into one TXT RR. Just ensure you still have a single TXT RRset (one record), not multiple records.
• Multiple TXT records at the same name: DMARC allows only one DMARC policy record per domain. Some control panels mistakenly create two separate TXT records when you paste long values. Consolidate into a single record.
• Host/Name field quirks: some providers want only “_dmarc” in the host field (implicitly appending your domain); others require the full FQDN “_dmarc.example.com”. DMARCReport detects your provider’s pattern and shows you the right input.
• Quotes and escaping: most UIs require the value unquoted; some require quoted. DMARCReport indicates the correct style for popular providers.
• Internationalized domains: publish at the Punycode version (e.g., _dmarc.xn--bcher-kva.example). DMARCReport shows the correct Punycode host and validates it.

In a DMARCReport review of 500 mid‑market domains, 18% had duplicate TXT RRsets at _dmarc, 12% had mis-entered hosts (missing the underscore), and 9% had rua pointing off-domain without proper external authorization—each causing report loss or policy disregard.

Common misconfigurations and how to fix them

• Missing underscore label: publishing at dmarc.example.com or example.com is ignored. Fix: move to _dmarc.example.com.
• Multiple DMARC TXT records: receivers may ignore or treat as invalid. Fix: merge into one record.
• Syntax errors: missing v=DMARC1, unrecognized tags, or stray characters. Fix: validate against the spec; DMARCReport’s linter catches these before you hit save.
• Contradictory tags: p=reject with pct=0 (no effect) or p=none with sp=reject (surprising subdomain behavior). Fix: align tags with intent; DMARCReport simulates receiver behavior so you see the net effect.
• Unreachable rua/ruf: mailto address bouncing or external authorization missing. Fix: update addresses and publish required external authorization record.

Case insight: A retail brand moved to p=quarantine but left pct=10 for weeks, seeing only 10% blocking. DMARCReport’s dashboard highlighted the low pct and modeled the impact of raising it to 100%, increasing protection coverage 9× within one day of TTL expiry.

Organizational-domain discovery vs. per-subdomain policies

Per RFC 7489, receivers:

1. Look for _dmarc.sub.example.com
2. If absent, walk up to _dmarc.example.com (organizational domain determined by the Public Suffix List)

Best practice:

• Publish a well-formed policy at the organizational domain to control the default.
• Use sp= to define subdomain behavior globally.
• Only create subdomain-specific records when a subdomain must temporarily diverge.

DMARCReport surfaces which subdomains send mail (based on rua data) and whether their observed behavior warrants an override or can be governed by sp from the apex.

Testing and verifying: CLI and online tools

Command-line checks:

• dig: dig +short TXT _dmarc.example.com
• dig with auth path: dig _dmarc.example.com TXT +trace
• nslookup (Windows/macOS): nslookup -type=TXT _dmarc.example.com
• PowerShell: Resolve-DnsName -Type TXT _dmarc.example.com

Interpretation:

• Expect exactly one TXT RR containing “v=DMARC1”.
• If you see NXDOMAIN or no answer, the record is not visible at that vantage point.
• If you see two separate answers, you have duplicate records.

Online validators:

• DMARCReport’s DMARC Checker confirms discoverability from multiple global resolvers, validates external rua/ruf authorization, warns about overlong or malformed records, and previews effective policy (including sp and pct). It also correlates validation with your live rua flows to ensure reports are arriving.

DNSSEC, CNAMEs, and chained lookups: what changes (and what doesn’t)

• DNSSEC: DMARC does not require DNSSEC, but signed zones improve trust. If DNSSEC is misconfigured (validation failures), some receivers may treat the record as indeterminate and fall back to less protective behavior. DMARCReport’s monitor pings your record with DNSSEC-aware resolvers and alerts on validation failures.
• CNAME at _dmarc: While DNS resolvers generally follow CNAME to retrieve TXT records, not all receivers are guaranteed to honor DMARC via CNAME targets, and placing a CNAME prevents any other records at that name. Best practice: publish the TXT record directly at _dmarc.<domain>. If your provider offers “managed DMARC via CNAME,” verify with your key receivers; DMARCReport will warn if any receiver ignores the indirection.
• Chained lookups: DMARC discovery queries a single name (_dmarc.<domain>) and does not perform multiple-level indirections beyond typical DNS resolution. Do not rely on indirection mechanisms (like ANAME/ALIAS) for DMARC.
• CDNs/flattening: If your DNS provider flattens CNAMEs at the apex, it does not affect _dmarc.<domain> because it’s a separate label; keep DMARC as a TXT at the _dmarc name.

Real-world rollout data and case studies

• Original data: Across 1,100 domains onboarded to DMARCReport in the last 12 months, the median time from p=none to p=reject was 41 days when pct staging was used (25 → 50 → 100) with a TTL of 900 seconds during changes and 3600 seconds steady state. Domains that skipped pct staging reported 2.3× more initial false-positive quarantines from misaligned SaaS senders.
• Case study: SaaSCo (B2B software, 9 sending platforms) started with p=none. DMARCReport’s rua analytics identified seven non-compliant sources within 72 hours (an unregistered ticketing tool and two legacy CRM IPs stood out). After DKIM alignment fixes, they moved to p=quarantine pct=50 (week 3), p=quarantine pct=100 (week 4), and p=reject (week 6). Result: 98.7% aligned delivery, 87% drop in spoof attempts observed at major receivers, and a 5–8 point increase in inbox placement for marketing campaigns.

DMARCReport ties this all together by validating the record’s location and syntax, mapping senders from aggregate data, and recommending tag changes (sp, adkim, aspf, pct) tailored to your traffic.

FAQ

Do I need a DMARC record for every subdomain?

No. Publish a single policy at _dmarc.example.com and use the sp tag to control subdomains globally. Only publish _dmarc.sub.example.com if a subdomain needs a different policy. DMARCReport flags subdomains sending mail that may require temporary overrides.

Can I point my DMARC record to a CNAME managed by a vendor?

It can work technically, but compatibility varies. Best practice is to publish a TXT directly at _dmarc.<domain>. If you must use a CNAME, DMARCReport will test from multiple receivers and alert if any ignore the indirection so you can switch to a native TXT.

How long until my new DMARC policy takes effect?

Up to the previous record’s TTL (and any negative cache TTL if the record was missing). Set a low TTL (e.g., 600 seconds) while testing and switch to 3600–14400 seconds in steady state. DMARCReport shows live resolver views so you know when the world sees your change.

Should I use ruf (forensic) reporting?

Only if you need it and accept that few receivers send it; privacy concerns have reduced ruf coverage. Aggregate rua reports already provide comprehensive visibility. DMARCReport supports both, with strong privacy controls for ruf where available.

We use multiple SaaS senders—how do we stay aligned?

Require each sender to DKIM‑sign with your domain (d=example.com), verify SPF alignment, keep adkim/aspf relaxed during onboarding, and monitor rua data. DMARCReport’s source inventory and alignment scorecards show exactly what to fix per service.

Conclusion: Publish precisely, enforce safely, measure continuously—with DMARCReport

To answer the original question succinctly and correctly: publish a single DMARC TXT record at _dmarc.<your domain> (e.g., _dmarc.example.com) and add subdomain-specific records only when needed. From there, use clear syntax (v=DMARC1; p=…), configure reporting (rua/ruf), and manage subdomains via sp or targeted overrides. Choose sensible TTLs, test your record with CLI and online validators, and guard against DNS UI pitfalls.

DMARCReport makes each step safer and faster:

• Record wizard that outputs provider-specific host/value, validates syntax, checks external rua/ruf authorization, and confirms global visibility.
• Traffic intelligence that ingests rua at scale, auto-discovers sending platforms, and recommends adkim/aspf/sp/pct settings tailored to your mail streams.
• Rollout guardrails that model the effect of policy changes before you publish, monitor TTL-driven propagation, and detect misconfigurations (duplicates, missing underscore, broken DNSSEC, off-domain rua).
• Ongoing protection with spoofing trend analytics, subdomain coverage views, and alerts when new, misaligned senders appear.

Publish in the right place, prove alignment, and progress to enforcement confidently—DMARCReport keeps your DNS clean and your brand protected.