How this DMARC builder works
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989, formerly RFC 7489) is the TXT record published at _dmarc.<domain> that tells receiving mail servers what to do with messages claiming to be from you when SPF or DKIM fails to align with the From header. The builder below lets you assemble that record one tag at a time, picking a policy strength, alignment mode, reporting addresses, and subdomain handling, while showing the resulting TXT value live.
Start with one of the presets below if you don't know where to begin: Monitoring (p=none) is the safe entry point that collects aggregate reports without affecting delivery; Quarantine sends suspicious mail to Junk; Reject blocks it at the gateway and is the only setting that stops direct-domain spoofing. The builder enforces the syntax rules from RFC 9989 (DMARCbis) (valid tag combinations, percentage ranges, comma-separated rua URIs, alignment modes) so you can't publish a record that fails parsing at the receiver. If you already have a record, paste it into the field at the top and the builder pre-fills every tag so you can edit rather than rebuild.
Once published, verify the record live with the DMARC record checker. For a tag-by-tag breakdown with valid values, defaults, and the RFC citations behind each one, see our DMARC tags reference. For an overview of what changed in DMARCbis (DMARC 2.0), see the DMARCbis overview.
🛡️ DMARC Record Builder
Build a DMARC TXT record step-by-step. Start with p=none to collect reports,
then advance to p=quarantine or p=reject for full enforcement.
Quick start: pick a preset
Start with one of these common configurations, then tweak the form below.
Got an existing record? (Optional)
Enter your domain to fetch your current DMARC record automatically and prefill the form below.
Or paste your current DMARC record here to prefill the options below.
1. Policy (p=)
2. Subdomain Policy (sp=)
By default, subdomains inherit the main domain policy. You can override this or explicitly exclude subdomains from the policy.
sp= means subdomains use the same policy as the main domain. This is the most common and recommended approach. Subdomains automatically get the protection you configure for your root domain.
3. Percentage (pct=)
What percentage of failing emails should the policy apply to? Use 100 for full enforcement.
t=y testing mode tag instead for staged rollouts.4. Aggregate Reports (rua=)
Email address(es) to receive daily aggregate XML reports. Separate multiple addresses with commas.Strongly recommended. Required by Google and Yahoo for bulk senders.
5. Forensic Reports (ruf=, optional)
⚠️ Most providers no longer send forensic reports due to privacy regulations. Leave blank unless your organisation explicitly requires them.6. Alignment
Relaxed (recommended): a subdomain can satisfy DMARC for the parent domain. For example, mail sent from mail.example.com passes for example.com. Pick this unless you know you need otherwise.
Strict: the visible From: domain must exactly match the SPF or DKIM signing domain. Useful if you've cleaned up every sending source and want maximum spoofing protection.
7. Report Interval (ri=, optional)
How often (in seconds) to send aggregate reports. Default is 86400 (24 hours).
8. Failure reporting options (fo=, optional)
Controls when receivers send failure (forensic) reports back to your ruf= address. Most large receivers no longer send forensic reports due to privacy regulations. Set this only if your forensic processor needs it.
9. Testing mode (t=, optional)
New in DMARCbis (RFC 9989). Set t=y while you watch reports during a staged rollout. Receivers treat the record as not fully deployed yet and weight enforcement decisions accordingly. Replaces the old pct= sampling approach.
10. Non-existent subdomain policy (np=, optional)
New in DMARCbis (RFC 9989). Policy for subdomains that don't exist in DNS at all (NXDOMAIN). Setting np=reject blocks spoofing of names like support-recovery.yourbank.com that nothing legitimate ever uses. If np= is absent, receivers fall back to sp= and then p=.
11. Advanced: public suffix flag (psd=, registries only)
New in DMARCbis (RFC 9989), promoted from the experimental RFC 9091. Almost nobody needs this. It identifies your domain as a public suffix (TLD or eTLD like .co.uk) so receivers know to keep walking up the DNS Tree Walk past it. Set psd=y only if you operate a registry. If you're a normal sender, leave this alone.
Generated DMARC Record
Add as a TXT record at _dmarc.yourdomain.com
Tag breakdown
Frequently Asked Questions
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that tells mail servers what to do if an email fails SPF or DKIM checks. It ensures that the authenticated domain matches the visible "From" address you see in your inbox. For bulk senders, DMARC is a mandatory requirement for inbox delivery at Google and Yahoo.
What policy should I start with?
Always start with p=none (monitor mode). This lets you collect reports without affecting email delivery. Stay in monitor mode for 2-4 weeks to confirm all your legitimate email services are correctly authenticated before moving to p=quarantine (send to spam) or p=reject (block entirely).
Do I need to include subdomains?
Usually not. A single DMARC record at _dmarc.yourdomain.com automatically applies to all subdomains. You only need a separate record on a subdomain if you want a different policy for it. You can also use the sp= tag to set a subdomain-specific policy without creating new records.
What are aggregate reports (RUA)?
Aggregate reports are daily files sent by major providers like Gmail and Outlook to your rua= address. They show which servers are sending email as your domain and whether they passed authentication. These reports show you who is spoofing your domain, and flag any legitimate sender that has started failing authentication.
What is DMARC alignment?
Alignment means the domain in your SPF or DKIM result must match the domain in your "From" address. Relaxed alignment (the default) allows subdomains, while strict alignment requires an exact match. Relaxed alignment is recommended for most users as it's more forgiving and prevents accidental blocks.