What Mailbox Providers Really Do With Broken SPF Records: We Tested 21 of Them

RFC 7208 spells out how a receiver should evaluate an SPF record, including broken ones, and DMARC says what to do when the result isn't a pass. SPF checkers, as we found in our comparison of free SPF checkers, mostly agree with the standard, if not always with each other. But neither the standard nor a checker decides whether your mail arrives. The receiving server does.

So we asked the receivers. In October 2026 we published 13 SPF configurations, two clean controls and eleven variations on the mistakes we see in real DNS every week, each on its own subdomain. Over three days, we sent about 3,800 test messages from them along two sending paths, with a separate set of subdomains for each. Every subdomain had a DMARC policy of p=reject, and apart from one control per path, no message carried an aligned DKIM signature, so DMARC depended on SPF alone. Then we watched what 21 mailbox providers and five spam filters did with each message: refused it, accepted it, filed it in spam, or accepted it and quietly threw it away.

Disclosure: DMARKOFF builds DMARC monitoring tools, and we read the receivers' aggregate reports for this test in DMARKOFF. The seed mailboxes came from GlockApps, which is made by the same team. All domains, IPs, and accounts were our own, and the data behind every claim is on GitHub.

TL;DR

• Gmail and Yahoo passed a record over the 10-lookup limit; most others didn't. Our test record needed 11 DNS lookups before it reached the sender. Gmail, Google Workspace, Yahoo, AOL and AT&T returned spf=pass and accepted it under p=reject. Microsoft, Apple, GMX, WEB.DE, Yandex, Mail.ru, La Poste, Onet and Interia refused it, and Libero, Virgilio and Proton filed it in spam as an SPF failure. The void-lookup limit hardly registered: only Onet and the Barracuda filter refused a record with three void lookups.
• The other mistakes failed at most receivers, Gmail included. An include pointing to a name without an SPF record, a mistyped ip4 or include, and a missing record were refused, deferred, or quietly dropped by most receivers; a handful delivered them to spam or even the inbox. The surprise was Outlook.com, which passed ipv4: as if it were ip4:.
• Two SPF records gave inconsistent results. Within two minutes, the same domain reached two of six Outlook.com and Hotmail mailboxes, and the other four refused it. Yandex accepted it on the direct path and refused it through Mailgun.
• Accepted doesn't mean delivered. Seznam answered 250 OK to every failing message and delivered none of them; Naver did the same through Mailgun. T-Online and Vodafone did the opposite: they put every test message in the inbox, and their headers showed no SPF or DMARC result at all.
• Fix the record; don't lean on lenient receivers or on reports. A sender listed before the broken part kept passing in our lookup-limit and missing-include cases, but by the standard that can't rescue a mistyped mechanism or a second record, which breaks the whole record. And 12 of the 21 providers, Apple and Yandex among them, sent no DMARC aggregate reports during the test, so some failures only show up in seed tests.

Why ask the receivers

 
An SPF checker tells you what the standard says. It can't tell you that Gmail will evaluate past the tenth lookup, or that two German providers deliver mail to the inbox even when the domain asks for it to be refused. Those are decisions each receiver makes, and they only show up when you send real mail and look at what happened to it.

DMARC makes the question sharper. With p=reject, a domain asks receivers to refuse mail that has neither an aligned SPF pass nor an aligned DKIM pass. If DKIM is missing or broken, the SPF result is the whole verdict. That's the situation we set up on purpose: one SPF configuration per subdomain, no aligned DKIM signature except on one control per path, and p=reject everywhere.

The test

 
Each case lived on its own subdomain (s00.mailpath.io to s12.mailpath.io), which was both the From domain and the MAIL FROM domain, so receivers evaluated exactly the record below.

We sent every case along two paths:

• Directly from our own server on a fresh AWS address, with a forward-confirmed PTR (mta.mailpath.io). Two full runs, a day apart, plus a pilot.
• Through Mailgun's shared IPs, on a second set of subdomains (m00 to m12). Here ip4:<our IP> became include:_spf.mailgun.org, the typos became include= and includes:, and the ptr case pointed at mailgun.net.

The recipients were GlockApps seed mailboxes: test accounts at real providers that show where a message landed and what the receiver wrote into its headers. Each case went to 110 to 112 seeds on the direct path, covering 34 mailbox types at 21 providers plus five spam filters, and to 44 on the Mailgun path, one or two per mailbox type. We combined four sources wherever they existed: the SMTP reply (or Mailgun's delivery event), the folder the message landed in, the authentication results the receiver wrote into the message's headers, and the receiver's DMARC aggregate reports.

We started the seed tests and read the results with an AI assistant connected to two MCP servers. The GlockApps MCP server started every seed test and returned where each message landed, provider by provider.

The DMARKOFF MCP server returned the receivers' aggregate reports for all 26 subdomains, grouped by reporter and by report window. That is how we lined up the SMTP logs, the seed results and the reports case by case.
 

Try DMARKOFF MCP

 

Lab note: We hadn't sent a single broken record when the first surprise came. Our brand-new AWS address was already on a blocklist: Spamhaus lists the whole 184.192.0.0/10 range in its PBL, and removal "is not allowed by the IP netblock owner's policy". More than half of the seed mailboxes, 59 of 111 in the pilot, refused us before looking at SPF at all. We kept the address, wrote the blocking down as a finding of its own, and added the Mailgun path so that Microsoft, Apple, Yahoo and GMX would get to read our records too.

Thirteen new Mailgun domains had the opposite problem: no reputation at all. So before breaking anything, we spent a day sending colleagues harmless little newsletters from them, about a calmer inbox, emails people actually read and quieter Monday mornings. We sent 138 messages, and all were delivered except the four sent to an address that turned out to be dead. The next morning we swapped in the broken records.

Results at a glance

 
This table uses the Mailgun run, where no receiver refused us for the IP. The direct runs agree wherever a receiver accepted our address; the exceptions are in the footnotes and the text. Keep in mind that acceptance at SMTP, an SPF pass, and the inbox are three different outcomes: a receiver can give you any one of them without the others.

pass: accepted with SPF pass; the folder then depends on other signals, such as reputation. refused: rejected during the SMTP session. bounced: accepted, then returned as undeliverable. dropped: accepted without a bounce, but never seen in the seed mailbox (we checked until 25 October). spam, inbox: delivered to that folder although SPF didn't pass. deferred: answered with temporary errors until the sender gave up. In brackets: the SPF result from the receiver's own header, where it explains the outcome.

Rows group brands that share a mail system (Yahoo, AOL and AT&T; GMX, WEB.DE and mail.com; Libero and Virgilio) or that behaved identically in every case. Of the five spam filters, Barracuda has its own row. The Google filter seed is a Google Workspace mailbox, and the Microsoft EOP and Proofpoint seeds receive through Microsoft 365, so they're counted in those rows. SpamAssassin only scores messages and refused none.

¹ On the direct path, Outlook.com passed the ipv4: typo; see the section on typos.
² Three mailboxes, two of them behind spam-filter seeds. Bounces read 550 5.7.509 Access denied, sending domain … does not pass DMARC verification.
³ Yandex accepted the two-record case in both direct runs.
⁴ On the direct path, Naver refused every failing case after the message body instead.
⁵ These receivers write no SPF or DMARC result into their headers, so only the folder is known. They delivered the clean controls to the inbox too.

The 10-lookup limit: Google and Yahoo look the other way

 
RFC 7208 allows ten terms that need DNS queries (include, a, mx, ptr, exists, redirect=), counted across all nested includes. Our record put eleven includes in front of the sender, each pointing to a record that matches nothing (v=spf1 -all), so a strict receiver hits the limit at the eleventh and returns permerror before it ever sees our address.

Gmail didn't. Its headers read spf=pass and dmarc=pass for this case in every run, from both paths, and Google Workspace agreed. Yahoo, AOL, and AT&T accepted it too.

Gmail's verdict on a record that needs 11 DNS lookups: spf=pass, dmarc=pass

Most of the other big names enforced the limit. Microsoft answered 5.7.509, Apple 554 5.7.1 … DMARC policy, GMX and WEB.DE Reject due to sender domain's DMARC policy, and Yandex, Mail.ru, La Poste, Onet, Zoho, and mailo refused it as well. Interia went further and refused at RCPT, before seeing the message, with Rejected due to SPF with invalid content.

How nine receivers refused the 11-lookup record through Mailgun: Outlook.com, Zoho, Mail.ru, Apple, Yandex, Interia, GMX, Onet and La Poste (Mailgun log, recipient addresses hidden)

In the seed mailboxes, the split looks like this:

The 11-lookup case through Mailgun: Gmail and Workspace deliver it, Yahoo files it in spam as it did the clean controls, and it never appears in the Microsoft, Apple, GMX, Yandex, or Mail.ru seed mailboxes (selection of providers)

The receivers' own aggregate reports say the same. Google, Yahoo and Seznam recorded spf=pass; Mail.ru, GMX, WEB.DE and mail.com recorded permerror and reject.

DMARKOFF, the receivers' own reports for the 11-lookup domain: Google and Seznam pass, Mail.ru permerror and reject

Three more receivers enforced the limit without refusing the message. Libero and Virgilio wrote Received-SPF: permerror, Proton wrote spf=fail, and all three filed the message in spam, where the clean control had gone to the inbox. Amazon WorkMail reached the opposite verdict from Gmail and the same outcome: it returned permerror, treated that as a temporary DMARC error, and delivered the message to the inbox.

The same eleven includes placed after our address passed everywhere. Evaluation stops at the first match, so a sender listed before the limit never notices it. That's how records over the limit survive for years: the main sender sits at the front and works, and whoever is listed after the break fails quietly at Microsoft, Apple, and the others that enforce it.

The same eleven includes after the sender: DMARKOFF flags lookup 11 of 10, and all 82 reported messages still passed SPF

What it means for you: Gmail's tolerance is not a safety net. In our test, a record over the limit failed at Outlook.com, Microsoft 365, iCloud, GMX, WEB.DE, Yandex, and Mail.ru, which together hold a large share of real inboxes.

Void lookups: a limit almost nobody applied

 
A void lookup is a DNS query that comes back empty: an a: term for a host that doesn't exist, for example. RFC 7208 recommends allowing two and returning permerror on the third. Our record had three in front of the sender.

Only Onet and the Barracuda filter, which sits in front of many corporate mailboxes, refused it. ukr.net accepted it, wrote permerror into its Received-SPF header, naming the void lookup limit, and filed it in spam. Everyone else, Microsoft included, passed it. The record with two void lookups passed everywhere.

What it means for you: Gmail and Outlook passed our three-void-lookup case; Onet, ukr.net and Barracuda didn't. Old a: and mx: terms for hosts you've retired are the usual cause, and they're easy to delete.

An include that points nowhere: refused, dropped, or deferred

 
An include whose target has no SPF record is a permerror (RFC 7208 §5.2), and no receiver that shows an SPF result passed it. Gmail, Yahoo, Microsoft, Apple, and the other big names refused it; Gmail's reply was 5.7.26 Unauthenticated email … is not accepted due to domain's DMARC policy. Seznam and Naver accepted it and never delivered it, and the receivers that filed failures in spam did so here too.

ukr.net treated the missing record as a temporary problem: 451 4.1.0 Temporary error during SPF verification. It kept deferring the message until the sender gave up; Mailgun retried for eight hours.

As with the lookup limit, putting the sender first saved it: the same broken include after our address passed everywhere.

What it means for you: this is the failure you're most likely to meet in real life. A vendor shuts down a service, renames its SPF host, or lets a domain expire, and the senders listed after its include start failing at every major provider at once.

Typos: ip4= and ipv4: end the same way, except at Outlook.com

 
The two typos are different mistakes. ip4=<IP> is a valid unknown modifier, which receivers must ignore, so our record collapsed to v=spf1 -all and SPF returned fail for our sending IP. ipv4:<IP> is an unknown mechanism, a syntax error that makes the whole record permerror.

For the address in the mistyped term, the outcome was nearly always the same: Gmail, Yahoo, Apple, and most other receivers refused both. The difference matters in a longer record. An ip4= typo only drops the one address; an ipv4: typo takes every other sender in the record down with it.

The exception was Outlook.com. Its own aggregate report for the ipv4: record gives spf=pass and DMARC pass. The mistyped term was the only one in the record that could match our address, so the result is consistent with Outlook.com reading ipv4: as ip4:. It isn't lenient about typos in general: through Mailgun, includes: got the usual 5.7.509 refusal, and Outlook.com's report calls the include= typo permerror where every other reporter says fail. Microsoft's reading departs from the standard in both directions.

DMARKOFF, the receivers' own reports for the ipv4: typo: Google, Mail.ru and Seznam reject it, Outlook.com passes it

The four receivers that reported on the ipv4: record gave it four different labels: fail at Google, none at Mail.ru (as if there were no record at all), permerror at Seznam, and pass at Outlook.com. At SMTP, three receivers told the two typos apart. Onet refused the fail at RCPT, citing SPF, and the permerror after the message body, citing DMARC. Interia refused the fail and kept deferring the permerror as SPF with invalid content. Naver refused both on the direct path for different reasons; through Mailgun, it refused the fail and accepted the permerror, which then never reached the mailbox.

ptr: deprecated, still works (mostly)

 
RFC 7208 says ptr SHOULD NOT be published: it's slow, and it puts load on reverse DNS. Receivers still support it. Our ptr:mailpath.io on the direct path and ptr:mailgun.net through Mailgun, whose servers resolve to *.send.mailgun.net, passed at every receiver that shows an SPF result except ukr.net, which returned spf=fail for both and filed them in spam.

What it means for you: a ptr in your record probably works today. Replace it anyway with the ip4, ip6 or include terms it stands for: the standard says so, and ukr.net already fails it.

Two SPF records: a coin toss

 
RFC 7208 §4.5 says a domain with more than one SPF record gets a permerror. Our domain published a passing record and v=spf1 -all, so a pass could only come from a receiver that evaluated the record listing our address and ignored the other.

The inconsistency was clearest at Microsoft. Of six Outlook.com and Hotmail seeds, two received the message with spf=pass, and four refused it with 5.7.509, from the same domain, within two minutes. Of three Microsoft 365 mailboxes, one received it, and two bounced it. Microsoft's aggregate reports match message for message: Outlook.com lists two passes and four fails, Microsoft 365 lists one pass and two fails.

Two SPF records at Microsoft: one Outlook and one Hotmail mailbox receive the message with spf=pass, the other four don't

Yandex accepted the two-record domain in both direct runs and refused it through Mailgun. Google, Mail.ru and Interia refused it in every run, Apple and GMX did so wherever they got to read our records, and Libero, Virgilio and Proton filed it in spam every time. In their reports, Google, Interia and Microsoft call it fail; Yahoo, GMX, Mail.ru and Seznam call it permerror.

Lab note: We didn't touch DNS between the two Outlook mailboxes that got the message and the four that didn't. The most likely difference is which of the two TXT records each Microsoft server happened to read first. If you've ever been told "it works for some recipients", this is one way to get there.

DMARKOFF shows both records and the fix; by the standard, SPF can't pass for any sender

What it means for you: a second record published "just for the migration" makes delivery unpredictable. Merge the mechanisms into one record, then delete the other.

No record at all

 
A domain without SPF gets none, and with p=reject and no aligned DKIM, that's a DMARC failure. Gmail, Yahoo, Microsoft, Apple, and most others refused or bounced it, Interia kept deferring it, and Seznam, Naver, and Amazon WorkMail accepted it and never delivered it. T-Online and Vodafone put it in the inbox, which brings us to the receivers that never say no.

"250 OK" doesn't mean delivered

 
Several receivers accepted almost every message at SMTP and decided later. From the outside, an accepted message looks delivered. The seed mailboxes showed what actually happened:

• Seznam and Naver dropped failing mail silently. The SMTP reply was 250 OK, no bounce followed, and the message never reached the mailbox. Seznam did this with every failing case on both paths. Naver did it through Mailgun with every failing case except the fail from the include= typo, which it refused; on the direct path, it refused all of them.
• Amazon WorkMail split the difference. It dropped fail and none, but turned permerror into a temporary DMARC error and delivered those messages to the inbox.
• Libero, Virgilio, Proton and ukr.net filed failing mail in spam. ukr.net wrote its own verdict into the header every time, including permerror for the void lookups and fail for ptr.
• T-Online and Vodafone put everything in the inbox. They outright refused our direct IP, but through Mailgun every test message, including the fail and none cases, went to the inbox, and their headers recorded no SPF or DMARC result at all. Freenet behaved the same, except the two-record and no-record cases went to spam.

Microsoft did a version of this on the direct path: the handful of messages it accepted from our blocklisted address never reached a mailbox, including the ipv4: ones it had passed. Messages that passed SPF cleanly, the control among them, vanished the same way, so we put this drop down to the IP rather than SPF.

Seznam's decision also shows in its aggregate reports: every failing message it accepted with 250 OK is listed there with the disposition reject.

What it means for you: SMTP acceptance doesn't prove mailbox delivery. Seed tests and the receivers' own DMARC reports are how you see the mail that was accepted and then thrown away.

A side finding: your ESP may sign your mail for you

 
On the Mailgun path, we turned DKIM signing off, so that SPF alone would decide DMARC. Gmail, Yahoo, and GMX still reported dkim=pass.

The headers explained it. Mailgun adds its own signature, d=mailgun.org; s=mg, to mail bound for three groups of providers: Gmail, the Yahoo family (Yahoo, AOL, AT&T) and United Internet (GMX, WEB.DE, mail.com). We checked every delivered copy of one case: all 12 of those mailboxes had it, and none of the other 26 did, Google Workspace and Microsoft included. The signature covers Mailgun's X-Feedback-Id header, which points to complaint feedback loops as the reason, and it sits right next to X-Mailgun-Dkim: false. Google's and Yahoo's aggregate reports list it; GMX's, WEB.DE's, and mail.com's don't mention it at all.

Mailgun's own DKIM signature on a message sent with DKIM off: d=mailgun.org, s=mg, next to X-Mailgun-Dkim: false

Lab note: For a day this was the experiment's open question. We had sent the message unsigned and checked it: a probe to our own mailbox arrived with no DKIM signature at all. Gmail disagreed, and Gmail was right.

That signature passes DKIM but doesn't align with your From domain, so it does nothing for DMARC. It matters when a tool shows "DKIM: pass" without the signing domain: you can't tell your own aligned signature from your provider's.

What the receivers' own reports say

 
Aggregate reports are each receiver's own account of what it decided, sent daily to the address in the domain's rua tag; ours went to DMARKOFF. They agree with the SMTP replies and seed results above case by case, and no receiver changed its verdict between the two direct runs. Outlook.com's reports even list the messages it refused during the SMTP session. They add three things.

More than half of the providers sent no reports. Google, Yahoo, Microsoft (Outlook.com and Microsoft 365), GMX, WEB.DE, mail.com, Mail.ru, Seznam and Interia sent reports; Amazon WorkMail did for one case and Zoho only days later. Apple, Yandex, Onet, La Poste, mailo, Naver, ukr.net, Proton, Libero, Virgilio, T-Online, Vodafone and freenet sent none during the test: 12 of the 21 providers. For them, SMTP replies and seed tests are all there is.

The same failure gets different names. RFC 7208 has one answer for each of these records: permerror, except for the include= typo, an ignored modifier that leaves -all to return fail. The reports disagree:

No report: that receiver's reports have no entry for this case.

For DMARC, the label changes nothing: none of these results is an aligned SPF pass, and with no aligned DKIM signature in these cases, DMARC fails either way. It matters when you read the reports: a fail from Google can mean an unauthorized sender or a broken record of your own, and Mail.ru's none looks like a domain without SPF.

Silent drops show up here first. Seznam lists every failing message it accepted with 250 OK under the disposition reject. Without the reports, the only sign would have been a seed mailbox that stayed empty.

Lab note: Reading the reports by day nearly fooled us. Mail we sent at 06:57 UTC on 22 October turned up in Google's report for the 21st, although the report says it covers 00:00 to 23:59 UTC; Google's day apparently follows Pacific time. Seznam's reports run from 22:00 UTC. Before you match a send to a day of reports, check each reporter's window.

We read all of these reports in DMARKOFF, which shows each domain's results by reporter, so a receiver that rejects your mail stands out even when it never sends a bounce.
 

Start 14-day Free Trial

 

What to do with your own record

 

We expected Gmail to be the strictest receiver in the test. On the lookup limit, it turned out to be one of the most forgiving, which is why a record over the limit can look fine for months. If your SPF only works because Google is lenient, it doesn't work.

Aliaksandr MarkauCo-founder & CTO at DMARKOFF and GlockApps

1. Stay within the 10-lookup limit, whatever Gmail does. Count nested includes, and leave some headroom: a vendor can add a lookup to its own include at any time. In our test, Microsoft, Apple, Yandex, GMX, and Mail.ru enforced the limit.
2. Keep void lookups to two. Remove a: and mx: terms for hosts that no longer exist.
3. Check that every include still resolves to an SPF record. A missing record behind one include is a permerror for the whole check, so the senders listed after it never get evaluated.
4. Publish exactly one record. During a migration, merge the mechanisms instead of adding a second record.
5. Proofread mechanism names. ip4:, not ip4= or ipv4:; include:, not include= or includes:.
6. Replace ptr with the terms it stands for.
7. Put your main sender first while you fix the rest. In our lookup-limit and missing-include cases, that kept it passing everywhere. It won't help with a typo in a mechanism name or a second record, which breaks the whole record, and it doesn't fix the senders after the break.
8. Watch your DMARC aggregate reports by reporter. They're where silent drops show up, and where you'll notice which receivers never report at all.

You can paste a draft record into DMARKOFF's SPF checker before you publish it.
 

Run SPF Check

 

Limitations

• One blocked IP on the direct path. Our AWS address sat in Spamhaus PBL, so on that path more than half the seeds refused us before evaluating SPF. The Mailgun path covers those receivers, but Mailgun's shared IPs bring their own reputation, and its own DKIM signature.
• Small samples. On the Mailgun path, we had one or two seeds per mailbox type; on the direct path, 1 to 17, but more than half refused our IP before evaluating SPF. Each case ran three times, twice directly and once through Mailgun (plus a three-case pilot), which is how path-dependent results like Yandex's showed up.
• Seed mailboxes are test accounts. Their folders reflect their own history as well as our mail, so we used authentication results and refusals to read SPF behavior, and folders only to describe where the mail ended up.
• Not every receiver reports. For the 12 providers that sent no aggregate reports, we only have SMTP replies and seed results.
• A snapshot. Receivers change their filtering without notice. These results describe 21 to 23 October 2026.

Methodology and data

 
Dates. Pilot on 21 October 2026, direct runs on 22 and 23 October, and the Mailgun run on 23 October. Seed mailboxes were checked until 25 October.

Sending. The direct path used our own sender on an AWS address with a forward-confirmed PTR, three seconds between recipients, and up to five retries of temporary refusals, 10 to 80 minutes apart. The Mailgun path used Mailgun's US shared IPs; its domains were warmed up the day before with ordinary messages to our own mailboxes, and Mailgun handled retries.

Domains. One subdomain per case, used as From and MAIL FROM, each with p=reject and aggregate reports sent to DMARKOFF. DKIM was off except for one control per path. We recorded the DNS for every case before each run.

Observations. SMTP replies for every attempt on the direct path, Mailgun's delivery events on the other, folders from GlockApps seeds, the authentication results the receivers wrote into those seeds' headers, and the receivers' aggregate reports, read in DMARKOFF report by report with each reporter's window.

Data. The SMTP and Mailgun logs (recipients reduced to their domain), per-provider seed results, the receivers' aggregate report extracts, header excerpts, and DNS snapshots are in dmarcoff/articles on GitHub.

FAQ