The email industry believed Microsoft abandoned SPF2/PRA in 2014. Our investigation into 25,000+ daily bounces across seven sending domains proved otherwise. One forgotten DNS record, invisible to every DMARC dashboard in use, was the cause.

The Anomaly

Earlier this year, we were investigating persistent Microsoft deliverability issues for one of the largest European B2C online retailers, sending across multiple country domains at significant daily volume.

The bounce pattern was consistent and unambiguous:

smtp;550 5.7.515 Access denied, sending domain doesn't meet
the required authentication level. The sender's domain in the
5322.From address doesn't meet the authentication requirements
defined for the sender.

Spf= Fail , Dkim= Pass , DMARC= Pass

The scale was significant. Across seven sending domains, we were losing tens of thousands of emails per day to these rejections. The problem had been building for months:

By early 2026 we were losing over 25,000 emails per day to these rejections across all domains. The trend was worsening.

What made this particularly frustrating: DKIM was passing. DMARC was passing. The standard SPF record was correct. Microsoft's own error message named the exact domain it checked and returned Spf= Fail anyway.

The Investigation

We worked through every hypothesis systematically.

Step 1: SPF Record Simplification

Our first hypothesis was that complex include: chains were the problem - either hitting the 10-lookup DNS limit or containing stale entries pointing to infrastructure no longer in use.

We replaced all sending domain SPF records with clean flat records, covering 100% of sending IPs with direct /24 CIDR blocks:

v=spf1 ip4:91.x.x.0/24 ip4:94.x.x.0/24 ip4:193.x.x.0/24 ip4:217.x.x.0/24 -all

We verified via DMARC reports that every single active sending IP fell within these blocks.

Result: Partial improvement on some domains. Rejections continued at significant scale, weeks after the change.

Step 2: Ruling Out DNS Caching

Microsoft is known for aggressive DNS caching of SPF records. We waited three weeks. Numbers slowly declined but never reached zero. We cross-referenced every bouncing IP against our sending infrastructure map, confirming each one was within our authorised CIDR blocks.

The SPF record was correct. The IPs were covered. Yet Microsoft continued returning Spf= Fail.

Step 3: Verifying the Impossible

At this point we had an uncomfortable finding. Microsoft was explicitly reporting Spf= Fail for a domain when:

• The sending IP was in that domain's SPF record
• DKIM was passing
• DMARC was passing via DKIM alignment
• Microsoft's own error message named the exact domain it checked

Every possible explanation was eliminated:

• DNS caching: three weeks elapsed, no full resolution
• Missing IPs: verified all covered
• DNS lookup limit: new flat record has zero lookups
• Envelope-from mismatch: would have caused millions of failures, not thousands
• Composite authentication reputation: would not explain the consistent pattern

Step 4: The Discovery

During a continued DNS audit, we fetched all TXT records for the primary sending domain and noticed something unexpected alongside the standard v=spf1 record:

spf2.0/pra include:legacy-server1.olddomain.com include:legacy-server2.olddomain.com
include:legacy-server3.olddomain.com include:legacy-server4.olddomain.com -all

An SPF2/PRA record. Also known as a Sender ID record.

Microsoft's proprietary predecessor to SPF, reportedly abandoned by Microsoft themselves around 2014.

The problem was immediately clear. This spf2.0/pra record pointed to old include chains that had never been updated to include the current sending IP ranges. When we overhauled the standard SPF record months earlier, we updated the v=spf1 record. The spf2.0/pra record was forgotten entirely. It still pointed to legacy infrastructure that did not cover a single current sending IP.

We audited all sending domains in the portfolio. Eleven domains had identical spf2.0/pra records, all pointing to the same stale legacy infrastructure.

The Fix

We removed the spf2.0/pra TXT records from all affected domains.

One DNS change. No other modifications.

What Is SPF2/PRA and Why Does This Matter?

A Brief Technical History

Sender ID (SPF2/PRA, Purported Responsible Address) was a Microsoft-developed email authentication standard proposed in 2004. It was an attempt to extend SPF - which validates the MAIL FROM envelope address - to also check the From: header directly.

Where standard SPF evaluates the 5321.From (envelope sender), Sender ID evaluated the 5322.From (the header From: address the recipient sees). Microsoft called this the Purported Responsible Address, or PRA.

Sender ID was rejected by the IETF in 2005 due to conflicts with open-source licences and technical objections from the broader community. It was published as an Experimental RFC (RFC 4406) but never became a standard. The email industry moved on. Microsoft themselves were reported to have stopped evaluating it around 2014.

The Industry Consensus - Which Appears to Be Wrong

For the past decade, the accepted position in the email deliverability community has been:

SPF2/PRA is dead. No major provider evaluates it. You can safely ignore these records.

This belief is so widespread that tools, guides, and deliverability consultants universally treat spf2.0/pra records as harmless relics. Most DNS audit tools do not even flag them.

Our data contradicts this assumption, at least for Microsoft.

The evidence is not circumstantial:

1. The Spf= Fail bounces came exclusively from Microsoft infrastructure (Hotmail, Outlook, Live)
2. Sending IPs were provably covered by the standard v=spf1 record
3. DMARC passed via DKIM alignment, proving the standard authentication stack was working
4. The only change made was removing spf2.0/pra records
5. Bounces dropped 99%+ within 24 hours across five domains
6. The effect persisted across multiple subsequent high-volume send days

An Important Nuance: Not All Microsoft Infrastructure Behaves the Same

One observation from our data deserves specific attention: the failures we documented were persistent but not universal. At peak, we lost over 25,000 emails per day to these rejections, but this represented only a fraction of total Microsoft-bound traffic. The majority of emails to Hotmail, Outlook, and Live addresses delivered without issue.

This is significant. If SPF2/PRA evaluation were applied uniformly across all of Microsoft's receiving infrastructure, we would expect to see failures in the millions per day, affecting every single email sent to a Microsoft-hosted address. That is not what we observed.

Our hypothesis is that SPF2/PRA evaluation is not implemented at the MX level across Microsoft's entire receiving fleet. Instead, it appears to be present on a subset of the infrastructure - specifically as a legacy code path rather than a legacy server.

Here is the key observation that supports this: the bounce messages we received contained DMARC= Pass alongside Spf= Fail. DMARC did not exist when Sender ID was originally built. If these bounces were generated by a true legacy server from the Sender ID era, it would not know what DMARC is, let alone report it.

This tells us something significant: the SPF2/PRA evaluation is almost certainly not happening on an old server that was forgotten. The more likely explanation is that the evaluation logic - the code that checks spf2.0/pra records - exists as a component within modern Microsoft infrastructure that was never removed when Microsoft nominally deprecated Sender ID. The modern server runs the full authentication stack including DMARC, but also still executes this legacy evaluation path, and when that path returns a failure, it is included in the composite authentication result.

Think of it less as an old server that was forgotten and more as an old code path inside a modern server that was never cleaned up. The bounce message is modern. The evaluation that triggers it is not.

This also explains the 1–5% failure rate: not every Microsoft receiving server runs this code path. Mail that routes through infrastructure where the legacy code path is active returns Spf= Fail. Mail that routes through infrastructure where it was removed or never present processes only standard SPF and passes without issue.

We cannot confirm this from outside Microsoft's infrastructure. What we can confirm is the correlation: the spf2.0/pra record existed, Microsoft returned Spf= Fail for a consistent subset of traffic, removing the record dropped those failures by 99%+, and the effect has held across subsequent high-volume send days.

Why DMARC Data Alone Will Not Catch This

This is critical: DMARC aggregate reports show spf_result based on standard v=spf1 evaluation only. Microsoft's internal SPF2/PRA evaluation is entirely separate and not reflected in DMARC data.

If you rely exclusively on DMARC monitoring - which most teams do - you will see spf=pass in your aggregate reports while simultaneously receiving Spf= Fail bounce messages from Microsoft. The signals appear contradictory. This is why the problem is so difficult to diagnose and why it can persist for months undetected.

In our case: seven months and hundreds of thousands of lost deliveries, invisible to DMARC dashboards throughout.

The only signal is systematic analysis of delivery receipts and bounce messages, not DMARC dashboards.

The Audit: Check Your Domains Now

If you send email to Microsoft-hosted addresses - Hotmail, Outlook, Live, MSN - audit your sending domains immediately.

# Check for SPF2/PRA records
dig TXT yourdomain.com | grep spf2

Or via Cloudflare DNS-over-HTTPS without installing anything:

https://cloudflare-dns.com/dns-query?name=yourdomain.com&type=TXT

Look for any TXT record beginning with spf2.0/pra.

If you find one:

1. Check whether the included IP ranges or include: chains still cover your current sending infrastructure
2. If there is any divergence from your v=spf1 record, remove the spf2.0/pra record
3. No other mail provider evaluates SPF2/PRA. There is no legitimate reason to keep these records.

The fix takes five minutes. The impact, if you have this problem, will be visible within 24 hours.

Key Takeaways

spf2.0/pra records are not dead. Microsoft still evaluates them in 2026. Any organisation with these records and a mismatch between the authorised IPs and actual sending infrastructure will experience Microsoft rejections that look like standard SPF failures but are not.

SPF updates require auditing spf2.0/pra too. When you update your v=spf1 record - for any reason - check whether a spf2.0/pra record exists and ensure it is either consistent or removed. The two records evolve independently unless you maintain them together.

Removal is the safest action. Since no other provider evaluates SPF2/PRA, keeping these records creates ongoing maintenance risk with no benefit. Remove them.

DMARC monitoring will not surface this. DMARC reports show standard SPF evaluation only. Microsoft's SPF2/PRA check is invisible to DMARC tooling. The only way to detect this problem is through systematic bounce analysis.

Bounce analysis is not optional. This issue was discoverable only through detailed analysis of delivery receipts. If your deliverability monitoring relies on DMARC dashboards and ESP-level reporting, problems like this will go undetected for months. In our case: seven months and hundreds of thousands of lost deliveries.

This investigation was possible only because Engagor ingests raw SMTP delivery receipts and bounce messages - not just DMARC aggregate data. Problems like this one, invisible to dashboards that rely on DMARC feeds, surface automatically in Engagor's bounce intelligence layer.

See how Engagor surfaces authentication anomalies →

Conclusion

The email industry has operated for over a decade under the assumption that SPF2/PRA is an irrelevant artifact of a failed standard. This investigation shows that assumption is wrong, at least where Microsoft is concerned.

A forgotten spf2.0/pra record - unchanged since the early days of Sender ID and pointing to infrastructure that had long since been replaced - was silently causing over 25,000 bounced emails per day across seven domains for at least seven months.

The fix was one DNS change. The impact was immediate and definitive.

If you manage email infrastructure for senders with long-established domains, check your spf2.0/pra records today. The command is four words. The fix, if needed, takes five minutes.

Analysis by the Engagor deliverability research team, May 2026.

Engagor is an Agentic Email Intelligence Platform that ingests raw SMTP events across ESPs and MTAs and surfaces deliverability anomalies autonomously. This investigation was conducted using Engagor's bounce intelligence and sender identity monitoring.