DMARC Setup Complete Guide: From Zero to Full Protection

Setting up DMARC requires three steps: configure SPF and DKIM for your domain, publish a DMARC TXT record at _dmarc.yourdomain.com, and monitor aggregate reports before moving to enforcement. DMARC (RFC 7489) ties SPF and DKIM together by checking that the domain in the visible From header aligns with the domain authenticated by SPF or DKIM. Without DMARC, failed authentication has no consequence and attackers can freely spoof your domain.

This guide walks you through the entire process, from understanding what DMARC does to publishing your first record, reading your first reports, and progressing through policy enforcement. Whether you are configuring DMARC for a single domain or rolling it out across hundreds, the fundamentals are the same.

The most common mistake we see during DMARC setup is jumping straight to p=reject without monitoring first, says Vasile Diaconu, Operations Lead at DuoCircle. Start at p=none, analyze your reports for at least a full quarter. You need to catch monthly, quarterly, and annual email senders that only fire periodically. Then fix any legitimate senders that fail before enforcing.

Why DMARC Is No Longer Optional

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

If you have not started, the time is now. Every day without DMARC is a day your domain can be spoofed without consequence.

Understanding What DMARC Does

DMARC solves a specific problem: email spoofing. Without DMARC, anyone can send email that appears to come from your domain. SPF and DKIM existed before DMARC, but they lacked a critical piece: a way for domain owners to tell receiving servers what to do when authentication fails and a way to receive reports about it.

DMARC adds two things:

A policy that tells receivers how to handle messages that fail authentication (none, quarantine, or reject)
A reporting mechanism that sends you data about every message claiming to be from your domain

A DMARC check passes when EITHER SPF or DKIM passes AND the authenticated domain aligns with the From header domain. This alignment requirement is what makes DMARC effective against spoofing. For a deeper look at what makes up a DMARC record, see our guide on the basic components required to create a DMARC record.

Prerequisites: SPF and DKIM

DMARC requires at least one of SPF or DKIM to be configured. Both is strongly recommended.

Setting Up SPF

SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record that lists which IP addresses and servers are authorized to send email for your domain. A basic SPF record looks like this:

yourdomain.com. IN TXT "v=spf1 include:spf.google.com include:sendgrid.net -all"

Key constraints to keep in mind:

10 DNS lookup limit. Each include, a, mx, and redirect mechanism counts as a lookup. Exceeding 10 causes a permanent error (permerror), which means SPF fails for every message.
Use -all (hard fail) rather than ~all (soft fail) once you are confident in your sending sources. Soft fail provides limited protection.
Only one SPF record per domain. Multiple SPF records cause both to fail.

Use our SPF checker tool to validate your record. For platform-specific SPF instructions, see our guides on configuring SPF records for Gmail and SPF records for Office 365.

Setting Up DKIM

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to outgoing messages. The receiving server checks this signature against a public key published in your DNS. If the signature verifies, DKIM passes.

DKIM setup varies by email provider:

Google Workspace: Generate a DKIM key in the Admin console under Apps > Gmail > Authenticate email. See our complete DKIM setup guide for Google Workspace.
Microsoft 365: Enable DKIM signing in the Microsoft 365 Defender admin center. See our DKIM for Microsoft 365 guide.
Postfix/self-hosted: Configure OpenDKIM with your MTA. See our complete guide to configuring DKIM with OpenDKIM and Postfix.

Validate your DKIM configuration with our DKIM lookup tool.

Step 1: Decide Where to Publish Your DMARC Record

Your DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. The underscore prefix is mandatory. If your domain is example.com, the record goes at _dmarc.example.com.

For guidance on choosing the right DNS location, including subdomains and multi-domain setups, read our guide on where to publish your DMARC record.

If you use a managed DNS provider, we have platform-specific guides:

Step 2: Create Your DMARC Record

A minimal DMARC record contains three tags:

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

Here is what each tag means:

Tag	Value	Purpose
`v`	`DMARC1`	Version identifier (required, must be first)
`p`	`none`, `quarantine`, or `reject`	Policy for messages that fail DMARC
`rua`	`mailto:address`	Where to send aggregate reports

Always start with p=none. This enables monitoring without affecting email delivery. You will change this later after analyzing reports.

Additional tags you may want:

Tag	Example	Purpose
`ruf`	`mailto:forensic@yourdomain.com`	Forensic (failure) report address
`pct`	`25`	Percentage of failing mail to apply policy to
`adkim`	`r` or `s`	DKIM alignment mode (relaxed or strict)
`aspf`	`r` or `s`	SPF alignment mode (relaxed or strict)
`sp`	`none`, `quarantine`, `reject`	Subdomain policy
`fo`	`0`, `1`, `d`, `s`	Forensic report options

For a step-by-step walkthrough of record creation, see our guide to creating a DMARC record without breaking email delivery. If you prefer a tool-assisted approach, our DMARC record generator creates properly formatted records for Gmail and Office 365 environments.

Step 3: Publish the Record in DNS

Add the DMARC record as a TXT record in your DNS provider:

Host/Name: _dmarc
Type: TXT
Value: Your DMARC record string
TTL: 3600 (1 hour) is a reasonable starting point

After publishing, verify the record is resolving correctly:

dig TXT _dmarc.yourdomain.com +short

Or use our DMARC checker tool to validate the record syntax and confirm it is publicly accessible.

DNS propagation typically takes 15 minutes to 48 hours depending on your provider and TTL settings. For details on propagation timing, see our guide on how long after DMARC DNS record setup it affects email delivery.

Step 4: Verify Your Setup

Before moving on, confirm all three authentication layers are working:

Check SPF: SPF checker - verify your record is valid and within the 10-lookup limit
Check DKIM: DKIM lookup - confirm your public key is published and signatures verify
Check DMARC: DMARC checker - validate your record syntax and reporting addresses

You can also verify from the command line. Our guide on checking DMARC records with dig and nslookup covers the manual approach.

If your setup has issues, check our troubleshooting guide on common signs your domain lacks a published DMARC record or how to fix the “no DMARC record found” error.

Step 5: Monitor Your Aggregate Reports

Within 24-48 hours of publishing your DMARC record, aggregate reports (RUA) will start arriving from receiving mail servers. These XML reports contain data about every message that claims to come from your domain, including which ones passed and failed SPF, DKIM, and DMARC.

Raw XML reports are difficult to read. DMARC Report parses them automatically and presents the data in a visual dashboard showing:

Which IPs are sending email as your domain
Which messages pass and fail authentication
Which sending sources are aligned and which are not
Volume trends over time

For a detailed explanation of what aggregate reports contain and how to interpret them, see our complete guide to DMARC aggregate reports. If you want to understand the raw XML format, our guide on reading DMARC reports breaks down every field.

What to Look For in Your First Reports

During the initial monitoring period, focus on three things:

Legitimate senders that fail. These are the services you authorized but that are not properly authenticated. Common culprits include marketing platforms, CRM systems, ticketing tools, and transactional email providers.
Unknown senders that pass. These might be services you forgot about, or they might indicate a configuration problem.
Spoofing attempts. Messages from IPs you do not recognize, using your domain in the From header. This is the threat DMARC is designed to stop.

Fix every legitimate sender that fails before moving to enforcement. This might mean updating SPF records to include new services, enabling DKIM signing on third-party platforms, or fixing alignment issues. Our guide on how to interpret DMARC reports to find email authentication issues walks through this analysis step by step.

Step 6: Progress Through Policy Enforcement

DMARC enforcement is a journey with three stages. Rushing through them risks blocking legitimate email.

Stage 1: p=none (Minimum 90 Days)

Monitor only. No impact on email delivery. Use this time to identify all legitimate sending sources and fix authentication failures. Read our guide on when to use the DMARC p=none policy for detailed guidance on this phase.

Stage 2: p=quarantine (Minimum 90 Days)

Failing messages are routed to spam instead of the inbox. Start with pct=25 to apply the policy to only 25% of failing mail, then gradually increase to 100%. This phased approach catches problems before they affect all your email. For details on when and how to use quarantine, see our guide on when your DMARC policy should use p=quarantine.

Stage 3: p=reject

Full enforcement. Failing messages are rejected outright. The receiving server returns a bounce to the sender. This is the ultimate protection against domain spoofing. Our guide on the DMARC reject policy covers the details, and our enforcement timeline roadmap provides realistic timelines for each phase.

For the complete picture of choosing the right policy for your situation, see our DMARC policy guide: from none to reject.

Platform-Specific Setup Guides

DMARC setup varies by email platform. We have dedicated guides for the most common environments:

Google Workspace / Gmail

For the full Google Workspace hub, see our DMARC for Gmail and Google Workspace guide.

Microsoft 365 / Office 365

For the full Microsoft 365 hub, see our DMARC for Office 365 guide.

Other Platforms

Common Setup Mistakes

These are the errors we see most frequently in support tickets:

Publishing multiple DMARC records. Only one DMARC record is allowed per domain. Multiple records cause all of them to fail. See our guide on whether you can have multiple DMARC records.

Skipping the monitoring phase. Going directly to p=reject blocks email from services you forgot to authenticate. Always start at p=none.

Forgetting the _dmarc prefix. The record must be at _dmarc.yourdomain.com, not yourdomain.com.

Not including a rua address. Without a reporting address, you get no visibility into authentication results. You are flying blind.

SPF lookup limit exceeded. Adding too many include mechanisms pushes you past the 10-lookup limit. Every message fails SPF as a result.

DKIM not enabled for custom domains. Both Google Workspace and Microsoft 365 require manual DKIM enablement for custom domains. The default signatures use the provider’s domain, not yours, which means DKIM alignment fails. See is your Google Workspace DKIM setup broken? and troubleshooting DKIM issues for Google Workspace.

Subdomains and Multi-Domain Setups

If you send email from subdomains (marketing.yourdomain.com, support.yourdomain.com), you have two options:

Use the sp tag in your parent domain’s DMARC record to set a default subdomain policy
Publish separate DMARC records for each subdomain that needs a different policy

Our guide on the DMARC subdomain policy tag explains how the sp tag works and when to use individual subdomain records instead. For organizations managing many domains, see how to implement DMARC for multiple domains and subdomains.

What Comes After Setup

DMARC is not a set-and-forget configuration. After reaching p=reject, ongoing monitoring is essential:

New sending services must be authenticated before they start sending. Add them to SPF or configure DKIM before go-live.
Third-party changes can break authentication. Vendors change IP ranges, rotate DKIM keys, or modify envelope senders.
Report analysis should continue indefinitely. DMARC Report dashboards flag anomalies so you catch problems before they affect delivery.

Consider implementing BIMI (Brand Indicators for Message Identification) once you reach p=reject. BIMI displays your brand logo in supporting email clients, but it requires DMARC enforcement as a prerequisite.

Quick-Start Checklist

Use this checklist to track your DMARC deployment:

SPF record published and validated (check now)
DKIM enabled and public key published (check now)
DMARC record published at _dmarc.yourdomain.com with p=none (check now)
Aggregate reports arriving and reviewed in DMARC Report dashboard
All legitimate senders identified and authenticated
Policy moved to p=quarantine with pct=25
Quarantine percentage gradually increased to 100%
Policy moved to p=reject
Ongoing monitoring configured

For a preparation-focused walkthrough before you touch DNS, see our DMARC setup stage 1: preparation guide.