A DMARC record is one line of text that tells receiving servers how to handle mail that fails SPF and DKIM alignment, and where to send reports about it. The syntax is short, but a typo can make receivers ignore the whole record, and publishing a strict policy too early can send your own invoices to spam.
This generator builds the record with valid syntax and explains each choice. Pair it with the staged rollout below and you can reach full enforcement without breaking legitimate mail.
The options in the generator
| Option | Tag | What it controls | Default |
|---|---|---|---|
| Policy | p= |
What to do with failing mail: none, quarantine or reject |
Required |
| Aggregate reports | rua= |
Where daily XML summaries go | Strongly recommended |
| Forensic reports | ruf= + fo=1 |
Where copies of individual failures go, and a request to report any failure | Optional |
| Subdomain policy | sp= |
Separate policy for subdomains | Inherits p |
| Percentage | pct= |
Share of failing mail the policy applies to | 100 |
| Strict alignment | adkim=s, aspf=s |
Require exact domain match instead of organisational match | Relaxed |
The generator outputs the record in the correct order, starting with v=DMARC1 and separating tags with semicolons.
Choosing a policy
p=none (monitor). Mail is delivered as normal. You receive reports showing every source that sends as your domain and whether it passes. Use it first, always.
p=quarantine. Failing mail goes to spam or junk. This is where you catch any source you missed without losing mail completely, since recipients can still find it.
p=reject. Failing mail is refused at the SMTP level, often with 550 5.7.26 at Gmail. This is the goal: it stops exact-domain spoofing and is required for BIMI logos.
A staged rollout from none to reject
Moving too fast is the most common DMARC mistake. This plan takes six to twelve weeks for most organisations.
Stage 1: monitor (weeks 1 to 4)
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Read the aggregate reports. List every source sending as your domain: your mailbox provider, ESPs, CRM, help desk, billing system, website forms. For each legitimate source that fails, set up aligned DKIM or a custom Return-Path. Check each fix with the DKIM checker and SPF checker.
Stage 2: partial quarantine (weeks 5 to 7)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
Raise pct to 50, then 100, as long as reports stay clean and nobody reports missing mail.
Stage 3: full quarantine (weeks 8 to 9)
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Stage 4: reject
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Keep reading reports afterwards. New tools get connected, and one that is not authenticated will now have its mail refused.
Reporting options explained
Aggregate reports (rua) arrive as zipped XML, usually once a day from each large receiver. They list sending IPs, message counts and SPF, DKIM and DMARC results. Raw XML is hard to read, so most teams send them to a DMARC reporting service or a parser.
Forensic reports (ruf) are copies or redacted samples of individual failing messages. Adding fo=1 asks receivers to send one when either SPF or DKIM fails, not only when both do. Many large providers no longer send forensic reports at all, and those that do may include personal data, so route them to a restricted mailbox.
You can list several addresses, separated by commas:
rua=mailto:dmarc@example.com,mailto:reports@dmarc-service.example
Where to publish the record
| Field | Value |
|---|---|
| Type | TXT |
| Host / Name | _dmarc (becomes _dmarc.example.com) |
| Value | The generated record |
| TTL | 3600, or 300 while you are adjusting it |
For a subdomain with its own policy, publish at _dmarc.news.example.com. Otherwise subdomains use the main record and its sp value.
After publishing, confirm the live record with the DMARC checker. If you send through an ESP such as Mailchimp, Brevo or SendGrid, make sure its DKIM is set up on your own domain first, since that is what lets its mail align.
Protecting domains that never send
Parked domains, old brand names and typo domains you registered defensively are easy targets for spoofers, because nobody watches them. Give each one a locked-down set of records:
_dmarc.example-old.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
example-old.com TXT "v=spf1 -all"
example-old.com MX 0 .
There is no rollout needed here. Since no legitimate mail should ever come from these domains, you can go straight to p=reject. Sending the reports to your main domain’s DMARC mailbox lets you see if anyone tries to abuse them.
After you reach reject
Enforcement is not the end of the job. Review aggregate reports monthly, add authentication for every new tool before it goes live, and rotate DKIM keys once or twice a year. With p=reject and a verified logo, you can also publish a BIMI record so supporting mailbox providers show your brand logo next to your messages.
Common generator mistakes to avoid
- Publishing at the root domain instead of
_dmarc. Receivers will not find it. - Two DMARC records. Receivers ignore both.
- Leaving out
mailto:in the report address. - Jumping straight to reject without reviewing reports.
- Setting
sp=nonewhile the main domain rejects, which leaves every subdomain open to spoofing.
For the bigger picture of how DMARC, SPF and DKIM fit together, read the email authentication guide. To see how your domain scores overall, run the sender reputation checker.