Does a Broken SPF Record Send Your Email to Spam? A Seed Test at 21 Providers

Estimated reading time: 13 minutes

Your ESP says the message was delivered, your SPF checker says the record has a problem, and nothing tells you where the message actually ended up. A broken SPF record can get mail rejected, filed in spam, accepted and never delivered, or delivered to the inbox as if nothing were wrong. Which one you get depends largely on the receiving provider.

To see the difference, we published 13 SPF configurations in October 2026, two clean controls and eleven variations on common SPF mistakes, and sent about 3,800 test messages from those test domains to GlockApps seed mailboxes at 21 mailbox providers and five spam filters. Every test domain published a DMARC policy of p=reject, and except for one control per sending path, the messages carried no aligned DKIM signature, so DMARC relied on SPF alone. This post covers what the seed mailboxes showed. The full study, with the receivers’ own DMARC reports and the raw data, is on the DMARKOFF blog.

Disclosure: GlockApps and DMARKOFF are built by the same team. All domains, IPs, and accounts in the test were our own.

Key takeaways

When SPF failed and no aligned DKIM signature could pass DMARC instead, most large providers rejected the message under p=reject. Those messages never reached a spam folder: the receiver refused them during the SMTP session or, at Microsoft 365, bounced them a few seconds after accepting them.
Gmail and Yahoo passed a record that needs 11 DNS lookups, one over the limit. Outlook.com, Hotmail, Apple, GMX, Yandex, and Mail.ru rejected the same message.
Libero, Virgilio, and Proton filed failing messages in spam. T-Online, Vodafone, and freenet put almost all of them in the inbox and recorded no SPF result at all.
Seznam, and Naver for most cases sent through Mailgun, accepted failing messages with 250 OK and never delivered them. The seed mailboxes showed the drops; Seznam’s DMARC reports also listed the messages as rejected, and Naver sent no reports.
Two SPF records split Microsoft. Two of six Outlook.com and Hotmail mailboxes received the message within two minutes; the other four refused it.
One clean inbox says little about your record. Test across providers, and read the authentication results wherever they’re available, along with the folder.

How we tested

Each configuration lived on its own subdomain, which served as both the From and the MAIL FROM domain. Two were clean controls. The others varied the mistakes we see most often in real DNS: a record that needs 11 DNS lookups, three void lookups, an include that points to a name without an SPF record, typos such as include= and includes:, a deprecated ptr, two SPF records, and no record at all. For the lookup limit and the missing include, we also tested a version with the sender listed before the problem; by the standard, those pass at the first match.

We sent every case along two paths: directly from a fresh AWS address, and through Mailgun’s shared IPs. On the direct path, each case went to 110 to 112 GlockApps seeds covering 34 mailbox types; through Mailgun, to 44. Inbox Insight reported where each copy landed and what the receiver wrote into its Authentication-Results header. We checked the seed mailboxes and collected bounces until 25 October, two days after the last run. We used the GlockApps MCP server to start the tests and collect the results, and an AI assistant matched each seed result with the sending log for the same message.

These are observations of specific seed mailboxes on 21–23 October 2026, not a forecast for every mailbox at a provider. Our direct IP turned out to be on a blocklist, so most comparisons come from the Mailgun run, where we had one or two seeds per mailbox type and sent through Mailgun’s shared IPs.

How providers handled the test messages

The table uses the Mailgun run. Where our direct IP was accepted, the direct runs mostly agreed. The exceptions: Yandex accepted the two-record domain, and Naver rejected the failing messages instead of dropping them.

Receiver	11 lookups	Include without SPF record	Typo¹	Two records	No record
Gmail, Google Workspace	inbox (SPF pass)	refused	refused	refused	refused
Yahoo, AOL, AT&T	spam (SPF pass)²	refused	refused	refused	refused
Outlook.com, Hotmail	refused	refused	refused	2 of 6 inbox	refused
Microsoft 365³	bounced	bounced	bounced	1 of 3 inbox	bounced
Apple iCloud, GMX, WEB.DE, mail.com, Mail.ru, La Poste, Zoho, mailo	refused	refused	refused	refused	refused
Yandex	refused	refused	refused	refused	refused
Onet, Barracuda filter	refused	refused	refused	refused	refused
Interia	refused	refused	refused, deferred	refused	deferred
Seznam	inbox (SPF pass)	dropped	dropped	dropped	dropped
Naver	dropped	dropped	refused, dropped	dropped	dropped
Libero, Virgilio, Proton	spam	spam	spam	spam	spam
ukr.net	inbox (SPF pass)	deferred	spam	spam	spam
Amazon WorkMail	inbox (permerror)	inbox (permerror)	dropped, inbox	inbox (permerror)	dropped
freenet	inbox	inbox	inbox	spam	spam
T-Online, Vodafone	inbox	inbox	inbox	inbox	inbox

inbox, spam: the folder the seed copy landed in; in brackets, the SPF result the receiver recorded, where it explains the outcome. refused: rejected during the SMTP session. bounced: accepted, then returned as undeliverable. dropped: accepted at SMTP, with no bounce and no copy in the seed mailbox by 25 October. deferred: answered with temporary errors until the sender gave up.

¹ Two typos. In our include= record, the unknown modifier was ignored and SPF returned fail; includes: is a syntax error that makes the whole record permerror. Where their outcomes differ, include= comes first.

² Yahoo, AOL, and AT&T filed the clean controls in spam too, so this placement wasn’t specific to the 11-lookup case.

³ Three seed mailboxes on Microsoft 365, two of them behind the Microsoft EOP and Proofpoint filter seeds.

Two cases caused few failures. Only Onet and the Barracuda filter refused three void lookups, and ukr.net filed them in spam; the deprecated ptr passed everywhere except at ukr.net.

A message that passes SPF can still land in spam. With brand-new domains on shared IPs, Yahoo, AOL, AT&T, and Yandex put even the clean controls in spam, and Apple, Outlook.com, and Hotmail did so for some of them. An SPF pass doesn’t guarantee the inbox, and a failing result didn’t lead to the same outcome everywhere: depending on the receiver, it meant a rejection, the spam folder, or even the inbox.

In Inbox Insight, a copy that never arrives shows up as Missing, whatever the reason. Refused, bounced, and dropped messages look the same there, and your sending logs tell them apart. A refusal comes back as the receiver’s SMTP reply. A bounce can arrive after the message was logged as delivered, as Microsoft 365’s did a few seconds later. We counted a message as dropped only when it was accepted, no bounce came back, and the seed mailbox still hadn’t received it by 25 October.

A record over the lookup limit: fine at Gmail, refused at Microsoft

SPF allows ten terms that need DNS queries, counted across all nested includes. Our record put eleven includes in front of the sender, so a strict receiver stops at the eleventh and returns permerror before it ever reaches the sending IP.

Gmail didn’t stop. It returned spf=pass and dmarc=pass in every run, from both paths, and Yahoo, AOL, and AT&T accepted the message too. In the Mailgun run, Gmail and Google Workspace delivered it to the inbox. The Yahoo family filed it in spam, as it did the clean controls. Outlook.com, Hotmail, Apple, GMX, WEB.DE, Yandex, Mail.ru, La Poste, Onet, and Interia refused it, and Microsoft 365 bounced it.

This is how a record over the limit survives for months: a sender who checks delivery at Gmail sees the inbox and moves on. The same eleven includes placed after the sending IP passed everywhere, because evaluation stops at the first match. Whoever is listed after the break fails at Microsoft, Apple, and the other providers that enforce the limit. Our guide on optimizing your SPF record covers how to stay within the 10-lookup limit.

“Delivered” doesn’t mean it arrived

Seznam accepted every failing message with 250 OK on both paths and delivered none of them. Naver did the same with mail sent through Mailgun, except for one typo case, which it refused; on the direct path, it refused the failing messages outright. Neither receiver sent a bounce, so the sending side recorded the dropped messages as delivered.

Microsoft 365 did the opposite. It accepted the failing messages with 250 2.6.0 … Queued mail for delivery and returned each of them 2 to 17 seconds later with 550 5.7.509. Mailgun’s log shows those messages twice: first delivered, then failed.

Seznam records its decision: its DMARC aggregate reports list every dropped message with the disposition reject. Naver sent no reports at all, and neither did most of the others: 12 of the 21 providers sent no DMARC reports during the test. For those providers, the sending logs and the seed mailboxes were all we had to go on.

Get 2 Free Deliverability Tests

Spam folder, or the inbox anyway

A few receivers delivered the failing messages instead of rejecting them. Libero and Virgilio wrote Received-SPF: permerror, Proton wrote spf=fail, and all three filed the messages in spam, where the clean controls had gone to the inbox. ukr.net also used the spam folder, with its own SPF verdict in the header every time.

T-Online and Vodafone went further: through Mailgun, every test message went to the inbox, including the ones with no SPF record at all, and their headers carried no SPF or DMARC result. freenet behaved the same way, except that the two-record and no-record cases went to spam. Amazon WorkMail treated permerror as a temporary error and delivered those messages to the inbox too.

Inbox placement at these providers doesn’t show that your SPF record works.

Two SPF records: some mailboxes get it, others don’t

A domain with two SPF records gets permerror by the standard, so no receiver should pass it. Ours published a record that lists the sending IP and a second one, v=spf1 -all. At Microsoft, the result depended on the mailbox. Within two minutes, two of six Outlook.com and Hotmail seeds received the message with spf=pass, and the other four refused it. Of the three seed mailboxes on Microsoft 365, one received it; Microsoft bounced the other two copies seconds after accepting them.

Yandex accepted the two-record domain on the direct path and refused it through Mailgun. Google, Mail.ru, and Interia refused it in every run. If you’ve ever heard “it works for some recipients”, a second record published “just for the migration” is one way to get there. Here’s how to merge multiple SPF records into one.

Check the signing domain behind dkim=pass

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 Gmail, the Yahoo family, and GMX, WEB.DE, and mail.com. All 12 of those mailboxes had it in the case we checked, and none of the other 26 did. It sits right next to X-Mailgun-Dkim: false.

That signature passes DKIM but doesn’t align with the From domain, so it does nothing for DMARC. When you see dkim=pass, open the message headers in Inbox Insight and check the d= domain: DMARC counts the signature only if that domain aligns with your From domain.

Your IP can fail before SPF is even read

Our direct-path address was brand new, and it was already on a blocklist: Spamhaus lists the whole range it came from in its PBL. In the pilot, 59 of 111 seed mailboxes refused us before looking at SPF at all, the clean controls included. If a test comes back mostly Missing, check the sending IP’s blocklist status before you change anything in DNS.

What to check before and after an SPF change

Validate the record. One SPF record per domain, no more than ten DNS lookups including nested includes, no more than two void lookups, and correctly spelled mechanisms: ip4:, not ip4= or ipv4:; include:, not include= or includes:.

Check your SPF record

Test inbox placement beyond Gmail. Gmail’s tolerance for the lookup limit hides a problem that Microsoft, Apple, and others act on.

Read authentication results where they exist, not only folders. Inbox placement at T-Online or Vodafone doesn’t show that your record works.

Treat Missing as a question. Match each missing seed with your sending logs, including bounces that arrive after delivered, to tell a refusal from a bounce or a silent drop.

Check the DKIM signing domain. A passing signature from a domain that doesn’t align with your From domain doesn’t give you a DMARC pass.

Watch your DMARC aggregate reports. They show rejects that never came back as bounces, for the providers that send reports. DMARKOFF collects them and shows each receiver’s verdict.

Conclusion

SPF results, SMTP acceptance, and the folder a message lands in answer different questions. In our test, the same broken record was rejected, bounced, filed in spam, dropped after 250 OK, or delivered to the inbox, depending on the receiver. The full study on the DMARKOFF blog has every case, the receivers’ DMARC reports, and the raw data.

FAQ

Does a broken SPF record send email to spam?

Sometimes. In our test, the failing messages had p=reject and no aligned DKIM signature, so most large providers rejected them instead of filing them in spam. Libero, Virgilio, and Proton used the spam folder, while T-Online, Vodafone, and freenet delivered most of them to the inbox.

Why does my ESP show an email as delivered when it never arrived?

Some receivers accept a message with 250 OK and drop it afterward without a bounce. In our test, Seznam did this with every failing message, and Naver did it with most failing cases sent through Mailgun. Microsoft 365 accepted messages and bounced them a few seconds later, so they showed as delivered and then as failed.

Why does my email reach Gmail but not Outlook?

One possible cause is an SPF record that goes over the 10-lookup limit. In our test, Gmail passed such a record, while Outlook.com and Hotmail refused it with 550 5.7.509. Two SPF records on one domain can also produce different results at different Microsoft mailboxes.

Can an inbox placement test show an SPF problem?

Yes, if you read more than the folders. For Missing copies, check your sending logs for SMTP refusals and later bounces. For copies that arrived, check the SPF, DKIM, and DMARC results in their headers. Some providers, like T-Online and Vodafone, record no SPF result at all, so test across several.