DMARC Record Generator
Build a valid DMARC record for your domain. Choose your policy, add reporting addresses, configure alignment, and copy the record to your DNS.
What to do with messages that fail DMARC
Policy for subdomains (defaults to main policy if omitted)
Where to receive daily DMARC aggregate reports. Separate multiple with commas.
Where to receive failure reports. Not all providers send these.
Percentage of messages to apply the policy to. Use less than 100% for gradual rollout.
Add this as a TXT record at _dmarc.yourdomain.com
v=DMARC1; p=noneSee your DMARC data in action
Once deployed, use our DMARC Checker to validate your record. The ShieldMarc dashboard parses your aggregate reports automatically, showing you exactly who is sending email as your domain.
Start monitoring freeWhat is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails authentication checks, and provides a reporting mechanism so domain owners can see who is sending email as their domain.
DMARC Rollout Strategy
Do not go straight to p=reject. The recommended approach is a three-stage rollout that gives you visibility before you enforce:
- Start with p=none and an
rua=reporting address. This lets you see all sources sending as your domain in aggregate reports — no mail is blocked. - Review reports for 2-4 weeks to identify legitimate services that need SPF or DKIM alignment. Use our DMARC Report Viewer to read the XML files, or join the early access list for continuous monitoring.
- Move to p=quarantine once all legitimate sources are aligned in your reports. Advance when the report data says it is safe, not on a fixed calendar.
- Advance to p=reject once quarantine reports are clean and no unresolved unauthorised senders remain. This is full enforcement and spoofed mail is blocked at the receiving server.
Why Aggregate Reports Matter
The rua= tag tells receivers where to send daily XML reports showing every source that sent email using your domain. Without this data, you are flying blind. You will not know which legitimate services need SPF/DKIM alignment before you can safely move to enforcement. The reports arrive as compressed XML attachments — use our DMARC Report Viewer to read them, or use ShieldMarc to have them parsed automatically.
Frequently Asked Questions
What alignment mode should I choose?
Relaxed alignment (aspf=r, adkim=r) is the correct default for most organisations. It allows SPF to pass when the Return-Path subdomain matches the From domain (e.g. mail.example.com matching example.com), and allows DKIM to pass when the signing domain is a subdomain of the From domain. Strict alignment requires an exact domain match and can break legitimate mail from sending services that use subdomains.
Do I need a ruf= forensic report address?
Forensic reports (ruf=) contain message content and metadata, which raises GDPR concerns. Most large providers (Google, Microsoft) no longer send them. The aggregate report address (rua=) is what matters — it gives you pass/fail statistics per source without including message content.
What does pct= do?
The pct= tag applies your policy to a percentage of failing mail. It was originally intended as a gradual rollout mechanism, but we do not recommend ramping pct as a rollout strategy. It hides real sender problems behind a probability and makes aggregate reports harder to interpret. A better approach is to read the parsed reports, authorise each legitimate source, and advance the policy when the data is clean. Leave pct at 100 (the default).
Can I use a third-party address for rua= reporting?
Yes, but the third-party domain must publish a DNS record granting your domain permission to send reports there. This is an RFC requirement to prevent report flooding. ShieldMarc provides a dedicated reporting address on all paid plans that handles this automatically.
Does DMARC protect subdomains automatically?
Not by default. The sp= tag controls the policy for subdomains. If omitted, subdomains inherit the parent p= policy. It is good practice to set sp=reject on parked or non-sending subdomains to prevent them from being used for spoofing.