DMARC Record Generator - Complete Guide

Create powerful DMARC policies with the world's most intuitive DMARC generator - Protect your domain from spoofing and phishing

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol defined in RFC 7489. It builds upon SPF and DKIM to provide domain owners with the ability to protect their domain from unauthorized use, commonly known as email spoofing.

DMARC allows you to:

  • Tell receiving servers what to do with messages that fail authentication
  • Request reports about messages claiming to be from your domain
  • Gradually implement email authentication without breaking legitimate email flows
  • Protect your brand reputation and prevent phishing attacks

Example DMARC Record:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100; adkim=s; aspf=s

How DMARC Works

DMARC combines SPF and DKIM authentication with a policy layer. Built by DigiCert, our generator simplifies this complex process:

  1. Authentication Check: Receiving server checks SPF and DKIM
  2. Alignment Verification: Ensures the authenticated domain aligns with the From: domain
  3. Policy Application: If authentication fails, apply the DMARC policy (none, quarantine, or reject)
  4. Report Generation: Send aggregate and/or forensic reports to specified addresses

DMARC Pass Conditions:

A message passes DMARC if EITHER:

  • SPF passes AND SPF domain aligns with From: domain
  • DKIM passes AND DKIM domain aligns with From: domain

DMARC Tags Explained

DMARC records use tags to define policies and reporting preferences. Here's what each tag means:

v=DMARC1

Required. Version tag, must be first and exactly "DMARC1".

p=none|quarantine|reject

Required. Policy for messages that fail DMARC:

  • none: Monitor only, take no action
  • quarantine: Mark as spam/suspicious
  • reject: Block the message entirely

rua=mailto:address@example.com

Recommended. Where to send aggregate reports (daily summaries). Multiple addresses separated by commas. Essential for monitoring.

ruf=mailto:address@example.com

Optional. Where to send forensic reports (individual failures). Note: Many providers don't send these due to privacy concerns.

pct=0-100

Optional. Percentage of messages to apply policy to. Default is 100. Useful for gradual rollout.

adkim=r|s

Optional. DKIM alignment mode:

  • r (relaxed): Organizational domain match (default)
  • s (strict): Exact domain match required

aspf=r|s

Optional. SPF alignment mode:

  • r (relaxed): Organizational domain match (default)
  • s (strict): Exact domain match required

sp=none|quarantine|reject

Optional. Policy for subdomains. If not specified, inherits from main policy (p=).

fo=0|1|d|s

Optional. Forensic reporting options:

  • 0: Generate report if all auth mechanisms fail (default)
  • 1: Generate report if any mechanism fails
  • d: Generate report if DKIM fails
  • s: Generate report if SPF fails

Policy Levels

Choose your DMARC policy based on your confidence level and email authentication maturity:

p=none (Monitor Mode)

Best for initial deployment. No impact on email delivery.

  • Collect data without affecting mail flow
  • Identify all legitimate email sources
  • Understand your email ecosystem
  • Typical duration: 2-4 weeks

p=quarantine

Intermediate step. Suspicious emails go to spam folder.

  • Test impact without losing emails
  • Users can recover from spam if needed
  • Start with low pct= value (e.g., 10%)
  • Gradually increase to 100%

p=reject

Maximum protection. Unauthorized emails are blocked.

  • Strongest anti-spoofing protection
  • Only after thorough testing
  • Ensure all legitimate sources pass
  • Monitor reports continuously

Alignment Modes

DMARC requires the authenticated domain to "align" with the From: domain. This prevents spoofing even if SPF/DKIM pass for a different domain.

Relaxed Alignment (Default)

Organizational domains must match:

  • ✅ From: user@example.com
  • ✅ SPF: mail.example.com
  • Aligned: Both are example.com

Works for: subdomain.example.com, mail.example.com, etc.

Strict Alignment

Exact domain match required:

  • ✅ From: user@example.com
  • ❌ SPF: mail.example.com
  • Not aligned: Domains don't match exactly

More secure but may break legitimate email flows.

Recommendation: Start with relaxed alignment (default) unless you have specific security requirements. Strict alignment can break email from legitimate services.

Deployment Strategy

Follow this proven strategy for successful DMARC deployment:

  1. 1

    Deploy SPF and DKIM

    Ensure SPF is properly configured and DKIM signing is enabled for all email streams. Use our SPF Generator.

  2. 2

    Start with p=none

    Monitor mode with aggregate reporting. Analyze reports for 2-4 weeks to identify all email sources.

  3. 3

    Fix Authentication Issues

    Address any legitimate senders failing authentication. Update SPF, configure DKIM, or adjust alignment.

  4. 4

    Move to p=quarantine

    Start with pct=10 and gradually increase. Monitor user spam folders and reports.

  5. 5

    Deploy p=reject

    After confirming no legitimate email is affected, move to full enforcement for maximum protection.

  6. 6

    Consider BIMI

    With DMARC at enforcement, you can deploy BIMI for brand indicators. Use our BIMI Validator.

DMARC Reporting

DMARC reports provide visibility into your email ecosystem:

Aggregate Reports (RUA)

XML reports sent daily by receiving servers. Contains:

  • Source IP addresses sending email
  • Message counts and authentication results
  • Policy actions taken
  • SPF/DKIM pass/fail rates

Format defined in RFC 7489 Appendix C. Use DMARC report analyzers to process.

Forensic Reports (RUF)

Individual message reports for failures. Contains:

  • Message headers
  • Authentication results
  • Sometimes message body (privacy concerns)

Note: Many providers don't send forensic reports due to privacy regulations.

Pro Tip: Use dedicated DMARC report processing services or create a separate email address for reports to avoid inbox clutter.

Common Mistakes to Avoid

❌ Jumping to p=reject

Moving directly to reject without monitoring will likely break legitimate email.

❌ Not setting up reporting

Without rua= tags, you're flying blind. Always configure aggregate reporting.

❌ Ignoring subdomains

Subdomains need protection too. Consider the sp= tag or individual DMARC records.

❌ Setting and forgetting

DMARC requires ongoing monitoring. New services may need authentication setup.

❌ Too strict alignment

Strict alignment (adkim=s, aspf=s) can break legitimate services using subdomains.

❌ Invalid email addresses

Ensure rua= and ruf= addresses can receive reports. Test before deployment.