DMARC Generator & Checker
Build a valid DMARC record interactively, or check the published policy for any domain.
DMARC Record Check
What does DMARC do?
DMARC tells receivers what to do when SPF or DKIM fails for your domain, and demands that the signing domain align with the visible From: address.
Published as a TXT record at _dmarc.{domain}.
Setting up DMARC for the first time? Read our Email Deliverability Guide 2026 for the full ramp-up plan.
Popular Domains
About DMARC Generator & Checker
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer of email authentication. SPF says who's allowed to send for your domain; DKIM proves a message wasn't modified; DMARC ties them together by telling receivers what to do when either check fails, and by demanding alignment between the SPF/DKIM signing domain and the visible From: address. The DMARC Generator builds a syntactically-valid record interactively — choose policy (none / quarantine / reject), set the percentage applied (pct=) for gradual ramps, configure aggregate (rua=) and forensic (ruf=) report destinations, choose alignment modes (adkim / aspf — relaxed or strict), and set the subdomain policy (sp=). The Checker side fetches the existing record at _dmarc.{domain}, parses each tag, validates RFC 7489 compliance, and reports email-format issues in the rua and ruf URIs.
Why use a DMARC Generator & Checker?
DMARC syntax is unforgiving. A single misplaced semicolon, an unquoted email address, or a forgotten mailto: prefix in the rua URI causes receivers to silently ignore the entire record — and you only find out weeks later when your aggregate reports never arrive. The Generator eliminates these mistakes by validating every input field, escaping special characters automatically, and producing a record that conforms to RFC 7489 exactly. The Generator is especially valuable during the policy migration that every domain must go through: p=none for 4-8 weeks, then p=quarantine pct=10 ramping to 100, then finally p=reject. Google's and Yahoo's February 2024 bulk-sender requirements mandate DMARC at p=none minimum for senders above 5,000 emails per day, with a valid rua=mailto: address pointing to a mailbox you actually monitor.
Who is it for?
Email administrators rolling out DMARC for the first time. DevOps engineers tightening policy from p=none to p=quarantine to p=reject. Security analysts investigating phishing and configuring forensic reports to capture attack samples. Marketing operations teams auditing whether their ESP's signing domain aligns with the From: domain. Compliance officers documenting DMARC posture for SOC 2 audits. Domain administrators handling sender-side requirements after Google's and Yahoo's 2024 mandates. ESP customer success teams generating customer-specific DMARC records during onboarding. Phishing investigators reading suspicious domains' DMARC posture to understand attack feasibility. Anyone migrating mail providers and needing to verify the new setup before tightening DMARC policy.
How to use the tool
Pick the Checker tab to inspect an existing DMARC record, or the Generator tab to build one
For Checker: enter the domain, click 'Check' — the tool queries _dmarc.{domain} and parses every tag
Review issues by severity (error / warning / info). Errors break parsing; warnings flag risky config; info clarifies semantics
For Generator: pick policy (p=none for monitoring, quarantine for soft enforcement, reject for full enforcement)
Enter the rua= mailbox (where aggregate reports are sent). Optionally enter a ruf= mailbox for forensic reports
Configure alignment modes — relaxed (r) is more compatible, strict (s) is more secure
Use the pct= slider during ramp-up to apply the policy to a fraction of failing mail
Copy the generated record and publish it as a TXT record at _dmarc.{domain} in your DNS provider
Key Features
Interactive generator
Every DMARC tag with an inline explanation: what it does, what values are valid, what the common pitfalls are. No more guessing.
Live preview
The resulting DMARC record updates as you build — copy-paste-ready for any DNS provider with one click.
Policy migration guide
Step-by-step ramp from p=none → p=quarantine pct=10/25/50/100 → p=reject. Avoids the classic mistake of jumping from none straight to reject and blackholing legitimate mail.
Aggregate report email validation
Validates rua= and ruf= addresses are well-formed, include the mailto: prefix, and are RFC-compliant — the #1 cause of 'why aren't my DMARC reports arriving'.
Bulk-sender compliance check
Flags whether the record meets the Google / Yahoo bulk-sender mandates that took effect in February 2024 and remain in force: v=DMARC1, p=, valid rua=mailto:.
Checker side
Fetches the live _dmarc record, parses every tag, surfaces missing required tags, invalid values, and alignment-mode warnings.
Common Use Cases
First-time DMARC setup
Scenario: You're rolling out DMARC for the first time and want to start safely with monitoring-only policy.
✓ Generator produces a safe p=none record with a valid rua= mailbox. Publish it, wait 4-8 weeks, then come back to tighten.
Policy tightening (ramp)
Scenario: You've been at p=none for 6 weeks; aggregate reports show all legitimate senders are aligned. Time to move to quarantine.
✓ Generator's pct= slider lets you ramp 10 → 25 → 50 → 100 over a few weeks before flipping to reject. Visualizes the migration so you don't skip a step.
Google / Yahoo 2024 compliance
Scenario: You're a bulk sender (5,000+/day to Gmail/Yahoo) and need to meet the February 2024 requirements.
✓ Generator's compliance check confirms the minimum tags are in place. One DNS publish and you're compliant.
Phishing posture audit
Scenario: You want to know if attackers can easily spoof your domain or a vendor's domain in phishing emails.
✓ Checker reveals the current policy — p=none means anyone can spoof without consequence; p=quarantine/reject means receivers will catch most attempts.
Subdomain policy split
Scenario: Your main domain needs lenient policy (corporate mail variety) but subdomains never legitimately send mail.
✓ Generator supports sp= configuration. Common pattern: p=quarantine; sp=reject. Lock down unused subdomains where phishing attacks typically target.
Validation follows RFC 7489 exactly. Matches what receiving mail servers (Gmail, Outlook, Yahoo) will compute when they evaluate your record.
The DNS lookup runs server-side through our edge proxy. The domain is queried but not stored. The Generator runs entirely in your browser — nothing leaves the page.
Globally distributed edge infrastructure for low-latency queries.
Frequently Asked Questions
What should p= be set to: none, quarantine, or reject?
Start with p=none for 4-8 weeks. This is monitoring-only — receivers send you daily aggregate reports listing every sender claiming to be from your domain, but don't change delivery. You'll discover legitimate senders you didn't know about (forgotten marketing tools, contractor mail servers, internal applications). Once aggregate reports show all legitimate senders are properly authenticated, move to p=quarantine with pct=10 and gradually ramp the percentage to 100. After 4+ weeks at p=quarantine pct=100 without legitimate mail being quarantined, move to p=reject. This 12-16 week ramp is the safe progression — jumping directly from p=none to p=reject can blackhole legitimate mail from forgotten senders.
Do Google and Yahoo require DMARC in 2026?
Yes, for bulk senders. Since February 2024, both Google and Yahoo require any sender of 5,000+ emails per day to a Gmail/Yahoo address to publish a valid DMARC record at minimum p=none, with a valid rua aggregate-report address. Senders below 5,000/day are encouraged but not strictly required. Failure to meet these requirements results in immediate spam-folder delivery or outright rejection. The minimum compliant record is: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — and the rua mailbox must be on a domain you control.
What is the difference between rua and ruf?
rua= specifies where receivers send daily aggregate reports — XML files summarizing all DMARC checks on your domain over a 24-hour window (typical receivers include Google, Microsoft, Yahoo, Comcast). These reports are the operational core of DMARC monitoring. ruf= specifies where to send per-message forensic reports — full headers of individual failed messages, sent immediately. Forensic reports are useful for active phishing investigation but rarely supported by major receivers due to privacy and volume concerns. For most setups, configure rua and skip ruf.
What is alignment in DMARC (adkim and aspf)?
Alignment is what makes DMARC stronger than SPF and DKIM alone. SPF and DKIM each pass against their respective signing domain, but DMARC requires those signing domains to align with the visible From: address. adkim= controls DKIM alignment (s for strict — exact match required, r for relaxed — subdomain match allowed). aspf= controls SPF alignment similarly. Most production setups use adkim=r and aspf=r for compatibility with subdomain senders. Strict alignment (s) closes some attack vectors but breaks legitimate setups where mail is signed by mailgun.example.com but the From: is example.com.
Do I need DMARC if I have SPF and DKIM?
Yes. SPF and DKIM authenticate sources independently, but neither requires the authenticated source to match the visible From: address. Without DMARC, an attacker can pass SPF and DKIM for their own domain while displaying a different From: domain — the user reads 'from your-bank.com' but the message was actually signed by attacker.net. DMARC requires alignment (the signing domain must match the From: domain) and tells receivers what to do when it fails. SPF + DKIM without DMARC is partial protection; SPF + DKIM + DMARC at p=reject is full protection.
How long should I keep DMARC at p=none?
Minimum 4 weeks, typically 4-8 weeks. The goal of p=none is to characterize all senders using your domain through aggregate report analysis. You need enough time to capture monthly cycles (marketing campaigns, payroll, billing runs) and discover any forgotten or contractor-managed senders. If you tighten policy too early, you'll blackhole legitimate mail from undiscovered senders. Many large organizations run p=none for 6-12 months before any policy tightening, especially across acquired subsidiaries.
Will my legitimate email get blocked if I set p=reject?
Only if you have unaligned legitimate senders. Before moving to p=reject, you must have verified through aggregate reports that every legitimate source either passes SPF with aligned return-path, or signs DKIM with aligned d= domain. If a marketing tool sends from your.marketing-provider.com without DKIM-aligning to your.com, p=reject will block their mail. The pct= ramp during quarantine phase is your last chance to catch these — start at pct=10, monitor reports, fix any aligned senders, then ramp. Skipping the ramp is how organizations accidentally block their own payroll notifications.
What is pct= and how should I use it?
pct= specifies what percentage of failing messages the policy applies to, allowing gradual rollout. With p=quarantine; pct=10, only 10% of unauthenticated messages get quarantined; the other 90% are delivered normally. This lets you detect alignment problems with reduced blast radius. Typical ramp: pct=10 → 25 → 50 → 100, with 1-2 weeks at each step. pct= only applies to quarantine and reject policies — at p=none, pct= has no effect.
How do I read DMARC aggregate reports?
Aggregate reports arrive as ZIP-compressed XML files attached to emails sent to your rua= address. Each XML report covers a 24-hour window from one receiving organization. The structure: record per IP+source-domain combination, showing message count, SPF result, DKIM result, DMARC disposition, and policy applied. Manual XML inspection works for low-volume domains but doesn't scale — most operators use dedicated parsers like dmarcian, valimail, postmark.com/dmarc, or self-hosted tools. The first signal to look for: legitimate-looking sources with failed alignment, which indicate a misconfigured ESP or forgotten sender.
Can I have different DMARC policies for subdomains?
Yes — the sp= tag sets a separate policy for subdomains. The most common pattern is p=quarantine; sp=reject — main domain is quarantine (to give yourself recovery time if something breaks), subdomains are reject (most attacks use never-used subdomains, so subdomain reject is safer). If sp= is omitted, subdomains inherit the main p= policy. Note that sp= only applies to organizational subdomains; you still need a separate DMARC record at _dmarc.subdomain.example.com if you want a different policy for that specific subdomain.
Technical Specifications
Supported Formats
- ✓RFC 7489 DMARC
- ✓All tags: v, p, sp, pct, rua, ruf, adkim, aspf, fo, rf, ri
- ✓Policy values: none, quarantine, reject
- ✓Alignment modes: r (relaxed), s (strict)
- ✓Multi-address rua/ruf with mailto:, https://
- ✓Subdomain policy splits
- ✓RFC 7489 validation rules
Limits & Performance
- •File Size: Single domain per check
- •Validations: Live DNS resolution + RFC validation
- •Response Time: Typically 200-1000ms
- •Browsers: All modern browsers
Pro Tips
- Always include a valid rua=mailto: address. Without it, you have no monitoring data — the entire point of DMARC is the aggregate reports.
- Use adkim=r and aspf=r unless you have a specific reason for strict alignment. Relaxed alignment is more compatible with subdomain senders.
- Start at p=none for 4-8 weeks minimum. Skipping monitoring is the #1 cause of accidentally blocking legitimate mail.
- When moving to p=quarantine, start with pct=10 and ramp slowly. Each step gives you a chance to catch undiscovered senders before they fail.
- If you don't have an in-house DMARC report parser, use a free tier from dmarcian, valimail, or postmark — manual XML inspection doesn't scale past trivial volumes.
- Pair DMARC reject with sp=reject for subdomains. Most attacks use never-used subdomains to bypass main-domain checks.
- Include fo=1 in the DMARC record to receive a forensic report whenever either SPF or DKIM fails (not just when both fail). Helps catch alignment problems early.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.