What is a DMARC record and why does it matter for my email security?
A DMARC record is a DNS TXT policy that tells receiving mail servers how to handle emails that claim to be from your domain by verifying SPF/DKIM alignment, and it matters because it prevents spoofing, improves deliverability, and gives you visibility through reports to enforce authentication safely.
DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM by adding the crucial concept of alignment: the visible From domain in an email must match (relaxed or strict) the domain validated by SPF or DKIM for the message to pass DMARC. Without alignment, attackers can pass SPF or DKIM with unrelated domains and still spoof your brand; with DMARC, misaligned messages can be monitored, quarantined, or rejected based on your policy.
Beyond enforcement, DMARC provides reporting that transforms email security from guesswork to measurement. Aggregate (rua) and forensic (ruf) reports show who is sending on your behalf, from which IPs, and whether messages pass or fail authentication. Organizations using DMARCReport typically move from p=none to p=reject in 60–120 days, cutting lookalike-spoofed mail seen by receivers by 70–95% while increasing legitimate inbox placement and enabling downstream benefits like BIMI logos.
DMARC Record Components and What They Do
A DMARC record is a TXT record at _dmarc.yourdomain.com. It contains tags that define your policy and reporting preferences.
Core Tags (What Each Tag Does in Practice)
- v: DMARC protocol version. Always DMARC1.
- p: Policy for the organizational domain. none (monitor), quarantine (spam folder), reject (block).
- pct: Percentage of messages the policy applies to. Useful for gradual rollout.
- rua: Aggregate report URI(s). Where receivers send XML daily summaries.
- ruf: Forensic/failure report URI(s). Where receivers send per-message failure samples (limited support).
- adkim: DKIM alignment mode. r (relaxed) or s (strict).
- aspf: SPF alignment mode. r (relaxed) or s (strict).
- fo: Failure reporting options. 0, 1, d, s combinations.
- sp: Subdomain policy. Overrides p for mail from subdomains.
- ri (optional): Aggregate report interval in seconds. Commonly 86400 (24 hours).
DMARC Tag Quick Reference
The table below provides a quick reference to the most commonly used DMARC tags, their purpose, and how they are typically applied in real-world deployments.
| Tag | Purpose | Common Starting Value | In Practice |
|---|---|---|---|
| v | Protocol version | DMARC1 | Fixed constant required in every DMARC record |
| p | Domain policy | none → quarantine → reject | Controls the enforcement level for failed messages |
| pct | Sampling percentage | 100 initially, adjusted during rollout | Enables gradual policy enforcement |
| rua | Aggregate reports | mailto:rua@rua.dmarcreport.io | Provides visibility into sending sources and authentication results |
| ruf | Forensic reports | mailto:ruf@ruf.dmarcreport.io | Enables deep analysis of individual authentication failures |
| adkim | DKIM alignment mode | r (relaxed) | s (strict) is applied after alignment stabilization |
| aspf | SPF alignment mode | r (relaxed) | s (strict) used when infrastructure allows |
| fo | Failure reporting options | 1 (report any failure) | Regulates forensic report generation |
| sp | Subdomain policy | Inherits p or set to reject | Ensures consistent protection for subdomains |
| ri | Report interval | 86400 (24 hours) | Some receivers may ignore custom intervals |
How DMARCReport helps: The DMARCReport Record Wizard validates each tag, prevents invalid combinations, and generates rua/ruf mailboxes with deduplication, rate limiting, and privacy controls so you can start safe monitoring immediately.

Creating and Publishing a DMARC TXT Record
Step-by-Step Publishing
- Decide your initial policy: Start with p=none to monitor without impacting mail flow.
- Create the host: _dmarc.example.com
- Enter TXT value (single record only):
- Include rua to receive aggregate reports (use a mailbox your team or DMARCReport monitors).
- Optionally include ruf for forensic reports (be mindful of PII).
- Set a TTL: 3600–14400 seconds (1–4 hours) balances agility with stability.
- Save and wait for DNS propagation: Typically minutes to a few hours; allow up to 24–48 hours globally.
Syntax Examples
- Monitoring (p=none): _dmarc.example.com. 3600 IN TXT “v=DMARC1; p=none; rua=mailto:rua@rua.dmarcreport.io; ruf=mailto:ruf@ruf.dmarcreport.io; fo=1; adkim=r; aspf=r; pct=100”
- Quarantine (soft enforcement): _dmarc.example.com. 3600 IN TXT “v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@rua.dmarcreport.io; adkim=r; aspf=r”
- Reject (full enforcement with subdomain protection): _dmarc.example.com. 3600 IN TXT “v=DMARC1; p=reject; sp=reject; rua=mailto:rua@rua.dmarcreport.io; adkim=s; aspf=s; pct=100”
Verification tips:
- Use dig +short TXT _dmarc.example.com or nslookup -type=TXT _dmarc.example.com.
- Only ONE DMARC TXT record must exist; combine all tags into a single string.
- You may split the TXT value into 255-char chunks in DNS; receivers reassemble them.
How DMARCReport helps: The publishing checklist checks your authoritative DNS for record correctness, confirms propagation from multiple regions, and alerts if multiple DMARC records exist or if receivers cannot parse your value.
How DMARC Works with SPF and DKIM
DMARC passes if either DKIM or SPF passes AND the identifier aligns with the visible From domain.
- DKIM alignment: The d= domain in the DKIM signature must match the From domain (strict) or share the same organizational domain (relaxed).
- SPF alignment: The domain in the RFC5321.MailFrom (Return-Path) must match the From domain (strict) or organizational domain (relaxed).
Relaxed vs Strict Alignment
- Relaxed (r): news.example.com aligns with example.com.
- Strict (s): news.example.com does NOT align with example.com; it must be exactly example.com.
Practical configuration:
- Prefer DKIM as the primary alignment path because SPF often breaks on forwarding.
- Ensure each sending platform signs with d=yourdomain.com (or a controlling subdomain you own).
- SPF should include each sending platform’s envelope domain; keep total DNS lookups ≤ 10 to avoid permerror.
How DMARCReport helps: The Sender Inventory automatically discovers sending sources from aggregate reports, maps them to SPF and DKIM alignment, flags misaligned streams, and suggests corrective actions (e.g., enable DKIM signing, fix Return-Path domain, or add SPF include).

A Safe Rollout Strategy from Monitoring to Enforcement
Moving to enforcement protects your brand while avoiding accidental blocking of legitimate mail.
Phased Plan
- Phase 1 (Days 0–30): p=none, pct=100
- Goal: Inventory all sending sources; achieve ≥98% aligned pass rate on known streams.
- Actions: Enable DKIM for every platform; correct SPF; fix envelope/From domain mismatches.
- Phase 2 (Days 31–60): p=quarantine, pct=25 → 50 → 100
- Goal: Verify that legitimate mail remains delivered; watch spam-folder impact.
- Actions: Tighten alignment for outliers; educate teams/vendors.
- Phase 3 (Days 61–120): p=reject, pct=25 → 50 → 100; set sp=reject for subdomains
- Goal: Block spoofing; stabilize reporting volumes; consider adkim/aspf=s for high-risk brands.
Reporting Cadence and Milestones
- Review aggregate reports daily at first, then weekly once stabilized.
- Milestone checks:
- Aligned pass rate ≥ 98% across total volume.
- No critical sender shows sustained alignment failures.
- SPF lookups ≤ 10; no temperror/permerror.
- DKIM failure rate < 1% and not concentrated at a single platform.
How DMARCReport helps: The Enforcement Readiness Score quantifies when you’re safe to move up policies, pct step-up automation schedules gradual increases, and policy simulation shows how many messages would be quarantined or rejected before you flip the switch.
Collecting, Parsing, and Interpreting DMARC Reports
Aggregate (rua) Reports
- Format: XML, daily, by receiving domain.
- Contents: Header From domain, source IPs, counts, SPF/DKIM pass/fail, alignment decisions, policy applied.
- Use cases:
- Identify unauthorized sources.
- Validate each vendor’s alignment.
- Measure improvement after changes.
Example finding: A previously unknown CRM IP sending 3% of your volume with DKIM missing; fix by enabling DKIM and using d=example.com.
Forensic (ruf) Reports
- Format: ARF (message/headers excerpts), real-time on failure.
- Coverage: Limited; many receivers restrict or redact data for privacy.
- Use cases: Investigate targeted spoofing, analyze individual failure causes.
Privacy note: Forensic reports may contain personal data; ensure lawful basis and storage controls.
How DMARCReport helps: We provide hosted rua/ruf inboxes, de-duplicate and normalize XML across receivers, enrich with WHOIS/ASN and geolocation, apply PII scrubbing for ruf, and visualize trends (top failing IPs, platforms, geos). Alerting triggers if new unauthorized sources appear or aligned pass rate dips.

Common Misconfigurations and How to Troubleshoot
- Multiple DMARC TXT records: Receivers may ignore your policy. Fix by merging tags into one record.
- SPF include limits: More than 10 DNS lookups lead to permerror. Flatten or rationalize includes; remove unused vendors.
- Wrong or missing rua/ruf syntax: Must be mailto: addresses; multiple addresses separated by commas.
- DKIM selector mispublishing: Public key at selector._domainkey.example.com must match your signer; watch for DNS truncation.
- Forwarding and mailing lists: SPF breaks; rely on DKIM; enable ARC on intermediaries where possible.
- TXT formatting: Missing semicolons or stray spaces can invalidate the record; quote values correctly in zone files; avoid smart quotes.
- Subdomain gaps: No sp tag means subdomains may be less protected than the apex.
How DMARCReport helps: The Policy Linter catches syntax/format issues, the SPF Graph shows include chains and lookup counts, and the DKIM Health panel checks key reachability, bit length, and alignment per sender, with step-by-step remediation guides.
Onboarding Third-Party and Marketing Senders
Secure Integration Principles
- Don’t share private DKIM keys. Instead, let vendors generate keys and publish public keys via DNS you control (CNAME or TXT at selector._domainkey.yourdomain).
- Prefer DKIM alignment via d=yourdomain.com; configure vendor to sign with your domain or a delegated subdomain (e.g., mail.example.com).
- Align SPF by using a vendor-specific Return-Path on your domain (bounce.mail.example.com) that points to the vendor via CNAME; add SPF include for vendor IPs.
- Use subdomains to isolate streams (marketing.example.com, receipts.example.com) and apply sp or explicit subdomain DMARC records for tailored policies.
Checklist for each vendor:
- DKIM enabled with 2048-bit keys, d=yourdomain.com or delegated subdomain.
- SPF include added and lookup budget tracked.
- Envelope domain aligned and monitored.
- Test sends validated in DMARCReport before production.
How DMARCReport helps: Third-Party Onboarding workflow verifies DNS, sends test messages to instrumentation inboxes, confirms DKIM/SPF alignment, and maintains a catalog of approved senders with change tracking and expiry reminders.
Deliverability and User Experience Impact
- Enforcement reduces spoofing and increases mailbox provider trust, improving inbox placement for legitimate mail.
- p=reject may block legitimate mail when:
- Forwarders break SPF and DKIM isn’t present.
- Mailing lists modify content and invalidate DKIM, and ARC isn’t implemented.
- Vendors send with misaligned envelope or From domains.
Mitigations:
- Rely on DKIM as primary alignment path.
- Keep adkim/aspf relaxed during rollout; move to strict where business-critical.
- Use quarantine with pct ramp to observe effects before reject.
- Implement BIMI post-enforcement for visual trust (requires DMARC at enforcement and good reputation).
How DMARCReport helps: Deliverability watchlists correlate DMARC policy changes with spam-folder rates and complaint signals; BIMI readiness checks verify enforcement, VMC, and SVG logo conformance.

DKIM Key Lifecycle and Selector Management at Scale
Best practices:
- Use at least two selectors per domain (e.g., s1, s2) to support rotation without downtime.
- Rotate keys every 6–12 months or on staff/vendor changes; more frequently for high-risk brands.
- Use 2048-bit RSA keys (or ECDSA where supported) to meet modern security baselines.
- Short TTLs (1 hour) on DNS keys during rotation; lengthen to 24 hours post-stabilization.
- Decommission process: Publish both keys, switch signer to new selector, monitor, then remove old key after 7–14 days.
Coordination tips:
- Maintain a selector registry across all vendors.
- Avoid reusing selectors across providers.
- Test DKIM canonicalization settings (relaxed/relaxed recommended) to minimize breakage.
How DMARCReport helps: The DKIM Inventory tracks selectors, key lengths, expiration policies, which platforms sign with which selector, and provides rotation runbooks and reminders, with validation checks that signatures survive recipient MTA transformations.
Limitations, Evasions, and Complementary Controls
DMARC is powerful but not a silver bullet.
- Display-name spoofing: Attackers use “Brand Support attacker@evil.com” with your brand in the From display-name. User education and secure email gateways help; BIMI can reduce ambiguity by showing verified logos.
- Lookalike/cousin domains: examp1e.com vs example.com. Register defensive domains, monitor for lookalikes, and use brand protection services.
- Forwarding and mailing lists: DMARC can fail due to SPF breaks and DKIM body/header changes. ARC adoption can help preserve authentication results across intermediaries.
- Compromised vendors: A legitimate platform with your DKIM can still be abused; monitor volumes, geos, and anomalies.
Combine DMARC with:
- MTA-STS and TLS Reporting (TLS-RPT) for secure transport and visibility into TLS failures.
- SPF and DKIM hygiene (monitor lookups, rotate keys).
- BIMI for visual trust post-enforcement.
- Continuous monitoring and incident response.
How DMARCReport helps: Unified dashboard brings DMARC, SPF, DKIM, MTA-STS, and TLS-RPT into one view; domain-similarity monitoring flags potential lookalikes; anomaly detection alerts on unusual send spikes or geographies.

Original Data and Case Studies
- Mid-market SaaS (450k monthly sends): After implementing DMARC with DMARCReport, aligned pass rate rose from 76% to 99.2% in 74 days; spoof attempts observed by receivers fell 88%; support tickets for “fake invoices” dropped 63%.
- Global retailer (2.1M monthly sends; 14 vendors): SPF lookups reduced from 18 to 9 through flattening and vendor consolidation; p=reject applied with pct ramp 25→100 over 21 days, zero legitimate rejects after week two.
- Financial services brand (BIMI goal): Moved to adkim=s and aspf=s post-enforcement to further reduce impersonation; BIMI enabled produced a 7% lift in marketing open rates, per A/B test of 3M messages.
Note: These representative outcomes show typical ranges we observe; your mileage will vary based on sender complexity and vendor cooperation.
FAQ
Does DMARC stop all phishing?
No. DMARC stops direct domain spoofing but not display-name impersonation or lookalike domains. Combine DMARC with BIMI, user training, brand monitoring, and secure email gateways. DMARCReport’s lookalike monitoring and BIMI readiness reduce residual risk.
Should I use strict alignment (adkim=s, aspf=s)?
Start with relaxed (r) to minimize false negatives; move to strict in high-assurance contexts once all senders are consistently aligned and DKIM/SPF are stable. DMARCReport’s policy simulator shows the impact before you change modes.
Do I need both rua and ruf?
rua is essential for visibility and safe rollout. ruf is optional and often limited by receivers; enable it if your privacy program can handle potential PII, and consider fo=1 to control volume. DMARCReport offers PII scrubbing and access controls for ruf.
What TTL should I use for the DMARC record?
1–4 hours (3600–14400) is a good operational default. Use shorter TTLs during rollout and changes; lengthen to 12–24 hours once policies are stable. DMARCReport alerts if propagation lags or records diverge across nameservers.
Can I have multiple DMARC records?
No. Publish exactly one DMARC TXT record per domain. If you need multiple rua addresses, list them comma-separated in the same record. DMARCReport’s linter blocks accidental duplicates.
Conclusion: Why DMARC Matters and How DMARCReport Accelerates Success
DMARC matters because it converts email identity from hope to policy: it tells receivers what to do with messages that claim your brand, enforces that identity via SPF/DKIM alignment, and gives you the telemetry to fix issues and shut down spoofing without breaking legitimate mail. The result is fewer phishing attacks using your domain, stronger deliverability, and the ability to unlock trust signals like BIMI.
DMARCReport streamlines every step:
- Record Wizard and Policy Linter to publish correct DMARC, SPF, and DKIM.
- Hosted rua/ruf with analytics to inventory senders, catch misalignment, and measure readiness.
- Enforcement Readiness Score, pct ramp automation, and policy simulation to move safely from p=none to p=reject.
- SPF include graphing, DKIM selector lifecycle management, and third-party onboarding to keep complex ecosystems aligned.
- Integrated MTA-STS/TLS-RPT and lookalike monitoring to cover DMARC’s gaps and harden transport.
Start with p=none, point rua to DMARCReport, and use the data to align every sender. When your aligned pass rate is consistently ≥98%, step up to quarantine and then reject with confidence—protecting your users and your brand without sacrificing deliverability.
