DMARC Record Generator
Configure your DMARC policy, reporting addresses, and alignment settings to create a properly formatted DMARC TXT record for your domain.
Generated DMARC Record
Publish this as a TXT record at _dmarc.yourdomain.com in your DNS provider.
You have p=none (monitor only) without any reporting addresses. Without rua reports, monitoring mode provides no value. Add at least one aggregate report email.
Domain
Enter your domain name to preview the DNS record name.
Policy (p=)
What should receiving servers do with emails that fail DMARC?
Subdomain Policy (sp=)
Override the policy for subdomains. If set to "Same as domain policy," the sp= tag is omitted.
Aggregate Report Emails (rua=)
Email addresses to receive daily aggregate DMARC reports. The mailto: prefix is added automatically.
Forensic Report Emails (ruf=)
Optional. Email addresses to receive individual failure reports. Not supported by all receivers. May contain PII.
DKIM Alignment (adkim=)
How strictly must the DKIM signing domain match the From header domain?
SPF Alignment (aspf=)
How strictly must the SPF-authenticated domain match the From header domain?
Percentage (pct=)
Apply the DMARC policy to this percentage of messages. Use values below 100 for gradual rollout.
Failure Reporting Options (fo=)
When should forensic failure reports be generated? Only relevant if you have ruf addresses configured.
Report Interval (ri=)
How often should aggregate reports be sent? Most receivers send daily regardless of this setting.
Understanding DMARC Policies
DMARC policies tell receiving mail servers what to do when an email claiming to come from your domain fails both SPF and DKIM authentication. The three policy levels represent increasing enforcement:
p=none
Monitor Only
No action taken on failing emails. Reports are collected so you can see who is sending as your domain. This is the starting point for any DMARC deployment.
p=quarantine
Send to Spam
Failing emails are delivered to the spam/junk folder instead of the inbox. This is the intermediate enforcement level during rollout.
p=reject
Block Entirely
Failing emails are rejected outright and never delivered. This is the strongest protection against spoofing and phishing using your domain.
DMARC Rollout Strategy
Moving directly to p=reject without monitoring will break legitimate email. Follow this phased approach to deploy DMARC safely:
- 1
p=none (Monitor)
Publish
p=nonewith a reporting address. Collect aggregate reports for 2–4 weeks. Identify all legitimate sending sources and ensure they pass SPF and DKIM. - 2
p=quarantine; pct=25
Quarantine 25% of failing messages. Monitor reports for false positives. If legitimate emails are being quarantined, fix their authentication before proceeding.
- 3
p=quarantine; pct=100
Quarantine all failing messages. Continue monitoring for 1–2 weeks to confirm no legitimate mail is impacted.
- 4
p=reject; pct=25
Begin rejecting 25% of failing messages outright. This is a significant step — rejected emails are not delivered at all.
- 5
p=reject; pct=100
Full enforcement. All emails that fail DMARC are rejected. Your domain is now fully protected against spoofing.
DMARC Reporting Explained
Aggregate Reports (rua)
Daily XML reports sent to your specified email address. They summarize authentication results for all emails sent using your domain, grouped by sending source.
- Volume of emails per sending IP
- SPF and DKIM pass/fail rates
- Policy applied to failing messages
- Sending organization identifiers
Forensic Reports (ruf)
Individual failure reports with message-level detail. Sent in near real-time when a specific email fails DMARC. Useful for debugging but may contain PII.
- Full message headers
- Specific authentication failure details
- Sending and receiving server information
- Not widely supported by all receivers
Note: Many large providers (Gmail, Yahoo) do not send forensic reports due to privacy concerns.
Alignment Modes
DMARC alignment determines how strictly the domain in the From header must match the domains used for SPF and DKIM authentication. You can configure alignment independently for each protocol.
Relaxed Alignment (default)
The organizational domains must match, but subdomains are allowed. For example, if the From header is user@mail.example.com, an SPF or DKIM domain of example.com will pass.
Recommended for most organizations, especially those using third-party sending services.
Strict Alignment
The domains must match exactly. If the From header is user@mail.example.com, only mail.example.com will pass — example.com alone will fail.
Use strict alignment only when you have full control over all sending infrastructure and want maximum protection.
Frequently Asked Questions
What is a DMARC record?▼
What DMARC policy should I start with?▼
What is the difference between rua and ruf in DMARC?▼
What is DMARC alignment?▼
How long does it take for a DMARC record to take effect?▼
Related Tools
DMARC Record Lookup
Check if your domain has a valid DMARC record and see the current policy settings.
Use tool →SPF Record Generator
Generate a properly formatted SPF TXT record with authorized senders and failure policy.
Use tool →DKIM Record Generator
Create a DKIM TXT record with your public key, selector, and signing configuration.
Use tool →Related Reading
SPF, DKIM & DMARC Setup Guide
Step-by-step DNS authentication setup for outbound email teams. Learn how SPF, DKIM, and DMARC work together to protect your domain and improve deliverability.
Need continuous DMARC monitoring?
This free tool generates your DMARC record on demand. Superkabe monitors SPF, DKIM, and DMARC across all your sending domains automatically — every 24 hours — and alerts you before misconfigurations cause deliverability failures.
Start free trial