DMARC Implementation

Creating Your First DMARC Record

A practical, step-by-step guide to creating and deploying your first DMARC record. Learn what each tag means, how to choose the right policy, and best practices for a successful rollout.

12 min read
Beginner Level

Prerequisites Before You Begin

  • SPF record deployed - DMARC requires SPF for authentication
  • DKIM configured - At least one DKIM selector active
  • DNS access - Ability to add TXT records to your domain
  • Email to receive reports - For aggregate and forensic reports

Understanding DMARC Record Structure

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com that tells email receivers how to handle authentication failures.

Basic DMARC Record Anatomy

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
v=DMARC1- Protocol version (always DMARC1)
p=none- Policy (none, quarantine, or reject) - what receivers should do
rua=- Aggregate report email - where to send daily reports
Important: Tags must be separated by semicolons (;) and spaces. Order doesn't matter except v=DMARC1 must be first.

Step-by-Step Record Creation

Step 1: Start with Monitoring Mode (p=none)

Always begin with p=none to collect data without affecting email delivery. This lets you identify all legitimate senders before enforcement.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Recommended Duration: Monitor for 2-4 weeks minimum before moving to enforcement.

Step 2: Add Report Destinations

Specify where to send aggregate (RUA) and forensic (RUF) reports. You can use multiple addresses separated by commas.

v=DMARC1; p=none;
rua=mailto:dmarc@yourdomain.com,mailto:reports@trustyourinbox.com;
ruf=mailto:forensic@yourdomain.com
rua - Aggregate reports (daily summaries, all providers support)
ruf - Forensic reports (real-time failures, limited provider support)

Step 3: Configure Alignment Mode (Optional)

Control how strictly domains must match for SPF and DKIM authentication.

v=DMARC1; p=none;
rua=mailto:dmarc@yourdomain.com;
aspf=r; adkim=r
aspf=r- SPF alignment (r=relaxed allows subdomains, s=strict requires exact match)
adkim=r- DKIM alignment (r=relaxed allows subdomains, s=strict requires exact match)
Default: If not specified, both default to relaxed (r). Most organizations should use relaxed alignment.

Step 4: Set Percentage for Gradual Rollout

Use the pct tag to apply your policy to only a percentage of emails during enforcement rollout.

v=DMARC1; p=quarantine;
rua=mailto:dmarc@yourdomain.com;
pct=10
pct=10 - Apply policy to 10% of failing emails
pct=100 - Apply to all emails (default if not specified)
Strategy: Start with pct=10, monitor for 1 week, then increase to 25%, 50%, 100% over 4-6 weeks.

Step 5: Add Subdomain Policy (Optional)

Specify a different policy for subdomains using the sp tag.

v=DMARC1; p=reject;
rua=mailto:dmarc@yourdomain.com;
sp=quarantine
Example: Main domain uses p=reject (strict), but subdomains use sp=quarantine (less strict) during transition.

Common DMARC Record Examples

Starter Record (Monitoring Only)

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Use case: First deployment, collecting data to understand email sources.

Gradual Quarantine Rollout

v=DMARC1; p=quarantine; pct=25;
rua=mailto:dmarc@yourdomain.com;
ruf=mailto:forensic@yourdomain.com

Use case: Moving from monitoring to enforcement, applying policy to 25% of failures.

Full Enforcement with Forensics

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

Use case: Mature implementation with full protection and detailed failure reports.

Enterprise with Third-Party Reporting

v=DMARC1; p=reject;
rua=mailto:dmarc@yourdomain.com,mailto:reports@trustyourinbox.com;
sp=quarantine;
pct=100;
adkim=s; aspf=s

Use case: Enterprise deployment with strict alignment, managed service reports, and subdomain protection.

Deploying Your Record to DNS

DNS Record Configuration

FieldValue
TypeTXT
Name/Host_dmarc
Valuev=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
TTL3600 (1 hour) or 300 (5 min) during initial testing
Common Mistake: Some DNS providers require just "_dmarc" as the host name, while others need "_dmarc.yourdomain.com". Check your provider's documentation.

Verification Steps

  1. Add the TXT record to your DNS zone file through your DNS provider
  2. Wait 5-60 minutes for DNS propagation (depends on your TTL)
  3. Verify the record using our DMARC Domain Checker
  4. Send test emails and check for DMARC authentication headers
  5. Wait 24-48 hours for first aggregate reports to arrive

Command Line Verification

# Linux/Mac
dig _dmarc.yourdomain.com TXT +short

# Windows
nslookup -type=TXT _dmarc.yourdomain.com

Expected output should show your DMARC record value.

Recommended Rollout Timeline

Weeks 1-2: Monitoring Phase

p=none

  • Deploy DMARC record with p=none
  • Collect aggregate reports daily
  • Identify all legitimate email sources
  • Fix SPF/DKIM for any legitimate failures

Weeks 3-4: Initial Quarantine (10%)

p=quarantine; pct=10

  • Move to quarantine with 10% application
  • Monitor for any delivery issues
  • Watch for complaints from users

Weeks 5-6: Increase to 25-50%

p=quarantine; pct=50

  • Gradually increase percentage if no issues
  • Continue monitoring reports
  • Address any new failures quickly

Weeks 7-8: Full Quarantine

p=quarantine; pct=100

  • Apply quarantine to 100% of failing emails
  • Verify SPF/DKIM pass rates remain high (95%+)
  • Prepare for final move to p=reject

Week 9+: Full Protection

p=reject

  • Move to p=reject for maximum protection
  • Maintain ongoing monitoring
  • Review reports weekly for new issues
Success Metric: Aim for 95%+ DMARC pass rate before moving to the next enforcement level.

Common Mistakes to Avoid

❌ Starting with p=reject

Why it's bad: You'll immediately block legitimate emails you weren't aware of. Always start with p=none.

❌ No report destination (missing rua tag)

Why it's bad: You won't receive data about authentication failures and can't monitor your deployment.

❌ Syntax errors (missing semicolons, wrong order)

Why it's bad: Invalid records will be ignored entirely, leaving you unprotected.

❌ Deploying without SPF/DKIM first

Why it's bad: DMARC requires at least one of SPF or DKIM to pass. Without them, all emails fail authentication.

❌ Not monitoring reports regularly

Why it's bad: New email sources or configuration changes can break authentication without you knowing.

❌ Multiple DMARC records

Why it's bad: Having more than one DMARC TXT record at _dmarc.yourdomain.com causes all records to be ignored per RFC 7489.

Next Steps After Deployment

1. Monitor Your Reports Daily

Review aggregate reports to identify authentication failures. Use our XML to JSON Converter for easier analysis.

2. Authorize Legitimate Sources

Add any legitimate third-party senders to your SPF record or configure DKIM signing for them.

3. Plan Your Enforcement Rollout

Follow the progressive timeline above to safely move from p=none to p=quarantine to p=reject.

4. Consider Subdomain Protection

Add DMARC records for subdomains or use the sp tag to protect them. Read our Subdomain DMARC Policies Guide.

5. Implement Ongoing Monitoring

Set up automated report processing with TrustYourInbox to catch issues before they impact delivery.

Related Guides

What is DMARC?

Learn DMARC fundamentals before creating your record

Understanding DMARC Reports

Learn how to read and interpret your DMARC reports

Moving to p=reject Safely

Progressive strategy for maximum email protection

Generate Your DMARC Record

Use our free DMARC Policy Generator to create a validated record in seconds.

Generate DMARC Record

Automate DMARC Management

Let TrustYourInbox handle reports, monitoring, and enforcement rollout for you.

See How It Works

Free DMARC Tools

DMARC Policy Generator

Create validated DMARC records with our interactive tool

DMARC Domain Checker

Verify your DMARC record is deployed correctly

XML to JSON Converter

Convert aggregate reports to readable JSON format