DMARC record generator
Choose a policy, a reporting address and your alignment. We build the record and flag the settings that will break your own mail.
Used to show you the hostname the record goes on. Nothing is looked up here.
Policy
Start on none with reports flowing. Every domain that skipped straight to reject and broke its own invoices did it in this order, except faster.
The daily XML summaries. Without this address the record does nothing useful on p=none.
Per-message forensic copies. Most large receivers never send these, and the ones that do include recipient data, so plenty of domains leave it off.
Subdomain policy
Subdomains inherit the main policy unless you set this. A reject on subdomains you never mail from closes a common spoofing route.
Your DMARC record
v=DMARC1; p=none| Where it goes | Value |
|---|---|
| Record type | TXT |
| Host / name | _dmarc.yourdomain.com |
| TTL | 3600 |
This record enforces nothing yet
Which is the right place to start. It collects the reports that tell you what would break under enforcement.
- No reporting address. On p=none this record does nothing at all: no enforcement and no reports.
The settings that break real mail
Strict alignment is the first trap. With aspf=s, the envelope sender domain must match the From: domain exactly, and almost every email platform uses its own bounce domain by design. Turning it on breaks mail that was passing a moment earlier.
Relaxed alignment, which is the default, accepts a subdomain match. That covers the normal arrangement where your ESP signs with a subdomain of yours, and it is what most domains should stay on.
The second trap is an unfinished rollout. A record left at pct=25 with p=reject looks like enforcement and enforces on a quarter of failing mail. Plenty of domains have sat there for years because the person who started the rollout moved on.
The third is jumping to reject with no reporting history. It works fine until the monthly invoice run goes out through a system that was never aligned, and those messages are now being rejected by every recipient rather than landing in spam.
| Setting | Safe default | When to change it |
|---|---|---|
| p | none, with rua set | Move to quarantine after a month of clean reports |
| adkim / aspf | Relaxed, which is the default | Rarely. Strict breaks most ESPs |
| pct | 100 | Lower it deliberately during a rollout, then finish the rollout |
| sp | reject, on domains whose subdomains send nothing | Leave inheriting while subdomains still send |
| ruf | Off | Only if you have somewhere to process forensic copies |
Getting reports you can act on
Aggregate reports arrive as compressed XML, one per receiving provider, once a day. A large domain gets dozens, and reading those by hand stops being reasonable quickly.
A dedicated mailbox is the minimum. A parser is better, and several free ones exist. What you are looking for in the first month is a list of sending IPs you cannot account for, and whether each one is a legitimate system of yours that simply is not aligned yet.
Once that list is empty, quarantine is safe. Give it a few weeks, then reject. The whole sequence takes a couple of months, and every step of it is boring, which is the point.
Questions people ask
Can rua point at a mailbox on another domain?
Yes, and that other domain has to publish a record authorizing it. Without that authorization record, reports are simply not sent and nothing tells you why.
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM authenticate identifiers a recipient never sees. DMARC is the piece that ties them to the From: address people read, and the only piece that produces reports.
Will Google reject my mail without a DMARC record?
For bulk senders, a record is required, and a record with p=none satisfies it. Complying is easy; getting value out of it takes the reports.
Should every subdomain have its own DMARC record?
Only where it needs a different policy. Otherwise the parent's sp tag covers them, which is simpler to maintain than a record per subdomain.
Policies decide who may send. Verification decides who can receive.
Both matter, and only one of them is settled by a DNS record. We report the addresses we reached a verdict on and label the ones nobody can.