M&A Diligence: Your Target’s SPF Record Is a Map of Their Hidden Risk

The deal is signed, the press releases are out, and then the phishing starts. Not just any phishing, but hyper-realistic spoofs of the CFO's email address, sent from a bizarre but technically-legitimate marketing service the acquired company abandoned years ago. Suddenly, the acquiring CISO is fighting a five-alarm brand-impersonation fire.

This isn't a hypothetical. It's a direct consequence of overlooking one of the most public, information-rich artifacts in M&A cyber due diligence: the target company's Sender Policy Framework (SPF) record. Most diligence teams glance at it, check for its existence, and move on.

That's a mistake. A company's SPF record is a public declaration of every server and third-party service trusted to send email on its behalf. It's a map of their digital supply chain, a history of their SaaS adoption, and often, a catalog of their security negligence.

Beyond the Balance Sheet: Trust Is a Technical Asset

In any acquisition, you're buying more than assets and liabilities; you're acquiring a brand. The trust that customers, partners, and employees place in that brand is intangible but invaluable. In digital communication, that trust is built on a foundation of verifiable identity. For email, this isn’t about fuzzy feelings. It's about cryptographic proof and strict, machine-readable policy.

Email authentication protocols are the technical bedrock of this trust. SPF (RFC 7208) validates the sending server's IP address. DKIM (RFC 6376) provides a cryptographic signature to verify the message body and certain headers haven't been altered in transit. And DMARC (RFC 7489) ties them together, telling the world's mail servers what to do when a message fails those checks—and giving you the data to see who is using your domain.

During M&A due diligence, analyzing the target's email authentication posture is non-negotiable. A weak posture means the brand you just spent millions or billions on is easily impersonated. It means they have little to no visibility into who is sending email from their domain, a condition no security team should be willing to inherit.

Anatomy of a Risky SPF Record

An SPF record is a simple TXT entry in a domain's DNS, but its implications are complex. It's a list of mechanisms that define authorized senders. You'll see `ip4` and `ip6` for specific IP addresses, `a` and `mx` for hosts associated with the domain, and the most common offender: `include`.

The 10-Lookup Limit and Vendor Sprawl

RFC 7208 imposes a hard limit of 10 DNS lookups to fully resolve an SPF record. Every `include`, `a`, `mx`, and `exists` mechanism counts. When a record exceeds this limit, it returns a `permerror` (permanent error), and many receivers will treat it as if there were no SPF record at all. The email fails SPF validation.

v=spf1 include:spf.protection.outlook.com include:mail.zendesk.com include:servers.mcsv.net include:_spf.salesforce.com include:sendgrid.net include:some-old-crm.com include:another-defunct-martech.co ip4:203.0.113.42 ~all

A record bloated with `include` statements is a giant red flag. It signals a sprawling, unmanaged collection of third-party vendors. Each `include` points to another company's infrastructure—Microsoft 365, Zendesk, Mailchimp, Salesforce, SendGrid. It’s a public directory of the target's SaaS stack. More importantly, it’s a directory of attack surface and third-party risk. If any of those services are compromised, the attacker can send authenticated mail on the target's behalf.

Hunting for Digital Ghosts

The real danger lies in what's been forgotten. Your target company likely trialed a dozen SaaS platforms over the last decade. They used a specific CRM for six months in 2018, then cancelled the subscription. They tested a marketing automation tool, decided against it, and moved on. But did they clean up their SPF record?

Probably not. That `include:some-old-crm.com` mechanism is a ghost in their DNS. The operational risk is catastrophic. If an attacker discovers that `some-old-crm.com` is an expired domain, they can simply register it. Then, they can publish their own malicious SPF record at that domain, instantly granting their own mail servers the authority to send authenticated email as your target company. This isn't theoretical; it's a known attack vector for sophisticated Business Email Compromise (BEC) campaigns.

The Diligence Playbook

The analyst's job during due diligence is to be a ghost hunter. For every single `include` in the target's SPF record, you must ask: Is this service still in active use? When was the last invoice paid? Who is the business owner? You need to perform DNS lookups on each included domain. Is it still registered? Who owns it? A simple WHOIS lookup can reveal if a domain has lapsed and been re-registered.

This process turns a simple DNS query into a powerful audit of the target's IT governance and operational discipline. The more ghosts you find, the higher the risk of inheriting a security nightmare.

Softfail Is Not a Security Control

The final component of an SPF record is the all-important qualifier, typically `~all` or `-all`. This tells receiving mail servers what to do with mail from sources not listed in the record.

A `~all` (Softfail) is merely a suggestion. It tells the receiver, "This message is probably not legitimate, but I'm not confident enough to tell you to block it. You decide." In practice, most mail gateways will deliver a soft-failed message, perhaps with a warning banner that users quickly learn to ignore. A `-all` (Fail), on the other hand, is an explicit command: "If the sending IP is not on my list, reject the message. It is fraudulent."

Finding a `~all` in a target's SPF record indicates a lack of confidence. It means the IT team doesn't have a complete inventory of their own sending infrastructure. They're afraid of breaking email from a shadow IT server someone spun up in a forgotten corner of their network. It's a technical crutch that signals poor asset management. Combined with a weak DMARC policy (or no DMARC at all), `~all` leaves the door wide open for IP-based spoofing from compromised devices or misconfigured servers within the target's own network space.

The Post-Acquisition Integration Playbook

Once the deal closes, the real work begins. You can't just staple the two companies' SPF records together. That would almost certainly exceed the 10-lookup limit and cause a massive `permerror` outage. Merging SPF records is a delicate but crucial part of technical integration.

Inventory, Consolidate, Harden

First, inventory. The most reliable source of truth is not the existing SPF record, but DMARC aggregate (`rua`) reporting. For several weeks, collect DMARC reports from a `p=none` (monitoring) policy. This will show you every IP address and third-party service on the planet attempting to send mail using that domain, along with their SPF and DKIM pass/fail status.

Second, consolidate. Now that you have ground-truth data, build a new, clean SPF record from scratch. If both companies use Salesforce and Microsoft 365, you only need one `include` for each. Challenge every other service. Use your DMARC data to prove it's still needed. Remove every ghost, every redundant entry, and every piece of legacy cruft.

Finally, harden. The end state for any mature organization is an SPF record ending in `-all`, enforced by a DMARC policy of `p=quarantine` or, ideally, `p=reject`. This is the only way to slam the door on domain impersonation. For complex mail flows like forwarded messages that legitimately break SPF, rely on DKIM alignment and the ARC chain (RFC 8617) to preserve authenticity through the forwarding path. A `~all` is a temporary measure, not a permanent solution.

The takeaway

An SPF record is not just a line of technical text in DNS. It's a public statement about a company's approach to security, identity, and risk management. In the high-stakes context of M&A, it provides an unvarnished signal about the operational maturity and technical debt of the company you are acquiring. Ignoring it is an unforced error.

Before your next technical due diligence review kicks off, start with a simple DNS query. Analyze the SPF record's complexity, hunt for ghosts, and assess the strength of its policy. Tools like MailSleuth.AI can automate this analysis and cross-correlate it with DMARC and DKIM intelligence, but even a manual `dig txt` command is a powerful first step toward uncovering the hidden risks.