DMARC Policy Guide: none, quarantine, reject

A DMARC policy tells receiving email servers what to do when an email fails authentication. You have three options: p=none (monitor and report, but deliver all email), p=quarantine (send failing email to spam), or p=reject (block failing email entirely). Most organizations start at p=none for visibility, then progress to p=reject for full protection.

This guide explains each policy option, when to use them, and how to move from monitoring to enforcement without breaking your legitimate email.

---

Let’s be honest: email authentication is complicated. If you’ve landed on this guide, you’re probably staring at a DMARC record wondering what all those tags mean, or you’ve been told your “DMARC policy not enabled” and you’re not sure what that actually means for your organization.

Here’s the reality. Setting up a DMARC policy isn’t a five-minute task you check off and forget. It’s a process that requires understanding your email ecosystem, coordinating with vendors, and making deliberate decisions about how aggressively you want to protect your domain. But it’s absolutely worth doing, and this guide will walk you through it step by step.

Understanding DMARC Policy

What is DMARC Policy?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The “policy” part is the instruction you publish in DNS that tells receiving mail servers what to do when an email claiming to be from your domain fails authentication checks.

Think of it this way: SPF and DKIM are the authentication mechanisms that verify whether an email is legitimate. DMARC is the enforcement layer that says, “If authentication fails, here’s what I want you to do about it.”

Your DMARC policy lives in a DNS TXT record at _dmarc.yourdomain.com. A basic record looks like this:

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

The p= tag is your policy. That’s what we’re here to talk about.

Importance of DMARC in Email Security

Without DMARC, anyone can send email that appears to come from your domain. Phishing attacks, business email compromise, and brand impersonation all exploit this gap. Your customers, partners, and employees receive fraudulent emails that look legitimate because there’s no mechanism telling mail servers to reject them.

DMARC enforcement changes that equation. When you reach p=reject, you’re telling every receiving mail server on the internet: “If an email claims to be from my domain and it doesn’t pass authentication, don’t deliver it. Period.”

The numbers tell the story. Countries that have mandated DMARC for government domains have seen phishing success rates drop from 69% to 14%. That’s not a minor improvement. That’s a fundamental shift in how effective email-based attacks can be against your organization.

Beyond security, DMARC is increasingly a deliverability requirement. Google and Yahoo now require DMARC for bulk senders. PCI DSS 4.0 mandates it for payment processors. If you’re sending significant email volume, DMARC isn’t optional anymore. See our guide on what counts as a bulk sender to understand the thresholds.

DMARC Policy Options

Policy	Action on Failure	Protection Level	When to Use
p=none	Deliver normally	None (monitoring only)	Starting out, discovering senders
p=quarantine	Send to spam folder	Medium	Testing enforcement, cautious rollout
p=reject	Block delivery	Full	Production enforcement, maximum protection

You have three choices for your DMARC policy. Each represents a different level of protection and a different level of risk if you haven’t properly configured your email authentication.

DMARC Monitoring Policy (p=none)

A bare-minimum monitoring record:

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

A realistic monitoring record that you’d actually publish at week one — with subdomain coverage, both aggregate and forensic reporting, and explicit alignment modes:

v=DMARC1; p=none; sp=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100; ri=86400

What each tag does, in plain terms:

• p=none — main domain policy: monitor only.
• sp=none — subdomain policy: also monitor only. Without this, subdomains inherit p once you move to enforcement, which can break unauthenticated subdomain mail before you’re ready.
• rua=mailto:... — where aggregate reports go. Use a dedicated mailbox or a reporting service inbox.
• ruf=mailto:... — where forensic (failure) reports go. Many large receivers (Gmail, Microsoft) don’t send these for privacy reasons, so don’t rely on them.
• fo=1 — forensic options: send a forensic report when either SPF or DKIM fails. The default fo=0 only fires when both fail, which misses most useful events.
• adkim=r / aspf=r — relaxed alignment, the default. Tighten to s only after you’ve verified every legitimate sender uses an exactly-matching domain.
• pct=100 — apply policy to 100% of messages. Has no effect at p=none but is good hygiene to keep set.
• ri=86400 — request reports every 86,400 seconds (24 hours). Most receivers ignore this and use their own schedule, but it documents intent.

The p=none policy is monitoring mode. You’re telling receivers: “Check authentication, send me reports about the results, but don’t take any action on failures.”

This is where every organization should start. Not because it’s safe, but because it’s necessary. You need visibility into who’s sending email as your domain before you can make enforcement decisions.

Here’s what p=none gives you:

• Aggregate reports showing authentication results for all email claiming to be from your domain (see our guide to understanding DMARC reports)
• Visibility into legitimate senders you may have forgotten about (that marketing platform from three years ago, the CRM your sales team set up)
• Time to fix authentication issues before they cause delivery problems

What p=none doesn’t do is protect you. Spoofed emails still get delivered. You’re just watching it happen with better data.

DMARC Quarantine Policy (p=quarantine)

A simple quarantine record:

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]

A realistic gradual-rollout quarantine record — typically what you publish in week 9 of a typical migration when you want to start enforcing on a slice of failing mail:

v=DMARC1; p=quarantine; pct=25; sp=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r

Note the pct=25: only 25% of failing messages get quarantined; the other 75% are still treated as p=none (delivered normally with reports). This is the safest way to discover whether your authentication is actually ready before you flip the switch on every legitimate-but-misconfigured sender. Roll pct from 25 → 50 → 75 → 100 over 2–4 weeks based on what your reports show.

sp=none is intentional here too — keep subdomains in monitoring mode until you’ve completed enforcement on the parent domain.

The p=quarantine policy tells receivers to treat failing emails as suspicious. In practice, this usually means sending them to spam or junk folders rather than the inbox.

Quarantine is the intermediate step. You’re saying: “I’m confident enough in my authentication setup to start taking action, but I want a safety net in case something’s misconfigured.”

Some organizations stay at quarantine permanently. Others use it as a stepping stone to full enforcement. The right choice depends on your risk tolerance and how mission-critical your email deliverability is.

The pct= tag lets you apply the policy to only a percentage of failing messages. Setting pct=25 means quarantine only 25% of failures while the rest are treated as p=none. This gives you a way to test enforcement gradually.

DMARC Reject Policy (p=reject)

A simple reject record:

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

A production-grade reject record — full enforcement on parent and subdomains, with reporting kept on for ongoing monitoring:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r

Notice forensic reporting (ruf) is dropped here. Once you’re at full enforcement, forensic reports rarely add information you don’t already have from aggregate reports, and the privacy/storage overhead isn’t worth it. Keep fo=1 for the same reason — it only matters if ruf is set.

sp=reject means subdomains also enforce. If you have a marketing subdomain that hasn’t completed authentication, change this to sp=quarantine or sp=none until that subdomain catches up. Don’t leave sp= unset at this stage — without it, subdomains inherit p=reject, which is usually what you want, but being explicit prevents surprises.

The p=reject policy is full enforcement. Emails that fail DMARC authentication don’t get delivered at all. They’re blocked before they reach any folder.

This is the destination. This is what actually stops spoofing. Everything before this is just preparation.

Reaching p=reject requires confidence that:

1. All legitimate email sources are properly authenticated
2. Your SPF record includes every service that sends as your domain
3. DKIM is configured for all sending sources
4. You’ve reviewed enough report data to know there aren’t surprises waiting

The fear most organizations have is blocking their own legitimate email. That fear is valid. It’s also why the monitoring and quarantine phases exist. If you do the work to get your authentication right, the move to reject is straightforward.

The BIMI Reward

There’s another benefit to reaching enforcement that most guides don’t mention: BIMI eligibility.

BIMI (Brand Indicators for Message Identification) displays your brand logo in recipients’ inboxes. Gmail, Yahoo, and Apple Mail all support it. But BIMI requires DMARC at p=quarantine or p=reject. Without enforcement, email clients won’t even look at your BIMI record.

Think of BIMI as the reward for completing the enforcement journey. You’ve done the work to authenticate your email properly. Now your logo appears next to your messages, building brand recognition and trust.

See our BIMI Setup Guide to implement it once you’ve reached enforcement.

Subdomain Policy (sp=)

The sp= tag sets the policy for subdomains that don’t have their own DMARC record. By default, subdomains inherit the main domain’s policy.

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

Common configurations:

• sp=none — Monitor subdomains while enforcing on the main domain (useful during rollout)
• sp=quarantine — Less aggressive policy for subdomains that may have authentication gaps
• sp=reject — Same protection level across all subdomains

If your organization uses subdomains for different teams or purposes (marketing.example.com, support.example.com), consider whether they need different treatment during your enforcement journey.

See our guide to DMARC for subdomains for detailed configuration options.

Steps to Implement DMARC Policy

Setting Up Your DMARC Record

Before you create a DMARC record, you need SPF and DKIM in place. DMARC builds on these protocols. If you haven’t configured them yet, start there. See our guides for Google Workspace and Microsoft 365 if you’re using those platforms.

You can check your current setup with our email authentication checker to see what’s already in place.

Step 1: Create your initial DMARC record

Start with monitoring mode:

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

The rua tag specifies where aggregate reports should be sent. Use an email address you actually monitor, or better yet, use a DMARC reporting service that can parse and visualize the data.

Step 2: Add the DNS record

Create a TXT record with:

• Host/Name: _dmarc
• Value: Your DMARC record string
• TTL: 3600 (1 hour) is reasonable

Step 3: Wait for reports

DMARC reports typically arrive within 24-48 hours, though some reporters take longer. You need at least 2-4 weeks of data before making policy decisions.

Step 4: Analyze and fix

Review your reports to identify:

• Legitimate senders failing authentication (fix these)
• Unknown senders (investigate whether they’re legitimate or spoofing)
• Spoofing attempts (these will be blocked once you enforce)

Step 5: Progress to enforcement

Once your pass rates are consistently above 95% and you’ve authorized all legitimate sources, you’re ready to move to quarantine and eventually reject.

Use our DMARC checker to verify your record is properly configured at each step.

Using a DMARC Policy Generator

Writing DMARC records by hand works, but it’s easy to make syntax errors that break the entire record. A DMARC policy generator helps you create valid records with the right tags for your situation.

A good generator should:

• Validate your syntax before you publish
• Explain what each tag does
• Warn you about common misconfigurations
• Support advanced options like forensic reporting (ruf), subdomain policies (sp), and alignment modes

The most important thing isn’t which generator you use. It’s that you understand what the generated record does before you publish it to DNS.

DMARC Alignment and Its Significance

DMARC alignment is the concept that trips up most people new to email authentication. Here’s what it means in plain terms.

When an email arrives, there are multiple “from” addresses involved:

• The Header From (what recipients see in their email client)
• The Envelope From (used by SPF, often called Return-Path or Mail From)
• The DKIM domain (the domain in the d= tag of the DKIM signature)

DMARC requires alignment between the Header From domain and at least one of the authenticated domains (SPF or DKIM). Without alignment, authentication can pass but DMARC still fails.

Relaxed alignment (the default) requires the organizational domains to match. So mail.example.com aligns with example.com.

Strict alignment requires exact domain matches. mail.example.com would not align with example.com.

Most organizations use relaxed alignment. Strict alignment is more secure but breaks many legitimate email flows, especially with third-party senders.

You can check alignment in your DMARC record with:

• adkim=r (relaxed DKIM alignment, the default)
• adkim=s (strict DKIM alignment)
• aspf=r (relaxed SPF alignment, the default)
• aspf=s (strict SPF alignment)

If you’re seeing DMARC failures despite SPF and DKIM passing, alignment is usually the culprit. Use our SPF checker and DKIM checker to verify your records are set up correctly.

DMARC Reporting and Monitoring

Understanding DMARC Reports

DMARC generates two types of reports:

Aggregate reports (rua) are XML files summarizing authentication results over a time period (usually 24 hours). They show:

• Sending IP addresses
• Message counts
• SPF and DKIM results
• Policy applied
• Disposition (none, quarantine, reject)

These reports are essential for understanding your email ecosystem. They’re also nearly unreadable in raw XML format. You’ll want a tool that parses and visualizes them. Read our complete guide to understanding DMARC reports for detailed analysis tips.

Forensic reports (ruf) contain details about individual failing messages. They’re useful for investigating specific issues but raise privacy concerns since they may include message content. Many large receivers don’t send forensic reports at all.

Start with aggregate reports only:

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

Add forensic reports later if you need them:

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

DMARC Dashboard Overview

Raw DMARC reports are XML files that look like this:

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

A proper DMARC dashboard transforms this data into something actionable:

• Pass rates over time showing your authentication health
• Source identification revealing who’s sending as your domain
• Failure analysis breaking down why messages are failing
• Trend monitoring alerting you to sudden changes

The goal of a dashboard isn’t just visibility. It’s answering the question: “Am I ready to move to a stricter policy?” If your pass rate is 97% but 3% of failures represent thousands of legitimate emails from a vendor you haven’t configured, you’re not ready.

Troubleshooting Common DMARC Issues

554 5.7.5 Permanent Error Evaluating DMARC Policy

The 554 5.7.5 permanent error evaluating DMARC policy message means the receiving server tried to check your DMARC record and encountered a problem it couldn’t recover from.

Common causes:

DNS issues

• Your DMARC record doesn’t exist or hasn’t propagated
• Multiple DMARC records (you should only have one)
• DNS server timeouts

Syntax errors in your DMARC record

• Missing required tags (v=DMARC1 must be first)
• Invalid characters or formatting
• Typos in tag names (p=quaratine instead of p=quarantine)

Cascading failures

• SPF record with syntax errors causing permerror
• DKIM signature validation failures due to key rotation issues

To diagnose, start by checking your DMARC record with our DMARC checker. Then verify your SPF and DKIM records are valid.

The 5.7.5 permanent error evaluating DMARC policy variant without the 554 prefix indicates the same class of problem. The prefix just indicates it occurred during the SMTP conversation rather than later processing.

DMARC Policy Not Enabled Errors

Seeing “DMARC policy not enabled” or “DMARC quarantine/reject policy not enabled” usually means one of two things:

You don’t have a DMARC record at all

Check _dmarc.yourdomain.com for a TXT record. If nothing’s there, you need to create one.

Your policy is set to p=none

Technically, you have DMARC configured. But p=none is monitoring only. It doesn’t provide protection. Security scanners and compliance tools flag this because you’re not actually enforcing authentication.

If you see “DMARC quarantine reject policy not enabled,” this specifically means you’re at p=none and haven’t moved to an enforcing policy. The fix is to progress through the implementation steps we covered earlier.

The related message “DMARC quarantine/reject policy not enabled” (with the slash) means the same thing. Different tools phrase it differently, but the underlying issue is identical.

Best Practices for DMARC Enforcement

Regularly Checking DMARC Policy

DMARC isn’t set-and-forget. Your email ecosystem changes over time:

• New vendors start sending as your domain
• Marketing tools get added or removed
• Acquisitions bring new domains and sending infrastructure (consider using Verkh’s multi-domain dashboard to manage authentication across your domain portfolio)
• Certificate rotations affect DKIM

Build a habit of reviewing your DMARC reports at least monthly. Watch for:

• New sending sources you don’t recognize
• Declining pass rates
• Spikes in message volume from unknown IPs
• Changes in which receivers are sending you reports

Automate what you can. Alerts for sudden drops in pass rate or new high-volume senders catch problems before they become emergencies.

Use our tools to periodically verify your DNS records haven’t drifted from their intended configuration.

Ensuring DMARC Quarantine/Reject Policy is Enabled

Moving to enforcement requires confidence, and confidence comes from data. The data trigger is the same at every stage: pass rate consistently above 95%, zero unauthorized senders for the prior 30 days, and every known legitimate sender authenticated and aligning. See the full migration timeline below for the week-by-week sequence.

The timeline varies based on organization complexity. A small business with one email provider might move to enforcement in two weeks. An enterprise with dozens of sending sources across multiple business units might take six months. The important thing is making progress on the data triggers, not hitting calendar deadlines.

Common DMARC Pitfalls (and How to Fix Them)

These are the failure patterns that show up over and over again in real DMARC migrations. Each one has wrecked a real organization’s email at some point.

1. Jumping straight to p=reject without monitoring

The failure pattern: A consultant or auditor tells you “you need DMARC enforcement,” so you publish v=DMARC1; p=reject directly. The next morning, the CEO can’t send mail through her phone’s IMAP client, the CFO’s QuickBooks invoices vanish, and the marketing team’s Mailchimp campaign returns 60% bounces.

Why it happens: You’ve never authenticated mail from your phone-side SMTP server, your accounting software, or your ESP. Without p=none first, you have zero data on which legitimate sources will fail.

Fix: Always start at p=none for at least 4 weeks. Use the reports to enumerate every legitimate sender before you tighten the policy. The stuck-at-p=none readiness gate is the data point that tells you it’s safe to move.

2. p=quarantine with no rampup destroys CFO email

The failure pattern: You move from p=none directly to p=quarantine; pct=100. Within hours, the finance team’s Concur expense reports, DocuSign envelopes from outside counsel, and webhook receipts from your billing provider all land in spam.

Why it happens: A handful of high-importance, low-volume senders (legal, finance, audit, vendor portals) authenticate inconsistently. They never showed up loudly in your aggregate reports because their volume was small, but they’re business-critical.

Fix: Roll pct gradually: 25 → 50 → 75 → 100 over 2–4 weeks. Watch the reports between each step for new failure sources before advancing. See the migration timeline below.

3. SPF flattening that breaks on the next vendor add

The failure pattern: You hit the SPF 10-DNS-lookup limit, “flatten” your SPF record by inlining all the IPs from include: directives, and your DMARC pass rate stabilizes. Three months later, your ESP rotates IPs, and 30% of marketing email starts failing SPF — but DKIM still passes, so DMARC still passes, so you don’t notice until your unsubscribe rate spikes.

Why it happens: Flattened SPF records are static snapshots. The vendor’s actual IP space is dynamic. The flatten breaks silently the moment a vendor adjusts infrastructure.

Fix: Don’t flatten SPF as a long-term solution. See SPF permerror: meaning and fix and how to flatten SPF records for the right ways to stay under the lookup limit. If you must flatten, automate refreshes weekly and monitor include: health.

4. Two SPF records on the same domain

The failure pattern: Marketing publishes v=spf1 include:mailchimp.net ~all for their campaigns. IT, unaware, publishes v=spf1 include:_spf.google.com ~all for Workspace. Both records exist as TXT records on the apex. Every receiver returns SPF permerror, and DMARC fails for everything.

Why it happens: SPF requires one record per domain. RFC 7208 says multiple records produce permerror, full stop. DNS UIs make it easy to create a second TXT record without realizing the first one was SPF.

Fix: Merge into a single record. See Can I have two SPF records? for the merge process.

5. Forgetting subdomains during enforcement

The failure pattern: You move to p=reject on your apex domain. Email from news.yourdomain.com (your marketing newsletter subdomain) starts bouncing because nobody set up DKIM there, and sp was unset, so subdomains inherited p=reject.

Why it happens: Without an explicit sp= tag, subdomains inherit the parent’s p= value. Marketing newsletters often run on subdomains with their own authentication setup that lags the apex.

Fix: Set sp= explicitly. While the apex is at p=reject, set sp=none or sp=quarantine for any subdomain that hasn’t completed its own enforcement. See DMARC for subdomains explained for the full breakdown.

6. BIMI prerequisites that only kick in at p=reject (or quarantine pct=100)

The failure pattern: You publish a BIMI record, set up an SVG and VMC certificate, and… the logo never appears. Gmail still shows initials.

Why it happens: BIMI requires DMARC at p=quarantine; pct=100 or p=reject. At any softer policy — including p=quarantine; pct=99 — Gmail and Yahoo don’t display the logo. They check the policy field and silently skip BIMI rendering otherwise.

Fix: Reach full enforcement first. Then validate your BIMI setup with the BIMI SVG checker and the BIMI complete guide.

7. Forwarders that strip DKIM signatures

The failure pattern: Internal emails from your CEO to a board member who forwards to a Gmail alias suddenly fail DMARC. The CEO’s mail otherwise authenticates fine.

Why it happens: Some forwarders rewrite headers or modify message bodies, which invalidates the DKIM signature. SPF also fails because the forwarder’s IP isn’t in your SPF. Both fail, DMARC fails, mail gets quarantined or rejected.

Fix: This is what ARC (Authenticated Received Chain, RFC 8617) was designed for. Most major receivers now honor ARC. Otherwise, see why email forwarding breaks DMARC for mitigations.

8. DKIM key rotation that breaks alignment

The failure pattern: Your ESP rotates DKIM keys (Mailchimp does this regularly, others on a schedule), and overnight your DKIM pass rate for marketing email collapses to zero.

Why it happens: Either your DNS hasn’t been updated with the new public key, or the selector changed and you didn’t republish. Authentication fails wholesale on that source.

Fix: Either use ESP-managed DKIM (where the ESP owns the DNS via CNAME delegation) or set up automated DNS-key rotation. See common DKIM mistakes and how often to rotate DKIM keys.

9. Strict alignment (adkim=s, aspf=s) on a third-party-heavy domain

The failure pattern: Someone on the security team publishes adkim=s; aspf=s thinking strict alignment is “more secure.” Half your transactional and marketing mail starts failing DMARC the same day.

Why it happens: Strict alignment requires the Header From domain to exactly match the SPF/DKIM domain. Third-party senders almost never use exact-matching domains — Mailchimp DKIM-signs as dkim.mailchimp.com and SPF-passes as mailchimp.net. Both are aligned under relaxed mode, neither under strict.

Fix: Stay on relaxed alignment (adkim=r; aspf=r, the default) unless you’ve audited every sender and know strict will pass. The marginal security gain almost never justifies the deliverability cost.

10. Missing or wrong rua mailbox

The failure pattern: You publish rua=mailto:[email protected], but that mailbox doesn’t exist or isn’t monitored. Reports fail to deliver. You think you have monitoring; you actually have nothing.

Why it happens: The mailbox was never created, or it was created but the auto-responder/forwarding configuration silently drops attachments. Some receivers will retry and then stop sending.

Fix: Use a real, monitored mailbox or a dedicated DMARC reporting service. Test with the DMARC checker, then verify reports actually arrive within 48 hours. If nothing comes, the mailbox is broken.

11. ruf= reports leaking message bodies

The failure pattern: You publish ruf=mailto:[email protected] and receive failure reports that include partial message bodies — including some legitimate internal messages flagged as misaligned. Compliance is now asking why customer email content is in your DMARC reports inbox.

Why it happens: Forensic reports can include message headers and partial bodies, which may contain PII or regulated data. Most large receivers don’t send these for exactly this reason, but smaller receivers do.

Fix: Drop ruf= once you’re past the discovery phase, or scope the reporting mailbox under your compliance/PII handling policy. See rua vs ruf reports explained.

12. “DMARC pass” that’s actually only DKIM-aligned, not SPF

The failure pattern: Your reports show 99% DMARC pass and you move to p=reject. The next week, your ESP has an outage that breaks DKIM for two hours. SPF still passes — but it’s not aligned, because the ESP envelope-from is bounce.esp-domain.com, not your domain. DMARC fails on every message during the outage.

Why it happens: DMARC passes if either SPF or DKIM is aligned. If DKIM has been carrying alignment for an entire sender, you have a single point of failure. Reports look healthy until DKIM breaks.

Fix: Aim for both SPF and DKIM to be aligned for every major sender. Use the DMARC checker plus aggregate report analysis to see which senders are single-aligned.

Real-World DMARC Record Patterns by Organization Type

The “right” DMARC record varies more by organization than most guides admit. Here are four archetypes with the actual record you’d publish at full enforcement, plus the reasoning.

Pattern A: SaaS company, 3 marketing tools + 1 transactional ESP

A typical mid-market SaaS: Mailchimp for marketing, Customer.io for product emails, Intercom for in-product, and SendGrid for transactional. Plus Google Workspace for human-sent mail.

Final record (after 12-week migration):

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r

Reasoning:

• sp=reject is fine because there are no random subdomains in play — everything goes through the apex.
• Relaxed alignment is required because Customer.io and Mailchimp both DKIM-sign with their own subdomains under your DNS (e.g., cm.yourcompany.com).
• pct=100 only after you’ve verified all four senders pass for at least 4 consecutive weeks.

The trap to avoid: Adding a fifth sender (e.g., your sales team adopts Lemlist) without going back to p=quarantine; pct=25 for that subset. Vendor adds are the #1 cause of post-enforcement breakage.

Pattern B: Small nonprofit, Google Workspace + Mailchimp only

A 15-person nonprofit using Workspace for staff email and Mailchimp for the donor newsletter. No subdomains, no transactional services.

Final record:

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

Reasoning:

• Minimal record. No ruf, no explicit adkim/aspf (defaults are fine), no fo.
• sp=reject matches the apex because the org doesn’t use subdomains.
• Migration can be done in 4–6 weeks total because the sender list is small.

The trap to avoid: Forgetting that personal Gmail forwards (someone forwards their @yournonprofit.org to a personal Gmail) can break alignment after enforcement. ARC handles this for most receivers, but smaller mail providers may still mishandle forwarded mail. See the Google Workspace DMARC guide for forwarding mitigations.

Pattern C: Enterprise IT, Microsoft 365 + SendGrid + Salesforce + Marketo + 8 subdomains

A 5,000-person enterprise: M365 for staff, SendGrid for transactional, Salesforce for CRM email, Marketo for marketing automation, and a handful of subdomains for different business units.

Final record on apex:

v=DMARC1; p=reject; sp=quarantine; pct=100; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r

Per-subdomain record (where each business unit has different sender authority):

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; adkim=r; aspf=r

Reasoning:

• sp=quarantine (not sp=reject) is intentional. With 8 subdomains across business units, the risk of one subdomain having a forgotten sender is too high to enforce blanket reject inheritance. Quarantine gives a safety net.
• Each subdomain gets its own DMARC record so the BU owners can manage their own enforcement timeline. The marketing subdomain might reach p=reject six months after the support subdomain.
• fo=1 stays on because forensic visibility matters at enterprise scale.

The trap to avoid: Treating all subdomains as equal. The marketing subdomain should not be at the same policy stage as the IT subdomain — they have different sender complexity. See Microsoft 365 DMARC guide for M365-specific alignment quirks.

Pattern D: MSP managing 20 client domains

An MSP managing DMARC for 20 client domains, each with different vendor stacks.

Standard MSP-managed apex record (templated per client):

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-{client-id}@msp-reporting.com; fo=1; adkim=r; aspf=r

Reasoning:

• Reports go to a per-client mailbox at the MSP’s domain so a single dashboard ingests all clients without each client needing to manage their own report inbox.
• pct=100 and p=reject because the MSP is responsible for verifying enforcement readiness for each client before flipping the policy.
• The {client-id} segmentation lets the MSP’s tool route reports to the right tenant.

The trap to avoid: Using the same rua mailbox for all clients (loses tenant routing) or using each client’s own mailbox (forces clients to install report parsers). The dedicated MSP report-ingestion address is the right pattern. See the MSP guide to adding DMARC services to your portfolio.

Advanced DMARC Tags Reference

The basic p=, rua=, and pct= tags cover most use cases. The advanced tags below matter when you’re dealing with edge cases — strict authentication requirements, forensic investigations, subdomain management, or unusual reporting needs.

pct= (Percentage rollout)

Specifies the percentage of failing messages to which the policy is applied. The remainder are treated as the next-lower policy (p=reject falls back to quarantine, p=quarantine falls back to none).

When to deviate from default (pct=100):

• During a quarantine rollout. Use pct=25 → 50 → 75 → 100 over 2–4 weeks to ramp gradually.
• During incident response. If you discover a legitimate sender breaking right after enforcement, drop pct temporarily to relieve pressure while you fix.

Common mistake: Leaving pct=25 permanently because “it works.” A 25% rollout is functionally not enforcement — three quarters of spoofed mail still gets quarantined-as-none, which means it gets delivered. Don’t stop until 100%.

sp= (Subdomain policy)

Specifies the policy for subdomains that don’t have their own DMARC record. If unset, subdomains inherit the parent’s p= value.

When to set explicitly:

• During parent enforcement when subdomains aren’t ready: sp=none or sp=quarantine.
• When you have many subdomains and want belt-and-suspenders explicit policy: sp=reject.
• When subdomains have totally different sender mixes: set sp=none and give each subdomain its own DMARC record.

Common mistake: Setting p=reject; sp=reject early in a migration. If a subdomain isn’t enforcement-ready, you’ve just rejected legitimate mail without realizing it. See DMARC for subdomains explained.

adkim= and aspf= (Alignment mode)

Controls whether DKIM/SPF alignment is r (relaxed, default) or s (strict).

Relaxed: organizational domains must match. mail.example.com aligns with example.com. Strict: exact match required. mail.example.com does not align with example.com.

When to deviate from default: Almost never on adkim. Sometimes on aspf=s for high-security inbound-only domains where the sending pattern is fully controlled. Strict alignment breaks third-party senders almost universally.

Common mistake: Treating “strict” as “more secure and therefore better.” It’s more rigorous but more brittle. The security delta is marginal; the deliverability cost is not.

fo= (Forensic options)

Controls when forensic reports are generated. Only matters if ruf= is set.

• fo=0 (default) — generate a forensic report only if both SPF and DKIM fail.
• fo=1 — generate if either SPF or DKIM fails. Most useful default.
• fo=d — generate if DKIM fails (regardless of result).
• fo=s — generate if SPF fails (regardless of result).
• Multiple values: fo=d:s (DKIM failure or SPF failure).

When to deviate from default: Always set fo=1 if you’re using ruf=. The default rarely produces useful events.

Common mistake: Setting fo= without ruf=. The tag has no effect without a forensic destination.

ri= (Report interval)

Requested aggregate-report interval, in seconds. Default 86400 (24 hours).

When to deviate from default: Almost never. Most receivers ignore this and use their own internal scheduling. Setting ri=3600 (hourly) won’t actually get you hourly reports from Google or Microsoft.

Common mistake: Assuming this controls when reports arrive. It documents intent; receivers honor it at their discretion.

rf= (Report format)

Requested aggregate-report format. Only afrf is defined and used.

When to deviate: Never. Don’t include this tag. It exists in the spec but adds nothing.

v= (Version)

Always v=DMARC1. Must be the first tag in the record. There’s no v=DMARC2.

Common mistake: Putting v=DMARC1 not first, or using a different value. Either invalidates the entire record. The receiving server doesn’t try to parse the rest if the version tag is wrong or missing.

DMARC Migration Timeline (Week by Week)

Here’s a concrete 12-week migration plan. Adjust pace based on your sender complexity.

Week	Action	Policy	Notes
1	Publish monitoring record	p=none; sp=none; pct=100	Wait 48h for first reports to arrive
2–3	Enumerate senders from reports	p=none	Build a list of every IP/source authenticating as your domain
4	Authenticate forgotten senders	p=none	Add SPF includes; configure DKIM for ESPs
5–6	Verify pass rates climbing	p=none	Target 95%+ aggregate pass before advancing
7	Fix high-volume failures	p=none	Address any sender with >1% failure share
8	Investigate unauthenticated subdomains	p=none; sp=none	Confirm no subdomain mail will break under quarantine
9	Move to gradual quarantine	p=quarantine; pct=25; sp=none	Watch for help-desk complaints over the next 7 days
10	Increase quarantine	p=quarantine; pct=50; sp=none	If clean for a week, advance
11	Increase quarantine	p=quarantine; pct=75; sp=none	Continue monitoring
12	Full quarantine	p=quarantine; pct=100; sp=none	The “quarantine plateau” — stay here 1–2 weeks before reject
13–14	Move to reject	p=reject; pct=100; sp=quarantine	Subdomains stay safer until separately enforced
15+	Subdomain enforcement	p=reject; sp=reject	Per-subdomain DMARC records or blanket sp=reject

The numbers are guidelines, not deadlines. The trigger for advancing each step is data, not the calendar:

1. Pass rate consistently above 95%.
2. Zero unauthorized senders in the past 30 days of reports.
3. All known legitimate senders authenticated and aligning.

This is the Verkh policy-progression readiness gate — the same data points that gate Verkh’s recommendation to advance.

How to Publish a DMARC Record on Common DNS Providers

The DMARC record is a TXT record at the host _dmarc (or _dmarc.subdomain for subdomain records). The exact UI varies by provider.

Cloudflare

1. Log in to the Cloudflare dashboard and select your domain.
2. Go to DNS → Records.
3. Click Add record.
4. Set:
   • Type: TXT
   • Name: _dmarc (Cloudflare auto-appends your domain)
   • Content: Your full DMARC record (e.g., v=DMARC1; p=none; rua=mailto:[email protected])
   • TTL: Auto
   • Proxy status: DNS only (TXT records can’t be proxied)
5. Save. Verify with the DMARC checker within 5 minutes (Cloudflare propagates fast).

AWS Route 53

1. Open the Route 53 console and select your hosted zone.
2. Click Create record.
3. Set:
   • Record name: _dmarc
   • Record type: TXT
   • Value: "v=DMARC1; p=none; rua=mailto:[email protected]" (Route 53 requires the record value in quotes)
   • TTL: 300 (5 minutes during testing) or 3600 (production)
4. Save. Propagation is typically under 60 seconds.

Google Cloud DNS / Google Domains

1. Open the Cloud DNS console (or Google Domains DNS section if using the registrar product).
2. Click Add record set (or Manage custom records in Google Domains).
3. Set:
   • DNS name: _dmarc.yourdomain.com. (note the trailing dot)
   • Resource record type: TXT
   • TTL: 300 or 3600
   • TXT data: Your DMARC record without quotes
4. Save.

GoDaddy

1. Sign in to GoDaddy and go to My Products → your domain → DNS.
2. Click Add under the records list.
3. Set:
   • Type: TXT
   • Name: _dmarc
   • Value: Your DMARC record (no quotes)
   • TTL: 1 hour (default)
4. Save. GoDaddy propagation can take up to 24 hours; verify before assuming the record didn’t take.

Common across all providers

After publishing, allow at least the TTL period plus a few minutes for caches to clear. Then verify three things:

1. The record exists (dig TXT _dmarc.yourdomain.com from a fresh resolver).
2. There’s only one DMARC record at _dmarc — multiple records produce permerror.
3. The syntax parses correctly. The DMARC checker flags syntax errors that DNS UIs accept silently.

DMARC Policy Decision Tree

Use this to decide which policy to publish at any point in your migration. Find the row that matches your current state and follow the condition branches.

For deeper enforcement playbooks, see the stuck-at-p=none guide and the DMARC enforcement journey.

Conclusion and Next Steps

Implementing a DMARC policy is a journey from visibility to protection. You start by understanding who’s sending email as your domain, progress through fixing authentication issues, and ultimately reach enforcement where spoofed emails get blocked entirely.

The path isn’t always smooth. You’ll discover forgotten vendors, wrestle with alignment issues, and spend more time than you’d like waiting for DNS propagation. But each step brings you closer to actually protecting your domain rather than just hoping nobody abuses it.

Here’s where to go from here:

1. Check your current state with our email authentication checker
2. Verify your records using our DMARC, SPF, and DKIM tools
3. Start monitoring if you haven’t already with at least a p=none policy
4. Review your reports to understand your email ecosystem
5. Progress to enforcement when your data shows you’re ready—see our enforcement guide for detailed steps

The destination is enforcement. The transformation is knowing you’ve actually done something about email security rather than just talking about it. You can get there. It just takes the willingness to work through the complexity rather than pretending it doesn’t exist.