The Problem

Inbound mail was intermittently producing spf=temperror results in Exchange Online despite a valid, RFC 7208-compliant SPF record and no delivery failures. Messages were accepted and delivered, so no NDRs, no user-visible symptoms, but authentication headers showed this:

Authentication-Results: spf=temperror (sender IP is 209.85.128.197)
  smtp.mailfrom=yourdomain.com
Received-SPF: TempError (protection.outlook.com: error in processing
  during lookup of yourdomain.com: DNS Timeout)

External resolvers (Google (8.8.8.8), Cloudflare (1.1.1.1)), direct queries to the authoritative nameserver, all resolved the SPF record cleanly and consistently. The timeout was happening exclusively inside Exchange Online’s MTA infrastructure.

This post is about what it actually takes to diagnose this, prove it, and get Microsoft to act on it.

Understanding What’s Actually Happening

SPF evaluation follows MAIL FROM, not the originating IP

SPF is evaluated by the receiving system against the domain in the SMTP MAIL FROM (envelope sender), per RFC 7208. When something like Mimecast sits between the internet and Exchange Online as an inbound gateway, it applies SRS Sender Rewriting Scheme, which rewrites the envelope sender to your own domain for bounce routing purposes.

The practical result: Exchange Online sees inbound mail from Gmail, relayed through Mimecast, but with smtp.mailfrom=yourdomain.com. It then evaluates your SPF record, not Gmail’s. This is expected behavior, not a misconfiguration.

[Gmail sender] --> [Mimecast relay] --> [Exchange Online]
                   SRS rewrites MAIL FROM to yourdomain.com
                   Exchange Online evaluates yourdomain.com SPF record

This also means enabling Enhanced Filtering for Connectors in Defender (Policies & Rules > Threat Policies > Enhanced Filtering for Connectors) does not change the SPF evaluation path. Enhanced Filtering tells Exchange Online to look past Mimecast’s IP for reputation and filtering purposes, it does not undo Mimecast’s envelope rewrite. You can verify this by checking the smtp.mailfrom field in Authentication-Results after enabling it; it will still show your domain.

What temperror actually means

RFC 7208 Section 2.6.7 defines temperror as a transient DNS resolution failure at the evaluating system. Specifically, if the receiving system’s DNS resolver times out during any step of the SPF lookup chain, evaluation halts and returns temperror. This is explicitly a receiver-side failure, the sender’s record validity is irrelevant.

The key clause from RFC 7208 Section 5.1: if a DNS query times out, “the mechanism stops and the topmost check_host() returns ’temperror’.”

Verifying Your SPF Record is Not the Problem

Before engaging support, rule out your own record completely.

Check lookup depth

RFC 7208 hard-limits SPF evaluation to 10 DNS-querying mechanisms (includes, a, mx, ptr, exists). Count only mechanisms that require DNS lookups – ip4: and ip6: entries are free. A record like:

v=spf1 ip4:x.x.x.x include:us._netblocks.mimecast.com include:sendgrid.net
  include:_spf.google.com include:_spf.qp-mail.com
  include:spf.protection.outlook.com -all

Has 5 top-level includes. Each expands recursively. Run a full expansion check at MXToolbox SPF checker to get the actual recursive count before assuming you’re under the limit.

Verify authoritative TTL, not cached TTL

This distinction matters and is frequently confused, including by support engineers running diagnostic tooling against caching resolvers.

Wrong: queries a caching resolver, returns remaining TTL:

dig TXT yourdomain.com +ttl | grep spf1
# Returns something like: yourdomain.com. 1553 IN TXT "v=spf1 ..."
# 1553 is time remaining on a cached response, not the configured TTL

Right: queries the authoritative nameserver directly:

# First, find your authoritative nameservers
dig NS yourdomain.com +short

# Then query one directly
dig TXT yourdomain.com +ttl @your-auth-ns.example.com | grep spf1
# Returns: yourdomain.com. 3600 IN TXT "v=spf1 ..."
# 3600 is the actual configured TTL from the zone file

If a support engineer tells you your TTL is 1800 based on their diagnostic tooling, there’s a reasonable chance they queried a caching resolver and observed a decaying cached value. The authoritative query is the source of truth.

Escalating to Microsoft Engineering

This is where the process gets interesting. The standard M365 support tier is vendor-staffed and does not have direct access to Exchange Online’s internal MTA telemetry or the ability to open ICM (internal engineering) tickets unilaterally. Getting a platform-level issue in front of Exchange Online engineering requires navigating this structure deliberately.

What Microsoft support will ask for

Based on internal escalation intake criteria that surfaced during this case, a PG (Product Group) escalation for SPF timeout issues requires:

  1. Advanced Hunting results: EmailEvents table queries showing SPF/DKIM authentication statistics. Note: this requires Microsoft Defender for Office 365 Plan 2. If your tenant doesn’t have that license, this table doesn’t exist in your schema and the query will fail with a semantic error. This is worth flagging explicitly, it’s a licensing gap in the intake process, not a data availability problem.

  2. Comprehensive domain list: all affected sending domains

  3. Message headers: full internet headers from affected messages showing spf=temperror in the Authentication-Results field. Export as .eml from OWA (three-dot menu on a message > Download) or pull via PowerShell.

  4. DNS output: authoritative TTL verification (use the method above)

  5. Retry list status: whether the domain is on the AntispamRetrySpfWithExtendedTimeouts list (kicker: you have no way of knowing this but Microsoft support expects it)

Item 5 is the most important and the least publicized. AntispamRetrySpfWithExtendedTimeouts is an internal Exchange Online list that grants specific domains an extended DNS timeout window during SPF evaluation. It’s the per-domain operational workaround for exactly this problem. Its existence won’t surface in public documentation, it appeared in this case only because an engineer attached an internal intake criteria document that included it as a checklist item.

If you are hitting intermittent SPF temperror on a valid record, asking explicitly whether your domain is on this list and what the process is for requesting addition is the right question to push to.

How to pull message headers via PowerShell

If you need to collect headers programmatically rather than opening individual messages in OWA:

Connect-ExchangeOnline

$trace = Get-MessageTrace `
  -StartDate (Get-Date).AddDays(-10) `
  -EndDate (Get-Date) `
  -PageSize 1000

$trace | ForEach-Object {
    $detail = Get-MessageTraceDetail `
        -MessageTraceId $_.MessageTraceId `
        -RecipientAddress $_.RecipientAddress
    $authEvent = $detail | Where-Object { $_.Detail -like "*temperror*" }
    if ($authEvent) {
        [PSCustomObject]@{
            Received       = $_.Received
            Sender         = $_.SenderAddress
            Recipient      = $_.RecipientAddress
            MessageTraceId = $_.MessageTraceId
            Detail         = ($authEvent.Detail | Select-Object -First 1)
        }
    }
} | Export-Csv -Path "$env:USERPROFILE\Desktop\spf_temperror_hits.csv" -NoTypeInformation

This gives you a CSV of every temperror hit in the last 10 days. From there, search for the specific senders in OWA, open the messages, and export the .eml files for the ones you want to submit.

What Microsoft Eventually Found

After sustained escalation, the Product Group reviewed backend telemetry and confirmed two things:

  1. The auto-retry mechanism for SPF DNS lookups (AntispamRetrySpfWithExtendedTimeouts) had been rolled out to the tenant, which reduced temperror frequency significantly
  2. The behavior that remained was within what engineering considered acceptable service operation given the retry logic in place

The frequency dropped from intermittent across a meaningful percentage of inbound mail to a statistically rare occurrence – the PG quoted 1 failure in 1302 evaluated messages over a 7-day window after the retry mechanism was active.

The case isn’t cleanly closed. One confirmed temperror occurred the same day engineering declared the issue mitigated, after the retry mechanism was live. That sample was submitted as the case was being closed. The honest framing: Microsoft improved the underlying infrastructure in response to customer-reported data, reduced the failure rate substantially, but did not eliminate it. Whether the retry mechanism fully stabilizes over time or a residual edge case remains is still an open question.

Key Takeaways

  • spf=temperror from Exchange Online on a valid record is a receiver-side DNS timeout, not a sender-side misconfiguration
  • Mimecast SRS rewrites the MAIL FROM envelope, so Exchange Online evaluates your domain’s SPF record on inbound relayed mail regardless of Enhanced Filtering settings
  • Always verify SPF TTL against the authoritative nameserver, not a caching resolver – the values can differ significantly and the distinction matters when disputing support recommendations
  • The AntispamRetrySpfWithExtendedTimeouts internal list exists – if you’re hitting this issue persistently, ask about it explicitly
  • Getting a platform-level issue escalated through vendor-staffed M365 support requires sustained, technically specific pushback with documented evidence; the intake criteria are real but navigable