How to Setup DMARC: Complete Step-by-Step Configuration Guide (2026)

Email providers are no longer treating DMARC setup as a “nice-to-have” security measure. With Gmail, Yahoo, and Microsoft enforcing stricter authentication requirements, organizations that haven’t implemented DMARC risk permanent message rejection, increased spoofing attacks, and compliance challenges.

In this guide, you’ll learn how to set up DMARC from scratch, validate your SPF and DKIM configuration, publish a compliant DMARC record, and gradually move from monitoring mode to full enforcement. We’ll also cover the latest RFC 9989 updates, common configuration mistakes, and practical troubleshooting tips to help you deploy DMARC with confidence.

By the end of this DMARC setup guide, you’ll have a clear roadmap for securing your domain against spoofing attacks while ensuring legitimate email continues to reach the inbox.

2026 Compliance: Enforcement Is Live

Gmail & Yahoo (Nov 2025): Permanent 5xx rejection enforcement is live for bulk senders (5,000+ emails/day). Non-compliant messages are permanently rejected, not just filtered.

Microsoft Outlook (May 2025): SPF, DKIM, and DMARC enforcement active. Non-compliant mail faces deferrals and rejection.

PCI DSS v4.0 (March 2025): Anti-phishing controls required for all entities handling payment card data.

• CISA BOD 18-01: All U.S. federal agencies must deploy DMARC with p=reject policy.
• See full requirements: Global and Regional DMARC Requirements

What Is DMARC and How Does It Work?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that lets domain owners tell receiving mail servers what to do with messages that fail SPF and DKIM authentication checks. In plain terms, it prevents others from spoofing your domain and tells receivers how to handle impostors.

DMARC works on top of two existing protocols, SPF and DKIM. Together, the three form the foundation of modern email security.

DMARC, SPF, and DKIM: How They Work Together

SPF (Sender Policy Framework) authorizes which mail servers are allowed to send email from your domain. It’s a DNS record that says, “Only these IP addresses can send mail claiming to be from example.com.”

DKIM (DomainKeys Identified Mail) applies a cryptographic signature to your emails. It proves that the message came from you and hasn’t been modified in transit. The signature is verified using a public key published in your DNS.

DMARC ties them together. It says: “Here’s my policy. If an email claims to be from my domain, it must pass SPF or DKIM alignment. If it fails, here’s what I want you to do: none (monitor only), quarantine (send to spam), or reject (block entirely).”

Learn more about DMARC, SPF and DKIM in our comprehensive guide.

What Happens When an Email Fails DMARC?

When a receiver gets an email claiming to be from your domain, they check it against your DMARC policy. The outcome depends on your policy:

• p=none (monitoring): The email is delivered regardless of the result. You get a report showing what passed and what failed.
• p=quarantine: Failing emails are sent to the spam/junk folder. Legitimate mail still arrives.
• p=reject: Failing emails are rejected outright. The sender receives a bounce-back message.

Before You Set up DMARC: Prerequisites and Sender Inventory

Many organizations rush to deploy DMARC and move quickly to p=reject, only to discover that legitimate senders (CRM, ESP, helpdesk, marketing automation platforms) are being blocked. This section walks you through the audit process to prevent that costly mistake.

Step 1: Verify SPF Is Published for Your Domain

Your domain must have a valid SPF record in DNS before DMARC can work.

1. Use our SPF Checker to verify your SPF record exists.

2. Confirm that exactly one SPF TXT record exists for your domain. Having two SPF records breaks SPF as receivers will ignore both.

3. The record should look something like: v=spf1 include:sendgrid.net include:mailchimp.com ~all

If SPF is not published or there are two conflicting records, fix this first before proceeding. Use our free tool to create your SPF record now.

Step 2: Check the SPF 10-Lookup Limit

SPF allows a maximum of 10 DNS lookups per message evaluation. Each third-party sender you authorize (via include:) consumes 1-3 of these lookups. Exceeding the limit causes SPF to fail for some senders.

1. Use our SPF Checker to review your SPF record’s lookup count

2. Count the DNS lookups required. If you’re approaching or exceeding 10, you’ll see an error.

3. If you’re over the limit, use optimize your record to consolidate lookups by replacing include: statements with explicit IP addresses. This is a common blocker for large organizations with many third-party senders.

Step 3: Verify DKIM Is Configured for All Senders

DKIM is required by Google, Yahoo, and Microsoft for bulk senders, it’s not optional.

1. For your primary domain: use our free DKIM Checker to confirm your DKIM record is published.

2. For each third-party sender (Salesforce, HubSpot, Klaviyo, etc.): confirm they have enabled DKIM signing and published their public key as a DNS record. This typically requires asking the vendor to “enable custom DKIM for your domain.”

3. Each sender should have a unique DKIM selector (e.g., k1._domainkey.example.com, sendgrid._domainkey.example.com).

If DKIM is missing, configure it now before moving to DMARC enforcement. Use our free tool to generate a DKIM record for your domain.

Step 4: Inventory All Third-Party Email Senders

Create a list of every service that sends email from your domain:

• ESPs (SendGrid, Mailchimp, Klaviyo, etc.)
• CRM (Salesforce, HubSpot, Pipedrive, etc.)
• Helpdesk/support systems (Zendesk, Freshdesk, etc.)
• Marketing automation (Marketo, Pardot, ActiveCampaign, etc.)
• Transactional email platforms (Auth0, Stripe, AWS SES, etc.)
• Internal servers or applications sending notifications
• Forwarding services or mailing list managers

For each sender, verify:

1. They pass SPF alignment (included in your SPF record)
2. They pass DKIM alignment (DKIM signing enabled for your domain)
3. They are configured to use your domain in the From: header

Use our DMARC Report Analyzer to scan for unauthorized senders.

Step 5: Check Whether a DMARC Record Already Exists

Use our DMARC Checker to see if your domain already has a DMARC record.

• If you see p=none: Your domain is in monitoring mode. This guide helps you safely advance to enforcement.
• If you see deprecated tags (pct=, rf=, ri=): These are no longer part of the RFC 9989 standard and should be removed when you next edit the record.
• If no record found: You’re starting fresh. Proceed to the next section.

How to Setup DMARC: Step-by-Step

Step 1: Generate a DMARC Record

Use our DMARC Generator tool to create your initial record.

Required fields:

• Domain: Your domain (e.g., example.com)
• Policy: Start with p=none (monitoring mode, no enforcement)
• Reporting address: Email where you want to receive aggregate reports (e.g., [email protected])

Recommended additions:

• np=reject: Protects non-existent subdomains from spoofing (new in RFC 9989, zero cost)
• rua address: Aggregate report destination (critical for monitoring)

Example starting record:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

This record tells receivers: “Monitor emails from my domain and send me daily reports, but don’t block anything yet.”

Step 2: Understand Your DMARC Record Before Publishing

A DMARC record is a string of tag-value pairs separated by semicolons. Only v= and p= are required – everything else is optional but recommended. Before you publish, understand what each tag does:

Required Tags

Tag	Description & Rules
v= (version)	• Value: Always v=DMARC1 • Must be the first tag in the record • There is only one valid value
p= (policy)	• Values: none, quarantine, or reject • Tells receivers how to handle emails that fail DMARC checks • See policy table below for differences

Optional Tags

np= (non-existent subdomain policy)

• Values: none, quarantine, or reject
• Applies a policy to subdomains that don’t have a DMARC record
• Protects against spoofing of random subdomains (e.g., random123.example.com)
• Recommendation: Set np=reject for all domains. It costs nothing and closes a spoofing gap.

rua= (reporting address for aggregate reports)

• Format: rua=mailto:[email protected]
• Can include multiple addresses separated by commas: rua=mailto:[email protected],mailto:[email protected]
• Aggregate reports are XML summaries sent daily by receivers
• This is critical for monitoring. Without it, you have no visibility into your mail flow.

sp= (subdomain policy)

• Values: none, quarantine, or reject
• Applies a policy to subdomains that have a DMARC record
• If not specified, falls back to the main policy (p=)
• Use when you want stricter enforcement on subdomains (e.g., mail.example.com)

fo= (failure reporting options)

• Values: 0 (default), 1, d, s, or combinations (0:1:d:s)
• Controls when forensic (failure) reports are sent
• fo=0: Generate reports only if all auth mechanisms fail
• fo=1: Generate reports if any auth mechanism fails (more verbose, useful for setup phase)
• Typically used with the ruf= tag (see below)
• Recommendation: Use fo=1 during initial setup to catch all failures; switch to fo=0 once you’re confident in your alignment

adkim= (DKIM alignment mode)

• Values: r (relaxed, default) or s (strict)
• Relaxed: From domain and DKIM signing domain share the same organizational domain (e.g., mail.example.com and example.com align)
• Strict: Domains must match exactly
• Recommendation: Start with adkim=r (relaxed). Move to strict only after you control all signing sources.

aspf= (SPF alignment mode)

• Values: r (relaxed, default) or s (strict)
• Relaxed: From domain and SPF Return-Path domain share the same organizational domain
• Strict: Domains must match exactly
• Recommendation: Start with aspf=r. Move to strict only after you control all sending sources.

t= (test mode)

• Values: y (test mode on) or omitted (test mode off)
• When set to t=y, signals to receivers to apply your policy one level lower
• p=quarantine; t=y behaves like p=none to receivers
• p=reject; t=y behaves like p=quarantine to receivers
• This is the replacement for the deprecated pct= tag
• Use when advancing to a stricter policy: publish with t=y, monitor reports, then remove t=y to enforce

ruf= (forensic report address)

• Format: ruf=mailto:[email protected]
• Sends real-time copies of messages that fail authentication
• Important note: Google, Microsoft, and Yahoo no longer send forensic reports (as of RFC 9989). This tag is safe to include but won’t produce reports from major receivers.
• Include only if you have an automated system to process forensic reports

Deprecated and Removed Tags (RFC 9989)

These tags were part of RFC 7489 but are no longer part of the standard. Do not add them to new records. If they appear in existing records, remove them at your next DNS edit.

pct=

• Was used to apply policy to a percentage of failing messages
• Produced inconsistent results across receivers
• Replacement: Use t=y for staged rollout instead
• If still in old records, it will be ignored by RFC 9989-compliant receivers

rf=

• Was the failure report format tag (only ever used one value: afrf)
• Removed because modern reporting uses a different mechanism

ri=

• Was the report interval tag
• Removed because reporting intervals are now standardized

Step 2: Log In to Your DNS Provider

Log in to your DNS management console (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53, etc.).

Step 3: Add the DMARC Record by DNS Provider

Find the option to add a new TXT record, copy paste the value from the tool, and hit the Save icon.

The process is the same across all providers: add a new TXT record, set the name to _dmarc, paste your record as the value, and save.Provider-specific navigation paths and the most common gotcha for each are in the table below.

Step 5: Wait for DNS Propagation

DNS changes can take up to 48 hours to propagate globally, but most DNS providers propagate within 1-2 hours. To monitor propagation in real-time, you can use our DNS Propagation Checker. Simply enter your domain and look for the _dmarc TXT record.

Step 6: Verify Your DMARC Setup Is Live

Once DNS propagation is complete, verify your record using our DMARC Checker tool.

1. Enter your domain name
2. Click Lookup
3. You should see your record displayed with all tags parsed
4. If the checker shows “DMARC record found” with your policy, you’re live

If you see errors or the record isn’t found after 48 hours, review your DNS entry for syntax and configuration errors.

Setting Up DMARC Under RFC 9989 – What Changed in 2026

In May 2026, the IETF published RFC 9989, replacing RFC 7489 as the official DMARC standard. Your existing v=DMARC1 records remain fully valid, so there is no emergency migration required. However, three changes affect anyone configuring DMARC today.

What RFC 9989 Means for Your DMARC Setup

1. pct= is now deprecated

The pct= tag was used to apply policy to a percentage of failing messages. It produced inconsistent results across receivers and is no longer part of the standard.

Action: Remove pct= from any new records. If older records contain it, remove it at your next DNS edit. Receivers will ignore it, but it adds confusion.

2. np= is new

The np= tag (non-existent subdomain policy) allows you to protect subdomains that don’t exist. Attackers can spoof random subdomains (e.g., random123.example.com) to evade DMARC checks. Setting np=reject closes this gap at zero cost.

Action: It’s optional, but you can choose to add it to all new records.

3. t=y is the new way to stage policy changes

The t=y tag signals to receivers to apply your policy one level lower than declared. This lets you test a stricter policy before committing to enforcement.

• p=quarantine; t=y behaves like p=none (receivers don’t quarantine; they deliver and report)
• p=reject; t=y behaves like p=quarantine (receivers quarantine instead of rejecting)

Action: When advancing from p=none to p=quarantine or p=reject, use t=y first. Monitor reports for 1-2 weeks. Once confident, remove t=y to enforce.

How to Use t=y for Staged Rollout

Here’s the exact workflow:

1. Current state:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. When you are ready to test quarantine, publish:

v=DMARC1; p=quarantine; t=y; np=reject; sp=quarantine; rua=mailto:[email protected]

Receivers treat this as p=none, they deliver everything and report. You observe for 1–2 weeks.

3. Confirm that no legitimate mail was affected, then remove t=y to enforce:

v=DMARC1; p=quarantine; np=reject; sp=quarantine; rua=mailto:[email protected]

4. Now failing mail goes to spam, while legitimate mail is unaffected.

5. Once you are ready to test the reject policy, publish:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

6. Receivers treat this as p=quarantine. You need to observe for 1–2 weeks.

7. Final enforcement: Remove t=y:

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

8. Full rejection is now active.

If something breaks at any step: Remove t=y, drop back one policy level, fix the failing sender, then re-advance.

How to Safely Advance Your DMARC Policy

Most DMARC failures happen because organizations skip to p=reject without verifying their mail flow first. Legitimate mail gets blocked, users complain, and the domain owner rolls back in a panic. This section walks you through the right approach: a three-phase rollout that uses aggregate reports to build confidence before each step.

Note: RFC 9989 explicitly states that receivers must treat p=reject as p=quarantine for indirect mail flows (forwarding, mailing lists). For domains whose users participate in mailing lists, p=quarantine is the safer permanent enforcement policy. For pure transactional or marketing-only domains with no user mailboxes, p=reject is appropriate.

Phase 1: Monitor (p=none)

Duration: 2-4 weeks minimum. Longer for complex sending environments (10+ third-party senders).

What your record looks like:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

What to do:

1. Publish the record above

2. Wait for receivers to send aggregate reports (typically start within 24–48 hours)

3. Use our DMARC Report Analyzer to review daily reports

4. Look for:

• All known sending sources appearing in reports
• SPF and DKIM pass rates for each sender
• Any unknown senders you don’t recognize
• Alignment status (are your senders passing or failing alignment?)

When to advance:

• All legitimate senders are passing SPF or DKIM
• No unknown sources in reports
• You’ve observed at least 2 weeks of consistent data
• You’ve fixed any failing senders

If you are new to DMARC reports, refer to our guide on how to read DMARC reports for a simplistic walkthrough.

Phase 2: Quarantine (p=quarantine)

Duration: 1-2 weeks with t=y (test mode), then ongoing.

Step A: Test with t=y (dry run)

Publish:

v=DMARC1; p=quarantine; t=y; np=reject; sp=quarantine; rua=mailto:[email protected]

With t=y, receivers apply the policy one level lower: quarantine behaves like none. Failing mail still gets delivered; you just get reports showing what would have been quarantined.

Monitor for 1–2 weeks. Check reports and monitor your inbox. Look for:

• Legitimate mail still arriving
• Failure reports showing which senders would be affected
• Normal spam complaint rates

Step B: Enforce (remove t=y)

Once you’re confident, remove t=y:

v=DMARC1; p=quarantine; np=reject; sp=quarantine; rua=mailto:[email protected]

Now failing mail goes to spam. Legitimate mail continues to arrive normally.

Ongoing monitoring:

• Review aggregate reports weekly
• Monitor spam folder for legitimate mail
• If legitimate senders start failing: immediately drop back to p=none, fix the alignment issue, then re-advance

BIMI eligibility note: If you want to use BIMI (Brand Indicators for Message Identification) to display your logo in Gmail, you must have p=quarantine or p=reject. p=none is not eligible. This adds urgency to advancing policy. Here’s how to Enable BIMI for your domain.

Phase 3: Reject (p=reject)

Duration: 1-2 weeks with t=y, then ongoing.

Step A: Test with t=y (dry run)

Publish:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

With t=y, receivers treat reject as quarantine. Failing mail goes to spam, not rejected outright. Monitor for 1-2 weeks.

Step B: Enforce (remove t=y)

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

Now failing mail is rejected outright. The sender gets a bounce message.

Policy recommendations:

• If your domain has human mailboxes whose users are on mailing lists (NAR, MLS, association lists, etc.), use p=quarantine as your enforcement policy.
• If your domain is transactional-only (SaaS, payments, fintech, marketing emails with no user mailboxes): use p=reject.

DMARC Setup Troubleshooting: Common Issues and Fixes

Issue 1: “No DMARC Record Found” When Checking

Why it happens: DNS propagation is not yet complete, or you entered the hostname incorrectly.

How to fix it:

1. Wait 24-72 hours after publishing
2. Double-check that the hostname is exactly _dmarc (not _dmarc.yourdomain.com in some tools, check your specific provider)
3. Use our DNS Propagation Checker to verify propagation status
4. Try our DMARC Checker again

Issue 2: SPF and DKIM Not Aligned

Why it happens: The domain in the From: header doesn’t match the domain authenticated by SPF or DKIM.

Example failure:

• From: header says [email protected]
• SPF authenticated domain is mail.otherdomain.com
• DKIM signing domain is newsletter.anotherdomain.com
• Result: No alignment. DMARC fails.

How to fix it:

1. Start with relaxed alignment (adkim=r; aspf=r) in your record. This allows subdomain matches.

2. Use our DKIM Checker to verify each sender’s signing domain

3. Use our SPF Checker to verify each sender’s SPF inclusion

4. For each failing sender, ask the vendor to configure the domain. For example:

• “Please enable DKIM signing for the domain example.com (not a subdomain)”
• “Please use example.com in the Return-Path/envelope-from domain”

5. Once all senders pass with relaxed alignment, you can move to strict (adkim=s; aspf=s) if desired

Issue 3: Third-Party Sender Failing Authentication

Why it happens: An ESP, CRM, or marketing platform is sending email from your domain but is not configured in your SPF record and/or doesn’t have DKIM enabled.

How to fix it:

For SPF failures:

1. Get the sender’s SPF include from their documentation (e.g., include:sendgrid.net)

2. Add it to your SPF record: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Test with our SPF Checker

For DKIM failures:

1. Ask the vendor to enable custom DKIM for your domain

2. Publish the DKIM public key they provide (usually in format: selector._domainkey.yourdomain.com)

3. Test with our DKIM Checker

Issue 4: Multiple SPF Records or SPF Over 10-Lookup Limit

1. More than one SPF records: Having two SPF TXT records on the same domain breaks SPF entirely, and receivers will ignore both.

How to fix it: Merge your SPF records into one, since you can only have a single SPF TXT record per domain.

Example:

• Old Record 1: v=spf1 include:sendgrid.net ~all
• Old Record 2: v=spf1 include:mailchimp.com ~all
• New Merged Record: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Over 10 DNS lookups: Each include: can require 1-3 DNS lookups. If you exceed 10, SPF fails for some senders.

How to fix it: Use our hosted SPF to dynamically optimize your record. This replaces include: statements with explicit IP addresses, reducing lookups.

Example:

• Before (10+ lookups): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• After optimization: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Issue 5: Legitimate Mail Going to Spam After p=quarantine

Why it happens: You advanced to p=quarantine before verifying all legitimate senders pass authentication.

How to fix it:

1. Drop back to p=none immediately
2. Review your aggregate reports to identify which sender is failing
3. Fix their authentication (SPF or DKIM alignment)
4. Re-advance to p=quarantine but test with t=y and monitor for 1-2 weeks before enforcing

Issue 6: DMARC Record Syntax Errors

Why it happens: Typo in the record, missing semicolons, or unsupported tags

How to fix it:

1. Validate with our DMARC Checker as it will show syntax errors
2. Use our DMARC Generator to rebuild the record rather than editing manually
3. Copy the generated record and paste it into your DNS provider

Final Words

Configuring DMARC correctly is no longer optional. Gmail’s permanent rejection enforcement, Yahoo and Microsoft’s requirements, PCI DSS v4.0 recommendations, and CISA BOD 18-01 all make DMARC a compliance necessity.

The safe, reliable path is to move slowly, verify continuously and enforce responsibly. But if you want faster, easier DMARC management with automated report processing, compliance monitoring, and ongoing support, consider a hosted DMARC platform like PowerDMARC that handles setup, scaling, and enforcement so you can focus on security. Start your free trial today or book a demo to secure your domain now.

Frequently Asked Questions

How long does DMARC setup take?

Initial DNS record setup takes minutes. DNS propagation takes up to 72 hours (usually 1-2 hours). Full enforcement (reaching p=reject with confidence) typically takes 4-8 weeks, depending on the number of sending sources and how quickly alignment issues are resolved.

Does DMARC setup affect email deliverability?

At p=none, there is zero delivery impact on deliverability, since monitoring mode has no enforcement. At p=quarantine or p=reject, only unauthenticated and misaligned mail is affected. Properly authenticated mail is not impacted and often sees improved deliverability. DMARC can improve inbox placement long-term by establishing domain reputation with inbox providers.

How do I set up DMARC for multiple domains?

When setting up DMARC for multiple domains, remember that each domain needs its own DMARC TXT record at _dmarc.[domain].

Example:

• Domain 1: _dmarc.example.com TXT record
• Domain 2: _dmarc.example.org TXT record

For organizations managing many domains, a hosted DMARC platform manages all records from one dashboard, making scaling easy.

What is DMARC alignment?

Alignment means the domain in the From: header must match the domain authenticated by SPF or DKIM. Relaxed alignment (the default, adkim=r; aspf=r) allows organizational domain matches, whereas strict alignment (adkim=s; aspf=s) requires exact matches.

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• How to Setup DMARC: Complete Step-by-Step Configuration Guide (2026) - June 20, 2026
• How to Read DMARC Reports: A Complete Guide to RUA & RUF - June 10, 2026
• What Is DMARC? Definition, How It Works, and Why It Matters - April 28, 2026