Email authentication
DMARC record generator
Build a DMARC record step by step, from monitoring through to full enforcement.
Free, no accountIn your browser
Leave on "Same" unless a subdomain needs its own, lighter or stricter, policy.
Start below 100 while confirming the policy is not catching legitimate mail; raise it to 100 once it is.
Comma-separated if more than one. Needed to see what the policy is actually catching.
Per-message reports, if the receiver supports them. Most domains leave this empty.
Result
p=none
Publish the record below as a TXT record at "_dmarc." plus the domain.
- Info
Monitoring stage: nothing is enforced yet
Mail is delivered exactly as it would be without this record; the only effect is that reports start arriving at the address above, which is the point of this stage.
DMARC record to publish
At _dmarc (TXT)
Publish this at "_dmarc.<yourdomain>", not the domain itself.
- This builds the record you asked for; it does not check that the report addresses actually receive mail, or that an external address has authorised reports about this domain - the DMARC checker next door does both.
What this is
This DMARC record generator builds a valid record from the policy, percentage and report addresses you choose, and follows the recommended path a DMARC rollout actually takes: watch first, then quarantine, then reject, rather than enforcing anything on day one.
A DMARC record has one job with teeth - the "p" policy, which tells a receiver what to do with mail that fails SPF or DKIM alignment - and several jobs that support it: where to send reports, what percentage of failing mail the policy actually applies to, and how strictly alignment is judged.
The policy is not meant to go straight to "reject". It is meant to start at "none", where nothing is enforced and the only effect is that reports start arriving, so you can see what is actually failing before anything is blocked.
How to read the result
The stage shown in the findings - monitoring or enforcement - is the thing to watch, more than the raw tags. Monitoring means nothing is being blocked yet; enforcement means it is, for the percentage chosen.
A warning here is almost always about order: enforcing without anywhere for the reports to go, or jumping straight to full rejection without having watched first. Both still produce a valid record - DMARC does not require you to have read your own reports - but neither is the safe way to roll it out.
Common mistakes
What goes wrong most often, and how to tell.
- Publishing p=reject before reading a single reportWithout the aggregate reports, there is no way to know which of your own senders - a help desk, an old server, a marketing platform - would be rejected along with any forged mail.
- Leaving pct below 100 foreverA partial percentage is for the ramp-up period. Left low indefinitely, a share of failing mail keeps getting through one level lighter than the policy says, by design, with no plan to close it.
- Setting a policy with no rua addressEnforcing without a report address means failing mail is already being quarantined or rejected with no visibility into whether any of it was legitimate.
- Forgetting the subdomain policy defaults to the main oneLeaving "sp" unset is not a gap - RFC 7489 §6.3 says subdomains inherit "p" automatically. Set "sp" explicitly only when a subdomain genuinely needs a different policy.
How it works
- 1. Monitor at p=nonePublish with the policy set to "none" and a real aggregate address. Nothing is enforced; you are only collecting reports about what is passing and failing right now.
- 2. Read the reports before changing anythingConfirm every legitimate sender shows up passing. Anything failing that should not be is a gap in SPF or DKIM to fix first, not a reason to delay moving to enforcement forever.
- 3. Move to quarantine, below 100%Set the policy to "quarantine" with a percentage below 100, so only a sample of failing mail is affected while you confirm nothing legitimate is caught.
- 4. Raise the percentage, then move to rejectOnce quarantine at 100% shows nothing wrong, move to "reject", again starting below 100% and raising it once you are confident.
Questions
What people ask about this tool.
- Start at "p=none" to monitor without enforcing anything, confirm the aggregate reports show only mail you recognise, then move to "quarantine" and finally "reject" - raising the "pct" percentage gradually at each stage rather than jumping straight to 100%.
- Only if a subdomain should be treated differently. Without an "sp" tag, every subdomain inherits the main "p" policy automatically, so most domains never need to set it.
- It applies the chosen policy to only that percentage of failing messages, chosen at random by the receiver, and treats the rest one level lighter. It exists specifically so you can roll out quarantine or reject gradually instead of all at once.
- Because reject at 100% with no reporting address is the end of a rollout, not a safe place to start one - the warning is there so a domain is not accidentally dropping its own mail with nobody finding out.
Use it from the API
The same check, as one request.