Configure Your DMARC Record
No enforcement — monitoring starting point
Override the policy applied to subdomains independently of the main domain.
Receives daily XML aggregate reports from Gmail, Outlook, and other receivers.
Receives per-failure forensic reports. Less widely supported than rua=.
Relaxed: DKIM d= subdomains of From: domain are accepted.
Relaxed: envelope From subdomains of the From: domain are accepted.
100% — policy applies to all failing messages (recommended for full enforcement).
Controls when forensic reports (ruf=) are generated. Only applies if ruf= is set.
Generated DMARC Record
WeakScore: 35/100
v=DMARC1; p=none
Publish as DNS TXT record at
_dmarc.yourdomain.com
→ p=none provides monitoring only — no enforcement. Plan to upgrade to quarantine then reject.
→ Add an rua= address to receive daily aggregate XML reports — required to safely enforce quarantine or reject.
What this tool does
Free DMARC record generator — build and publish your DMARC policy
A DMARC record (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record published at _dmarc.yourdomain.com that instructs receiving mail servers how to handle email that fails SPF or DKIM authentication. This generator builds a syntactically correct DMARC record based on your configuration choices — no DNS knowledge required — and scores the result so you know exactly how strong your protection is and what to improve.
DMARC deployment is a phased process. Most organizations start with p=none (monitoring only) combined with an rua= address to collect aggregate reports. After 2–4 weeks of report analysis, they confirm all legitimate email is passing authentication, then move to p=quarantine (routing failures to spam) and eventually p=reject (blocking failures outright). The pct= tag lets you increase enforcement gradually — for example, start at pct=10 and increase by 10–25% each week until you reach 100%.
Getting DMARC to p=reject and pct=100 is one of the most impactful email security steps you can take. It prevents attackers from sending phishing emails that appear to come from your domain, protects your brand reputation, and is now required by major providers like Google and Yahoo for bulk senders. This tool generates the correct syntax every time so you can focus on the deployment process rather than record formatting.
What each option configures
p= policy
Core enforcement: none (monitor), quarantine (spam), or reject (block)
sp= subdomain
Override the policy for subdomains independently of the main domain
rua= aggregate
Daily XML reports showing authentication pass/fail rates from receivers
ruf= forensic
Per-failure reports for individual messages that fail DMARC
adkim= alignment
How strictly the DKIM signing domain must match your From: header
aspf= alignment
How strictly the SPF envelope sender must match your From: header
pct= rollout
What percentage of failing messages the policy applies to (1–100)
fo= reporting
Conditions under which forensic (ruf=) reports are generated
How to publish your DMARC record
1
Configure — Use the form above. Start with p=none and add a rua= address as a minimum.
2
Copy the record — Click Copy Record to copy the generated DMARC syntax to your clipboard.
3
Log into DNS — Open your DNS provider's control panel (Cloudflare, Route 53, GoDaddy, Namecheap, etc.).
4
Create TXT record — Add a new TXT record. Set the hostname to _dmarc and paste the record as the value.
5
Verify — Use our DMARC Checker tool to confirm the record is live and parsing correctly after a few minutes.
6
Review reports — After 1–2 weeks, check your rua= inbox for aggregate reports. Identify all sending sources.
7
Enforce — Upgrade: p=none → p=quarantine (pct=10) -> gradually increase pct -> p=reject pct=100.
Examples
What DMARC records look like — common configurations explained
These examples cover the most common DMARC configurations and explain the strength score each would receive.
ExcellentFull enforcement — production-ready
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com
Maximum protection. p=reject blocks all unauthenticated email. pct=100 applies the policy to 100% of failures. rua= ensures daily aggregate reports so you maintain visibility. This is the end-state every domain should aim for.
GoodQuarantine with subdomain override
v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@example.com
p=quarantine routes failing messages to spam. sp=reject applies stricter enforcement to subdomains — useful when subdomains are parked or not used for sending. A solid interim configuration during rollout to full reject.
FairGradual rollout — 25% enforcement
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
pct=25 means only 25% of failing messages are quarantined — the rest are unaffected. This is a typical phased rollout configuration. Increase pct by 25% increments weekly as you confirm legitimate email is passing, until you reach pct=100.
WeakMonitoring only — no enforcement
v=DMARC1; p=none; rua=mailto:dmarc@example.com
p=none provides zero protection — emails are delivered regardless of authentication results. However, rua= is correctly configured, so you will receive aggregate reports. This is the recommended starting point before enforcing quarantine or reject.
WeakMissing rua= — blind enforcement
v=DMARC1; p=reject
p=reject is set but there is no rua= address. Without reports, you have no visibility into authentication failures and cannot tell whether legitimate email is being blocked. Always add at least one rua= address before enforcing a reject policy.
FAQ
Frequently asked questions about DMARC record generation
What is a DMARC record generator?
A DMARC record generator is a tool that builds a properly formatted DMARC TXT record based on your chosen settings — ready to copy and paste into your DNS management panel. Instead of writing the record syntax by hand (and risking errors), you configure the options visually and the generator produces a valid, publish-ready string like: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com
Where do I publish my generated DMARC record?
Log into your DNS provider's control panel (Cloudflare, Route 53, GoDaddy, Namecheap, etc.) and add a new TXT record. Set the hostname to _dmarc (your DNS provider will automatically append your domain), and paste the generated DMARC value as the record content. Set the TTL to 300 seconds initially so you can iterate quickly if changes are needed. After publishing, use the DMARC Checker tool on this site to verify the record is live and correctly configured.
Which DMARC policy should I start with?
Start with p=none combined with an rua= address. This monitoring mode delivers emails normally but sends daily aggregate reports showing who is sending email on behalf of your domain. After 2–4 weeks, review the reports, fix any authentication gaps with SPF and DKIM, then move to p=quarantine (failures go to spam), and finally p=reject (failures are blocked). Skipping straight to p=reject without monitoring risks blocking legitimate email.
What email address should I use for rua=?
Use a dedicated mailbox like dmarc@yourdomain.com that you check regularly, or a third-party DMARC reporting service (EasyDMARC, Postmark, Valimail, etc.) that parses the XML reports into readable dashboards. Major providers like Gmail and Outlook send reports daily. If you publish DMARC for a third-party domain, the third-party must publish a DNS record authorizing your rua= address to receive reports for that domain.
What is the difference between rua= and ruf= in DMARC?
rua= (aggregate reports) receives daily XML summary files from receivers listing all mail they saw from your domain and whether it passed or failed authentication. ruf= (forensic reports) receives individual failure reports for each message that fails DMARC — these can include message headers and sometimes full content. ruf= is less widely supported by receivers and raises privacy considerations, so rua= is the more important of the two. Many organizations only configure rua=.
What does pct= do in a DMARC record?
The pct= tag controls what percentage of non-authenticating messages the policy is applied to. For example, pct=10 means only 10% of failing messages are quarantined or rejected; the remaining 90% are treated as if p=none. This allows a gradual, risk-managed rollout — you increase pct as you gain confidence that legitimate email is authenticating correctly. Once fully deployed, set pct=100 for complete enforcement.
What is DKIM alignment (adkim=) in DMARC?
DKIM alignment determines how strictly the domain in the DKIM d= tag must match the From: header domain for DMARC to pass. Relaxed alignment (adkim=r, the default) allows subdomain matches -- a DKIM signature from mail.example.com satisfies DMARC for example.com. Strict alignment (adkim=s) requires an exact match between the DKIM d= domain and the From: domain. Relaxed is appropriate for most senders. Use strict only if you are certain all your signing configurations use the exact root domain.
What is SPF alignment (aspf=) in DMARC?
SPF alignment determines how strictly the envelope From (Return-Path) domain must match the From: header domain for DMARC to pass. Relaxed alignment (aspf=r, the default) allows subdomain matches -- a Return-Path of bounce.example.com satisfies DMARC for example.com. Strict alignment (aspf=s) requires an exact match. Most email service providers use a shared Return-Path domain for bounce handling, so relaxed SPF alignment is the correct setting for nearly all senders using a third-party ESP.
Should subdomains have their own DMARC records?
Subdomains inherit the parent domain's DMARC policy by default. You can override this with the sp= tag (for example, sp=reject on the parent domain ensures subdomains are also fully protected even if p= is still set to none for monitoring). Alternatively, publish a separate _dmarc.subdomain.com record to set a completely independent policy for that subdomain. High-risk subdomains like mail.yourdomain.com or store.yourdomain.com should have explicit protection.
How do I test my DMARC record after publishing?
After publishing your record, use our DMARC Checker tool to verify it was created correctly and is resolving as expected. The checker performs a live DNS lookup at _dmarc.yourdomain.com and validates each tag — the same way receiving mail servers read it. Allow a few minutes for DNS propagation before testing. You can also verify manually with the command: dig TXT _dmarc.yourdomain.com
Do I need DMARC even if my domain does not send email?
Yes. Non-sending domains are a prime target for phishing because they often lack authentication records. Attackers use them to send convincing spoofed emails that appear to come from your brand. Publish p=reject along with an SPF record of 'v=spf1 -all' (explicitly blocking all senders) to prevent your domain from being exploited. This takes 5 minutes and significantly reduces your phishing exposure.
Related Email Authentication Tools
Need a disposable address right now?Generate a free, instant throwaway email — zero signup, zero trace.
Get Free Temp Mail