The anatomy of the record you are building
A DMARC record is a semicolon-separated tag list in a single TXT record on the _dmarc label. Only two tags are required — v and p — and every other tag has a defined default, so a minimal valid record is short:
# Minimal, and almost useless: no reports come back
v=DMARC1; p=none
# The record you should actually start with
v=DMARC1; p=none; rua=mailto:[email protected]
# The record you should end up with
v=DMARC1; p=reject; rua=mailto:[email protected]| Tag | Default when absent | What it does |
|---|---|---|
v=DMARC1 | Required, must be first | Identifies the record. Anything else and receivers discard it. |
p= | Required | none, quarantine, or reject — the policy for the domain itself. |
rua= | None sent | Address for daily aggregate XML reports. Effectively mandatory in practice. |
ruf= | None sent | Per-message failure reports. Largely obsolete; most receivers never send them. |
sp= | Inherits p | A different policy for subdomains. |
pct= | 100 | Percentage of failing mail the policy applies to. |
adkim= | r (relaxed) | How closely the DKIM d= domain must match From:. |
aspf= | r (relaxed) | How closely the MAIL FROM domain must match From:. |
fo= | 0 | Which failures generate a forensic report. Only meaningful with ruf. |
ri= | 86400 | Requested aggregate report interval in seconds. Receivers rarely honour anything but daily. |
The generator omits tags that match their default, which is deliberate. A record carrying pct=100; adkim=r; aspf=r says exactly the same thing as one without them, and shorter records are easier to audit at a glance six months from now.
Alignment: leave it relaxed unless you are sure
DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From: header domain. Relaxed alignment (r) accepts any name sharing the same organisational domain, so a From: of example.com aligns with a DKIM d=mail.example.com or a bounce address at bounces.example.com. Strict alignment (s) requires an exact, label-for-label match.
Read the full explanation of dmarc record generator results ↓Show less ↑
A staged rollout that will not eat your mail
The mistake that generates support tickets is publishing p=reject on day one. You do not yet know every system that sends as your domain — the invoicing tool, the monitoring alerts, the recruitment platform, the application relay someone set up in 2019. Enforce before you enumerate and those streams stop dead, silently, at every receiver that honours DMARC.
- Weeks 1–4 — `p=none` with `rua`. Publish
v=DMARC1; p=none; rua=mailto:[email protected]. Nothing changes for your mail. Aggregate reports start arriving daily as gzipped XML from each large receiver. Build the list of every source sending as your domain. - Fix alignment for each legitimate source. For third parties this almost always means completing their branded/custom DKIM setup so they sign with
d=example.cominstead of their own domain. Confirm each one with the DKIM checker, and confirm your SPF record is still inside the ten-lookup limit. - Weeks 5–8 — `p=quarantine`, ramping `pct`. Start at
pct=25, move to 50, then 100 over a few weeks. Failing mail goes to spam rather than being lost, so mistakes are recoverable and users report them. - Week 9 onward — `p=reject`, no `pct`. Full enforcement. Keep the
ruatag and keep reading reports: new SaaS tools get bought every quarter and each one is a fresh chance to break alignment.
Raw aggregate XML is readable but tedious at volume. Point rua at a mailbox you will actually check, or at a DMARC reporting service — either way, the tag has to be there. A domain sitting at p=none with no rua has all of the paperwork and none of the benefit.
Publishing it without the classic mistakes
- Record type TXT. There is no "DMARC" record type.
- Host/name:
_dmarc. Most panels append the zone automatically — typing_dmarc.example.comin a panel that appends will create_dmarc.example.com.example.com, which resolves to nothing. - Value: the whole tag string on one line. Do not split it across records.
- Exactly one DMARC record. Two at
_dmarcand receivers ignore DMARC for the domain completely — worse than publishing nothing. - If
ruapoints at a different organisational domain, that domain must publishexample.com._report._dmarc.reporter.comwithv=DMARC1, or receivers will not send your reports there (RFC 7489 §7.1). - Verify with the DMARC checker after the TTL expires, and with a raw TXT lookup if the checker disagrees with your panel.
Why this is no longer optional
Since February 2024, Google and Yahoo require any sender delivering 5,000 or more messages a day to their users to publish SPF, DKIM and a DMARC record of at least p=none, with the From: domain aligned to one of the two. Microsoft applied the same requirement to Outlook.com, Hotmail and Live from May 2025, initially filtering non-compliant mail to Junk. Below those volumes Gmail still expects at least SPF or DKIM on every message. A missing DMARC record is now a deliverability problem in its own right, not just a security gap.
Verify from the command line
# Read back exactly what you published
dig +short TXT _dmarc.example.com
# Catch the double-record mistake
dig +short TXT _dmarc.example.com | grep -c DMARC1
# Check what policy a subdomain will actually get
dig +short TXT _dmarc.mail.example.com
# Ask the authoritative nameserver, ignoring every cache
dig @$(dig +short NS example.com | head -1) TXT _dmarc.example.com +noall +answerThe record for a domain that never sends mail
Parked domains, brand-defence registrations and web-only domains are prime spoofing targets precisely because nobody monitors them. Publish v=DMARC1; p=reject; at _dmarc and v=spf1 -all on the bare domain. There is no rollout period to observe — no legitimate mail exists to break — so enforce immediately. Build the SPF half with the SPF generator.