DMARC: Protecting Your Domain from Spoofing

What is DMARC?

DMARC is an email authentication protocol that builds on top of SPF and DKIM. While SPF verifies the sending server and DKIM verifies message integrity, DMARC adds two critical capabilities:

Policy Enforcement

DMARC tells receiving servers what to do when SPF or DKIM checks fail - whether to deliver, quarantine, or reject the message.

Reporting

DMARC provides visibility into who is sending email on behalf of your domain, helping you identify legitimate senders and potential abuse.

Without DMARC, even if you have SPF and DKIM configured, receiving servers have no instruction on how to handle authentication failures. DMARC closes this gap by providing explicit policy guidance.

How DMARC Works

DMARC introduces the concept of "alignment" - the requirement that the domain in SPF or DKIM must match (align with) the domain in the From header that users see.

Alignment Modes

Relaxed Alignment (default)

The organizational domain must match. For example, mail.example.com aligns with example.com. This is the recommended setting for most organizations.

Strict Alignment

An exact domain match is required. mail.example.com would NOT align with example.com. Use this only if you need maximum security and have tight control over all sending sources.

Authentication Flow

For an email to pass DMARC, it must pass either:

SPF check AND SPF alignment, OR
DKIM check AND DKIM alignment

The email only needs to pass one of these (not both), giving you flexibility in your email infrastructure.

DMARC Record Structure

A DMARC record is a TXT record published at _dmarc.yourdomain.com. Here's an example with all common tags:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; sp=reject; pct=100

Key DMARC Tags

Tag	Required	Description
v=DMARC1	Yes	Version identifier, must be first
p=	Yes	Policy: none, quarantine, or reject
rua=	No	Address for aggregate reports (daily summaries)
ruf=	No	Address for forensic reports (individual failures)
sp=	No	Policy for subdomains (defaults to p= value)
pct=	No	Percentage of messages to apply policy (1-100)
adkim=	No	DKIM alignment mode: r (relaxed) or s (strict)
aspf=	No	SPF alignment mode: r (relaxed) or s (strict)

DMARC Policies Explained

DMARC offers three policy levels. The key is to start permissive and gradually increase enforcement as you gain confidence.

p=noneMonitor Only

No action is taken on failing emails. Use this to collect data and identify all legitimate senders before enforcing. Emails are delivered normally regardless of authentication results.

p=quarantineSoft Enforcement

Failing emails are marked as suspicious and typically sent to spam. This is a good intermediate step - you catch most spoofing while minimizing risk if you missed a legitimate sender.

p=rejectFull Protection

Failing emails are rejected outright and never delivered. This provides maximum protection against spoofing but requires confidence that all legitimate senders are properly authenticated.

Goal: Work toward p=reject for your domain. This is the only policy that fully prevents domain spoofing. It's also required for BIMI implementation.

Setting Up DMARC: A Phased Approach

Implementing DMARC requires patience. Rushing to p=reject can block legitimate email. Follow this proven approach:

Phase 1: Monitor (2-4 weeks minimum)

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

Collect aggregate reports to see all email sources
Identify legitimate senders that may not be authenticated
Fix SPF and DKIM for any missing sources
No impact on email delivery during this phase

Phase 2: Quarantine (2-4 weeks)

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

Start with pct=25 to quarantine only 25% of failing mail
Monitor for any legitimate email going to spam
Gradually increase pct to 50, 75, then 100
Address any issues before moving to reject

Phase 3: Reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com

Full protection against domain spoofing
Continue monitoring reports for any new sending sources
You can now implement BIMI for brand display

Important: Don't skip the monitoring phase. Many organizations discover third-party services (CRMs, marketing tools, HR systems) sending email on their behalf that they forgot to authenticate.

Reading DMARC Reports

DMARC aggregate reports are XML files sent daily by receiving mail servers. They contain valuable data about emails sent from your domain.

What Aggregate Reports Tell You

Sending Sources

IP addresses sending email claiming to be from your domain

Authentication Results

SPF, DKIM, and DMARC pass/fail status for each source

Message Counts

Volume of email from each source to help prioritize fixes

<!-- Simplified DMARC aggregate report structure -->
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1706400000</begin>
      <end>1706486399</end>
    </date_range>
  </report_metadata>
  <record>
    <source_ip>192.0.2.1</source_ip>
    <count>150</count>
    <policy_evaluated>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </record>
</feedback>

Raw XML reports can be difficult to read. Consider using a DMARC report analyzer service to visualize and aggregate your reports, especially if you send high volumes of email.

Summary

1.DMARC ties SPF and DKIM together with alignment and policy enforcement
2.Start with p=none to monitor, then progress to quarantine and reject
3.Use aggregate reports (rua=) to identify all sending sources
4.The pct= tag lets you gradually roll out enforcement
5.p=reject is the goal - it fully protects your domain from spoofing

Resources

DMARC.org Official Website RFC 7489: DMARC Specification Google Workspace DMARC Documentation