Playbook: Fixing Your SPF Record After a Proofpoint & M365 Integration

The cutover was clean. MX records now point to Proofpoint's infrastructure, your test messages flow, and the dashboards are lighting up. Then the first incident report lands. A key partner’s mail gateway is rejecting your invoices with a `550-5.7.26` error. The message is clear: your domain has a permanent SPF error. But how? You just followed the vendor's documentation.

The problem isn't your new Proofpoint include. The problem is that your old Microsoft 365 include is still there, and it still needs to be. When these two behemoths share a single SPF record, they often exceed the 10 DNS lookup limit defined in RFC 7208.

This isn't a simple typo. It's a structural failure that silently breaks your mail deliverability. Fixing it requires more than just editing a TXT record; it requires a strategic audit of every service that sends email on your behalf.

Why Exchange Online Never Really Goes Away

The first mistake is assuming that once your MX records point to a Secure Email Gateway (SEG) like Proofpoint, all your mail originates from their IPs. This is dangerously false. Your users' Outlook clients will send outbound mail that routes through the new smart host, sure. But Microsoft 365 is more than just a mailbox.

It's a sprawling platform where dozens of services can generate and send email directly from Microsoft's own infrastructure, completely bypassing your SEG's outbound path. If you remove `include:spf.protection.outlook.com` from your SPF record, you are essentially telling the world that these legitimate emails are forged.

The Hidden Senders in Your Tenant

Think about the automated processes inside your M365 tenant. Calendar invites and meeting updates are generated by Exchange Online, not by a user hitting 'send' in a client that respects your outbound smarthost. Power Automate flows can trigger email notifications. SharePoint sends alerts. Even something as simple as a 'password reset' email initiated from a user's ID in Azure AD might originate from a Microsoft IP.

If the IP address sending that SharePoint alert isn't covered by your SPF record, receiving mail servers will see a mismatch. The source IP belongs to Microsoft, but your SPF record—lacking the `outlook.com` include—doesn't authorize it. At best, it gets flagged as suspicious. At worst, it’s discarded before it ever reaches the recipient's inbox, causing a business process to fail silently.

Unpacking the `include` Cascade Effect

An SPF record that looks simple on the surface can be a monster of complexity. The `include:` mechanism isn't a single lookup. It's a directive to the receiving mail server: 'Stop processing this record, go fetch the one at this other domain, and process it as if it were part of mine.' Every `include:` costs one DNS lookup, and the chain reaction begins.

v=spf1 include:spf.protection.proofpoint.com include:spf.protection.outlook.com include:_spf.salesforce.com include:sendgrid.net -all

That record looks like it has four lookups. It has more. The `spf.protection.proofpoint.com` record itself contains another `include`. The `spf.protection.outlook.com` contains three more `include`s (`spfa.protection.outlook.com`, `spfb.protection.outlook.com`, and `-all` which terminates). Each of those sub-records might contain `ip4` and `ip6` mechanisms, but it's the nested `include` statements that burn through your 10-lookup budget.

This cascading expansion is the source of the 'permerror' or permanent error. When a receiving server starts validating your SPF and hits an 11th DNS query, it is required by RFC 7208 to stop and return a failure verdict. It won't 'try its best' with the first ten lookups. It fails hard. Your email is now treated as if you had no SPF record at all, tanking your DMARC alignment and deliverability.

Triage Workflow: Finding the Bloat

You can't fix what you can't measure. Before you change anything, you need to diagnose the current state of your SPF record. This isn't a guessing game; it's a forensic process. Any number of free online SPF checkers can do this for you by simulating the recursive lookup process.

Establish a Pre-Integration Baseline

Before you add the Proofpoint `include`, run your existing record through a validator. How many lookups are you already using? If you're at 8 or 9 with just Microsoft 365, Salesforce, and a marketing platform, you're already in the danger zone. Adding Proofpoint, which can add 2-3 lookups on its own, will guarantee failure.

This baseline serves two purposes. First, it identifies the problem before it becomes an outage. Second, it gives you a clear picture of every third-party service authorized to send mail on your behalf. You might be surprised at what you find—legacy services from forgotten projects, redundant entries for the same vendor, or includes for platforms you no longer use.

Diagnose the Post-Integration Permerror

If you're already in a failed state, the validation tool will show you exactly where the chain breaks. It will list each lookup in order and flag the point at which the count exceeds ten. This is your hit list. The includes appearing lower in the record are often the first to be ignored by a failing parser, but the problem is the total count, not a single 'bad' entry.

Surgical SPF: Trimming Lookups Without Breaking Mail Flow

Once you've identified the bloat, the solution is to eliminate unnecessary DNS lookups. The most effective technique is called 'SPF flattening,' but it comes with significant risk.

Replacing `include` with `ip4`/`ip6`

Instead of using `include:some-vendor.com`, you can perform the lookup yourself, find the specific IP addresses or CIDR ranges listed in that vendor's SPF record, and hardcode them into your own record using `ip4:` and `ip6:` mechanisms. These do not cost a DNS lookup during validation. In theory, you could replace every `include` with a list of IPs and reduce your lookup count to zero.

This is a brittle and dangerous strategy. When the vendor adds a new mail server or changes an IP address, your hardcoded record will be instantly out of date. Legitimate emails from their new IP will start failing SPF. You are taking on the operational burden of monitoring their infrastructure for changes. For this reason, you should never, ever flatten the records for major providers like Proofpoint or Microsoft. Their infrastructure is vast, dynamic, and managed via nested includes for a reason.

The pragmatic approach is to flatten the records for smaller, more stable services. A marketing automation tool that sends from only a handful of documented IPs is a prime candidate. A transactional mail service with a static IP is another. Tackle these third-party services first. Often, removing just one or two non-critical `include`s is enough to get you back under the 10-lookup limit.

Validation: Trust the `Authentication-Results` Header

Your DNS record is updated. The SPF validator tool gives you a green light with 9/10 lookups. You are not done. The final step is to prove it works in the real world by sending tests and inspecting the headers of the delivered message.

You need to test from both primary sending sources. First, send an email from a standard user's Outlook client. This message should flow through your Proofpoint smarthost. Second, trigger an email from a native M365 service—a SharePoint alert is a reliable test. This message will originate directly from Microsoft's IPs.

In both cases, send the test to an external mailbox you control, like a personal Gmail or Outlook.com address. Once received, view the original message source and find the `Authentication-Results` header. This header is the receiving server's official verdict on your authentication.

Authentication-Results: mx.google.com; spf=pass (google.com: domain of my-domain.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=user@my-domain.com — Gmail Received Header

You are looking for `spf=pass`. A `spf=neutral`, `softfail`, or `fail` verdict means something is still wrong. The IP address noted in the header (in this example, `209.85.220.41`) must be present in one of the IP ranges authorized by your complete, recursively expanded SPF record. A `pass` for both the Proofpoint-routed test and the M365-native test is the only acceptable outcome.

The takeaway

The SPF 10-lookup limit isn't a bug; it's a feature designed to prevent DNS-based denial-of-service attacks. Our cloud-first infrastructure, with its reliance on dozens of third-party services, constantly pushes against this architectural ceiling. Managing a complex mail environment means accepting that your SPF record is no longer a static DNS entry you set once. It's a living policy that requires regular audits.

Every time a department wants to trial a new sales cadence tool or a new customer support platform, the first question must be, 'Does it send email on our domain?' If the answer is yes, the follow-up is, 'How many lookups will its SPF include add?' Staying ahead of this problem is far less painful than cleaning up after a deliverability failure. Auditing all your authorized senders and their DNS requirements manually is a headache, which is why platforms like MailSleuth.AI exist to automate that discovery and help you maintain policy hygiene.