Deliverability Rescue
SPF, DKIM, DMARC alignment and blocklist cleanup on a Microsoft 365 tenant
Context
A sender running two domains through a shared Microsoft 365 tenant had poor inbox placement and no idea why. One domain scored 6.2/10 on mail-tester and was landing in spam at Outlook and Yahoo; the other looked healthy but shared the same infrastructure and the same neighborhood reputation. Business mail, real one-to-one correspondence, not bulk, was silently disappearing into junk folders, and the sender only knew because recipients occasionally mentioned it.
The audit found authentication that existed but failed silently: an SPF include chained to a dead domain, collapsing the entire evaluation to permerror at every receiver; DMARC published at p=none with no rua aggregate reporting, enforcing nothing and observing nothing; DKIM delegated through Microsoft 365 selector CNAMEs but unverified; and both sending IPs listed on subnet-level blocklists with generic reverse DNS. The work: forensic audit, root-cause repair, reputation cleanup, and proof by real placement measured against the Gmail/Yahoo/Microsoft bulk-sender baseline, then a monitoring cadence so it stays proven.
The Challenge
- Everything "looked configured", records existed for SPF, DKIM and DMARC, so the failure was invisible to anyone reading DNS without evaluating it the way receivers do.
- A single dead include inside SPF invalidated the whole record: permerror is not a partial failure, it is authentication absent.
- DMARC at p=none with no rua address meant months of failures had produced zero forensic data to work from.
- The blocklist listings were subnet-level (neighborhood reputation), not direct listings, a distinction that completely changes the remediation path.
- Fixes had to land on a live tenant carrying daily business mail, no downtime, no experimentation on production DNS.
Scope and Approach
-
01
Header-level forensic audit
Audited both domains the way receivers evaluate them: live DNS record walks, raw .eml collection from real recipient mailboxes, Authentication-Results and ARC chain inspection at Gmail, Outlook and Yahoo, SPF include-chain expansion against the RFC 7208 10-lookup ceiling, DKIM selector verification, and composite blocklist checks across ~70 lists. Every finding ranked by placement impact before anything was touched.
-
02
SPF reconstruction
Rebuilt the SPF record to eliminate the permerror: removed the include pointing at a defunct domain, verified every remaining mechanism resolves, confirmed the expanded chain sits safely under the 10-DNS-lookup limit, and kept the strict -all qualifier so the record asserts something once it evaluates cleanly.
-
03
DKIM verification through M365 delegation
Verified the selector1/selector2 CNAME delegation to the onmicrosoft.com namespace for both custom domains, confirmed 2048-bit signing on real messages, and checked relaxed alignment, header.d matching the visible From domain, on live mail, not just in the admin panel.
-
04
DMARC ramp: visibility first, enforcement second
Moved DMARC from a blind p=none to monitoring with rua aggregate reporting, reviewed the reports to confirm all legitimate mail paths authenticated, then ramped to p=quarantine at pct=100. Enforcement followed evidence, jumping straight to reject on a misconfigured domain is how legitimate mail gets destroyed.
-
05
Reputation and reverse-DNS cleanup
Diagnosed the UCEPROTECT-class listings as subnet-level neighborhood reputation rather than direct-spam evidence, verified the IPs were clean on every individual-level list that matters (Spamhaus ZEN, Barracuda, SpamCop), addressed the generic PTR / forward-confirmed rDNS gaps, and monitored delisting over two weeks rather than paying for expedited removal that reputation does not actually require.
-
06
Placement verification with real sends
Proved the fix the only way that counts: real messages to real mailboxes at Gmail, Outlook and Yahoo, headers pulled and read. Both domains reached 10/10 on mail-tester with spf=pass, dkim=pass, dmarc=pass end to end through Microsoft's outbound pool, and inbox placement confirmed per provider.
-
07
Handover and monitoring cadence
Documented every record change and its rationale in plain language, then moved to bi-weekly monitoring reports covering authentication state, blocklist status and live placement, because sender reputation is a trend line, not a checkbox.
Architecture flow
Technical Deep Dive
Why one dead include kills everything
SPF evaluation is all-or-nothing at the record level: an include that cannot resolve produces permerror, and under DMARC a permerror means SPF contributes nothing to alignment. The domain was not "mostly authenticated", it was unauthenticated at every receiver on earth because one referenced domain had quietly expired. Silent dependency rot in DNS is a real operational risk and exactly what scheduled monitoring exists to catch.
Reading Authentication-Results instead of dashboards
Admin panels show configuration intent; the Authentication-Results header shows what the receiving provider actually concluded. The audit worked from raw headers in recipient mailboxes, including the ARC chain Microsoft adds through its outbound pool, which is how the permerror and alignment state were established as facts rather than guesses.
Subnet listings are a different disease
UCEPROTECT L2/L3 list entire subnets and allocations when neighboring IPs misbehave. Panicking and paying for delisting, or migrating infrastructure, is the usual mistake. The correct read: confirm the individual IPs are clean on the lists receivers actually weight, fix what is controllable (rDNS, FCrDNS), and let the subnet listings age out, which they did within the two-week monitoring window.
The M365 outbound pool nuance
Mail from this tenant egresses through Microsoft's shared outbound infrastructure with Microsoft's HELO and PTR identities. That constrains what a tenant can control (no custom PTR on shared pool IPs) and makes domain-level authentication, SPF, DKIM, DMARC alignment on the custom domains, carry the entire reputation load. The remediation focused precisely there.
Engineering Decisions
Quarantine, not reject, as the enforcement target
p=quarantine at pct=100 delivers the anti-spoofing and reputation benefit while leaving a recovery path for edge-case legitimate senders discovered late. Reject is the right end state only after rua data shows sustained clean alignment, enforcement strength follows evidence, not bravado.
No paid delisting services
The listings that mattered were subnet-level and age out on their own once the neighborhood quiets; the individual-level lists were already clean. Paying for expedited removal would have spent the client's money on theater.
Bi-weekly monitoring as part of the deliverable
A one-time fix report is obsolete the day DNS changes or a new SaaS tool starts sending as the domain. The recurring report catches drift, new includes, DMARC failures, fresh listings, while it is still cheap to correct.
Results
- The failing domain from 6.2/10 to 10/10 on mail-tester; both domains verified aligned and clean.
- SPF permerror eliminated at the root; the record now evaluates cleanly under the 10-lookup ceiling with -all intact.
- DKIM verified end to end through the Microsoft 365 selector delegation; DMARC ramped from blind p=none to p=quarantine with rua visibility.
- Core fixes shipped in one week; subnet-level delisting confirmed over the following two.
- Placement proven by Authentication-Results headers at Gmail, Outlook and Yahoo, then held by a bi-weekly monitoring cadence.
Have a system that needs
this kind of work?
Tell me what is breaking or what you need built. I will reply with how I would approach it and what I would check first.