Policy Composer

DMARC Record Generator.

Build a syntactically-clean v=DMARC1 TXT record without memorising tag names. Pick a policy, set reporting endpoints, and copy the result straight to your DNS host.

Where will this record live? Without subdomain — DMARC publishes at _dmarc.{domain}.

What should receivers do with mail that fails DMARC? Start at none, escalate to quarantine, finish at reject.

Optional. Overrides the policy for subdomains. Leave empty to inherit.

Legacy tag. The DMARCbis update (RFC 9989) removed pct= — enforcement is now all-or-nothing, so roll out by advancing p=none → p=quarantine → p=reject rather than by percentage. Leave this blank for new records; only set it if you must interoperate with a receiver that still reads pct=.

Mailto: for aggregate XML reports. Use a dedicated DMARC platform address; raw XML is not human-readable.

Mailto: for per-message failure reports. Most platforms ignore this; safe to leave blank.

Relaxed is the safe default for most rollouts. Strict if you control every sending source.

Relaxed allows subdomain DKIM signatures. Strict requires exact match to From: domain.

Which failure types trigger ruf reports. 1 = either SPF or DKIM fails (most useful default).

Seconds between aggregate report bundles. Default is 86400 (24h). Most receivers honor this.

terminal

Generated DMARC Record

Live updates as you fill the form. Copy and publish at _dmarc.{domain} as a TXT record.

Publish at
_dmarc.example.com
Record value
v=DMARC1; p=none;

How the generator builds your record

The composer assembles a string that starts with v=DMARC1; (required), then appends each non-empty tag in the order RFC 7489 recommends. Tags you leave blank are omitted entirely — DMARC defaults fill in. No string-escape headaches; no DNS provider treats the output differently.

A safe rollout, every time

Generate at p=none first. Watch reports for 2–4 weeks. Move to p=quarantine once your sender inventory is clean, then to p=reject after pass-rate is steady for several reporting cycles. The DMARCbis update (RFC 9989) removed the pct= tag, so each step is all-or-nothing — sender-inventory quality is the safety mechanism, not a percentage.

Every DMARC tag, explained

Tag Description
v= Always v=DMARC1. The version marker. Anything else makes the record invalid.
p= none, quarantine, or reject. What receivers do with mail that fails DMARC.
sp= Same values as p=. Defaults to whatever p= is set to.
pct= Removed by the DMARCbis update (RFC 9989). Older records used an integer 0-100 to apply the policy to a fraction of failing mail; enforcement is now all-or-nothing. Omit from new records.
rua= Comma-separated mailto: URIs for aggregate XML reports.
ruf= Per-message failure reports. Most receivers ignore this.
adkim= r (relaxed, default) or s (strict).
aspf= r (relaxed, default) or s (strict).
fo= 0, 1, d, s. Controls which failures trigger ruf reports.
ri= Seconds between aggregate reports. Default 86400 (24h).

The four-phase rollout your record needs to support

Publishing a v=DMARC1 record is the first move, not the last. The phases below are the operational arc every successful DMARC deployment travels. The generator above lets you compose the right record for the phase you're in.

1
2–4 weeks

Discover (p=none)

Publish p=none with rua= pointed at a DMARC platform. Read the aggregate reports until your sender inventory is stable and you've fixed obvious authentication gaps. No mail is blocked.

2
4–6 weeks

Enforce (p=quarantine)

Move to p=quarantine once the discovery phase shows a clean sender inventory. Failing mail goes to recipient spam folders; legitimate senders you missed surface as anomalies in the reports. The DMARCbis update (RFC 9989) removed the pct= tag, so this is an all-or-nothing switch rather than a percentage ramp — which is why the discovery phase matters.

3
Ongoing

Enforce full (p=reject)

Move to p=reject when quarantine has been stable for several reporting cycles with 99%+ pass rate from legitimate senders. Failing mail is bounced at the SMTP gate.

4
Ongoing

Maintain

New SaaS signups, DKIM rotations, brand acquisitions — every change to the sender estate requires confirming DMARC posture. The recurring monitoring is the work that justifies the service line.

Common DMARC record mistakes

Most published DMARC records have at least one of the following issues. Skim before you publish.

critical p=reject as the first published record expand_more
Symptom
You publish v=DMARC1; p=reject; with no rollout monitoring; legitimate mail starts bouncing within hours.
Fix
Always start at p=none. Move to quarantine and reject only after the discovery and enforce-partial phases complete cleanly.
high No rua= reporting address expand_more
Symptom
You publish a policy but get no aggregate reports — flying blind on deliverability impact.
Fix
Add rua=mailto:[email protected]. Use a DMARC platform endpoint for the parsed view.
high rua= address on a different domain without delegation expand_more
Symptom
Receivers refuse to send reports to the cross-domain address.
Fix
Publish a DMARC reporting delegation TXT at {your-domain}._report._dmarc.{rua-host}. The generator notes when this applies.
medium Legacy pct= tag still in the record expand_more
Symptom
The DMARCbis update (RFC 9989) removed the pct= tag entirely, but an old pct=25 or pct=100 left over from a percentage-ramp rollout still lingers in the published record.
Fix
Remove pct= altogether. Enforcement is now all-or-nothing: advance p=none → p=quarantine → p=reject once your sender inventory is clean.
medium Strict alignment (adkim=s aspf=s) on first publish expand_more
Symptom
Many legitimate mail flows fail alignment because they use subdomain DKIM signatures.
Fix
Start with relaxed alignment. Move to strict only after auditing every legitimate sender uses exact From: alignment.
low ruf= configured but unused expand_more
Symptom
Forensic report mailbox exists but receives nothing because most major receivers don't send ruf reports.
Fix
Safe to leave ruf= off entirely. ruf is rarely useful and adds attack surface (per-message detail).

DMARC Generator vs hand-crafting the TXT

You can absolutely hand-write a DMARC record — the syntax is forgiving and the tag set is small. Generators add value in three places: validating every tag against RFC 7489 before you publish (the most common errors are typos in p= and rua=), surfacing the soft warnings that the spec doesn't enforce but operational experience does (p=reject without rua= is technically valid but operationally reckless), and producing a copy-ready TXT string with mailto: prefixes already in place so DNS providers don't reject the record on save.

No percentage ramp under DMARCbis

DMARCbis (RFC 9989, published May 2026) removed the pct= tag, so there is no partial rollout to compose and any generator still offering one is out of date. The progression is p=none, then p=quarantine, then p=reject, and each step applies to every message at once. That puts the weight on the sender inventory you build while the policy is still at monitoring.

How to audit a UK client domain DMARC for UK MSPs

Pair this with the rest of your auth stack

verified

DMARC validator

Audit the live record after publishing — does what you generated actually resolve at receivers?

 mark_email_unread

SPF analyzer

DMARC fails if SPF or DKIM doesn't align. Check SPF lookup count and include chain before going to enforcement.

 vpn_key

DKIM validator

Verify every selector your mail flows use, plus key length. 1024-bit keys are increasingly distrusted.

 dns

DNS Lookup

Confirm the TXT you just published actually resolves at every authoritative resolver — Cloudflare, Google, Quad9.

Continue learning

The academy articles that go deeper on each DMARC tag.

What does DMARC p=none mean? north_east

Why monitoring mode is the right first step, and what to look for in the first two weeks.

DMARC policy explained: p=none, p=quarantine, p=reject north_east

When to move between phases and how to recognize you're ready.

DMARC alignment explained: relaxed vs strict north_east

When relaxed is enough; when strict catches the spoof attempts relaxed misses.

How to move from DMARC monitoring to enforcement safely north_east

The p=none → p=quarantine → p=reject progression, the rollback windows, and the checkpoint that confirms enforcement is safe.

Authoritative references

Generator FAQ

What goes in the rua= address? expand_more
A mailbox that accepts the aggregate XML reports. Use a DMARC platform endpoint (e.g., tenant-specific address) so the XML gets parsed into a usable dashboard rather than landing in your IT team's inbox as unreadable XML.
Should I publish at p=reject immediately? expand_more
No. Start at p=none for 2–4 weeks of monitoring, then move to p=quarantine once your sender inventory is clean, and finally to p=reject. The DMARCbis update (RFC 9989) removed the pct= tag, so each step is all-or-nothing — p=reject is the end state of a rollout, not the starting point, and the generator warns you if you try.
What if my rua= mailbox is on a different domain? expand_more
You need DMARC reporting delegation — publish a TXT at {your-domain}._report._dmarc.{rua-host} authorizing reports to flow across domains. Without it, receivers will silently refuse to send reports.
Can I include multiple rua= addresses? expand_more
Yes — separate them with commas inside the rua= tag. Most receivers honor up to 2 comma-separated mailtos. Use one for the platform that parses XML and a second for an archive mailbox if you want belt-and-braces visibility.
What's the difference between relaxed and strict alignment? expand_more
Relaxed (the default) lets organizational-level alignment satisfy DMARC — a DKIM signature from mail.example.com is good enough for a From: of example.com. Strict requires an exact match. Most rollouts use relaxed; switch to strict only after auditing every legitimate sender.
Why is the generator warning me when I haven't done anything wrong? expand_more
Soft warnings (yellow) point out operationally risky combinations — p=reject without rua= is technically a valid record but you'll be flying blind. The generator never blocks a valid record; warnings are advisory.
How is this different from typing the record by hand? expand_more
Functionally identical — the syntax is forgiving and the tag set is small. The value-adds: server-side validation against RFC 7489, mailto: prefixes added automatically, copy-ready output (no quote characters that some DNS providers reject), and warnings for operationally risky combinations.
Will the generator publish the record for me? expand_more
No. We compose the TXT body; you publish it at your DNS provider. The "Publish at" hostname above tells you exactly where: _dmarc.{your-domain} as a TXT record. Most providers also accept TXT records of this length without issue.

Stop composing DMARC records by hand.

DMARC AI generates, publishes, monitors, and escalates DMARC policies across your entire client portfolio — one dashboard, multi-tenant.

Start free account arrow_forward Book demo