Email Deliverability: The One DMARC Policy That Stops Spoofing Without Losing Mail

The one DMARC policy (and why it works)

If you want spoofing protection without losing legitimate mail, you don’t start with “p=reject” and vibes. You start with a policy that
forces authentication to become real, measurable, and enforceable—while giving you an escape hatch for the ugly parts of email (forwarding,
broken mailing lists, third-party senders, and legacy systems that think “DKIM” is a new music festival).

The policy

The practical default I recommend for most organizations that send real mail and have at least one third-party sender:
DMARC at the organizational domain with p=quarantine, pct=100, strict DKIM alignment (adkim=s), relaxed SPF alignment (aspf=r), and a sane reporting setup.
Then you move to p=reject once your authenticated streams are clean.

A representative record (tune it to your domain and report mailbox):

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

Why this specific shape?

• p=quarantine at pct=100: you’re enforcing, but in a way that tends to route failures to spam instead of a hard drop.
  That keeps business mail flowing while you clean up senders. You’re not “monitoring”; you’re changing outcomes.
• adkim=s (strict DKIM alignment): DKIM is the most reliable path through forwarding and modern email plumbing.
  Strict alignment forces your vendors and systems to sign using your domain (or a properly aligned subdomain strategy).
• aspf=r (relaxed SPF alignment): SPF breaks constantly due to forwarding and NAT’ed relays. Relaxed SPF saves you from
  punishing legitimate flows while you migrate the world to DKIM-first authentication.
• sp=quarantine: don’t forget subdomains. Attackers don’t.
• rua/ruf/fo: you need telemetry. Not perfect telemetry, but enough to identify which systems are failing and why.

The punchline: DMARC is not “SPF and DKIM exist.” DMARC is “SPF or DKIM passes AND aligns with the domain the user sees.”
That alignment clause is where spoofing dies and where deliverability can accidentally die too.

One quote that still holds up in operations: paraphrased idea from Werner Vogels: “Everything fails, all the time; design and operate assuming that.”
DMARC rollouts fail in boring ways. Plan for that, and you won’t learn it the expensive way.

Joke #1: Email authentication is the only security system where “forwarding” counts as “tampering,” but everyone does it anyway.

When you should go straight to p=reject

Rare, but it exists. If your domain is not used for any legitimate email (a parked domain, or a brand domain that only redirects to
a separate mail domain), then go straight to:

cr0x@server:~$ dig +short TXT _dmarc.brand-only.example
"v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc-rua@brand-only.example; sp=reject"

If nothing legitimate should come from it, be ruthless. Otherwise, quarantine-first is how you keep revenue emails out of the graveyard.

DMARC in production terms: what actually happens to a message

DMARC is a policy evaluated by the receiver (Gmail, Microsoft, Yahoo, your customer’s gateway). It reads your DNS record, checks the message’s
authentication results, and decides what to do.

The three domains that matter (and why people get confused)

• Header From: the domain humans see in the From: header. DMARC aligns to this. This is the identity you’re protecting.
• SPF domain: the domain used during SMTP MAIL FROM / Return-Path evaluation. Often a bounce domain.
• DKIM d= domain: the domain that signs the message.

DMARC passes if (SPF passes and aligns) OR (DKIM passes and aligns).
Receivers then apply your policy: none, quarantine, or reject.

Alignment: the part everyone trips over

Alignment is a string comparison rule, not a philosophical concept.

• Relaxed alignment (r): subdomains align. mail.example.com aligns with example.com.
• Strict alignment (s): must match exactly. mail.example.com does not align with example.com.

Why be strict on DKIM but relaxed on SPF in the recommended policy?
Because DKIM is the durable identity. SPF is an IP-path check; the path changes. DKIM survives when the message takes the scenic route.

Deliverability reality: receivers don’t only use DMARC

DMARC is table stakes. Receivers also score reputation, content, engagement, complaint rate, and sending patterns.
DMARC makes you eligible for trust. It doesn’t guarantee inbox placement. What it does do is prevent attackers from borrowing your
domain reputation to send garbage. That, indirectly, helps your legitimate mail.

If you want to stop spoofing without losing mail, treat DMARC like a rollout of a distributed system: observe, enforce gradually, validate with
telemetry, then tighten.

Interesting facts and historical context (the stuff that explains the weirdness)

• DMARC emerged because SPF and DKIM solved different halves of the problem. SPF authenticates a sending path; DKIM authenticates a message. Neither alone protects the visible From domain reliably.
• SPF predates widespread cloud email. It was designed when “the server that sends your mail” was a more stable concept than it is now.
• DKIM was built to survive forwarding. It signs the message body and selected headers, so it can pass even when the SMTP path changes—unless a forwarder rewrites content.
• DMARC is receiver-driven. You publish policy; recipients decide enforcement. That’s why “we set p=reject” doesn’t mean everyone rejects in the same way.
• DMARC popularized domain-based reporting at scale. Aggregate reports (RUA) became the first consistent way for many orgs to inventory shadow senders.
• Subdomain policy (sp=) exists because attackers love subdomains. Organizations forget them; phishers don’t.
• Early DMARC deployments leaned on quarantine. Organizations learned that going straight to reject often breaks legitimate marketing and ticketing flows.
• ARC exists largely because of DMARC’s side effects. Forwarding and mailing lists can break DMARC; ARC helps preserve authentication context across hops.
• “p=none” is not harmless. It’s a monitoring mode, but it also signals to receivers that you’re not enforcing. That can affect how seriously they treat spoofing attempts.

Mini-story #1: the wrong assumption that broke outbound

A mid-sized SaaS company decided to “finish the DMARC project” before their annual compliance audit. They had SPF, they had DKIM (somewhere),
and they had a spreadsheet listing vendors. Someone assumed that was enough.

They flipped DMARC from p=none to p=reject on the apex domain late Friday. Monday morning, customer success couldn’t email onboarding docs.
Sales reps complained that prospects “stopped replying.” Finance said invoices were bouncing. Support tickets piled up with screenshots of
“message rejected due to DMARC policy.”

The actual issue was boring: their CRM sent mail using a Return-Path domain owned by the vendor (SPF passed, but didn’t align), and DKIM signing
used d=vendor.example (DKIM passed, didn’t align). In p=none, nobody cared. In p=reject, receivers did.

The fix wasn’t heroic. They configured the vendor to sign with d=their-domain.example using a custom DKIM key, and set a dedicated bounce domain
that aligned. The key lesson: authentication passing is not enough; it must align to the domain you put in From.

They also learned to never deploy enforcement without a recent report baseline. The reports had been going to an unattended mailbox.
Telemetry that nobody reads is performance art.

Mini-story #2: an optimization that backfired

A large company with multiple business units wanted to reduce DNS lookups from SPF because of the 10-lookup limit. An engineer proposed an
optimization: replace a chain of includes with a single vendor include, and tighten SPF to a smaller set of IPs “for security.”

The change did reduce lookups. It also caused intermittent SPF softfails and permerrors for legitimate mail because some mail was routed through
regional outbound relays not on the “tight” list. Worse, the marketing platform’s sending IPs rotated, and the vendor include they relied on was
not the one actually used for their account’s mail stream.

DMARC was set to quarantine. Messages that used to pass via SPF alignment now failed SPF, and DKIM wasn’t present on certain automated flows
because of a legacy app sending through an internal relay that stripped headers and did not sign.

Deliverability didn’t collapse instantly. It degraded in that slow, insulting way: some recipients received, others didn’t, and the patterns
looked random. Incident response wasted time because it didn’t reproduce consistently.

The resolution was to stop treating SPF as the primary identity. They restored SPF to a stable, correct baseline and prioritized DKIM signing on
every outbound stream, using aligned d= domains. The optimization was real, but it was applied to the wrong layer. SPF should be accurate and
minimal, not “clever.”

Mini-story #3: the boring practice that saved the day

Another organization—unsexy, operationally mature—had a practice: every outbound system had an owner, a runbook, and a monthly DMARC report review.
Nobody got promoted for it. That’s why it worked.

They ran DMARC at p=quarantine for months while they migrated vendors. Each time a new sender appeared in RUA reports, it created a ticket:
identify the owner, validate the stream, configure DKIM with aligned d=, and confirm SPF alignment or document why it won’t be relied upon.

One day, a phishing campaign hit the industry, spoofing executive names at multiple companies. Their domain was targeted too. Customers saw the
attacks in the wild, but the major mailbox providers rejected or spammed almost all of it because DMARC enforcement was already in place.

The best part: they didn’t have to scramble. They already had the knobs set. They simply increased monitoring and checked that no legitimate
stream had regressed. That’s what “boring” looks like when it pays your salary.

Joke #2: The most reliable email system is the one nobody notices—until the CFO can’t send a spreadsheet and suddenly it’s a “priority incident.”

Fast diagnosis playbook

When deliverability or spoofing control is failing, you need a fast path to the bottleneck. Here’s the order that saves the most time in the most
incidents.

First: confirm what domain identity is being protected

• What’s the Header From domain users see?
• Is this the apex domain, a subdomain, or a lookalike?
• Do you have a DMARC record for that exact domain (including subdomain policy behavior)?

Second: check DMARC evaluation on a real sample

• Grab one affected message (or send a test to a controlled mailbox) and read Authentication-Results.
• Determine which of SPF or DKIM is passing, and whether it aligns.
• If neither aligns, DMARC will fail no matter how “correct” SPF or DKIM looks in isolation.

Third: inventory senders via DMARC aggregate data

• Which IPs are sending as your domain?
• Which sources fail and at what volume?
• Are failures concentrated in a vendor, a region, or a specific application?

Fourth: decide whether the failure is enforcement-related or reputation-related

• If you see hard bounces citing DMARC, it’s enforcement/alignment.
• If you see “accepted but spam,” it can be reputation, content, or authentication inconsistency (intermittent DKIM, SPF permerror, etc.).

Fifth: make one change at a time

Email is a distributed system you don’t control. If you change DMARC policy, SPF, DKIM, and sending infrastructure at once, you’ll learn nothing
and still break things.

Hands-on tasks: commands, outputs, and decisions (12+)

These are practical tasks you can run from a shell. They assume you have basic DNS tools and access to message headers from a mailbox.
For header analysis, you’ll paste content into files locally. The point is not the tooling; it’s the decision-making.

Task 1: Fetch the DMARC record and validate syntax

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

What the output means: You have a DMARC record, it’s DMARC1, and policy enforcement is quarantine for the domain and subdomains.

Decision: If there’s no record or multiple conflicting records, fix that first. DMARC is “one TXT record” territory.

Task 2: Confirm you don’t have multiple DMARC TXT records (a classic footgun)

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; sp=quarantine"

What the output means: Exactly one record returned in the answer section.

Decision: If you see two TXT answers, consolidate into one. Some receivers pick one arbitrarily, which is the email equivalent of playing roulette with payroll.

Task 3: Check SPF record and spot the 10-DNS-lookup problem

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

What the output means: SPF uses multiple includes; each include can trigger additional DNS lookups.

Decision: If you suspect lookup limits, simplify SPF or move flows to DKIM-first. Don’t “optimize” SPF by removing legitimate senders.

Task 4: Inspect DKIM selector presence for a known sender

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

What the output means: DKIM selector s1 exists and has a public key.

Decision: If the selector is missing or truncated, fix DNS publishing before touching DMARC policy.

Task 5: Send a test message and verify Authentication-Results header (from a saved header file)

cr0x@server:~$ grep -i "^Authentication-Results:" -A2 message.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=Qd9...
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com

What the output means: DKIM and SPF both pass. DKIM is signing as example.com.

Decision: This stream should pass DMARC assuming Header From is example.com and alignment settings allow it.

Task 6: Check DMARC result in headers (the receiver tells you)

cr0x@server:~$ grep -i "^Authentication-Results:" -A5 message.eml | grep -i dmarc
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

What the output means: DMARC passed and policy would quarantine failures; disposition NONE means no enforcement action was applied.

Decision: If DMARC fails here, stop arguing about SPF “being correct” and fix alignment or DKIM signing.

Task 7: Detect a common failure: DKIM passes but does not align

cr0x@server:~$ grep -i "^Authentication-Results:" -A3 message.eml
Authentication-Results: mail.receiver.example;
       dkim=pass header.i=@vendor.example header.s=selector1 header.b=abc...
       spf=pass smtp.mailfrom=vendor-bounces.example

What the output means: DKIM passes for vendor.example, SPF passes for vendor-bounces.example. If Header From is example.com, neither aligns.

Decision: Configure vendor for custom DKIM d=example.com (or an aligned subdomain strategy) and use an aligned bounce domain where possible.

Task 8: Verify relaxed vs strict alignment implications

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=s; aspf=r"

What the output means: DKIM must match exactly; SPF can align via subdomain.

Decision: If your legitimate mail is signed as d=mail.example.com but From is example.com, strict DKIM will fail alignment. Either sign with d=example.com or relax adkim (usually not my favorite, but sometimes pragmatic).

Task 9: Confirm MX and who actually receives inbound (spoofing targets inbound too)

cr0x@server:~$ dig +short MX example.com
10 mx1.mailhost.example.
20 mx2.mailhost.example.

What the output means: These are your inbound receivers; they will enforce inbound policies and provide headers/logs.

Decision: If your inbound is split across providers, align enforcement expectations and investigate where failures are observed.

Task 10: Check if subdomains are accidentally unprotected

cr0x@server:~$ dig +short TXT _dmarc.mail.example.com

What the output means: No explicit DMARC record on the subdomain.

Decision: If your apex DMARC has sp=quarantine or sp=reject, subdomains inherit. If not, publish DMARC on high-risk subdomains or set sp= appropriately.

Task 11: Validate reverse DNS (not DMARC, but it will ruin your day)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout.example.com.

What the output means: PTR exists for the sending IP, which helps reputation and acceptance.

Decision: If there’s no PTR or it points to something sketchy, fix rDNS with your ISP/cloud provider. DMARC won’t compensate for bad sender hygiene.

Task 12: Check that the HELO/EHLO name resolves (again, not DMARC, still important)

cr0x@server:~$ dig +short A mailout.example.com
203.0.113.10

What the output means: Forward DNS matches the hostname used by the outbound server.

Decision: If the name doesn’t resolve or points elsewhere, fix it. Some receivers penalize sloppy SMTP identity.

Task 13: Spot SPF permerror risk by listing includes (manual sanity check)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 include:_netblocks.google.com ~all"

What the output means: Includes can nest; your original SPF record may exceed the lookup limit depending on what those includes expand into.

Decision: If you’re near the limit, reduce includes, move some streams to dedicated subdomains with separate SPF, or rely on DKIM alignment more consistently.

Task 14: Verify DKIM signature is present in the message

cr0x@server:~$ grep -i "^DKIM-Signature:" -m1 -n message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:mime-version; bh=...; b=...

What the output means: The message is signed with d=example.com. This is the identity DMARC can align to.

Decision: If DKIM signature is missing intermittently, find which system path strips it (relays, gateways, or apps).

Task 15: Confirm that your DMARC report mailbox exists and receives mail

cr0x@server:~$ host -t MX example.com
example.com mail is handled by 10 mx1.mailhost.example.
example.com mail is handled by 20 mx2.mailhost.example.

What the output means: Your domain has working MX. This doesn’t prove the mailbox exists, but it confirms inbound routing.

Decision: If you publish rua to a mailbox that doesn’t exist or rejects large attachments, you’ll be blind. Ensure the mailbox is monitored and can accept report volume.

Checklists / step-by-step plan

Step-by-step rollout that stops spoofing without losing mail

1. Inventory legitimate senders.
   Use existing knowledge (IT, marketing, billing, support) and confirm with DMARC aggregate data once available.
   Goal: a list of systems that send “From: @yourdomain”.
2. Pick your domain strategy.
   Decide whether you will:
   • Send everything from the apex domain (harder), or
   • Use functional subdomains for third parties (recommended): billing.example.com, news.example.com, support.example.com.

   This reduces blast radius and makes alignment more controllable.

3. Set up DKIM for every sender.
   Prioritize DKIM over SPF for long-term reliability. Require aligned d= domains.
4. Publish SPF that is correct, not clever.
   Keep it minimal. Avoid chaining 9 includes and praying. Use subdomains to separate concerns if needed.
5. Publish DMARC with p=none only long enough to collect baseline.
   Usually 1–2 weeks is plenty if your traffic is normal.
6. Move to p=quarantine, pct=100.
   This is where spoofing gets meaningfully harder and you still have deliverability forgiveness.
7. Fix alignment failures.
   Use reports and headers to identify which senders fail and why. Get vendors to support custom DKIM and aligned bounce domains.
8. Lock down subdomains.
   Set sp=quarantine or sp=reject. Publish explicit DMARC records for high-risk subdomains if needed.
9. Graduate to p=reject.
   Only when:
   • Your high-volume legitimate streams pass DMARC consistently.
   • You understand the remaining failures and have consciously accepted them (or moved them to subdomains with separate policy).
10. Keep the boring loop alive.
    Monthly review of reports, ownership, and vendor changes. Email ecosystems drift. So do vendor settings.

Operational checklist for “we’re about to change DMARC policy”

• Do we have a rollback plan (DNS TTL, previous record string saved, change window)?
• Do we know the current pass rate per sender stream?
• Are high-risk third parties (marketing, CRM, ticketing) DKIM-signed with aligned d=?
• Is SPF under lookup limits and free of permerrors?
• Do we have subdomain policy set (sp=)?
• Do we have a monitored mailbox for RUA/RUF and a way to process XML attachments?
• Are we prepared for forwarded mail edge cases (mailing lists, alumni forwards, customers forwarding receipts)?

Common mistakes: symptom → root cause → fix

1) Symptom: “DMARC fail” but SPF and DKIM both say “pass” somewhere

Root cause: One passes for a different domain. No alignment with Header From.

Fix: Ensure DKIM signs with d= aligned to the From domain (prefer exact alignment if you set adkim=s). Use a custom bounce domain for SPF alignment where possible.

2) Symptom: Marketing emails suddenly go to spam after moving to p=quarantine

Root cause: The vendor signs with their own domain or uses a non-aligned Return-Path; DMARC now fails and receivers quarantine.

Fix: Configure vendor custom DKIM for your domain or send from a dedicated subdomain with its own DMARC policy and authentication.

3) Symptom: Some transactional emails pass, others fail, from the same “system”

Root cause: Multiple outbound paths: some signed, some not; or some routed through a relay that modifies content and breaks DKIM.

Fix: Trace the path and standardize: either sign at the edge after all rewriting, or ensure intermediaries don’t modify signed parts. Verify with message samples from each path.

4) Symptom: DMARC reports show a ton of unknown IPs sending as your domain

Root cause: Spoofing attempts are common, and p=none lets them “look” more legitimate to some receivers. Also, you may have shadow IT senders.

Fix: Move to quarantine enforcement; investigate high-volume sources. For legitimate unknowns, assign ownership and configure aligned DKIM/SPF.

5) Symptom: Receivers say SPF “permerror” or “temperror”

Root cause: SPF lookup limit exceeded, malformed SPF record, or DNS timeouts.

Fix: Reduce includes, flatten SPF responsibly (without breaking ownership), or segment by subdomain. Improve DNS reliability.

6) Symptom: Forwarded messages (customers auto-forwarding invoices) fail DMARC and get quarantined

Root cause: SPF fails on forward (different sending IP), and DKIM may break if the forwarder rewrites content or modifies headers.

Fix: Prioritize DKIM robustness (sign the final form, avoid content rewriting). Consider ARC support if you operate forwarders; for external forwards, accept some loss and mitigate with alternate delivery (portals, authenticated customer accounts).

7) Symptom: Subdomain spoofing continues even after apex is locked down

Root cause: No sp= tag and no DMARC records on subdomains.

Fix: Set sp=quarantine or sp=reject on the apex DMARC record, and explicitly publish DMARC for high-value subdomains.

8) Symptom: You set p=reject and now a partner says your emails “disappear”

Root cause: Their gateway rejects DMARC failures; your legitimate mail is failing alignment due to a vendor or relay.

Fix: Temporarily move to quarantine while you remediate, or move the failing stream to a subdomain with a less strict policy as an interim measure. Then fix alignment properly.

FAQ

1) Is “p=none” useless?

It’s useful for discovery, but it doesn’t stop spoofing. Treat it like logging without alerting: fine briefly, irresponsible forever.
Move to quarantine once you have a baseline and owners assigned.

2) Why not start with p=reject if spoofing is bad?

Because your legitimate mail probably has unknown senders and alignment problems. Reject turns those into hard failures immediately.
Quarantine is enforcement with a safety net while you clean up the estate.

3) Should I rely on SPF or DKIM for DMARC pass?

Prefer DKIM alignment for durability. SPF breaks on forwarding and complex routing. Use SPF as a helpful signal, not your primary identity.

4) What does “alignment” practically mean for vendors?

It means the vendor must sign with your domain in DKIM (custom DKIM), and ideally use a bounce/Return-Path domain that is within your domain
(custom return-path). Without that, DMARC will fail when From is your domain.

5) What are adkim and aspf settings I should choose?

A solid default is adkim=s and aspf=r during rollout. It pushes vendors to do DKIM correctly while not over-penalizing SPF path variance.
If your environment signs from subdomains intentionally, adjust adkim accordingly or change your From domain strategy.

6) Do I need RUF (forensic) reports?

Sometimes. Many receivers limit or redact them for privacy reasons, and volume can be messy. RUA aggregate reports are the workhorse.
If you enable RUF, route it to a controlled mailbox and be prepared to handle sensitive content responsibly.

7) What about mailing lists that modify the subject or add footers?

They can break DKIM signatures by modifying signed content. If SPF also fails (common with forwarding), DMARC fails.
Your options: encourage list operators to preserve DKIM, rely on ARC where supported, or accept that some list flows won’t be reliable under strict enforcement.

8) How do subdomains help deliverability and security?

They isolate reputation and policy. Put marketing on news.example.com, transactional on billing.example.com, and keep human mail on the apex.
Then tune DMARC per subdomain if needed while still protecting the brand.

9) If DMARC passes, why are messages still going to spam?

Because authentication is not reputation. Check sending IP reputation, complaint rates, engagement, content patterns, and consistency.
DMARC pass is necessary; it’s not sufficient.

10) How long does it take for DMARC changes to take effect?

DNS TTL governs propagation, but receivers cache and evaluate at their own cadence. Expect hours, not minutes.
Plan changes with TTL reductions ahead of time if you need faster rollback.

Conclusion: next steps you can ship this week

The “one DMARC policy” that actually works in production is not a magic string; it’s a posture: enforce with quarantine at 100%, force DKIM alignment,
keep SPF relaxed enough to avoid self-inflicted wounds, and use reporting to hunt down every sender pretending to be you.

Do this next

1. Publish or verify DMARC at the apex with p=quarantine; pct=100; adkim=s; aspf=r; sp=quarantine.
2. Run the hands-on tasks above for your top 3 outbound streams and confirm DMARC pass and alignment in real headers.
3. Pick a subdomain strategy for third parties and start moving the messiest vendor there if they can’t do aligned DKIM quickly.
4. Set a calendar reminder: monthly DMARC report review with owners assigned. This is how you prevent regression.
5. Once your legitimate streams are consistently passing, switch to p=reject with confidence, not optimism.

Spoofing stops when receivers can reliably tell what’s yours. Deliverability survives when you stop guessing and start operating identity like a system:
with telemetry, ownership, and gradual enforcement.