Why DMARC Enforcement Matters
Email spoofing — sending messages with a forged From: address using your domain — requires no access to your mail infrastructure. Anyone can send an email claiming to be from ceo@yourcompany.com. Without DMARC enforcement, receiving mail servers have no instruction to reject or quarantine these messages; whether they're delivered depends entirely on the receiver's own heuristics.
The attacks enabled by domain spoofing are concrete and costly: business email compromise (BEC) fraud, where attackers impersonate executives to authorise wire transfers; phishing campaigns that use trusted brand domains to steal credentials; and supplier impersonation attacks that target accounts payable teams. These attacks are significantly harder to execute against domains with p=reject enforcement, because receiving servers actively refuse unauthenticated messages claiming to be from those domains.
DMARC enforcement also satisfies the authentication requirements imposed by Google and Yahoo for bulk senders — a p=none policy is technically compliant with the minimum requirement, but p=quarantine or p=reject is increasingly expected by major receivers and will likely be mandated in future requirements updates.
The Three DMARC Policy Levels Explained
| Policy | Action on Failing Mail | Risk Level | Appropriate Stage |
|---|---|---|---|
p=none | Deliver normally — report only | None to sender | Initial deployment; monitoring phase |
p=quarantine | Route to spam/junk folder | Low–Medium | Intermediate enforcement; after confirming legitimate senders pass |
p=reject | Reject at the SMTP level — not delivered | Low (when ready) | Full enforcement; after quarantine phase confirms clean pass rate |
The policy level applies only to messages that fail DMARC alignment — meaning they fail both SPF alignment and DKIM alignment simultaneously. Messages that pass either SPF or DKIM alignment are not affected by the DMARC policy, regardless of the policy level.
DMARC alignment means the domain in the authenticated mechanism matches the domain in the From: header:
- SPF alignment: The domain that passes SPF (the
envelope-from/Return-Pathdomain) must match theFrom:header domain (relaxed: same organisational domain; strict: exact match) - DKIM alignment: The
d=domain in the DKIM signature must match theFrom:header domain
A message from newsletter@marketing.example.com with a DKIM signature d=example.com passes relaxed DKIM alignment with From: noreply@example.com. A message from a third-party ESP that sends on behalf of your domain using only their own DKIM signature and their own Return-Path will fail both alignment checks — and become subject to your DMARC policy.
DMARC Record Tags Reference
| Tag | Purpose | Values | Default |
|---|---|---|---|
p= | Policy for the domain | none, quarantine, reject | Required — no default |
sp= | Policy for subdomains | none, quarantine, reject | Inherits p= value |
rua= | Aggregate report destination (URI) | mailto:reports@example.com | None — reports not sent if omitted |
ruf= | Forensic/failure report destination | mailto:forensic@example.com | None — rarely used |
pct= | Percentage of failing mail to apply policy to | 1–100 | 100 |
adkim= | DKIM alignment mode | r (relaxed), s (strict) | r |
aspf= | SPF alignment mode | r (relaxed), s (strict) | r |
fo= | Forensic report generation options | 0, 1, d, s | 0 |
ri= | Aggregate report interval (seconds) | Integer | 86400 (24 hours) |
ℹ️ Note: The
ruf=forensic report tag is increasingly ignored by major receivers (Google and Yahoo do not send forensic reports due to privacy concerns). Build your DMARC workflow aroundrua=aggregate reports — they contain everything you need to make enforcement decisions.
Phase 1 — Deploy p=none and Start Collecting Reports
The p=none phase is not optional — it's where you discover every source of mail that claims to be from your domain. Skipping it and going directly to p=quarantine or p=reject on an actively used mail domain is the most common cause of blocking legitimate mail.
Deploying your initial DMARC record
; Phase 1 — Monitoring only
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Key decisions at Phase 1:
rua=address: This is where aggregate reports will be sent. You can use an internal mailbox, but a dedicated report inbox or a third-party DMARC report processing service (dmarcian, Valimail, EasyDMARC, Postmark's DMARC Digests) is easier to analyse at scale. If therua=address is at a different domain than your DMARC domain, that domain must publish a DNS record authorising receipt:_dmarc.example.com. TXT "v=DMARC1;"atyourdomain.comgrants that permission.- Omit
sp=initially — let subdomains inherit thep=nonepolicy for now. You'll handle them explicitly in Phase 3.
Verify the record is correctly published:
dig TXT _dmarc.example.com +short
# "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Use our DMARC Checker to validate the record syntax and confirm it's resolving correctly from public resolvers.
How long to stay at p=none
Minimum 2 weeks. Ideally 30 days. You need enough report data to see a full sending cycle — especially for domains with infrequent batch sends (monthly newsletters, quarterly reports, automated notifications that don't send daily). Leave p=none active until you have aggregate reports covering at least one full business cycle for every sending system.
How to Read DMARC RUA Aggregate Reports
Aggregate reports arrive as gzip-compressed XML files, typically one per sender domain per day. They are not designed to be read directly — use a report processor to parse and visualise them.
The key fields in each aggregate report record:
<record>
<row>
<source_ip>209.85.128.0</source_ip> <!-- Sending IP -->
<count>1542</count> <!-- Messages from this IP -->
<policy_evaluated>
<disposition>none</disposition> <!-- What policy was applied -->
<dkim>pass</dkim> <!-- DKIM result -->
<spf>pass</spf> <!-- SPF result -->
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from> <!-- From: header domain -->
<envelope_from>bounce.sendgrid.net</envelope_from> <!-- Return-Path domain -->
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>s1</selector>
</dkim>
<spf>
<domain>bounce.sendgrid.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
What to look for in Phase 1 reports
Categorise every source IP in your aggregate reports into one of three buckets:
Legitimate senders you control: Your own mail servers, ESPs you've authorised (Google Workspace, Microsoft 365, Mailchimp, SendGrid, etc.). These should show dkim=pass or spf=pass with alignment. If they're failing, there's an authentication misconfiguration to fix before advancing.
Legitimate senders you need to authorise: Third-party services sending on your domain's behalf that you haven't fully authenticated yet — CRM platforms, support ticket systems, marketing automation tools. Identify each one, verify it's legitimate, and configure SPF and/or DKIM for it.
Spoofing/spam sources: IP addresses sending mail claiming to be from your domain that you don't recognise and haven't authorised. These are the messages your DMARC enforcement will eventually block. Note the volume — it gives you a baseline for how much fraudulent mail is using your domain.
Phase 2 — Move to p=quarantine
You're ready to advance to p=quarantine when: all legitimate senders in your aggregate reports show dkim=pass or spf=pass with alignment, you've confirmed there are no unknown legitimate senders, and you've had at least 2 weeks of clean reports.
⚠️ Warning: Never jump directly from
p=nonetop=rejecton a live domain that sends transactional or operational email. Even one undetected legitimate sender that fails DMARC alignment will have its messages silently rejected — with no bounce, no error visible to the sender, and no indication to recipients. Start atp=quarantineto catch any alignment failures before they cause outright rejection.
Deploying p=quarantine with pct=
Use the pct= tag to apply the quarantine policy incrementally, starting at a low percentage:
; Phase 2a — Quarantine 10% of failing mail
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"
The pct=10 instruction tells receiving servers to apply the quarantine policy to 10% of messages that fail DMARC — the remaining 90% are delivered normally (as if p=none). This limits the blast radius of any misidentified legitimate sender.
Escalation schedule:
Week 1: p=quarantine; pct=10 — watch reports for unexpected failures
Week 2: p=quarantine; pct=25 — if clean, continue escalating
Week 3: p=quarantine; pct=50
Week 4: p=quarantine; pct=100 — all failing mail goes to spam
Monitor aggregate reports closely at each step. If you see legitimate mail appearing in the failure reports at any stage, pause, diagnose the alignment failure, fix it, and then resume escalation.
Common Alignment Failures to Fix Before Escalating
Third-party ESP sending with their own Return-Path
Many ESPs (Mailchimp, Constant Contact, HubSpot) send using their own envelope-from domain for bounce handling: Return-Path: bounce-123@mg.mailchimp.com. SPF passes for mg.mailchimp.com, but SPF alignment fails because mg.mailchimp.com ≠ example.com. If these ESPs also don't sign with DKIM on your domain, the messages will fail DMARC.
Fix: Configure custom domain alignment at your ESP — most major ESPs allow you to set up a custom return path subdomain (bounce.example.com) that satisfies SPF alignment, and enable DKIM signing with your own domain's key. Consult your ESP's documentation for their "custom authentication" or "branded sending domain" feature.
CRM and support tool emails
Platforms like Zendesk, Salesforce, HubSpot, and Intercom can send email claiming to be From: support@example.com using their own mail infrastructure. Unless you've explicitly configured them to sign with DKIM on example.com, these messages will fail DKIM alignment.
Fix: Set up DKIM signing for each platform. Most require you to add a CNAME or TXT record to your DNS zone pointing to their DKIM key. Verify with our DMARC Checker after each configuration.
Internal automated email
Scripts, monitoring systems, and internal applications that send email using your domain often don't authenticate properly. A cron job that sends alerts via a local MTA without SPF-aligned sending or DKIM signing will appear as an alignment failure in your reports.
Fix: Route all automated email through an authenticated relay — your primary email platform, or a transactional ESP with proper DKIM and SPF alignment configured.
Forwarding
Email forwarded by a third-party service (mailing lists, university forwarding, personal forwarding rules) breaks SPF alignment because the forwarding server's IP isn't in your SPF record. DKIM typically survives forwarding intact (unless the forwarder modifies the message body). DMARC will pass for forwarded messages as long as DKIM alignment holds.
This is a known limitation of SPF-based DMARC alignment. DKIM is the more robust mechanism for surviving forwarding — ensure all your outbound mail is DKIM-signed.
Phase 3 — Move to p=reject
You're ready for p=reject when you've been at p=quarantine; pct=100 for at least 2 weeks with no legitimate mail appearing in the failure reports.
; Phase 3 — Full enforcement
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
At p=reject, receiving servers that support DMARC enforcement will reject messages that fail both SPF and DKIM alignment at the SMTP level — the message never reaches the recipient's inbox or spam folder. The sender typically receives an NDR (non-delivery report) indicating the rejection.
Apply the same incremental pct= approach if you want extra caution:
; p=reject with staged rollout
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@example.com"
Escalate pct= from 25 → 50 → 75 → 100 over 2–4 weeks, monitoring reports at each stage.
Once at p=reject; pct=100, you have full DMARC enforcement. Spoofed messages claiming to be from your domain will be rejected by every receiver that honours DMARC policy.
Handling Third-Party Senders That Break Under Enforcement
Some third-party senders cannot be configured to authenticate with your domain — legacy systems, partner platforms, or tools where custom DKIM signing isn't available. Options:
Option 1: Subdomain sending. Configure the third-party to send from a subdomain (notifications.example.com) rather than the primary domain. Create a separate DMARC record for that subdomain with an appropriate policy, and configure SPF/DKIM for the subdomain independently.
Option 2: Accept the limitation. If the third-party sends low volumes and the business cost of their mail being quarantined or rejected is acceptable, enforce anyway. Monitor your aggregate reports to understand the impact.
Option 3: Replace the sender. If a tool can't authenticate properly, it's worth evaluating whether a replacement that does support proper authentication is available. Authentication support is increasingly a baseline capability expectation.
What you should not do: lower your domain's DMARC policy for the sake of one non-compliant sender. That defeats the entire purpose of enforcement and leaves your domain open to spoofing.
DMARC for Subdomains: The sp= Tag
By default, subdomains inherit your primary domain's DMARC policy. mail.example.com, bounce.example.com, and newsletter.example.com are all governed by _dmarc.example.com unless they have their own DMARC records.
The sp= tag lets you set a different policy for all subdomains at the primary domain level:
; Enforce reject on primary domain, quarantine on all subdomains
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com"
For subdomains that send legitimate mail and need their own policy, publish a DMARC record at the subdomain level:
; Override for a subdomain with its own sending
_dmarc.mail.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Don't forget parked domains and non-sending domains. Any domain you own that never sends email is a spoofing surface unless it has a p=reject DMARC record. The correct configuration for non-sending domains:
; Non-sending domain — block all spoofing
_dmarc.parked-example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
Pair this with SPF v=spf1 -all (reject all senders) and no DKIM keys published for the domain.
Monitoring DMARC After Full Enforcement
Reaching p=reject is not the end — it's the beginning of an ongoing monitoring commitment. Your sending infrastructure changes over time: new ESPs are added, internal tools are deployed, acquired companies are integrated, and new products send transactional email. Any change that introduces unauthenticated sending will cause silent failures under p=reject.
Establish a regular DMARC review cadence:
- Weekly: Check aggregate reports for any new IP addresses appearing in the failure category
- Monthly: Review the full list of sending sources against your known-legitimate sender inventory
- On any infrastructure change: Check DMARC reports within 48 hours of deploying a new sending system
- Quarterly: Verify SPF and DKIM records are still correct for all authorised senders using the Email Deliverability Report
Use our DMARC Checker to verify your record syntax and policy level at any time, and our SPF Checker to confirm your SPF record remains within the 10-lookup limit as new senders are added.
For the authentication requirements imposed by Google and Yahoo on bulk senders — including the specific DMARC policy thresholds and alignment requirements — see our Google & Yahoo Bulk Sender Requirements guide.
Frequently Asked Questions
Q: How long does the full none → quarantine → reject journey typically take?
For a well-organised domain with a clear picture of its sending infrastructure, the minimum realistic timeline is 6–8 weeks: 2–4 weeks at p=none collecting data, 2–4 weeks escalating through p=quarantine stages. Domains with complex sending environments — many ESPs, legacy systems, acquired company email — often take 3–6 months to reach p=reject safely, particularly when third-party sender remediation requires vendor engagement.
Q: We went to p=reject and legitimate email is being blocked — what do we do?
First, revert to p=quarantine to stop the bleeding (this is why p=quarantine is always the step before p=reject). Then check your DMARC aggregate reports to identify which source IP the blocked mail is originating from, and which authentication check it's failing. Identify the sending system, configure DKIM signing and SPF alignment for it, verify in the reports that it now passes, then re-escalate to p=reject.
Q: Does DMARC work for all email clients and receiving servers?
No — DMARC policy is only enforced by receiving servers that have implemented DMARC support. Major providers (Gmail, Outlook/Exchange, Yahoo Mail, Apple Mail via iCloud, Proton) all enforce DMARC. Some smaller or self-hosted mail servers may not. DMARC coverage is broad but not universal — a small percentage of mail will reach recipients through non-enforcing servers regardless of your policy.
Q: What's the difference between adkim=r and adkim=s (relaxed vs strict alignment)?
Relaxed alignment (adkim=r, the default) allows the DKIM d= domain to be the same organisational domain as the From: domain — so d=mail.example.com aligns with From: user@example.com. Strict alignment (adkim=s) requires an exact match — d=example.com is required for From: user@example.com; d=mail.example.com would fail. Relaxed alignment is appropriate for almost all deployments; strict alignment may break subdomain-based sending and should only be used when you have a specific reason and have verified all sending matches exactly.
Q: Should I use ruf= forensic reports?
For most senders, no. Forensic reports contain message headers (and potentially message bodies or full messages depending on the fo= setting) from individual failed messages. Most major receivers don't send them due to privacy concerns. They can be useful for diagnosing specific failure cases, but rua= aggregate reports are sufficient for making enforcement decisions and are available from all receivers that support DMARC.
Q: What should my DMARC record look like for a domain that never sends email?
v=DMARC1; p=reject; rua=mailto:your-reports-address@example.com. You still want rua= even on non-sending domains — the reports will show you if someone is spoofing the domain. Pair with v=spf1 -all in a TXT record and no MX records to create a complete "non-sending domain" posture.
Next Steps
Start by publishing a p=none DMARC record today if you haven't already. Use our DMARC Checker to verify the record is correctly published and resolving, and confirm your rua= address is receiving reports within 24–48 hours.
Once reports start arriving, cross-reference the sending sources against your SPF record using the SPF Checker — any legitimate sender appearing in the DMARC failure category needs SPF or DKIM alignment fixes before you advance to enforcement.
For the full context on what DMARC alignment requires from your SPF and DKIM configuration, see our SPF Record Explained guide and DKIM Explained guide.
Browse all email authentication guides on DNSnexus for related topics.