What Is DMARC and How Does It Work

What is DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol defined in RFC 7489. It ties together two existing protocols — SPF and DKIM — and adds two critical capabilities: a policy (what to do with unauthenticated emails) and reporting (feedback on who is sending emails from your domain).

SPF and DKIM verify on their own — but neither tells the recipient what to do when verification fails. DMARC fills that gap. The domain owner publishes a DNS record that says: "If an email from my domain fails authentication, here's what to do with it."

How DMARC works

DMARC operates in five steps:

1. You send an email from your domain (e.g., example.com).
2. The receiving server extracts the domain from the "From" header and queries DNS for the DMARC record at _dmarc.example.com.
3. The server performs SPF and DKIM checks.
4. The server verifies alignment — whether the domain from the SPF or DKIM result matches the "From" header domain, according to the rules in the DMARC record.
5. Based on the policy, the server delivers, quarantines, or rejects the email. It also sends the domain owner a report.

Why alignment matters

SPF checks the envelope sender address (MAIL FROM), not the "From" header that recipients see. DKIM verifies the domain that signed the message — which can also differ from the "From" domain.

DMARC requires that at least one protocol (SPF or DKIM) passes and that the domain from the successful check matches the "From" header domain. This matching process is called identifier alignment.

DMARC supports two alignment modes:

Relaxed alignment is sufficient for most organizations.

Anatomy of a DMARC record

A DMARC record is published as a TXT record in DNS on the _dmarc subdomain. For example.com:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:example.com@rua.spfmonitor.com; pct=100"

Required tags

Optional tags

DMARC policies

The policy tag (p=) determines what the receiving server should do with emails that fail DMARC:

Why you need DMARC

Protection against spoofing and phishing

Without a DMARC record set to quarantine or reject, an attacker can send emails with your domain in the "From" header — and the recipient has no instruction on how to handle them. Even if SPF or DKIM fails, the email may be delivered.

DMARC with a reject policy tells recipients: "If an email from my domain fails authentication, reject it." This eliminates most spoofing and phishing attacks that abuse your domain.

Google and Yahoo requirements

Since February 2024, Google and Yahoo require at least SPF or DKIM authentication for all senders. Bulk senders (over 5,000 messages per day to Gmail) must also have a DMARC record (at minimum p=none) along with both SPF and DKIM. Since November 2025, Gmail has tightened enforcement — non-compliant emails face rejection.

Without email authentication, you risk deliverability issues with the world's largest mailbox providers.

Visibility and control over your domain

DMARC reports give you insight into who is sending emails from your domain. Aggregate reports (rua) arrive daily in XML format and contain:

• IP addresses of sending servers
• SPF and DKIM check results
• Message counts and alignment outcomes

Reports help you identify legitimate services you forgot to include in your SPF record and detect potential abuse of your domain.

How to deploy DMARC

DMARC deployment happens in three phases. Jumping straight to p=reject without monitoring first can block legitimate emails.

1. Set up SPF and DKIM

DMARC builds on SPF and DKIM — without them, it has nothing to evaluate. Make sure you have:

• A working SPF record with all authorized senders
• Active DKIM signing for all sending services

2. Start with p=none

Publish a DMARC record with a none policy and a reporting address:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com"

The address example.com@rua.spfmonitor.com sends reports to SPF Monitor, which automatically processes and visualizes them — no need to manually parse XML files. You can also send reports to both SPF Monitor and your own email at once:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com,mailto:dmarc@example.com"

In this mode, emails are delivered normally, but you receive reports. Analyze them for several weeks — identify all legitimate senders and fix any SPF or DKIM issues.

3. Tighten the policy

Once reports show that all legitimate emails pass authentication:

1. Move to p=quarantine — unauthenticated emails go to spam.
2. Monitor reports and verify no legitimate traffic is being blocked.
3. Move to p=reject — unauthenticated emails are rejected at the SMTP level.

The pct= tag enables gradual rollout. For example, pct=10 applies the policy to only 10% of emails — the remaining messages are evaluated as p=none (monitoring without enforcement). Gradually increase to 100%.

Common DMARC issues

Email forwarding

When an email is forwarded, the sending server changes, so SPF fails (the new server isn't in the original domain's SPF record). If the email lacks a valid DKIM signature, the entire DMARC check fails. This is why a working DKIM setup matters — DKIM survives forwarding as long as the message body remains unchanged.

The ARC (Authenticated Received Chain) protocol helps address this issue by preserving authentication results across the forwarding chain.

Third parties sending on your behalf

Marketing platforms, helpdesk systems, and billing services send emails on behalf of your domain. Each such service must be:

• Included in your SPF record (include mechanism)
• Configured for DKIM signing with your domain

If you miss a service, its emails will stop reaching recipients once you tighten your DMARC policy.

Subdomain policy

A DMARC record on the main domain applies to subdomains as well (unless they have their own DMARC record). The sp= tag lets you set a different policy for subdomains. A common pattern: p=reject on the main domain and sp=reject for subdomains — this prevents attackers from spoofing non-existent subdomains.

DMARC complements SPF and DKIM

DMARC is not a replacement for SPF or DKIM — it's their orchestrator. Without SPF and DKIM, DMARC has nothing to evaluate. Without DMARC, you have no control over what happens to unauthenticated emails.

Complete protection requires all three protocols. Check your DMARC record to find out if your domain is protected.