What is DMARC? A Complete Guide to Configure It

Every day, billions of spoofed emails impersonate trusted brands, tricking people into clicking phishing links or handing over credentials. The way domain owners fight back is with DMARC— an email authentication protocol that gives you control over what happens when someone sends email pretending to be from your domain.

In this guide you will learn exactly what DMARC is, how it works together with SPF and DKIM, how to write and publish a DMARC record, and how to graduate safely from monitoring to full enforcement.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based email authentication policy that lets domain owners:

• Declare which mail servers are authorized to send email on their behalf.
• Instruct receiving mail servers what to do with messages that fail authentication — deliver, quarantine, or reject them.
• Receive aggregate and forensic reports so they can monitor who is sending email from their domain.

Published as a simple DNS TXT record at _dmarc.yourdomain.com, DMARC builds on two older standards — SPF and DKIM — to close the gap that lets spoofed email reach inboxes.

DMARC was developed in 2012 by a group of major email senders and receivers (PayPal, Google, Microsoft, Yahoo, and others) and published as RFC 7489 in 2015. Today it is effectively required by Gmail, Yahoo, and most enterprise mail filters for bulk senders.

How DMARC Works

When a receiving mail server gets a message claiming to be from yourdomain.com, it performs the following checks in order:

1. Check SPF — does the sending IP match the authorized IPs listed in the domain's SPF record?
2. Check DKIM — is there a valid cryptographic signature on the message that traces back to the From domain?
3. Check DMARC alignment — does the domain that passed SPF or DKIM match the domain in the visible From: header?
4. Apply the DMARC policy — if alignment fails, do what the domain owner instructed (none / quarantine / reject).
5. Send a report — include this message in the aggregate report delivered to the rua address.

The critical concept here is alignment: it is not enough for SPF or DKIM to pass on their own — the domain they authenticate must align (match, either exactly or at the organizational level) with the domain in the visible From: address. This is what closes the spoofing loophole.

SPF, DKIM, and DMARC: The Authentication Trinity

DMARC does not work in isolation. Understanding what SPF and DKIM do is essential before configuring DMARC.

SPF — Sender Policy Framework

SPF lets you publish a list of IP addresses and mail servers that are allowed to send email for your domain. It is a DNS TXT record at your root domain that looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.42 ~all

When a receiving server gets a message from you@yourdomain.com, it checks whether the sending IP appears in your SPF record. If it does, SPF passes. The limitation of SPF is that it checks the envelope sender (used during the SMTP transaction), not the visible From: address — which is why DMARC's alignment requirement matters.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. Your mail server signs each message with a private key, and the corresponding public key is published in DNS. Receiving servers fetch the public key and verify the signature — proving the message was not tampered with and came from a server controlled by your domain.

mail._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgk..."

Unlike SPF, DKIM survives email forwarding because the signature is attached to the message headers, not tied to the sending IP. This makes DKIM the more reliable authentication signal for DMARC.

DMARC Alignment

For DMARC to pass, at least one of the following must be true:

• SPF passes AND the domain in the Return-Path (envelope sender) aligns with the From: domain.
• DKIM passes AND the d= domain in the DKIM signature aligns with the From: domain.

DMARC Policy Modes

The p= tag is the heart of your DMARC record. It tells receivers what to do with messages that fail DMARC:

Anatomy of a DMARC Record

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is a complete example:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1; adkim=r; aspf=r; pct=100; sp=none

Here is what each tag means:

How to Configure DMARC Step by Step

Step 1 — Verify SPF Is Configured

Run a DNS lookup for your domain's TXT records and look for a record starting with v=spf1. Make sure every service that sends email on your behalf (Google Workspace, SendGrid, Mailchimp, your own mail server, etc.) is included.

# Check your SPF record
dig TXT yourdomain.com | grep spf

Step 2 — Implement DKIM Signing

Enable DKIM in every email sending service you use. Each platform generates a key pair and gives you a DNS record to publish. Verify the signature is working by sending a test email and inspecting the raw headers for a DKIM-Signature field with d=yourdomain.com.

Step 3 — Start with p=none

Create your first DMARC record in monitoring mode. This collects data without affecting deliverability:

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

Step 4 — Publish the DNS Record

Log in to your DNS provider and add a new TXT record with:

• Host / Name: _dmarc (some providers need the full _dmarc.yourdomain.com)
• Type: TXT
• Value: your DMARC record string
• TTL: 3600 (1 hour) is fine

Step 5 — Analyze Aggregate Reports

After 24–48 hours you will start receiving XML aggregate reports at your rua= address. These reports show every IP that sent email using your domain and whether each message passed or failed SPF, DKIM, and DMARC alignment. Use them to identify:

• Sending services you forgot to add to SPF.
• Platforms that need DKIM configured.
• Third parties legitimately using your domain (newsletters, CRM tools, etc.).
• Unauthorized senders — spoofing or phishing attempts.

Step 6 — Graduate to Quarantine, Then Reject

Once your reports show that close to 100% of legitimate email is passing DMARC, tighten your policy:

# Phase 1 — Monitor (no impact)
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

# Phase 2 — Quarantine a small percentage first
"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com; fo=1"

# Phase 3 — Full quarantine
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; fo=1"

# Phase 4 — Full rejection (goal state)
"v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1"

Spend at least one to two weeks at each phase, reviewing reports before moving on. There is no fixed timeline — what matters is that your legitimate email consistently passes before you restrict anything.

How to Read DMARC Aggregate Reports

Aggregate reports are delivered as gzip-compressed XML files. Each file covers a 24-hour period and lists every sending IP, the count of messages from that IP, and the SPF and DKIM disposition for each. A typical entry looks like this (simplified):

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1024</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Key things to look for: any disposition: quarantine or reject entries while you are on p=none — these show what would happen if you enforced. IPs sending large volumes that fail both checks are likely spoofers.

Common DMARC Configuration Mistakes

• Jumping to p=reject before all sending sources are covered — the most common cause of broken email.
• Forgetting third-party senders: marketing platforms, helpdesk tools, ticketing systems, CRM notifications.
• SPF record exceeding 10 DNS lookups — causes SPF to fail permanently. Flatten or consolidate includes.
• Not setting a rua= address — you cannot improve what you cannot measure.
• Using strict alignment (aspf=s or adkim=s) without verifying that your From domain exactly matches the SPF/DKIM domain.
• Setting pct=100 immediately on quarantine — use a gradual rollout (pct=10, pct=50, pct=100) to catch surprises.

Benefits of Implementing DMARC

• Blocks domain spoofing and phishing emails that impersonate your brand.
• Protects your customers, partners, and employees from social engineering attacks.
• Satisfies requirements from Google, Yahoo, and Microsoft for bulk senders (required for >5,000 emails/day to Gmail).
• Improves sender reputation and email deliverability over time.
• Provides full visibility into all email sent using your domain — including unauthorized use.
• Required for BIMI (Brand Indicators for Message Identification), which shows your logo in inboxes.

Frequently Asked Questions

Summary

DMARC is the most impactful email security control a domain owner can deploy. It stops spoofing, protects your brand reputation, satisfies modern inbox provider requirements, and gives you unprecedented visibility into who is sending email on your behalf.

The path to full DMARC enforcement is straightforward: configure SPF and DKIM, publish a p=none record, analyze aggregate reports, fix any gaps, and gradually tighten your policy to p=reject. The monitoring phase is where most teams spend the most time — and having a tool that parses and surfaces the important data from those XML reports makes all the difference.