Who Can Send as the S&P 1500? Mapping the SPF Supply Chain of 1,210 Public Companies

Measured October 7, 2026. Published October 2026.

Summary

SPF records are usually audited as syntax: is there a record, does it end in -all, does it stay under ten lookups. We treated them as what they really are, a list of other organizations' infrastructure that a company has authorized to send mail in its name. On October 7, 2026 we resolved the complete SPF authorization tree (every include, redirect, a, mx and exists term, recursively) for 1,210 mail-enabled corporate domains in the S&P 500, MidCap 400 and SmallCap 600, then checked every dependency for signs that it could be claimed by an outsider. All measurement was passive public DNS and registry lookups.

• Sender authorization is concentrated in a few operators. Microsoft 365 appears in the SPF trees of 47.1% of companies, Proofpoint in 34.0% and Salesforce in 29.7%. 981 of 1,210 companies (81.1%) authorize at least one of those three.
• Shared address space is the norm. A single IPv4 address is SPF-authorized by up to 649 companies (53.6% of the sample). 1,008,428 IPv4 addresses are each authorized by 100 or more index companies. SPF alone cannot tell one tenant of a shared platform from another.
• Much of the decision is made in someone else's DNS. 731 companies (60.4%) have an SPF tree that hands the per-connection decision to a third party's DNS zone through macros, and 477 (39.4%) do so directly in their top-level record. 357 of those 477 also publish DMARC p=reject on 100% of mail.
• Some SPF fails for everyone. 50 companies (4.1%) publish SPF that evaluates to a permanent error under RFC 7208. 16 of them are at full p=reject, so their legitimate mail passes DMARC only through DKIM.
• We found no takeable SPF dependency, and we report that as a result. Across 770 registrable domains, 2,444 dependency hostnames and 740 registry RDAP records, we found 0 unregistered or expired domains, 0 domains in redemption or pending delete, and 0 dangling CNAMEs. 15 dependency domains are within 30 days of their registry expiration date; the most widely used of them is relied on by 16 index companies.

Adoption numbers (98.0% publish DMARC, 58.8% enforce full p=reject) are included below as context, not as the headline.

Why the SPF supply chain matters

When a receiving mail server evaluates SPF, it asks one question: is the connecting IP address on the list this domain published? It does not ask which customer of a shared platform is connecting. Every include therefore extends a company's sending identity to whatever a vendor's DNS says at that moment, to every address the vendor publishes, and, transitively, to every vendor that vendor includes. A company's real exposure is set by three things that ordinary adoption surveys do not measure: how many operators it trusts, how much shared address space those operators bring with them, and whether any link in the chain has lapsed or can be claimed.

Prior academic work established the attack class. BreakSPF (Wang et al., NDSS 2024) showed that permissive SPF records covering shared cloud, proxy and CDN address pools can be abused to pass SPF and DMARC, measured across the Tranco top one million. This study is narrower and adds three things: it is scoped to a defined population of public companies with a tier breakdown, every authorization target was checked for registration and delegation status rather than inferred, and it reports provider concentration and dynamic delegation as first-class measurements.

Findings

Figure 1. Third-party operators authorized anywhere in corporate SPF trees, share of 1,210 mail-enabled domains. Measured October 7, 2026.

1. Three operators sit in four out of five SPF trees

We resolved 6,045 SPF terms across the 1,210 domains, reaching 770 distinct registrable domains, 440 of which belong to a party other than the company itself. The median company authorizes 2 third-party sending domains; the 90th percentile authorizes 6 and the maximum is 13.

Counts include authorization at any depth of the tree. 981 companies (81.1%) authorize at least one of the top three and 37 authorize all three. The mix shifts with company size: Proofpoint is more common in the S&P 500, while Microsoft 365 and marketing and transactional senders are more common further down the index.

2. Half a million shared addresses, authorized by more than half the index

Counting only addresses that can be enumerated statically (ip4 terms and resolved a and mx targets), the median company's SPF tree authorizes 458,758 IPv4 addresses. 734 companies (60.7%) authorize more than 100,000 addresses and 18 authorize more than one million.

Most of that space is shared. One 458,752-address block of Microsoft 365 outbound ranges is authorized by up to 649 companies at a single address. That is 79 more companies than reference a Microsoft hostname anywhere in their tree, because some companies paste ("flatten") a copy of a vendor's ranges into their own records. In total 1,008,428 IPv4 addresses are each SPF-authorized by at least 100 index companies, and 1,499,279 by at least 10.

This is not a claim that these companies can be spoofed. Large platforms apply their own tenant-level controls on which sender domains a customer may use, and DMARC with aligned DKIM does not depend on the IP address. It does mean that, for these companies, SPF provides little separation between tenants of the same platform, and that DKIM alignment and the provider's tenant controls carry most of the weight.

3. Dynamic delegation: the decision lives in a vendor's zone

SPF macros (for example %{i}, the connecting IP) let a vendor answer "is this IP allowed for this domain?" from its own DNS at query time. Hosted-SPF services do the same through a plain include. Both are useful operationally, and both mean the authoritative list of permitted senders is not in the company's own zone.

• 731 companies (60.4%) have a macro-evaluated term somewhere in their SPF tree.
• 477 companies (39.4%) delegate directly in their top-level record, through an email-security gateway's hosted SPF, a DMARC or SPF management service, or a vendor exists macro. This is most common in the S&P 500 (48.5%), then the MidCap 400 (38.0%) and SmallCap 600 (29.6%).
• 357 of those 477 companies also enforce DMARC p=reject on 100% of mail, so the vendor zone is part of the enforcement path for their strongest control.

Macro-evaluated authorization cannot be enumerated passively without sending queries on behalf of specific IP addresses, so the shared-address figures above are a lower bound.

4. SPF that fails closed for everyone

RFC 7208 requires a permanent error when evaluation needs more than 10 DNS-querying terms, when an include or redirect target has no SPF record, when more than two lookups return nothing (the void lookup limit), or when a domain publishes more than one SPF record. 50 companies (4.1%) hit at least one of these: 41 exceed the lookup limit (the largest needs 27), 8 include a target with no SPF record, 2 publish two SPF records, and 1 exceeds the void lookup limit. 16 of the 50 also publish DMARC p=reject on all mail. For those 16, receivers that evaluate the full record cannot pass SPF at all, and legitimate mail reaches the inbox only if it carries an aligned DKIM signature.

5. The dangling-authorization hunt: a clean null result

A takeable SPF dependency, such as an include pointing at a domain anyone can register, would let an outsider authorize their own servers for a company's domain. We looked for this carefully and found none.

• Registration. Every one of the 770 registrable domains in any SPF tree, including the static suffix of macro targets and the parents of hosts behind mx terms, was queried for NS records at both Cloudflare and Google. None returned NXDOMAIN from both. Our rule was to report a domain as dangling only if both resolvers returned NXDOMAIN and the registry's RDAP service returned "not found"; no domain reached the first condition.
• Registry status. Registry RDAP records were retrieved for 740 of the 770 domains. The other 30 could not be checked through RDAP (no RDAP service for the TLD, a registry error, or a private-suffix name), and all 30 have live NS delegation. 0 were past expiration and 0 were in redemption, pending delete or hold.
• CNAMEs. All 2,444 dependency hostnames were checked for CNAME chains ending in NXDOMAIN. 26 hostnames use CNAMEs; 0 dangle.
• Near-term watch list. 15 dependency domains are within 30 days of their registry expiration date. All showed active status with registrar locks, so most are likely on auto-renew. The most widely used is relied on by 16 index companies.

What we did find is decay that is not exploitable by registration. 22 references at 17 companies point to hostnames outside the company's own domain that no longer resolve or no longer publish SPF, and 9 references at 8 companies do the same inside the company's own domain. A representative example, redacted: include:spf-xxxxxxxx.<email-security-vendor>.com, a per-tenant hostname at a large email gateway vendor that now returns NXDOMAIN, left behind after a configuration change. Such references are controlled by the vendor, not by an outsider, but they cost lookups and can turn into permanent errors.

Context: enforcement posture

The posture figures below come from the same sample, measured between 3:00 and 3:02 PM ET.

Figure 2. Email authentication posture by index tier (context). Measured October 7, 2026.

Of the 192 domains at p=none, 178 already collect aggregate (rua) reports. 46 domains enforce DMARC on the parent domain but set sp=none for subdomains.

Methodology

Sample. Constituent lists of the S&P 500, MidCap 400 and SmallCap 600 from English Wikipedia on October 7, 2026 (revision IDs retained), with each company's official website taken from Wikidata (P856). Websites were reduced to registrable domains and deduplicated (1,266 domains); the analysis set is the 1,210 that publish an MX record. A domain in more than one list is counted in the larger-cap tier.

SPF tree resolution. For each domain we fetched the top-level SPF record and followed every include and redirect recursively (depth limit 10, loop detection), resolved a and mx targets (and the address records of MX hosts), and recorded exists and ptr terms. Macro terms were recorded but not expanded. Static IPv4 authorizations were collapsed per company and swept to compute overlap between companies. Operators were assigned by the registrable domain of each target. This pass ran from 3:45 to 3:46 PM ET on October 7, 2026.

Dangling checks. NS and SOA queries for every registrable domain in any tree at two independent resolvers; registry RDAP via the IANA bootstrap file for status and expiration; A and TXT queries for every dependency hostname to detect CNAME chains ending in NXDOMAIN. These checks ran between 3:47 and 3:50 PM ET.

Transport. All DNS queries used DNS-over-HTTPS (Cloudflare primary, Google fallback, and both independently for the registration test). The measurement host's local resolver returned empty answers for some zones, so it was not used.

Limitations. The website domain is not always the primary mail domain. Macro-evaluated authorization is a lower bound. Operator attribution by registrable domain can merge separate products of one vendor. Shared address space shows where SPF cannot separate tenants, not that spoofing succeeds; we sent no mail to test it. DKIM is not observable without selectors. The data is a single snapshot. SmallCap coverage is lower (416 of 603 rows had a website in Wikidata).

Recommendations

For mail administrators

1. Inventory your SPF tree, not just your record. Resolve every include to the bottom and list each operator and address range you actually authorize. Remove services you no longer use.
2. Do not lean on SPF where the infrastructure is shared. Require aligned DKIM from every platform that sends as you, so that DMARC passes on a signature that only you and that vendor control.
3. Fix permanent errors first. If your record exceeds 10 lookups, includes a target with no SPF record, or exists twice, receivers may fail SPF for every message. Check this after every vendor change.
4. Treat flattening as a copy that drifts. Pasted vendor ranges go stale when the vendor changes them. Prefer the vendor's include, or regenerate copies automatically and monitor them.
5. Know who controls your delegated zones. If a gateway or SPF management service answers for your domain, put that dependency in your vendor inventory and offboarding checklist.
6. Move DMARC to p=reject with pct=100, and do not set sp=none.

For sending platforms and SPF service providers

1. Publish tenant-specific include hostnames or enforce verified sender domains per tenant, and document which one you do.
2. Retire per-tenant hostnames with a clear, long-lived negative answer rather than silently, and tell the customer when their reference no longer matches an account.
3. Keep the domains your customers' SPF depends on on long registration terms with registry locks.

Responsible use and reproducibility

This study used only public DNS and registry data that any mail server can see. We sent no mail, scanned no ports, attempted no logins, registered nothing and tested no vulnerabilities. We publish aggregates only and do not name any organization or any specific dependency. Per-domain results are retained privately with the scripts used to produce them (scripts 00 to 11), so every figure can be reproduced. Organizations that want their own results can write to security@valty.ai.

Valty builds software for quantifying cyber exposure and governing remediation decisions. Questions about this research can be sent to security@valty.ai.