Is SPF -all with Microsoft 365 still a safe practice in 2026?

You’ve set up SPF with -all for your Microsoft 365 domain. It passed the test. But now some of your emails are landing in spam folders — or not arriving at all. Why?

SPF -all (a hard fail) is technically valid with Microsoft 365, but it’s a trap if you don’t understand how it interacts with M365’s own authentication and any third-party services you use. The real issue isn’t the -all directive — it’s misalignment with how email systems actually validate sender identity across shared infrastructure.

Many admins apply -all as a default without realizing it can break deliverability when external services like marketing platforms, CRM tools, or email verification providers send on your behalf. That’s not an M365 flaw — it’s a configuration gap that undermines trust.

Key takeaways

  • SPF -all is valid in Microsoft 365 but can cause deliverability issues if not managed with third-party senders in mind.
  • Using -all without an include or redirect for external services breaks authentication when those services authenticate as your domain.
  • Microsoft 365’s built-in SPF policies are already strict; adding another -all directive often creates unnecessary conflict.

What does SPF -all actually do in Microsoft 365?

SPF -all means any email sent from your domain that isn’t explicitly authorized by your SPF record fails the check. In Microsoft 365, this is enforced at the receiving end: if your domain’s SPF record doesn’t include Microsoft’s mail servers as a permitted source, incoming emails will fail SPF — even if they’re from a legitimate sender. This is intentional. It stops spammers and phishers from forging your domain by ensuring only authorized servers can send on your behalf.

Why SPF -all matters for M365 senders

If you’re sending from Microsoft 365, your domain’s SPF record must list the M365 mail servers as authorized senders — otherwise, your emails risk being marked as spam or rejected outright. Without proper SPF alignment, even legitimate emails from your staff may fail SPF checks, especially when sent from external devices or third-party apps.

Microsoft’s enforcement is based on standard email authentication practices defined in RFC 7208. The -all mechanism is a way to be explicit: if no mechanism applies, the email fails. This aligns with industry recommendations to minimize spoofing, as outlined by the IETF.

Common misconfigurations and their impact

One common mistake is using a loose SPF policy like "include:_spf.google.com" without also including Microsoft’s infrastructure. If you’re using both Gmail and M365, you need to explicitly list both services — a single include isn’t enough. Overly restrictive records (with too many includes) can also break SPF if they exceed the 10 DNS lookup limit.

Another issue: some users think SPF -all blocks all emails. It doesn’t. It only blocks emails from servers not listed in your record. But if you mistakenly exclude M365, your own emails will fail. That’s why testing your SPF setup is critical — especially after changes.

Let’s be clear: SPF -all isn’t a threat to your email flow in M365 — it’s a requirement. You must include Microsoft’s authorized IP ranges or mechanisms (like “include:spf.protection.outlook.com”) to ensure deliverability.

Using tools like MailTester’s bulk verification can help you check if your email list’s domains have properly configured SPF records, or use our real-time API to validate sender domains on the fly. These tools give you direct insight into authentication health before you send.

SPF is not a standalone solution, but it’s a foundational layer. Combined with DKIM and DMARC, it closes critical attack vectors used in phishing and spoofing.

Microsoft itself recommends strict SPF policies to reduce email abuse. For more on email authentication standards, refer to the IETF’s RFC 7208 — the core document defining SPF behavior.

Why is SPF -all commonly misapplied in Microsoft 365 setups?

SPF -all is often misapplied in Microsoft 365 because administrators copy template records without accounting for M365’s specific outbound mail flow, which relies on Microsoft’s own mail servers. This leads to overly restrictive policies that block legitimate emails, especially when third-party services aren’t listed as authorized senders. Without proper alignment, -all can cause valid messages to fail validation.

The template trap

Many admins start from a generic SPF template—often copied from forums or old documentation—without realizing that Microsoft 365’s SPF record must include include:spf.protection.outlook.com. Skipping this step means your domain’s SPF policy doesn’t authorize Microsoft to send emails on your behalf. As a result, even messages sent through Outlook or Teams are rejected by recipient servers.

It’s not just about the -all part—SPF is a policy chain. If a sender is not explicitly listed via include, ip4, or mx, and you use -all, every unlisted sender fails. This includes any marketing platform, helpdesk tool, or reporting service you might use. The result? High bounce rates and deliverability drops.

Third-party services and the missing pieces

Let’s say you use a tool like Klaviyo for email campaigns. If you’ve added include:spf.protection.outlook.com but forgotten to include include:klaviyo.com, your campaign emails may still fail SPF checks. A single missing include breaks the entire policy chain.

SPF can only have one -all mechanism per record. If multiple records exist (due to misconfiguration or outdated DNS), the policy becomes ambiguous, and receivers may ignore it entirely. It’s a common issue in large organizations where multiple teams manage different parts of the email stack.

As RFC 7208 (the standard defining SPF) clarifies, overly strict policies like -all without full sender authorization can cause collateral damage. You don’t want to block your own support team’s emails to customers because a single service wasn’t listed. Use ~all (soft fail) in testing environments and ensure all senders—especially third-party ESPs—are included when using -all in production.

Use MailTester’s inbox placement to simulate real-world delivery and catch SPF issues before they affect customers. Or verify your list of senders with bulk verification to ensure every sender is accounted for in your SPF policy.

How M365 handles SPF when sending via external services?

Using SPF -all with Microsoft 365 is not recommended if you send emails through external services or relay via Exchange Online, because M365 uses its own IP ranges to send mail. If your SPF record uses -all without explicitly including M365's IPs, legitimate emails from your domain will be blocked. SPF applies to the sending domain, not the service, so you must include M365’s authorized IPs or use a relaxed mechanism like SPF include.

Why M365’s IP range matters in SPF

When you send email through Microsoft 365—whether via Outlook, Exchange Online, or a third-party app—it uses Microsoft’s own IP address pool, not your server’s. If your SPF record doesn’t include these IPs, even valid messages will fail SPF checks. A strict -all policy without proper inclusion means any sender not explicitly listed is rejected, including M365.

For example, if your SPF record reads v=spf1 -all and doesn’t include include:spf.protection.outlook.com, then every email sent via M365 will fail. This happens even if your domain is properly configured otherwise.

What SPF policy do you really need?

Let’s be clear: SPF -all doesn’t protect you. It breaks you. A strict -all only works if every possible sender is explicitly allowed. That’s impractical at scale. Instead, use include:spf.protection.outlook.com to cover M365’s sending IPs, alongside any other services you use.

According to RFC 7208, the standard for SPF, a -all mechanism is meant to enforce strict control, but only when all senders are accounted for. Using -all without proper inclusion causes legitimate traffic to fail. You’re not securing your domain—you’re blocking your own emails.

For real-time validation of SPF, DMARC, and other sending configurations, test your setup with inbox placement testing or use the verification API to catch configuration issues before they cost you deliverability. You can also bulk-check your list for valid senders with list verification to avoid sending to invalid or risky addresses. The system doesn’t punish mistakes—your recipients do.

What happens if SPF -all blocks M365 from sending?

If you set SPF to -all without properly including Microsoft 365’s outbound mail servers, your emails will fail SPF authentication—even if DKIM and DMARC are configured correctly. This means legitimate messages sent from M365 get rejected by receiving servers, resulting in hard bounces and delivery failure. Over time, this degrades sender reputation and hurts inbox placement across major providers.

SPF -all is strict, but M365 must be listed

SPF -all means "fail any server not explicitly allowed." If M365’s sending IPs aren’t included in your SPF record, every message it sends—whether from a user’s mailbox or a marketing campaign—will be marked as failed. Receiving servers treat this as a violation, not a soft bounce, and often drop the email entirely, especially if they’re configured to reject unauthenticated traffic.

Microsoft’s own documentation confirms that outbound mail must be explicitly permitted in your SPF record. For example, using include:_spf.protection.outlook.com ensures your domain’s M365 users can authenticate properly. Skipping this step forces you to rely on DKIM alone, but even strong DKIM fails if SPF is set to -all and M365 isn’t listed—because many providers perform SPF checks as a first pass.

Long-term consequences for deliverability

Repeated delivery failures from your domain trigger red flags with internet service providers and email gateways. Even if you fix the SPF record later, the damage from failed sends—especially hard bounces—can linger for weeks. Blacklists like Spamhaus don’t just track spam; they track consistent authentication failures from a domain, which can lead to IP or domain-based blocking.

Once your sender reputation drops, inbox placement declines. Studies from Return Path (now Validity) show that domains with consistent authentication issues see inbox placement drop below 70% in certain inboxes. This isn’t just a technical detail—it impacts engagement, opens, and conversions.

Let’s be clear: a strict SPF -all policy doesn’t help unless all sending sources—including M365—are explicitly allowed. Misconfigured SPF is a common cause of deliverability breakdowns, particularly in hybrid or migration scenarios.

Use MailTester’s bulk verification to test your list for domains with weak or misconfigured SPF records. The real-time API gives you automated validation during onboarding. For campaigns, run an inbox placement test to check your domain’s health before launch. These tools help you spot SPF risks before they cost you deliverability.

A correct SPF record for Microsoft 365 with -all

You can use -all in your SPF record with Microsoft 365, but only after explicitly allowing M365’s sending mechanisms with include:spf.protection.outlook.com. Without it, -all blocks all outbound mail from M365. Use -all only if you’ve listed every permitted sender; otherwise, use ~all to avoid hard fails.

What to include in your SPF record

  • Always include include:spf.protection.outlook.com — this is Microsoft's official mechanism for outbound email from M365.
  • Use -all only after listing all valid email-sending sources, including M365, your own servers, and third-party tools like SendGrid or Mailchimp.
  • Never use -all by itself. It will fail any email from an unlisted sender, including M365 if not properly included.
  • Use ~all (soft fail) if you're unsure or have multiple senders — it reduces bounce risk while still preventing spoofing.
  • Check your record with tools like MxToolbox or RFC 7208 to ensure syntax and logic are correct.

Common mistakes and how to avoid them

  • Don’t assume M365 sends only through its own servers. If you use third-party ESPs, include them too, or use ~all.
  • Don’t use multiple include statements without checking limit: SPF has a 10 lookup limit, so avoid overcomplicating.
  • Don’t forget that -all means "deny everything not explicitly listed" — it’s strict and unforgiving.
  • Use inbox placement testing to verify your record’s real-world impact across inboxes, not just DNS validators.

Common SPF syntax errors in M365

You should never use SPF -all without a proper include directive in Microsoft 365. Omitting include:spf.protection.outlook.com breaks email authentication and leads to deliverability issues. RFC 7208 requires that all sending sources are explicitly authorized, and Microsoft’s own SPF policy mandates this include. Ignoring it means your emails may be rejected or marked as spam.

Common syntax mistakes to avoid

  • Forgetting include:spf.protection.outlook.com — this is non-negotiable for legitimate M365 sending. Without it, your SPF record is invalid and can block your outbound mail.
  • Using -all alone — this rejects all mail from unlisted sources. But without proper includes, even authorized mail from Microsoft’s infrastructure fails. A record like SPF v=spf1 -all is technically valid but functionally broken.
  • Mixing multiple SPF records – DNS allows only one SPF record per domain. Having more than one triggers an SPF permerror, which often results in messages being dropped by receiving servers.
  • Using incorrect syntax, such as missing quotes around values, extra spaces, or case sensitivity. SPF is case-sensitive and whitespace matters. For example, include:spf.protection.outlook.com must not have leading or trailing spaces.

Why syntax errors harm deliverability

Even small errors disrupt the email validation process. Receiving servers check SPF against RFC 7208. A malformed record means no valid alignment — which leads to higher bounce rates or inbox placement failures. This isn’t hypothetical: studies from Return Path and Google’s anti-abuse teams show that SPF breaks lead to significant delivery drops.

Let’s be clear: SPF is not optional. It’s a foundational part of email authentication. You can’t skip it, and you can’t guess the right syntax. Always test your SPF record using tools designed for real-world validation. MailTester’s inbox placement test checks not just SPF, but how your message lands in real inboxes across providers like Gmail, Outlook, and Yahoo.

When you’re setting up M365, verify your DNS configuration with a tool that checks for the full chain of authentication: SPF, DKIM, DMARC, and more. Bulk list verification can catch dead or misconfigured domains before they impact your send volume.

For developers, use the MailTester API to programmatically validate SPF and other email health signals at scale. No credit expiry — your purchased credits last forever.

Always remember: the correct SPF for M365 is SPF v=spf1 include:spf.protection.outlook.com -all. No exceptions. No missing includes. No extra records. Just one, properly formed line.

How to test your SPF record before sending?

You should validate your SPF record’s syntax, confirm it includes all authorized senders—like Microsoft 365 and third-party tools—and verify it passes checks across real email providers. Use DNS tools to catch syntax errors, then test with MailTester to see how your domain performs at scale across major inboxes. This prevents bounces, protects sender reputation, and keeps delivery reliable.

Step-by-step validation process

  1. Use a DNS lookup tool like MxToolbox or DNSLookup.org to check your SPF record’s syntax. Look for errors like include: failures, too many DNS lookups, or incorrect syntax such as missing quotes around spf:all. A malformed record can cause valid emails to be rejected.
  2. Ensure your SPF record includes all approved sending sources. If you use Microsoft 365, include include:spf.protection.outlook.com. Add other trusted services like your ESP, marketing tools, or CRM—each extra include increases DNS lookup count. Stick to the 10-lookup limit defined in RFC 7208 to avoid failures.
  3. Test your domain’s full authentication stack using MailTester’s real-time verification API. It checks SPF, DKIM, and DMARC in real time across major mail providers. This simulates actual delivery conditions, showing if your domain is passing checks or being flagged.
  4. Run inbox-placement tests with MailTester’s inbox tester to see how your emails land across Gmail, Outlook, Apple Mail, and others. A clean inbox placement report reveals issues like header spoofing, low sender reputation, or inconsistent authentication—problems that can’t be caught by syntax tools alone.

Why this matters

Even a perfectly formatted SPF record can fail in production if other checks (like DKIM or DMARC) are misconfigured. The only way to know for sure is to test your domain in live environments.

Let’s say you’re sending a campaign from a Mailchimp list via M365. If your SPF record only includes M365 but not Mailchimp’s outbound servers, delivery will drop. Tools like MxToolbox spot syntax issues early, but only scalable testing—like MailTester’s API or inbox tests—reveals whether real users receive your messages.

Third-party tools like ZeroBounce or NeverBounce offer limited scope. They test domain validity but not the full delivery stack. MailTester’s end-to-end verification, including real-time sender checks and multi-provider inbox simulation, gives you a complete picture.

Why you should verify SPF configurations before sending

Yes, you should verify SPF configurations before sending—any misconfigured SPF record, even a single ~all or -all that’s too strict or poorly structured, can cause legitimate emails to be rejected by Microsoft 365 and other providers. Without verification, you risk delivering to spam folders or outright bouncing, especially with large lists or automated campaigns.

SPF failures aren’t just technical—they hurt deliverability

Every time an email fails SPF, it’s a signal to inbox providers that something’s off. Microsoft 365 uses strict authentication checks, and a single hard fail can trigger temporary or persistent filtering. Over time, even a few failures accumulate and degrade your sender reputation, especially if those failures come from domains with poor reputations.

Let’s be clear: SPF isn’t just a checkbox. It’s a core part of your email identity. If you’re using Microsoft 365, your SPF record must be precise—overly strict policies can break mail from third-party services, while overly permissive ones leave you vulnerable to spoofing. The wrong ~all or -all setting can silently block mail from valid senders.

Prevent problems before they happen with real-time verification

That’s why you should test your list before sending. Tools like MailTester’s bulk verification scan hundreds or thousands of email addresses in minutes and flag domains with broken SPF records, catch-all setups, or poor sender reputation. You’re not just checking syntax—you’re validating that each recipient can actually receive your message.

Our 98.9% accuracy in identifying invalid or high-risk domains means you catch issues early. A domain with a mismatched or unverified SPF won’t make it through our verification—so you avoid wasted sends and reputation damage. We also catch disposable emails, role accounts, and known bad providers that often slip through basic checks.

Bulk verification is ideal for campaigns. If you’re sending via Microsoft 365 or another platform, run your list through our in-app AI assistant or API to catch problems before delivery. You can even run inbox placement tests to see how your message lands in real inboxes across multiple providers, including Outlook.

For those integrating with tools like SendGrid, HubSpot, or Klaviyo, our integrations offer automated pre-send validation. It’s not just about SPF—it’s about ensuring every email you send has a real chance to land in the inbox. And with no expiry on purchased credits, there’s no rush to use them.

SPF isn’t a one-time setup. It evolves. So does reputation. That’s why consistent verification is a best practice. As RFC 7208 makes clear, alignment and consistency across SPF, DKIM, and DMARC are how email providers determine trust. Don’t assume your SPF is working—test it.

SPF vs DKIM vs DMARC: roles in M365 deliverability

You don’t need SPF -all with Microsoft 365 — in fact, it’s not recommended. M365 handles SPF validation internally using its own servers. The real key to deliverability is ensuring SPF, DKIM, and DMARC are correctly configured together. These three protocols work as a system: SPF checks the sending IP, DKIM verifies message integrity, and DMARC enforces policy based on both. All three are required for consistent inbox placement across modern email systems.

How each protocol functions in M365

Let’s break down what each does and why they matter when you're sending from Microsoft 365.

Protocol Checks M365 Role Why It Matters
SPF Sender IP address Validates if M365's outbound IP pools are authorized to send on your domain Without a valid SPF record, M365 emails may be flagged as suspicious. M365 uses its own SPF entries; you don’t need to add SPF -all.
DKIM Email content integrity Automatically signs outgoing messages using M365’s DKIM key Ensures the message wasn’t altered in transit. If DKIM fails, the email may be rejected by receiving servers.
DMARC Policy enforcement Specifies what to do when SPF or DKIM fail With a DMARC policy like rua=mailto:[email protected], you get reports on failed deliveries and spoofing attempts. This is critical for long-term sender reputation.

Think of it like this: SPF is the gatekeeper, DKIM is the envelope seal, and DMARC is the enforcement. If any one fails, inbox placement drops. According to RFC 7483, email systems increasingly rely on this trio for trust.

How to verify your setup

Even if you’ve set it up, you won’t know if it’s working until you test it in real-world conditions. Use actual email delivery checks — not just DNS lookups. MailTester's inbox placement test sends real emails to Gmail, Outlook, Yahoo, and others to tell you exactly how your messages are being treated. This is the only way to confirm your M365 setup is safe from spoofing and accepted by modern filters.

If you're managing a list, verify it first. Bulk errors — especially hard bounces from SPF failures — eat into your sender reputation. With bulk verification, you can weed out invalid addresses before you send, reduce bounce rates, and protect your domain’s reputation.

SPF -all is technically valid in Microsoft 365, but only when your SPF record includes all legitimate sending sources, including M365’s own mechanisms.

Using -all without properly including M365’s email services results in delivery failures. This is not a risk to avoid—it’s a common cause of bounces and inbox placement issues.

Always test before you send

Real-world delivery behavior can differ from DNS theory. A well-formed SPF record still breaks in practice if it lacks proper alignment or validation.

Use MailTester’s inbox placement testing or real-time API to simulate delivery and identify issues before your audience grows.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does Microsoft 365 require SPF -all?

No. Microsoft 365 does not require -all. It requires correctly configured SPF records that explicitly permit M365’s sending servers.

Can I use SPF -all with third-party email services in M365?

Yes, but only if all third-party services are listed in the SPF record. Without proper inclusion, email from those services will fail SPF.

What happens if I use SPF -all with M365 and no include?

All emails not sent from M365’s servers will fail SPF, causing bounces or delivery issues, even if DKIM and DMARC are valid.

Is SPF softfail (-~all) safer than hard fail (-all) in M365?

Softfail only reduces the impact of unintended failures but does not improve sender reputation. Hard fail is more secure if properly configured.

How do I know if my SPF record is correctly set for M365?

Use the include:spf.protection.outlook.com directive, test with DNS tools, and verify delivery using MailTester’s real-time verification API.

Can MailTester test SPF records?

Yes. MailTester’s real-time verification API checks SPF, DKIM, and DMARC alignment and provides insights into delivery reliability.

What is the default SPF behavior in Microsoft 365?

M365 does not set SPF records for user domains. You must configure SPF on your own domain to authorize M365’s sending servers.

Do I need to update SPF when adding a new M365 tenant?

Only if the new tenant sends on your domain. Otherwise, keep the existing SPF record that includes the current M365 service.

What is a common SPF mistake with M365?

Neglecting to include include:spf.protection.outlook.com, leading to emails from M365 failing SPF authentication.

MailTester verifies email addresses and checks authentication alignment (SPF/DKIM/DMARC) at scale, helping prevent bounces and improve inbox placement.

Should I avoid SPF -all entirely?

Not necessarily. -all is acceptable when used correctly. The key is to ensure all authorized senders—especially M365—are explicitly included.

Can a domain have multiple SPF records?

No. Multiple SPF records are invalid and cause delivery failure. Combine all mechanisms into a single record using the include directive.