DMARC fails: choose a policy without breaking legitimate mail

Your CEO’s email “didn’t go through,” the helpdesk has three screenshots of bounce messages that don’t match, and Marketing swears they “didn’t change anything.” Meanwhile, your domain is being spoofed into phishing campaigns and the security team wants p=reject yesterday.

This is the DMARC trap: if you enforce too early, you drop real mail. If you don’t enforce, you’re basically running an all-you-can-spoof buffet. The trick is not choosing a policy. The trick is earning it.

What DMARC really does (and what it doesn’t)

DMARC is a policy and reporting layer built on top of SPF and DKIM. It answers one question: should a receiver trust that the domain in the visible From header is authenticated? DMARC checks whether either SPF or DKIM “passes” and is aligned with the domain in the From header. If aligned authentication exists, DMARC passes. If not, DMARC fails and the receiver applies your requested policy: none, quarantine, or reject.

Important: DMARC is not an anti-spam filter. It doesn’t score content. It doesn’t stop compromised accounts from sending abusive mail using valid authentication. It doesn’t fix your reputation. It’s closer to “brand protection with knobs,” and the knobs can hurt you if you turn them like a DJ at 2 a.m.

Interesting facts and historical context (the stuff that explains why it’s weird)

• DMARC was born from pain: it emerged around 2012 as a pragmatic answer to rampant domain spoofing that SPF and DKIM alone didn’t solve.
• SPF predates DKIM: SPF gained traction in the early 2000s when forged envelope senders were everywhere and SMTP didn’t care.
• DKIM came from industry collaboration: it grew out of efforts by major mailbox providers to preserve message integrity across hops.
• Alignment is the “new” requirement: SPF or DKIM passing isn’t enough; DMARC insists the authenticated domain matches (or closely matches) the visible From domain.
• Forwarding breaks SPF by design: standard forwarding changes the sending IP, so SPF often fails even when the original sender was legit.
• DMARC reports made email observable: aggregate reports are one of the first widely-used telemetry feeds for email authentication at Internet scale.
• Policy adoption accelerated after big providers pushed: once large inboxes started visibly flagging unauthenticated mail, executives suddenly cared.
• Subdomain policy exists because attackers love subdomains: the sp= tag is a tacit admission that “one policy fits all” rarely survives corporate email reality.

One quote that operations people repeat for a reason: “Hope is not a strategy.” — General Gordon R. Sullivan. Email authentication is a masterclass in that idea.

Fast diagnosis playbook

This is the “stop guessing” sequence. The goal is to find the bottleneck in minutes, not to produce a beautiful diagram no one will read.

First: confirm the failing axis (SPF, DKIM, or alignment)

1. Grab a real failing message (preferably from a mailbox provider, not a screenshot).
2. Inspect Authentication-Results and note:
   • SPF pass/fail and the domain used.
   • DKIM pass/fail and the signing domain (d=).
   • DMARC pass/fail and the “header.from” domain.
3. If SPF or DKIM passes but DMARC fails, you have an alignment problem, not an authentication problem.

Second: identify the sending system that produced the mail

1. Look for clues in headers: Received:, X-Mailer, vendor-specific headers.
2. Match it to a known stream: Microsoft 365, Google Workspace, Salesforce/Marketo, Zendesk, on-prem Postfix, HR system, invoice platform, etc.
3. If you can’t identify it quickly, DMARC aggregate reports will—if you’re collecting them.

Third: decide whether you can fix it with config or need a routing change

• Fixable by config: add DKIM signing, correct From domain, add SPF include, fix selector, publish DMARC record, set alignment mode.
• Requires routing change: third-party must send via your authorized relay, or must use their own domain, or must support DKIM with your domain.

Don’t start by changing your DMARC policy. Start by making your legitimate streams pass. Policy comes last.

Choosing a DMARC policy without breaking mail

DMARC policy is not a moral stance. It’s traffic engineering. Your objective is: stop spoofed mail while keeping legitimate mail deliverable. The safest path is staged enforcement with telemetry.

What the three policies really mean in practice

p=none (monitoring)

This asks receivers to do nothing special with failures. It’s not useless—if you have reporting wired up, it’s your visibility phase. Treat p=none like read-only mode: you’re measuring blast radius, enumerating senders, and fixing alignment. If you leave it here forever, attackers will thank you for your contribution to their quarterly goals.

p=quarantine (soft enforcement)

This asks receivers to treat failures as suspicious—usually spam folder placement. Behavior varies by provider. Some quarantine aggressively, some gently, some ignore you more than they admit. Quarantine is valuable because it surfaces user-facing impact with less catastrophic loss than reject. It’s also dangerous because people don’t always check spam folders, and business processes don’t enjoy probabilistic delivery.

p=reject (hard enforcement)

This asks receivers to outright reject failing mail, ideally at SMTP time. It’s the cleanest posture for spoofing prevention. It’s also unforgiving: any legitimate stream failing alignment becomes an outage. You don’t “try reject.” You deploy it the same way you deploy a firewall rule to prod: with inventory, canaries, and rollback.

Staged enforcement that doesn’t light production on fire

Use percentage rollout with the pct= tag. Start at pct=10 or pct=25 for quarantine or reject, depending on how confident you are in your sender inventory.

A typical safe progression:

1. Baseline: p=none + working aggregate reports (rua=) for at least 2–4 weeks.
2. Clean up: fix or eliminate failing legitimate streams; push DKIM signing everywhere you can.
3. Partial enforcement: p=quarantine; pct=25, monitor for user impact and unexpected sources.
4. Stronger: p=quarantine; pct=100 or go to p=reject; pct=25 if things are clean.
5. Target: p=reject; pct=100, plus sp=reject if you control subdomains.

Joke #1: DMARC is like a seatbelt—everyone loves it right up until it locks while you’re reaching for coffee.

What to do about subdomains (where complexity goes to breed)

If your organization uses subdomains for marketing, transactional mail, or regional brands, set an explicit subdomain policy with sp=. Otherwise you’ll accidentally enforce on subdomains you didn’t even know existed.

• Conservative: p=reject; sp=none to protect the parent while giving subdomains breathing room.
• Strict: p=reject; sp=reject once you know subdomain senders are clean.

How strict should alignment be?

DMARC alignment can be relaxed or strict:

• Relaxed alignment (default): allows organizational domain alignment (e.g., mail signed as d=mail.example.com aligns with From example.com).
• Strict alignment: requires exact domain match. This is where perfectly legitimate setups go to die.

In most enterprises, strict alignment is for later—after you’ve eliminated weird vendor behavior and standardized sending domains. Start relaxed unless you have a strong reason not to.

Alignment and failure modes that bite in production

SPF: the envelope sender isn’t the From header

SPF authenticates the domain in the SMTP envelope sender (Return-Path), not the header From. DMARC then checks whether that SPF-authenticated domain aligns with the header From domain.

Common failure pattern:

• Return-Path: bounces.vendor-mail.example.net (vendor domain)
• From: billing@example.com (your domain)
• SPF passes for vendor domain, but does not align with example.com → DMARC fails unless DKIM aligns.

DKIM: signing exists, but not for your domain

DKIM signs content and binds it to a domain via the d= tag. DMARC checks if that domain aligns with the header From domain. If a vendor signs as d=vendor.com while sending From your domain, DKIM may pass but DMARC still fails.

Forwarding: SPF fails, DKIM might survive

Classic forwarding breaks SPF because the forwarder’s IP isn’t listed in your SPF record. DKIM can survive forwarding if the message isn’t modified in transit. Many systems modify it (subject tagging, footer injection), which breaks DKIM too. Then DMARC fails and you get the “why did this work last year?” meeting.

Mailing lists: the DKIM shredder

Mailing lists often rewrap or modify messages (subject prefixes, list footers), which breaks DKIM. SPF rarely aligns because the list server sends it. DMARC fails. Modern list managers can mitigate this, but you don’t control every list your users subscribe to.

Multiple vendors: death by a thousand “just add this include”

SPF has a hard limit: 10 DNS lookups during evaluation. Every include: counts, plus redirects and some mechanisms. Exceed it and you get permerror. DMARC doesn’t care why SPF failed; it just sees failure. You can end up breaking mail by “authorizing” too many things.

DMARC reporting: the difference between control and superstition

Aggregate reports (RUA) show who is sending on behalf of your domain, which authentication they pass, and at what volume. They’re not perfect. They’re delayed, sampled by some providers, and sometimes difficult to parse. But without them, you’re making policy changes blind.

Practical tasks: commands, outputs, decisions

These tasks are designed for an SRE-ish workflow: verify state, interpret output, make a decision, change one thing at a time.

Task 1 — Check your DMARC record exists and is syntactically sane

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1; adkim=r; aspf=r; pct=100"

What it means: DMARC exists; policy is monitoring; reports go to your mailboxes; relaxed alignment is set.

Decision: If there is no record or it’s malformed, fix that before touching anything else. If you’re still at p=none, you’re in inventory mode.

Task 2 — Validate that DNS returns a single DMARC TXT record

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"

What it means: One record only. Good.

Decision: If you see multiple TXT answers, consolidate. Multiple DMARC records is undefined behavior, and mailbox providers tend to choose chaos.

Task 3 — Check SPF record and count includes (lookup risk)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org -all"

What it means: SPF authorizes Google, Microsoft, Mailgun. Potentially fine, but each include costs lookups.

Decision: If you have more than a handful of includes, run a lookup count test (next task). If you’re near 10, stop adding includes and switch strategy (DKIM alignment via vendors, or consolidate through a relay).

Task 4 — Detect SPF permerror due to DNS lookup limit

cr0x@server:~$ spfquery -ip=203.0.113.10 -sender=bounce@example.com -helo=mx.example.com
pass (lookup_count=7)

What it means: SPF evaluation passed and used 7 DNS lookups. You have headroom.

Decision: If you see permerror (lookup limit exceeded), you must reduce SPF complexity. That’s not “later” work; that’s “today” work before enforcement.

Task 5 — Pull a failing message header and read Authentication-Results

cr0x@server:~$ sed -n '1,120p' failing-message.eml | egrep -i 'authentication-results|dmarc=|spf=|dkim=|from:|return-path'
Return-Path: <bounces@vendor.example.net>
From: "Billing" <billing@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@vendor.example.net designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounces@vendor.example.net;
       dkim=none (message not signed);
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com

What it means: SPF passed for the vendor’s domain, but DMARC failed because there’s no DKIM and SPF doesn’t align with example.com.

Decision: You need DKIM signing with d=example.com (preferred) or change vendor to send with their own From domain (less ideal for brand), or route through your infrastructure.

Task 6 — Check DKIM public key record exists for a selector

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw..."

What it means: Selector s1 is published. That’s necessary, not sufficient.

Decision: If missing, DKIM will fail for mail signed with that selector. Publish or correct it before enforcement.

Task 7 — Verify a message is actually DKIM-signed and aligned

cr0x@server:~$ grep -i '^DKIM-Signature:' -m 1 good-message.eml
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:message-id; bh=...; b=...

What it means: The signing domain d=example.com aligns with From example.com. This stream should DMARC-pass even if SPF breaks (forwarding).

Decision: If d=vendor.com, DKIM may pass but DMARC alignment may fail. Fix vendor configuration to sign with your domain.

Task 8 — Test DMARC evaluation from a receiver-style tool (OpenDMARC)

cr0x@server:~$ opendmarc-testmsg < failing-message.eml | sed -n '1,25p'
opendmarc-testmsg: EnvelopeFrom: bounces@vendor.example.net
opendmarc-testmsg: HeaderFrom: example.com
opendmarc-testmsg: SPF: pass
opendmarc-testmsg: DKIM: fail
opendmarc-testmsg: DMARC: fail (policy=quarantine)

What it means: Receiver-side DMARC logic agrees with what you’re seeing in the wild.

Decision: Don’t argue with production. Fix DKIM or alignment.

Task 9 — Inspect Postfix logs for DKIM milter behavior (on-prem)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  3 10:12:11 mx1 postfix/cleanup[22190]: 9F3C42C10D: message-id=<20260103101210.9F3C42C10D@mx1.example.com>
Jan  3 10:12:11 mx1 opendkim[1187]: 9F3C42C10D: DKIM-Signature field added (s=s1, d=example.com)
Jan  3 10:12:11 mx1 postfix/qmgr[1120]: 9F3C42C10D: from=<billing@example.com>, size=28412, nrcpt=1 (queue active)

What it means: Your MTA is adding DKIM signatures using the expected selector and domain.

Decision: If you don’t see “DKIM-Signature field added,” your signing path is broken (milter down, wrong socket, wrong key permissions).

Task 10 — Confirm your DMARC reporting mailbox is receiving aggregate reports

cr0x@server:~$ sudo -u postfix mailq | head
Mail queue is empty

What it means: Not directly about DMARC, but it tells you your reporting mailbox isn’t backed up at the MTA queue. If you do local delivery, this matters.

Decision: If the queue is growing and the destination is your rua mailbox, you’re losing reports and flying blind. Fix mail delivery before changing policy.

Task 11 — Extract DMARC aggregate report XML and summarize top failing sources

cr0x@server:~$ unzip -p rua-archive/aggregate-report-001.zip '*.xml' | grep -Eo '<source_ip>[^<]+' | head
<source_ip>192.0.2.55
<source_ip>198.51.100.20
<source_ip>203.0.113.99

What it means: You have a quick list of source IPs sending as your domain.

Decision: For each top IP, identify the system/vendor. Unknown IPs are either shadow IT or active spoofing. Both deserve attention; only one deserves a vendor ticket.

Task 12 — Verify which systems are connecting to your inbound MX (spot spoofing and relays)

cr0x@server:~$ sudo grep -h "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  412 203.0.113.77
  198 198.51.100.20
   76 192.0.2.55

What it means: Top connecting IPs. This doesn’t prove spoofing, but it shows who’s talking to you.

Decision: If you see unexpected senders or huge spikes, correlate with DMARC failures and security events. You might be under active spoofing campaigns.

Task 13 — Check that your DMARC policy is what you think it is (cached DNS is a liar)

cr0x@server:~$ dig TXT _dmarc.example.com @8.8.8.8 +short
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"

What it means: A public resolver sees quarantine at 25%. Good for staged rollout.

Decision: If different resolvers disagree, your TTL or DNS propagation is in play. Don’t flip to reject until you see consistent results.

Task 14 — Inspect SPF for a specific vendor stream (does it align?)

cr0x@server:~$ dig +short TXT vendor.example.net
"v=spf1 ip4:198.51.100.0/24 -all"

What it means: Vendor authorizes their own IP range for their own domain. That does nothing for alignment with your From domain.

Decision: Stop trying to “SPF your way out” of misaligned third-party senders. Push DKIM signing with your domain or change the From domain.

Task 15 — Verify DKIM selector rotation didn’t leave dead records (common during “cleanup”)

cr0x@server:~$ for s in s1 s2 s2024; do echo "== $s =="; dig +short TXT ${s}._domainkey.example.com; done
== s1 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2024 ==

What it means: Selector s2024 is missing. If any sender still uses it, DKIM fails.

Decision: Either republish the key temporarily or migrate the sender to an existing selector before enforcement. Deleting old selectors is not “hygiene” if they’re still in use.

Task 16 — Confirm organizational domain boundary for relaxed alignment (public suffix behavior)

cr0x@server:~$ python3 - <<'PY'
import sys
from email.utils import parseaddr
print("example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com")
PY
example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com

What it means: Relaxed alignment uses organizational domain logic (based on public suffix rules). Country-code domains can surprise people.

Decision: If you operate under domains like example.co.uk, double-check vendor configs and expectations; strict alignment gets painful fast.

Joke #2: SPF is the diet plan of email security—simple on paper, wrecked by “just one more include.”

Three corporate mini-stories (because we never learn the easy way)

Mini-story 1: The outage caused by a wrong assumption

The company had a clean-looking setup: Microsoft 365 for employees, a big-name marketing platform, and an on-prem relay for printers and “special systems.” Security wanted p=reject. The email admin agreed, because DMARC reports showed “mostly pass.”

The wrong assumption was subtle: they assumed “mostly pass” meant “the rest is spoofing.” It wasn’t. A regional HR tool was sending offer letters using From: hr@example.com but routing through the vendor’s infrastructure with no aligned DKIM. SPF passed—just not for the right domain. DMARC failed. Under p=none, it still landed. Under p=reject, it bounced hard.

Monday morning, candidates didn’t receive offers. Recruiters escalated. Legal asked whether the company had “rescinded” offers. The security team got the blame because they asked for reject, and the email team got the blame because they implemented it. Management did what management does: scheduled a meeting, then another meeting about the first meeting.

The fix was straightforward: configure the HR vendor to DKIM-sign with d=example.com using a delegated selector, then re-enable enforcement. The lesson was uglier: DMARC success is about enumerating every legitimate sender. Any assumption that “unknown equals malicious” is a policy that will eventually page you.

Mini-story 2: The optimization that backfired

A different org decided to “simplify DNS.” Someone noticed the SPF record had grown into a small novel. They removed what looked like “old vendor includes” and merged DKIM selectors because “we don’t need so many.” It was well-intentioned. It was also not tested against reality.

Two weeks later, DMARC failure rates climbed. Not everywhere—only at a couple of mailbox providers. The team wasted time blaming “provider changes” and “reputation.” The truth: one “old include” still covered a transactional mail stream used for password resets in a legacy app. It sent rarely, so it didn’t show up in daily dashboards. When it did send, SPF failed, and the legacy app didn’t DKIM-sign. Under increasing enforcement, the reset emails quietly disappeared into quarantine or rejection, depending on the receiver.

Meanwhile, consolidating DKIM selectors broke a vendor integration that hardcoded the selector name. That vendor continued signing with the old selector, which no longer existed in DNS. DKIM failed immediately. DMARC failures shot up for that sender.

The team rolled back, then wrote a rule: no SPF/DKIM “cleanup” without mapping each include and selector to an owner, a system, and a test message. Optimization is great, but email authentication punishes cleverness. It prefers boring paperwork and stable DNS.

Mini-story 3: The boring but correct practice that saved the day

A mid-sized SaaS company ran DMARC reporting into an internal mailbox, then into a parser that produced a weekly sender inventory. Nothing fancy. No ML. Just a list of sources, pass rates, and “new senders since last week.” It was the kind of process people call “busywork” right until it matters.

One Tuesday, the report flagged a new source IP sending a small but non-zero volume of mail using From: finance@example.com. SPF failed. DKIM was absent. DMARC failed. Under their current p=quarantine, much of it was landing in spam. Good, but not enough.

Security investigated and found a phishing campaign targeting customers. Because the team had telemetry and a baseline, they didn’t argue about whether it was real. They moved to p=reject; pct=25 for 24 hours, verified no legitimate streams were impacted, then ramped to 100% reject. They also set sp=reject after confirming subdomains were clean.

Customers reported fewer phishing emails using the company’s name within days. The boring practice—consistent reporting and inventory—made enforcement a controlled change instead of a leap of faith. Nobody got paged. The best outages are the ones that never happen.

Common mistakes: symptom → root cause → fix

1) “SPF passes but DMARC fails”

Symptom: Authentication-Results shows spf=pass, DMARC fails.

Root cause: SPF passed for a domain that doesn’t align with header From (common with third-party senders).

Fix: Enable DKIM signing aligned to your From domain (best), or change the From domain to the vendor’s domain, or route the sender through your aligned infrastructure.

2) “DKIM passes but DMARC fails”

Symptom: dkim=pass but DMARC fails.

Root cause: DKIM signing domain d= is not aligned with header From; vendor signs as themselves.

Fix: Configure vendor to sign with your domain via delegated DKIM (publish their selector under your domain), or adjust the From domain.

3) “Everything worked until we set p=reject”

Symptom: Immediate bounces for some legitimate business mail.

Root cause: Unknown legitimate senders, broken DKIM selectors, or SPF permerror were masked under p=none/quarantine.

Fix: Roll back to quarantine with pct=, fix the sender inventory, then re-roll staged reject.

4) “Forwarded mail started bouncing after DMARC enforcement”

Symptom: Users forwarding to personal inboxes complain; mailing list deliveries fail.

Root cause: Forwarders break SPF; list modifications break DKIM; DMARC fails.

Fix: Ensure your outbound mail is DKIM-signed aligned; for lists, consider list-specific mitigations (e.g., From rewriting) or allowlist known list behaviors in downstream systems where feasible.

5) “SPF permerror appears randomly”

Symptom: Some receivers show SPF permerror or fail; others pass.

Root cause: DNS lookup limit exceeded; some evaluators short-circuit differently, or DNS timeouts push you into temporary errors.

Fix: Reduce SPF DNS lookups by consolidating senders, removing unused includes, or using DKIM alignment instead of SPF dependencies.

6) “DMARC reports stopped arriving”

Symptom: RUA mailbox is quiet; dashboards go stale.

Root cause: Mailbox full, routing changed, DMARC rua address invalid, or filtering blocks large zip attachments.

Fix: Ensure the reporting mailbox accepts large messages, doesn’t auto-delete, and that the rua address is correct and monitored.

7) “We have DMARC but spoofing still happens”

Symptom: Customers receive phishing using your brand despite DMARC record existing.

Root cause: You’re at p=none, or receivers don’t enforce uniformly, or attackers use lookalike domains.

Fix: Move to reject once legitimate streams pass; add subdomain policy; monitor lookalike domains separately (DMARC won’t save you from examp1e.com).

Checklists / step-by-step plan

Step-by-step plan: get to p=reject safely

1. Inventory senders via DMARC aggregate reports for at least 2–4 weeks. Tag each source with an owner.
2. Classify streams:
   • Employee mail (M365/Workspace)
   • Transactional (app mail, invoices, password resets)
   • Marketing (campaign platforms)
   • Support/ticketing
   • Infrastructure (alerts, monitoring)
3. Standardize From domains: decide which domains are allowed to appear in From for each stream. Be strict. Vendors love creative From addresses.
4. Enable DKIM aligned signing everywhere possible. Prefer DKIM over SPF for third-party streams because alignment is easier and forwarding survival is better.
5. Fix SPF but keep it lean:
   • Remove dead includes
   • Stay below 10 lookups
   • Use -all when confident; ~all is a crutch, not a strategy
6. Publish DMARC with reporting: p=none + rua. Verify reports actually arrive and are parsed.
7. Set subdomain policy explicitly using sp=. Don’t let subdomains inherit enforcement accidentally.
8. Roll to quarantine with pct: start pct=25, then 50, then 100 as failure rates drop and support noise stays acceptable.
9. Roll to reject with pct: start 10–25, watch for new failures. Ramp deliberately.
10. Lock in governance: any new vendor sender must support aligned DKIM or use a vendor domain; “we can’t” means “we won’t onboard you.”
11. Keep monitoring: DMARC is not set-and-forget. Vendors rotate IPs, integrations change, someone buys a company, and suddenly your DMARC posture meets reality again.

Checklist: before you change DMARC policy

• Do we have at least one working RUA destination and does it receive reports?
• Do we have a current sender inventory with owners?
• Do major streams pass DMARC (not just SPF or DKIM)?
• Is SPF below DNS lookup limit and stable?
• Are DKIM selectors published for all active signers?
• Do we have a rollback plan (previous record and TTL awareness)?
• Have we communicated expected impacts to support and security?

Checklist: when a vendor “must send as your domain”

• Can the vendor DKIM-sign with d=yourdomain using a delegated selector?
• Can they support custom Return-Path aligned with your domain (rarely the best path, but sometimes possible)?
• Can they send through your relay (SMTP submission) so you sign mail yourself?
• Do they have per-tenant DKIM and stable sending patterns?
• Can they provide test messages and a technical contact who understands authentication?

FAQ

1) Should we jump straight to p=reject to stop spoofing?

Only if you’re confident your legitimate streams already DMARC-pass. Otherwise you’re trading spoofing for self-inflicted mail loss. Stage it with pct and telemetry.

2) Is p=quarantine “safe”?

Safer than reject, not safe. Some business-critical mail will disappear into spam folders, which is functionally the same as lost mail—just with extra denial.

3) Why does SPF pass but DMARC still fail?

Because SPF authenticated the envelope domain, and DMARC cares about the header From domain. If those don’t align, SPF doesn’t help DMARC. DKIM aligned signing is usually the fix.

4) Forwarding is breaking our email. Is DMARC incompatible with forwarding?

DMARC exposes the fragility of forwarding. SPF breaks on forward; DKIM may survive if the message isn’t modified. For your outbound streams, DKIM-sign aligned so at least one mechanism can pass.

5) Do we need ruf= forensic reports?

Usually no. Forensic reports are inconsistently supported and can raise privacy concerns. Aggregate reports (RUA) are the workhorse for operational decisions.

6) What’s the biggest reason DMARC “suddenly fails” after years?

A new sender or changed routing. Common triggers: marketing team adds a platform, helpdesk changes vendor, a SaaS tool starts sending “from your domain,” or DKIM selectors get rotated improperly.

7) Do we need strict alignment (adkim=s, aspf=s)?

Not at first. Strict alignment is great for reducing ambiguity, but it raises the bar for every sender. Start relaxed, reach reject, then consider strict where it doesn’t break the world.

8) What about subdomains: should we set sp=reject?

Only when you know what’s using subdomains. If you have lots of vendor-driven subdomains, start with sp=none or sp=quarantine and inventory.

9) If we use Microsoft 365 or Google Workspace, do we still need DMARC?

Yes. Those platforms can authenticate your outbound mail, but DMARC is how the rest of the world knows what to do when someone spoofs your domain.

10) How long should we stay at p=none?

Long enough to capture normal business cycles: at least two weeks, often a month. Quarterly billing runs and rare workflows are where your “unknown senders” hide.

Conclusion: next steps you can execute

If DMARC is failing, don’t start by asking “quarantine or reject?” Start by asking “which legitimate stream is failing alignment?” Fix that, then enforce. Policy is the last step, not the first.

Practical next steps

1. Pull a failing message and read Authentication-Results. Decide whether the problem is SPF, DKIM, or alignment.
2. Verify DMARC and SPF records in DNS from multiple resolvers. Fix syntax and eliminate duplicates.
3. Turn DMARC reports into an inventory: every sender, owner, and pass rate.
4. Push aligned DKIM signing for every third-party sender that must use your From domain.
5. Stage enforcement with pct: quarantine first, then reject, with rollback planned and support briefed.

Do that, and “DMARC fails” becomes a solvable engineering problem instead of an endless email thread titled “URGENT.”