DMARC (Domain-based Message Authentication, Reporting & Conformance)

Complete Guide to Email Authentication - Enforcing SPF and DKIM Policies for Maximum Protection

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that tells receiving mail servers what to do with emails that fail SPF or DKIM checks. It also provides reporting on email authentication, giving you visibility into authentication failures and spoofing attempts.

Think of DMARC as the "enforcer" that uses SPF and DKIM results to make decisions. SPF and DKIM authenticate emails, but DMARC tells receiving servers what to do when authentication fails.

DMARC works by:

1. Checking SPF and DKIM: DMARC uses SPF and DKIM authentication results
2. Applying Policy: DMARC tells receiving servers what to do with emails that fail authentication
3. Providing Reporting: DMARC sends reports to you about authentication failures and spoofing attempts
4. Enforcing Alignment: DMARC verifies that the "From" domain matches the authenticated domain

How DMARC Works

When an email is received, the receiving mail server:

1. Checks SPF: Verifies if the sending server is authorized (SPF pass/fail)
2. Checks DKIM: Verifies if the email is signed and authentic (DKIM pass/fail)
3. Checks DMARC Policy: Looks up the DMARC record in DNS
4. Applies Policy: Decides what to do based on DMARC policy and authentication results:
   • None: Monitor only—accept all emails but send reports
   • Quarantine: Send failed emails to spam folder
   • Reject: Reject emails that fail authentication (strongest protection)
5. Sends Reports: If configured, sends authentication failure reports to your email address

DMARC Record Format

DMARC records are TXT records in DNS at _dmarc.yourdomain.gov. Here's the basic format:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.gov

The record contains tags that specify policy, reporting, and other options.

DMARC Tags

DMARC records use tags to specify policy and options:

• v=DMARC1: Version identifier (always starts with this)
• p=: Policy for emails that fail authentication:
  • none: Monitor only—accept all emails (use when starting out)
  • quarantine: Send failed emails to spam folder
  • reject: Reject emails that fail authentication (strongest protection)
• pct=: Percentage of emails to apply policy to (100 = all emails)
• rua=: Email address for aggregate reports (comma-separated if multiple)
• ruf=: Email address for forensic reports (comma-separated if multiple)
• sp=: Policy for subdomains (defaults to parent domain policy if not specified)
• aspf=: Alignment mode for SPF (r=relaxed or s=strict, default is relaxed)
• adkim=: Alignment mode for DKIM (r=relaxed or s=strict, default is relaxed)
• fo=: Failure reporting options (0, 1, d, s combinations)

Example DMARC Records

Strong DMARC Record (Recommended for Government)

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.gov; sp=reject; aspf=s; adkim=s

RECOMMENDED: This provides the strongest protection—rejects all emails that fail authentication, applies to 100% of emails, and uses strict alignment for both SPF and DKIM.

Quarantine DMARC Record (Monitoring Phase)

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.gov

MONITORING: Use this when initially deploying DMARC to monitor failures before moving to "reject" policy.

None DMARC Record (Initial Deployment)

v=DMARC1; p=none; pct=100; rua=mailto:dmarc@yourdomain.gov

WARNING: This provides NO protection—all emails are accepted regardless of authentication status. Use only during initial setup to monitor failures before moving to "quarantine" or "reject".

Why DMARC is Critical for Government Agencies

For government agencies, DMARC is not optional—it's mandatory per CISA requirements. Here's why:

1. Enforces Email Authentication

DMARC enforces SPF and DKIM policies. Without DMARC, even with SPF and DKIM configured, receiving servers may still accept spoofed emails. DMARC tells servers to reject or quarantine emails that fail authentication.

2. Provides Visibility Through Reporting

DMARC provides aggregate and forensic reports that show:

• Authentication failure rates
• Spoofing attempts from your domain
• Legitimate sources that need to be authorized
• Configuration issues that need to be fixed

These reports are critical for identifying and fixing email authentication issues.

3. Prevents Email Spoofing

DMARC with "reject" policy prevents attackers from sending spoofed emails claiming to be from your domain. Even if attackers bypass SPF or DKIM (through misconfigurations), DMARC enforces alignment checks that prevent spoofing.

4. Required for CISA Compliance

The Cybersecurity and Infrastructure Security Agency (CISA) mandates SPF, DKIM, and DMARC for all government email domains. Failure to implement DMARC results in non-compliance, which can lead to:

• Criminal charges for negligence
• Civil liability from email attacks
• Federal grant restrictions
• Insurance claim denials

5. Completes Email Security

DMARC completes the email authentication stack. SPF authorizes sending servers, DKIM signs emails, and DMARC enforces policies. Without DMARC, you have authentication but no enforcement—attackers can still spoof your domain.

DMARC Policy Options

DMARC policies determine what happens to emails that fail authentication:

p=none (Monitor Only)

p=none means "monitor only"—all emails are accepted regardless of authentication status, but reports are sent about authentication failures.

Use when: Initially deploying DMARC to monitor failures before enforcing policies.

Protection level: NO protection—all emails are accepted. Use only during setup.

p=quarantine (Send to Spam)

p=quarantine means "send to spam"—emails that fail authentication are sent to the spam folder instead of being rejected.

Use when: Monitoring failures but want some protection. Good intermediate step before moving to "reject".

Protection level: PARTIAL protection—failed emails go to spam but may still be accessed by users.

p=reject (Reject Email)

p=reject means "reject email"—emails that fail authentication are rejected entirely and not delivered.

Use when: SPF and DKIM are properly configured and you've verified legitimate sources are authenticated.

Protection level: STRONGEST protection—failed emails are rejected. Recommended for government agencies.

DMARC Alignment

DMARC alignment ensures that the "From" domain matches the authenticated domain. This prevents attackers from authenticating with a different domain and then spoofing your domain in the "From" field.

Relaxed Alignment (Default)

Relaxed alignment allows the "From" domain to be a subdomain of the authenticated domain. For example, if the authenticated domain is "mail.example.gov", the "From" domain can be "example.gov" or any subdomain.

aspf=r (relaxed) and adkim=r (relaxed) allow this flexibility.

Strict Alignment (Recommended)

Strict alignment requires an exact match between the "From" domain and the authenticated domain. This provides stronger protection against spoofing.

aspf=s (strict) and adkim=s (strict) enforce exact matching.

Recommended for government agencies: Use strict alignment for maximum protection.

DMARC Reporting

DMARC provides two types of reports:

Aggregate Reports (rua)

Aggregate reports are sent daily (or as configured) to the email addresses specified in the rua= tag. These reports contain:

• Summary of authentication failures
• Sources of failed emails (IP addresses)
• Counts of passed/failed emails
• Policy evaluation results

Aggregate reports help identify:

• Spoofing attempts
• Legitimate sources that need to be authorized
• Configuration issues
• Trends in authentication failures

Forensic Reports (ruf)

Forensic reports are sent in real-time when individual emails fail authentication. These reports contain:

• Full email headers
• Authentication failure details
• Message content (if configured)

Forensic reports are useful for investigating specific spoofing attempts but can be noisy and privacy-sensitive. Many organizations only use aggregate reports.

What Can Go Wrong Without DMARC?

The consequences of operating without DMARC are severe:

No Control Over Spoofed Emails

Without DMARC, even with SPF and DKIM configured, receiving servers may still accept spoofed emails. You have authentication but no enforcement—attackers can still send spoofed emails.

No Visibility Into Spoofing Attempts

Without DMARC reporting, you have no visibility into:

• Spoofing attempts from your domain
• Authentication failure rates
• Legitimate sources that need authorization
• Configuration issues

Cannot Achieve Complete Email Security

Without DMARC, you cannot achieve complete email security. SPF and DKIM provide authentication, but DMARC provides enforcement and visibility—both are essential.

Compliance Failures

Operating without DMARC means:

• Failure to meet CISA requirements
• Exposure to legal liability
• Insurance claim denials
• Potential loss of federal funding

How to Implement DMARC

Implementing DMARC requires a gradual approach to avoid blocking legitimate emails:

Step 1: Ensure SPF and DKIM Are Configured

Before deploying DMARC, ensure SPF and DKIM are properly configured and working. DMARC relies on SPF and DKIM results, so they must be in place first.

Step 2: Start with p=none (Monitor Only)

Start with p=none; pct=100; rua=mailto:dmarc@yourdomain.gov to monitor failures without blocking any emails. This allows you to:

• Identify legitimate sources that need authorization
• Fix configuration issues
• Monitor spoofing attempts
• Verify SPF and DKIM are working correctly

Step 3: Move to p=quarantine (Monitoring)

After monitoring for a period (typically 2-4 weeks), move to p=quarantine; pct=100 to send failed emails to spam. Continue monitoring reports to ensure legitimate emails aren't being quarantined.

Step 4: Move to p=reject (Full Protection)

Once you've verified all legitimate sources are authenticated and failures are minimal, move to p=reject; pct=100; aspf=s; adkim=s for full protection. This is the recommended policy for government agencies.

Step 5: Configure Reporting

Ensure rua= is configured with a valid email address to receive aggregate reports. Review reports regularly to identify and fix issues.

Step 6: Monitor and Maintain

DMARC requires ongoing monitoring:

• Review aggregate reports regularly
• Identify and authorize legitimate sources
• Fix configuration issues
• Update SPF and DKIM when mail servers change

Common DMARC Implementation Issues

Several common issues can cause DMARC problems:

1. Missing or Incorrect DMARC Record

If the DMARC record is missing or incorrect, DMARC won't work. The record must be at _dmarc.yourdomain.gov and start with v=DMARC1.

Solution: Ensure the DMARC record is properly published in DNS at the correct location.

2. Moving Too Quickly to p=reject

Moving directly to p=reject without monitoring can cause legitimate emails to be rejected if SPF or DKIM aren't properly configured.

Solution: Follow a gradual approach: start with p=none, then p=quarantine, then p=reject.

3. Not Configuring Reporting

Without rua= configured, you won't receive reports and won't know about authentication failures or spoofing attempts.

Solution: Always configure rua= with a valid email address to receive aggregate reports.

4. Ignoring Reports

If you don't review and act on DMARC reports, you won't identify legitimate sources that need authorization or configuration issues that need fixing.

Solution: Review aggregate reports regularly and take action to fix issues.

5. Not Updating SPF and DKIM

If SPF and DKIM aren't updated when mail servers change, legitimate emails will fail DMARC checks and be rejected.

Solution: Keep SPF and DKIM updated when mail servers or services change.

How YesGov Ensures DMARC is Properly Configured

YesGov handles all aspects of DMARC implementation and management for government agencies:

• Complete Setup: We configure DMARC with appropriate policy (starting with "none", moving to "quarantine", then "reject")
• Proper Policy: We implement "reject" policy with "pct=100" and strict alignment for maximum protection
• Reporting Configuration: We configure aggregate reports to monitor authentication failures
• DNS Configuration: We publish DMARC records in DNS with proper formatting
• Integration: We ensure DMARC works with SPF and DKIM for complete email security
• Ongoing Monitoring: We monitor DMARC reports to identify and fix issues
• Documentation: All DMARC configuration and status is documented for compliance and insurance purposes

How YesGov Ensures Complete DMARC Protection

At YesGov, we don't just check if DMARC is configured—we perform comprehensive validation of your entire DMARC setup:

• Policy Configuration: We configure strict "reject" policy for maximum protection
• SPF/DKIM Alignment: We ensure proper alignment with SPF and DKIM records
• Reporting Setup: We configure DMARC reporting to monitor email authentication
• DNS Record Configuration: We publish DMARC records in DNS with proper formatting
• Policy Enforcement: We verify that receiving servers enforce DMARC policies
• Report Analysis: We analyze DMARC reports to identify and fix issues
• Ongoing Monitoring: We continuously monitor DMARC status and policy enforcement

When you host with YesGov, DMARC is properly configured with strict "reject" policy, continuously monitored, and automatically maintained. We handle policy enforcement, report analysis, and issue resolution so you don't have to worry about email spoofing. This is one of our comprehensive security checks that ensures your agency meets and exceeds federal, state, and industry standards.

Additional Resources

• Back to Learn Home
• SPF (Sender Policy Framework)
• DKIM (DomainKeys Identified Mail)
• MTA-STS (Mail Transfer Agent Strict Transport Security)
• TLS-RPT (TLS Reporting)
• Check Your Domain's DMARC Status
• Email Security Overview
• Contact YesGov for Services

Learning Guides