🔑 DMARC Record Generator

Build a syntactically valid DMARC TXT record. Set your policy, reporting addresses, alignment mode and rollout percentage — the generator handles correct tag order and formatting.

✍️ Author: ToolsNovaHub Editorial Team • ✅ Reviewed by: ToolsNovaHub Security & Network Team • 📅 Last Updated: 15 August 2026
Used only to show where to publish the record — not sent anywhere.
Applies only when p= is quarantine or reject. Use below 100 for a gradual, lower-risk rollout.
Comma-separated. mailto: is added automatically. Strongly recommended.
Optional. Most receivers today send little or no forensic data regardless.
Optional. Most receivers send daily regardless of this value; leave blank for default.

What Is DMARC and Why Generate a Record Instead of Writing One by Hand

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record that tells receiving mail servers two things: what to do with mail claiming to be from your domain that fails SPF and DKIM alignment, and where to send reports about that authentication activity. The record itself is a single line of semicolon-separated tags, but getting the syntax exactly right — correct tag names, correct value formats, mailto: prefixes on reporting addresses, valid percentage ranges — is easy to get subtly wrong by hand, and a malformed record is typically treated by receivers as no record at all, silently discarding whatever protection you thought you'd published.

⭐
ToolsNovaHub Pro Tip
Start with p=none and a working rua= address before ever touching quarantine or reject. A week or two of aggregate reports showing all your legitimate mail passing cleanly is the safest evidence you're ready to enforce.
⚠️
Common Beginner Mistake
Jumping straight to p=reject on day one. Without first confirming every legitimate sending source (including ones you might have forgotten about) passes alignment, reject can silently block real mail the moment it's published.

How the Generator Works

Every field maps directly to one DMARC tag as defined in RFC 7489. The generator assembles them in the conventional order (v, p, sp, pct, rua, ruf, fo, adkim, aspf, ri), joins them with semicolons, formats reporting addresses as mailto: URIs automatically, and omits any tag you leave at its default or empty state — producing the shortest valid record that expresses exactly what you configured, rather than a bloated record listing every possible tag regardless of whether you set it.

DMARC Policy Controls Explained

TagPurposeTypical Starting Value
p=Policy for your exact domainnone, moving to quarantine then reject over time
sp=Separate policy for subdomainsLeave inherited unless subdomains need different handling
pct=Percentage of failing mail the policy applies to100, or lower during a gradual reject rollout
rua=Where aggregate reports are sentAn address you or your team actually monitors
ruf=Where forensic (per-message) reports are sentOptional; many receivers send little forensic data
fo=When forensic reports are triggeredOnly relevant if ruf= is set
adkim= / aspf=Alignment strictness for DKIM / SPFr (relaxed) for both, unless you have a specific reason for strict
ri=Requested reporting interval in secondsLeave default; most receivers send daily regardless

p=none vs quarantine vs reject

none takes no delivery action at all — it exists purely to turn on reporting so you can observe what's happening before enforcing anything. quarantine routes failing mail to spam/junk rather than blocking it outright, a reasonable middle step. reject blocks failing mail from being delivered at all, the strongest protection and the appropriate end state once you're confident every legitimate source is properly aligned. Moving through these in order, with real report data checked at each stage, is the difference between a safe DMARC rollout and one that silently breaks legitimate mail.

Practical Examples

ScenarioExample Record
Just starting, monitor onlyv=DMARC1; p=none; rua=mailto:reports@example.com
Gradual reject rollout at 25%v=DMARC1; p=reject; pct=25; rua=mailto:reports@example.com
Full enforcement, strict alignmentv=DMARC1; p=reject; pct=100; rua=mailto:reports@example.com; adkim=s; aspf=s

Common Mistakes This Generator Prevents

❌
Missing mailto:
Bare email addresses in rua/ruf are invalid syntax; the generator adds the prefix automatically.
❌
Wrong Tag Order
While technically flexible, conventional ordering avoids issues with less forgiving parsers; the generator always outputs the standard order.
❌
pct= Out of Range
Values must be 0-100; the generator's slider makes an invalid value impossible to enter.

Security Considerations

A DMARC record is only as protective as the SPF and DKIM setup it relies on for alignment — publishing a strict p=reject record without correctly configured, passing SPF and DKIM first will block your own legitimate mail, not just spoofed mail. Always verify SPF and DKIM are passing cleanly (via SPF Lookup and DKIM Lookup) before tightening DMARC policy.

Troubleshooting After Publishing

If aggregate reports show legitimate mail failing after publishing, check alignment mode first (relaxed vs strict) since strict alignment is a common, easy-to-miss cause of otherwise-legitimate mail failing DMARC despite SPF or DKIM passing individually. Use DMARC Lookup to confirm exactly what's currently published and propagated.

Related Reading

For the full process of planning a rollout, see Create a DMARC Record. For what every tag means in depth, read DMARC Tags Explained. For choosing between rua and ruf, see rua vs ruf. For a full safe-rollout checklist, see DMARC Deployment Checklist. For general best practices, read DMARC Best Practices.

🔗 Related Tools

🛡️
DMARC Lookup
Check any domain's live DMARC record
🔒
SPF Lookup
Parse SPF mechanisms & lookup count
🔑
DKIM Lookup
Check DKIM selector & public key

FAQ

A single, syntactically valid DMARC TXT record string, built from the policy and tag values you choose, ready to publish at _dmarc.yourdomain.com in your DNS zone.
No — the generator handles correct tag ordering, semicolon separation, and mailto: formatting automatically; you just choose values from labeled controls.
p= sets the policy for your exact domain; sp= optionally sets a separate policy specifically for subdomains, letting you enforce differently at the subdomain level than at the root.
100 is the default and is fine to start with since p=none (monitor-only) doesn't affect delivery either way; pct= becomes meaningful once you move to quarantine or reject and want a gradual rollout.
Not technically required by the specification, but strongly recommended — without it, you have no visibility into aggregate authentication results for your domain, which is the primary way most domains actually detect problems before enforcing a strict policy.
rua= requests periodic aggregate summary reports; ruf= requests forensic reports for individual failing messages. See the companion guide on rua vs ruf for a full comparison.
Because RFC 7489 requires reporting addresses to be specified as full mailto: URIs within the record, not bare email addresses; the generator handles this formatting for you to prevent a common manual syntax mistake.
They set DKIM and SPF alignment strictness respectively — r for relaxed (organizational-domain match is sufficient) or s for strict (exact domain match required); relaxed is the more commonly used default.
It controls when forensic reports are generated when ruf= is set — options include reporting on any failure, only when both SPF and DKIM fail, or when either fails independently; it has no effect unless ruf= is also configured.
Yes, a minimal valid record only needs v=DMARC1 and p=; all other tags including rua and ruf are optional, though omitting rua means you'll have no report-based visibility.
This generator focuses on building a new record from your chosen values; use the separate DMARC Lookup tool to check what's currently published for a domain before overwriting it.
It becomes active once published as a TXT record at _dmarc.yourdomain.com and DNS propagation completes, typically within minutes to a few hours depending on your DNS provider and TTL settings.
Receiving mail servers will generally treat a malformed record the same as having no DMARC record at all, meaning you lose DMARC's protection entirely rather than getting a partial or degraded version of it.
Yes, completely free with no signup, no usage limits for normal use, and results generated instantly in your browser.
Yes, it checks for basic valid email format before including them in the generated record, and flags clearly invalid entries so you can correct them before copying the record.