Suped

DMARC record and policy examples

Michael Ko profile picture

Michael Ko

2 Jul 2025

DMARC record examples overview

This guide provides real-world DMARC record examples for different deployment scenarios. Each example includes the complete DNS record, explanation of each tag, and guidance on when to use that configuration. Whether you're just starting with DMARC monitoring or implementing strict enforcement, these examples will help you choose the right approach for your domain.

What you'll find here

  • • Complete DMARC record examples
  • • Step-by-step deployment strategies
  • • Configuration for different use cases
  • • Common implementation patterns
  • • Best practices and recommendations

Deployment stages covered

  • • Monitoring and assessment
  • • Gradual policy enforcement
  • • Full protection implementation
  • • Advanced configurations
  • • Troubleshooting scenarios
🛠️

Need help building your DMARC record?

Use our interactive DMARC generator tool to create a valid DMARC record step-by-step. The tool walks you through each tag and helps you choose the right values for your domain's security needs.

Monitoring examples (p=none)

Start your DMARC journey with monitoring mode. These examples collect data about your email authentication without affecting email delivery, allowing you to understand your current email ecosystem before implementing enforcement.

Tip: DMARC aggregate reports are complex XML files that can be difficult to interpret manually. Using a DMARC monitoring tool like Suped makes it much easier to understand your authentication results and identify issues.

👁️

Basic monitoring

DNS record

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

What this does

  • Sets DMARC to monitoring mode (no enforcement)
  • Requests daily aggregate reports
  • Allows you to see all email sources and authentication results
  • Perfect for initial deployment and discovery

When to use

Use this configuration when first implementing DMARC. Deploy for at least 1-2 weeks to gather data about your email ecosystem before moving to enforcement policies.

🔍

Monitoring with forensic reports

DNS record

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;

What this does

  • Monitoring mode with both aggregate and forensic reports
  • Requests detailed failure reports for troubleshooting
  • fo=1 generates reports when either SPF or DKIM fails
  • Provides maximum visibility into authentication issues

When to use

Use when you need detailed troubleshooting information or are working with complex email infrastructures. Note that many providers don't send forensic reports due to privacy concerns.

Quarantine examples (p=quarantine)

Quarantine policies mark suspicious emails for special handling, typically moving them to spam folders. These examples show different approaches to implementing quarantine policies safely.

Gradual quarantine rollout

DNS record

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;

What this does

  • Quarantines 10% of emails that fail DMARC authentication
  • 90% of failing emails are still delivered normally
  • Allows testing impact before full enforcement
  • Continues sending aggregate reports for monitoring

Implementation strategy

  1. Start with pct=10 for 1-2 weeks
  2. Monitor reports for any legitimate email impact
  3. Gradually increase: 10% → 25% → 50% → 75% → 100%
  4. Remove pct tag when reaching 100% (default)
🚨

Full quarantine enforcement

DNS record

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

What this does

  • Quarantines 100% of emails that fail DMARC authentication
  • Provides strong protection while allowing email delivery
  • Emails typically go to spam/junk folders
  • Good intermediate step before reject policy

When to use

Use after successful gradual rollout when you're confident in your authentication setup but want to maintain email delivery rather than outright rejection.

Reject examples (p=reject)

Reject policies provide the strongest DMARC protection by instructing receiving servers to reject emails that fail authentication. Use these configurations only when you're confident in your email authentication setup.

🔒

Basic reject policy

DNS record

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

What this does

  • Rejects 100% of emails that fail DMARC authentication
  • Provides maximum protection against email spoofing
  • Failed emails are typically not delivered at all
  • Continues reporting for ongoing monitoring

Prerequisites

  • Successful monitoring phase (p=none) for several weeks
  • Successful gradual quarantine rollout
  • Confidence that all legitimate email sources are authenticated
  • SPF and DKIM properly configured for all sending sources
🛡️

Reject with comprehensive reporting

DNS record

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;

What this does

  • Maximum security with comprehensive failure reporting
  • Rejects all failing emails
  • Provides detailed forensic reports for security analysis
  • Ideal for high-security environments

When to use

Use for mature DMARC implementations where you need both maximum security and detailed monitoring capabilities. Suitable for organizations with dedicated security teams.

Advanced configuration examples

These examples demonstrate advanced DMARC configurations for complex scenarios, including subdomain policies, strict alignment requirements, and specialized reporting configurations.

🎯

Different subdomain policy

DNS record

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com;

What this does

  • Main domain (example.com): reject policy
  • Subdomains (*.example.com): quarantine policy
  • Allows different security postures for different purposes
  • Useful during staged rollouts or for third-party services

Use cases

  • Protecting main domain while testing subdomain configurations
  • Different security requirements for different services
  • Accommodating third-party services on subdomains
  • Gradual migration of subdomain policies
🔐

Strict alignment requirements

DNS record

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com;

What this does

  • Requires exact domain matching for both SPF and DKIM
  • More restrictive than default relaxed alignment
  • Provides higher security but may break some legitimate mail
  • Suitable for high-security environments

Important considerations

Strict alignment can break legitimate email from third-party services that use different domains for DKIM signing or Return-Path. Test thoroughly before implementing in production.

Industry-specific examples

Different industries and use cases may require specific DMARC configurations. These examples show common patterns for various organizational needs.

🏦

Financial services (high security)

DNS record

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@bank.com; ruf=mailto:security@bank.com; fo=1;

Configuration details

  • Maximum enforcement: reject policy for domain and subdomains
  • Strict alignment for both SPF and DKIM
  • Comprehensive reporting for security monitoring
  • Zero tolerance for authentication failures
🛍️

E-commerce (balanced approach)

DNS record

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@store.com; pct=100;

Configuration details

  • Quarantine policy for main domain (preserves delivery)
  • Monitoring mode for subdomains (allows flexibility)
  • Balances security with business continuity
  • Suitable for complex email ecosystems
🏢

Small business (simple setup)

DNS record

v=DMARC1; p=quarantine; rua=mailto:admin@smallbiz.com;

Configuration details

  • Simple quarantine policy without complexity
  • Basic reporting to admin email
  • Uses default settings where appropriate
  • Easy to implement and maintain

Troubleshooting examples

These examples show how to configure DMARC records for common troubleshooting scenarios and temporary configurations during problem resolution.

🔧

Temporary monitoring during issues

DNS record

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1;

When to use

  • When legitimate emails are being blocked
  • During authentication infrastructure changes
  • When investigating delivery issues
  • As a temporary rollback from enforcement

What this provides

  • Stops enforcement while maintaining visibility
  • Maximum reporting for troubleshooting
  • Allows detailed analysis of authentication failures
  • Preserves email delivery during investigation
🐛

Maximum debugging configuration

DNS record

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=0:1:d:s; ri=3600;

What this does

  • Monitoring mode with no enforcement
  • All possible forensic reporting options enabled
  • Requests hourly reporting (though rarely honored)
  • Maximum visibility into authentication behavior

Temporary use only

This configuration generates maximum reporting and should only be used temporarily during troubleshooting. The high volume of reports can be overwhelming for normal operations.

DMARC implementation roadmap

Follow this step-by-step roadmap to safely implement DMARC for your domain. Each phase builds on the previous one, ensuring a smooth transition to full email authentication.

Phase 1

Discovery and monitoring

Duration: 2-4 weeks

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Goals

  • Identify all legitimate email sources
  • Understand current authentication status
  • Establish baseline reporting
  • Fix any SPF/DKIM issues discovered
Phase 2

Gradual enforcement

Duration: 4-6 weeks

Week 1-2:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;
Week 3-4:
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com;
Week 5-6:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

Goals

  • Gradually increase enforcement percentage
  • Monitor for any impact on legitimate email
  • Verify no business disruption
  • Achieve full quarantine policy
Phase 3

Full enforcement

Duration: 2-4 weeks

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

Goals

  • Achieve maximum domain protection
  • Block all spoofing attempts
  • Maintain ongoing monitoring
  • Document final configuration

Start improving your email deliverability today

Get started