How to Set Up DMARC (Step-by-Step Guide)

DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving mail servers what to do when a message claims to be from your domain but fails SPF or DKIM checks. Setting it up takes about 15 minutes: you publish one DNS TXT record, collect reports for a few weeks, and then tighten the policy. Start here:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

That single record, published at p=none, is enough to start receiving aggregate reports without any risk to your mail flow.

Prerequisites: SPF and DKIM Must Come First

DMARC builds on top of SPF and DKIM. If those two aren’t in place, DMARC has nothing to work with. For a full explanation of how each record works and where each one falls short without the others, see What Is Email Authentication? SPF, DKIM, and DMARC Explained.

SPF authenticates the envelope sender (the Return-Path address). DKIM attaches a cryptographic signature to the message headers. DMARC then checks whether either of those authenticated identities aligns with the domain in the visible From: address. SPF is evaluated during the SMTP handshake itself, before the message body is transmitted.

According to RFC 7489, DMARC passes when at least one mechanism passes alignment: “the Organizational Domains of both the DKIM-authenticated signing domain and that of the RFC5322.From domain must be equal” (relaxed mode, the default). SPF alignment requires the Return-Path domain to match the From domain.

If you’re using a transactional email service, confirm that it supports custom Return-Path domains and DKIM signing on your domain. Many providers handle this automatically, so it’s worth checking your provider’s docs before publishing DMARC.

Check your existing records before continuing. If dig TXT yourdomain.com returns no SPF record, or your DKIM selector doesn’t resolve, fix those first. Google Workspace requires 48 hours after SPF/DKIM setup before enabling DMARC to avoid delivery issues.

Step 1: Confirm SPF Is Published

Run a DNS lookup against your domain:

dig TXT yourdomain.com

Look for a record starting with v=spf1. A valid, minimal SPF record looks like:

yourdomain.com  TXT  "v=spf1 include:_spf.google.com ~all"

If no SPF record exists, or there are multiple SPF records (only one is allowed), fix that before proceeding.

Step 2: Confirm DKIM Is Signing

DKIM keys are published at a selector subdomain. Your email provider will tell you the selector name; a common one is google._domainkey:

dig TXT google._domainkey.yourdomain.com

You should get a p= value containing a base64-encoded public key. If the query returns no records, DKIM isn’t published for that selector yet.

Step 3: Create the DMARC TXT Record

DMARC records go at _dmarc.yourdomain.com (note the leading underscore). The record value is a semicolon-separated list of tag=value pairs.

Required tags:

Tag	Required?	Description
v	Yes	Always DMARC1. Must appear first.
p	Yes	Policy: none, quarantine, or reject

Optional tags you’ll likely use:

Tag	Default	Description
rua	(none)	URI(s) for aggregate (RUA) reports, strongly recommended
ruf	(none)	URI(s) for failure (forensic) reports
pct	100	Percentage of messages the policy applies to (0–100)
sp	Inherits p	Policy for subdomains
adkim	r	DKIM alignment: r (relaxed) or s (strict)
aspf	r	SPF alignment: r (relaxed) or s (strict)

Syntax rules (common errors):

• Tags are separated by semicolons, not colons
• v must come first; p must come second
• The rua and ruf values must use mailto: URIs
• Only one DMARC record per domain is allowed; a second record causes receivers to ignore both

Step 4: Publish the Record at Your DNS Provider

Go to your DNS provider’s control panel (Cloudflare, Route 53, GoDaddy, Namecheap, etc.) and add a TXT record:

• Host/Name: _dmarc (some providers want the full _dmarc.yourdomain.com)
• Type: TXT
• Value: the record string, quoted (see the phase records below)
• TTL: 3600 (one hour) while testing; increase later

DNS changes propagate in minutes to hours depending on TTL and your provider. Use a DMARC lookup tool (MXToolbox, dmarcian Inspector) to verify the record resolves correctly before waiting for reports.

Step 5: Collect and Read Aggregate Reports

Aggregate reports (RUA) arrive as XML files sent daily by major receivers: Gmail, Outlook, Yahoo, and others. Each report shows:

• The source IP addresses sending mail from your domain
• Message volume per source
• SPF and DKIM pass/fail results
• The DMARC disposition applied (none, quarantine, or reject)

Raw XML is not readable at a glance. Feed the reports into a free parser (Google Postmaster Tools, dmarcian, or MXToolbox) or a forwarding address that auto-parses them. Spend two to four weeks here before touching the policy.

What you’re looking for: legitimate sources that are failing. Common culprits include a third-party CRM sending on your behalf without a custom Return-Path, a marketing tool using a different DKIM selector, or an internal relay that bypasses your primary mail server. Fix these alignment issues before tightening the policy, or you’ll block your own mail.

Step 6: Enforce the Policy Gradually

dmarc.org describes the phased approach directly: “Modify your DMARC policy flags from ‘none’ to ‘quarantine’ to ‘reject’ as you gain experience.” They note that “it is nearly impossible for an organization to flip a switch to production.”

A practical timeline:

• Weeks 1–4: p=none, collect reports, fix alignment issues
• Weeks 5–6: p=quarantine; pct=10, watch for legitimate mail going to spam
• Weeks 7–8: Increase pct to 50, then 100
• Weeks 9+: Move to p=reject at pct=100

Use the pct tag to roll out incrementally. Per RFC 7489: “The purpose of the pct tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism.” Messages outside the pct percentage are treated as if the next-lower policy applies.

Ready-to-Copy Records for Each Phase

Phase 1: Monitoring (start here)

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Phase 2: Partial enforcement

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"

Phase 3: Full enforcement

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"

Replace [email protected] with an address you own that can receive email. If you want reports delivered to a mailbox on a different domain, that domain must publish a _dmarc verification record permitting it.

Common Mistakes That Break Mail Flow

Publishing two DMARC records. Only one TXT record at _dmarc.yourdomain.com is permitted. Receivers that encounter two records discard both entirely, leaving your domain with no policy.

Publishing the record at the wrong hostname. The record must go at _dmarc.yourdomain.com, not at yourdomain.com or dmarc.yourdomain.com. The underscore prefix is required.

Jumping to p=reject without reading reports. Legitimate mail will get blocked. Always start at p=none, review RUA reports, resolve alignment failures, then advance the policy through p=quarantine with a low pct value first.

No rua address. Without an RUA address, you receive no aggregate reports and can’t monitor what’s happening. Blind enforcement is dangerous. As dmarcian notes: “Having a DMARC record with policy enforcement yet no reporting to monitor the domain doesn’t give you the visibility you need.”

SPF or DKIM not aligned with the From domain. DMARC checks alignment, not just authentication. SPF can pass on the Return-Path while failing DMARC alignment if the Return-Path domain doesn’t match the From domain. DKIM must sign with a domain that matches the From domain. If you send through a third-party ESP, verify that it signs with your domain’s DKIM key and that the Return-Path subdomain belongs to your organization. Alignment failures often appear as 5.7.1 hard bounces; see Soft Bounce vs Hard Bounce to understand how to handle those in your suppression logic. For the broader picture of deliverability factors beyond DMARC, the email deliverability best practices guide covers the full stack.

Syntax errors in the record value. Per dmarc.org’s analysis of real-world records, common syntax mistakes include: missing v= prefix, using colons instead of semicolons as tag separators, and omitting mailto: before the RUA address. All of these cause receivers to treat the record as invalid.

Frequently Asked Questions