DMARC record and policy examples

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.

Try DMARC generator tool

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

Start with pct=10 for 1-2 weeks
Monitor reports for any legitimate email impact
Gradually increase: 10% → 25% → 50% → 75% → 100%
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