Updated on June 16, 2026: We reviewed these examples against RFC 9989, RFC 9990, and RFC 9991 and adjusted the rollout records for current DMARCbis tag behavior.
DMARC record examples overview
These real-world DMARC record examples cover 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
|
|
|
|---|---|---|
p=none | Monitoring | No enforcement |
p=quarantine | Spam handling | Test first |
p=reject | Blocking | Needs readiness |
sp=reject | Existing subdomains | Check senders |
t=y | Test mode | One-level-lower policy |
Compact reference for the examples below.
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.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
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.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Basic monitoring
DNS record
DNS recorddns
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 failure reports
DNS record
DNS recorddns
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 failure 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 failure reports because of 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.
Policy enforcement stages
DMARC policy strength increases as authentication confidence improves.
Monitor
p=none
Collect reports without changing delivery.
Quarantine
p=quarantine
Send failing mail to spam or junk handling.
Reject
p=reject
Block failing mail at receiving systems.
Quarantine test mode
DNS record
DNS recorddns
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com;
What this does
- Declares a quarantine policy while test mode applies one level below it
- Failing mail is handled as p=none while t=y is active
- Allows impact testing before normal quarantine enforcement
- Continues sending aggregate reports for monitoring
Implementation strategy
- Start with t=y for 1-2 weeks
- Monitor reports for any legitimate email impact
- Fix sources that fail aligned SPF or DKIM
- Remove t or set t=n when ready for normal quarantine enforcement
Full quarantine enforcement
DNS record
DNS recorddns
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 test mode and monitoring 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
DNS recorddns
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
DNS recorddns
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 failure 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 existing subdomain policies, strict alignment requirements, and specialized reporting configurations. Under RFC 9989, DMARC policy discovery uses DNS Tree Walk, and active policy tags include sp, np, psd, and t for subdomain, non-existent domain, public suffix, and test mode behavior.
Flowchart showing how root policy, subdomain policy, SPF, and DKIM alignment lead to the final DMARC action.
Different subdomain policy
DNS record
DNS recorddns
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com;
What this does
- Main domain (example.com): reject policy
- Existing 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 existing subdomain configurations
- Different security requirements for existing subdomain services
- Accommodating third-party services on subdomains
- Gradual migration of subdomain policies
Strict alignment requirements
DNS record
DNS recorddns
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 can 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 can require specific DMARC configurations. These examples show common patterns for various organizational needs.
Financial services (high security)
DNS record
DNS recorddns
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
DNS recorddns
v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@store.com;
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
DNS recorddns
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
DNS recorddns
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
DNS recorddns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1:d:s;
What this does
- Monitoring mode with no enforcement
- All possible failure reporting options enabled
- Uses current failure reporting options without the removed ri tag
- 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.
Discovery and monitoring
Duration: 2-4 weeks
Phase 1 recorddns
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
Tested quarantine enforcement
Duration: 4-6 weeks
Week 1-2dns
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com;
Week 3-4dns
v=DMARC1; p=quarantine; t=n; rua=mailto:dmarc-reports@example.com;
Week 5-6dns
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;
Goals
- Move from test mode to normal quarantine enforcement
- Monitor for any impact on legitimate email
- Verify no business disruption
- Achieve full quarantine policy
Full enforcement
Duration: 2-4 weeks
Phase 3 recorddns
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
Conclusion
The safest DMARC rollout starts with p=none, moves through a measured quarantine phase with pct, and reaches p=reject only after every legitimate sender passes SPF or DKIM with alignment. The examples above give you working records for each stage, plus temporary troubleshooting records when delivery problems need investigation.
Suped's product is built around that workflow: DMARC monitoring, automated issue detection, hosted DMARC, hosted SPF, SPF flattening, real-time alerts, and blocklist monitoring in one place. That matters most when a domain has multiple senders, subdomains, and policy stages that need clear operational control.
