See Every SaaS Vendor a Company Uses From One Lookup

Open a terminal and run one query against a company you do not work for.

No login, no API key, and nobody scraped anything. A public resolver answered that on 2026-08-01, and the answer names seven identifiable third parties: a mailbox platform (spf.protection.outlook.com), Google's mail infrastructure, a customer support desk (mail.zendesk.com), a CRM (_spf.salesforce.com), an email marketing platform (servers.mcsv.net), a marketing automation suite (mktomail.com), and a transactional sending service (sendgrid.net).

Nobody leaked that. It was published deliberately, because it has to be. Microsoft puts the reason in one sentence in its own SPF documentation: "Specifically, SPF uses a TXT record in DNS to identify valid sources of mail for the domain." A receiver on the far side of the internet has to be able to check whether the machine talking to it is allowed to send as you. That check happens in DNS, in public, for everyone.

Now run the same query one domain over.

One mechanism. Same day, same resolver. So which of those two companies authorises more third-party senders to send mail as itself?

You cannot tell. Not "we did not check" — you cannot, and the reason why is most of this article. The honest version of the headline is this: one lookup returns every third-party sender a domain chose to publish at that name, on that day. That is a lot. It is not everything, and the gap between those two statements is where the interesting material lives.

Why the specification hands you this

SPF lives in a TXT record and nowhere else. RFC 7208 Section 3.1 is blunt about it: "SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only." The old dedicated SPF record type is gone. One record type, one query.

The mechanism that names outside companies is include:, and the RFC describes its purpose in terms that read like a description of the vendor stack:

"The "include" mechanism makes it possible for one domain to designate multiple administratively independent domains."

— RFC 7208, Section 5.2, IETF / RFC Editor, April 2014

The same section tells publishers when to reach for it, which is what makes an include target a strong signal rather than a coin flip:

"The "include" mechanism is intended for crossing administrative boundaries. When remaining within one administrative authority, "include" is usually not the best choice."

— RFC 7208, Section 5.2, IETF / RFC Editor, April 2014

RFC 7208 is a Proposed Standard, published in April 2014, obsoleting RFC 4408 and updated since by RFC 7372, RFC 8553 and RFC 8616. It is a published RFC, not an Internet-Draft, and it has been sitting there in the open the whole time.

Reading somebody else's zone is catalogued behaviour, incidentally. MITRE ATT&CK files it as sub-technique T1590.002 and names SPF specifically as a record type that exposes third-party providers; our piece on DNS recon into Entra tenant IDs takes that framing further than this article will.

The include mechanism does not include anything

Here is the part almost every explainer on the internet gets wrong, including some good ones.

The usual description says an include: pastes the vendor's record into yours, as if the mechanisms were being copied in. That is not what happens, and the specification says so about as plainly as a standards document ever says anything:

"In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than literally including the mechanisms of the referenced record in the first."

— RFC 7208, Section 5.2, IETF / RFC Editor, April 2014

What actually happens is a recursive evaluation. The evaluating server runs the whole check again against the referenced domain, using the same connecting IP and the same sender, and then throws away everything except the verdict. "The "include" mechanism triggers a recursive evaluation of check_host()," as Section 5.2 puts it. Only a pass from that nested run makes the include match. A nested fail, softfail or neutral simply does not match, and evaluation continues to the next mechanism. A nested none, meaning no SPF record at the target at all, makes the whole parent record return permerror.

Get that wrong and you get the consequence wrong too. If an include were a text splice, then a vendor's -all would land in the middle of your record and hard-fail everything after it. It does not:

"For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall "fail". (Better names for this mechanism would have been "if-match", "on-match", etc.)"

— RFC 7208, Section 5.2, IETF / RFC Editor, April 2014

If-match. That is the mechanism you are actually reading when you look at an include list: a series of questions, asked in order, each one of which the vendor answers on its own behalf.

The rest of the syntax is small. Section 4.6.2 says mechanisms are considered in turn from left to right, and gives you the four qualifiers: + pass, - fail, ~ softfail, ? neutral, with + assumed when none is written. Section 5.1 covers the thing on the end: all always matches, which is why it sits rightmost as the explicit default. So -all means "fail anything I did not list" and ~all means "softfail it". That is the entire reading protocol.

If the query mechanics are new to you, our TXT record guide covers them properly and this article will not re-teach them.

Reading the vendor tells

Once you accept that an include target is a name owned by somebody else, identification becomes pattern matching against vendor documentation. The quality of that documentation varies wildly, and the unevenness belongs in the table rather than in a footnote at the bottom. Some vendors publish the exact include value on an open page you can cite. Others do not. They tell customers to copy a value out of a console, or they have moved to a CNAME-based setup and no longer print the SPF value anywhere, which means the pattern you are matching is a convention nobody official currently documents.

The table below covers the distinct include and exists: targets observed across 14 hand-picked domains on 2026-08-01, from a single resolver. It is a convenience sample of large, well-known companies. It is not a survey, nothing in it was randomly selected, and no market share, ranking or trend can be computed from it. The format, a provenance column stating where each attribution comes from, is borrowed from a companion post on identifying email gateways from MX records, which uses the same discipline on the inbound half of the picture.

Four rows in that table are negative results, and they are worth as much as the confirmed ones. No current first-party Mailchimp page we could find prescribes servers.mcsv.net. SendGrid's own SPF page never prints sendgrid.net. Salesforce's help article would not render its body without a browser session. Fortra's detailed hosted-SPF knowledge-base article sits behind its support portal login, so we are not citing something readers cannot open. A provenance marker beats a confident guess every time, and the Mailchimp row makes its own point: an include can outlive the vendor's own published guidance and keep working perfectly.

The blind spot, which is also the second half of the article

Go back to nvidia.com. One include, three macros, no vendor list.

Two entire policies, each one mechanism long. Neither one names a marketing platform, a support desk, a CRM or a payroll system. Read them naively and you would write down "this company has almost no third-party senders," which is backwards.

Those %{...} sequences are SPF macros, defined in RFC 7208 Section 7:

"When evaluating an SPF policy record, certain character sequences are intended to be replaced by parameters of the message or of the connection."

— RFC 7208, Section 7: Macros, IETF / RFC Editor, April 2014

Parameters of the connection. Not of the record. Section 7.2 defines the letters, and four of them are doing all the work in the records above: %{i} is the connecting IP address, %{d} is the domain being checked, %{v} expands to the string in-addr for IPv4 or ip6 for IPv6, and %{h} is the HELO/EHLO name the sending server announced. Section 7.3 adds transformers. The one that matters here is r: it reverses the value on dots, so an IP that expands as 192.0.2.1 under %{i} expands as 1.2.0.192 under %{ir}, in the familiar reverse-DNS order.

Assemble it and Proofpoint's mechanism stops being cryptic. include:%{ir}.%{v}.%{d}.spf.has.pphosted.com becomes, for a specific connection, a lookup of a hostname built from the reversed sending IP, the address family, and the domain being checked. Every different sender gets a different query. Every different query can get a different answer.

The companion mechanism is exists:, from Section 5.7, which adobe.com was using on the same day:

"This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted."

— RFC 7208, Section 5.7: "exists", IETF / RFC Editor, April 2014

Construct a name, do an A lookup, and match if anything comes back. The RFC prints a worked example of the same shape in that section, which means none of this is a hack. It is the specification being used exactly as written.

A flat SPF record is a guest list. You read it at the door.

A macro record is a doorman. You have to walk up and be recognised, one visitor at a time.

The list did not get shorter. It moved to somebody else's server.

The vendors selling this describe the property themselves. Proofpoint, writing about its Hosted SPF product, states the design intent in the customer's own words:

"You want to make sure that outsiders can't view your IP list. We call this "security through obscurity.""

— The Next Evolution of Sender Policy Framework: Hosted SPF, Proofpoint, 6 April 2022

Valimail describes the same behaviour from the other side, and its wording is the precise one:

"Valimail's patented instant SPF response returns only the specific and targeted response needed for a given email sending service that has been enabled by the customer to send on their behalf."

— Valimail SPF Records, Valimail Help Center, 10 July 2024

Read that carefully. The customer's list of authorised senders still exists. It is complete, it is maintained, and it is disclosed one answer at a time to whoever happens to connect. From outside you can ask about an IP you already suspect. You cannot ask "who is on the list?" and there is no query that means that.

So a one-mechanism record is evidence of a hosted-SPF product, and of nothing else. Six of the 14 domains sampled on 2026-08-01 published Proofpoint's macro include: pfizer.com, paloaltonetworks.com, target.com, nasdaq.com, hsbc.com and walmart.com. That is a fact about those six domains on that day, from one resolver, and it is not a market share. What it does mean is that on this hand-picked list of large enterprises, the domains most likely to have the most interesting vendor stacks were also the ones publishing the least.

Vendors sell hosted SPF mainly as a way around RFC 7208's cap of ten lookup-causing terms per evaluation. Valimail says its records exist to address that limit directly, and our own SPF guide plus a companion post on PermError cover the budget side in full. This article is about the other consequence of the same mechanism, the one nobody advertises: the record stops being readable.

Two honest footnotes on macros, because they are not free. RFC 7208 Section 7.3 advises sending organisations to avoid the s, l, o and h macros alongside mechanism directives, since per-message values defeat DNS caching, and Valimail's documented record does use %{h}. The RFC advises against it; that is the whole of the claim, and it is not an accusation of non-compliance. Separately, in August 2023 Proofpoint disclosed a flaw in Valimail's macro implementation where a crafted HELO produced a temperror and so suppressed a DMARC policy; Valimail fixed it, and the disclosure is one vendor writing about a competitor, which you should weigh accordingly.

One identifier, two record types

A small observation while we are in Proofpoint's neighbourhood. On 2026-08-01, hsbc.com published this:

The eight hex characters in spf-00299f02.pphosted.com are the same eight characters that appear in the domain's inbound MX hostname, mxb-00299f02.gslb.pphosted.com, which our companion post on MX-based gateway identification recorded the same day. Same identifier, two different record types. That is the observation, and it stops there. We are not going to guess what the hex encodes, and we are not building a cross-organisation tracking method out of it.

A bug in our own dictionary

While collecting the records for this article, we found a defect in DNSai's vendor dictionary.

The dictionary mapped the pattern stspg-customer to Stripe. It belongs to Atlassian Statuspage. Any domain publishing include:stspg-customer.com was therefore reported as using Stripe, and on 2026-08-01 that included at least two domains in this sample: oracle.com and cloudflare.com. Both publish the include. Neither of those results was correct.

It surfaced the way these things usually do, by accident. Checking the mapping against the vendor's own domain produced a contradiction: statuspage.io's own SPF record publishes include:stspg-customer.com, and stripe.com's record does not contain it anywhere. A vendor's own domain publishing another vendor's include, while the supposed owner publishes nothing of the kind, is not a subtle signal.

Atlassian's documentation confirms it twice over. The Statuspage DNS configuration page instructs customers directly:

"Create an SPF record that includes: stspg-customer.com"

— Configure your DNS | Statuspage, Atlassian Support

The same page prints a worked example, v=spf1 include:mailgun.org include:stspg-customer.com -all, which shows the value sitting alongside another vendor's include in a customer's record. And Atlassian's public issue tracker treats it as the required field:

"Customers can explicitly add include:stspg-customer.com into the top level of their SPF record before they include the Proofpoint configuration."

— STATUS-996, Atlassian Jira (Statuspage project)

That same issue prints a real customer record combining both mechanisms this article has been dissecting: v=spf1 include:stspg-customer.com include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~all. A status page and a hosted-SPF macro, in one line, published by the vendor rather than observed by us.

The bug was reported for correction. We are not claiming a deployment date for the fix here, because this article was written before we could honestly claim one. A correct Statuspage entry keyed on statuspage already existed in the dictionary alongside the wrong one, which is how a mapping like this survives review: nothing looks missing.

This belongs in the article rather than in a changelog because it is the strongest available evidence for the article's actual argument. A vendor dictionary is a maintained heuristic. It is not a registry, it has no authority, and its output is a guess with a good track record. Ours is about 1,131 entries; on the 19 targets here it matched 18, missed one, and got one of the 18 wrong. Anyone publishing the coverage number without the error number beside it is selling you something.

Two ways the method fails on its own terms

The dictionary miss is more interesting than the dictionary error, because a human reads it instantly.

Look at the third include. greenhouse-outbound-mail.stripe.com is a Stripe-owned hostname whose label names a third-party vendor. You read "greenhouse" and you are done in half a second. A dictionary matching on registrable domains sees stripe.com, files it as first-party, and moves on. That is the one target out of 19 our dictionary did not match on 2026-08-01, and it is a fair representative of an entire failure class: vendor identity is not always in the registrable domain.

The phrasing matters here. Greenhouse's own documented include is mg-spf.greenhouse.io, which is not the string Stripe published. So the accurate sentence is "a Stripe-owned hostname whose label names Greenhouse", not "Stripe publishes Greenhouse's include". The label is legible; the delegation shape is Stripe's own.

The inverse case is on the same day, four domains down.

Three numbered includes behind first-party names, with no vendor string visible anywhere. Whatever _vspf1, _vspf2 and _vspf3 resolve into, the record itself discloses nothing about it. That is the pattern; we are describing it, not assigning a motive to it, and no observation in DNS supports one.

Between them those two records bracket the method. One vendor name sitting in plain sight that a machine cannot see, and three vendor slots a machine can see that carry no name at all.

What an include does not tell you

This section is longer than the how-to on purpose.

An include is authorisation, not usage. It records that somebody with write access to the zone once authorised a sender. It says nothing about volume, spend, seat count, contract status, whether the integration still runs, or whether anyone at the company remembers approving it. Nothing expires an include; a vendor decommissioned three years ago looks exactly like one in daily use. DMARCguard, which ran this same suffix-mapping technique across millions of domains and published its methodology, states the limit in the same terms:

"Suffix-based mapping — a domain including _spf.google.com is classified as Google Workspace, but could be using Google for relay-only delivery; the mapping reflects DNS configuration, not contractual relationship"

— SPF Supply Chain 2026, DMARCguard, 15 March 2026 (vendor research, not peer-reviewed)

The same report discloses that its roughly 80-provider registry left 66.9% of the includes it saw in an "other" bucket: self-hosted servers, regional ISPs, hosting providers, niche services. Different corpus, different dictionary, wildly different sample from ours, so it is not a benchmark anyone beats. It is a published number showing that dictionary coverage is a real and measurable limit of the method in general.

The apex record is not the whole domain. This one is documented as a best practice by Microsoft, which makes it the most systematic blind spot in the technique:

"For email services that aren't under your direct control (for example, bulk email services), we recommend using a subdomain (for example, marketing.contoso.com) instead of your main email domain (for example, contoso.com)."

— Set up SPF to identify valid email sources for your Microsoft 365 domain, Microsoft Learn, 3 July 2026

Microsoft is equally clear that a parent record does not cover its subdomains: each subdomain sending mail needs its own SPF record. So an apex-only sweep undercounts by construction, and it undercounts hardest in exactly the category the reader is most curious about: the bulk senders somebody deliberately moved off the main domain.

A heavy user can publish nothing at all. AWS documents that Amazon SES sets SPF implicitly, because messages default to a MAIL FROM domain that is a subdomain of amazonses.com; a customer only publishes their own SPF entry when they configure a custom MAIL FROM domain. Absence of an include is not absence of a vendor.

One include can name two companies. Greenhouse's own support documentation says plainly that "Replies to emails sent from Greenhouse will not be routed back to Mailgun, our email provider." A single include can therefore represent a vendor, that vendor's sending infrastructure provider, and any subprocessor underneath, collapsed into one label.

Fingerprints decay silently. Fortra moved the parent domain of its hosted SPF records and kept the old one working:

"The apex / parent domain for our Hosted SPF records has changed from agari.com to agari-dns.net. Existing SPF records using agari.com will continue to work and can be updated to use the new domain."

— Host Your SPF Records at Fortra, Fortra (Agari)

A dictionary keyed only on the old name keeps matching old records and quietly stops matching new ones. No error, no alert, just a slowly falling hit rate that looks like customers churning.

Most software never touches the mail domain. Issue trackers, design tools, data warehouses, an ERP nobody emails from: none of it appears in SPF, because SPF enumerates outbound mail senders. That is one slice of the stack, not the stack.

And the sample here is fourteen domains. One resolver, one vantage point, 2026-08-01, hand-picked from companies everyone can name. Nothing in this article should be turned into a ranking or a trend. For scale numbers there is real measurement work: Czybik, Horlboge and Rieck analysed 12 million domains for the ACM Internet Measurement Conference and reported growing adoption, "with 56.5 % of the domains providing SPF records", along with a finding that reframes what an include hands over: "For example, 34.7 % of the domains allow emails to be sent from over 100 000 IP addresses." When you authorise a vendor, you authorise their whole sending estate.

Back to the two records

github.com's record on 2026-08-01 named seven third parties in one query, and the correct sentence about each of them is "authorises this vendor to send mail as the domain", not "is a customer of", not "uses", not "spends money with". nvidia.com's record named one vendor, Valimail, and told you nothing whatsoever about who else is authorised, because the answer is computed per connection on somebody else's nameserver and there is no question you can ask that returns the list.

Both of those are useful findings. Only one of them looks like one.

Run the query yourself. Write down the resolver and the date, because these records change without notice. Say "authorises" rather than "uses". When a record is one macro long, write down "hosted SPF, list not enumerable" instead of an empty vendor column. And when a dictionary hands you a vendor name, remember that somebody typed that mapping in by hand, that nobody audits it on a schedule, and that ours said Stripe for every status page it saw until a contradiction fell out of a record we were reading for something else entirely.

Sources

1. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Sections 3.1, 4.6.2, 4.6.4, 5.1, 5.2, 5.7, 7, 7.2, 7.3) — IETF / RFC Editor, April 2014. https://www.rfc-editor.org/rfc/rfc7208.html
2. Information on RFC 7208 (status, obsoletes, updated-by) — RFC Editor, April 2014. https://www.rfc-editor.org/info/rfc7208
3. Gather Victim Network Information: DNS, Sub-technique T1590.002 — MITRE ATT&CK, last modified 24 October 2025. https://attack.mitre.org/techniques/T1590/002/
4. Set up SPF to identify valid email sources for your Microsoft 365 domain — Microsoft Learn, 3 July 2026. https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure
5. Set up SPF — Google Workspace Admin Help. https://knowledge.workspace.google.com/admin/security/set-up-spf
6. Allowing Zendesk to send email on behalf of your email domain — Zendesk Support. https://support.zendesk.com/hc/en-us/articles/4408832543770-Allowing-Zendesk-to-send-email-on-behalf-of-your-email-domain
7. Set up SPF and DKIM for your Email Deliverability — Adobe Marketo Engage, Adobe Experience League, 16 June 2026. https://experienceleague.adobe.com/en/docs/marketo/using/product-docs/email-marketing/deliverability/set-up-spf-and-dkim-for-your-email-deliverability
8. Using a Custom From Address — Qualtrics Support. https://www.qualtrics.com/support/survey-platform/distributions-module/email-distribution/using-a-custom-from-address/
9. Authenticating Email with SPF in Amazon SES — Amazon Web Services. https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-spf.html
10. My Email From Name Shows "mailchimpapp.net" or "mcsv.net" — Mailchimp (Intuit). https://mailchimp.com/help/my-campaign-from-name-shows-mcsvnet/
11. Set Up Email Domain Authentication (cited as a negative result: covers CNAME/DKIM and DMARC, prints no SPF include value) — Mailchimp (Intuit). https://mailchimp.com/help/set-up-custom-domain-authentication-dkim-and-spf/
12. Sender Policy Framework (SPF) (cited as a negative result: never prints sendgrid.net) — Twilio SendGrid Docs, 16 March 2026. https://www.twilio.com/docs/sendgrid/glossary/spf
13. Include Salesforce in Your SPF Record (cited as a negative result: article body did not render to an unauthenticated fetch) — Salesforce Help. https://help.salesforce.com/s/articleView?id=sales.emailadmin_spf_include_salesforce.htm&language=en_US&type=5
14. Greenhouse Mailgun Updates (April 2024) — Greenhouse Support, 10 April 2024. https://support.greenhouse.io/hc/en-us/articles/24674627688475-Greenhouse-Mailgun-Updates-April-2024
15. Email domain verification — Greenhouse Support. https://support.greenhouse.io/hc/en-us/articles/201111684-Email-domain-verification
16. Configure your DNS | Statuspage — Atlassian Support. https://support.atlassian.com/statuspage/docs/configure-your-dns/
17. STATUS-996: Customers with a custom email addresses that use Proofpoint in the SPF record will have it intermittently marked invalid — Atlassian public Jira (Statuspage project). https://jira.atlassian.com/browse/STATUS-996
18. The Next Evolution of Sender Policy Framework: Hosted SPF — Proofpoint, 6 April 2022. https://www.proofpoint.com/us/blog/email-and-cloud-threats/next-evolution-sender-policy-framework-hosted-spf
19. Proofpoint Discloses Valimail SPF Macro Vulnerability (one vendor disclosing about a competitor) — Proofpoint, 22 August 2023. https://www.proofpoint.com/us/blog/email-and-cloud-threats/proofpoint-discloses-valimail-spf-macro-vulnerability
20. Valimail SPF Records — Valimail Help Center, 10 July 2024. https://support.valimail.com/en/articles/8466461-valimail-spf-records
21. Host Your SPF Records at Fortra — Fortra (Agari). https://hstechdocs.helpsystems.com/manuals/agari/agari_DMARC_protection/current/Content/Topics/BP/SPF/Host_Your_SPF_Records.html
22. Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild — Czybik, Horlboge & Rieck, ACM Internet Measurement Conference 2023 (open arXiv preprint, 12 February 2025). https://arxiv.org/abs/2502.08240
23. SPF Supply Chain 2026: Email Sender Market Share Across 5.5 Million Domains (vendor research, not peer-reviewed) — DMARCguard, 15 March 2026. https://dmarcguard.io/research/spf-supply-chain/
24. Live SPF observations, 2026-08-01 — DNSai. dig +short <domain> TXT filtered to the record beginning v=spf1, single recursive resolver, 14 hand-picked enterprise domains. Dictionary coverage checked the same day against the production technology-vendor dictionary of about 1,131 entries: 19 distinct include/exists targets tested, 18 matched, 1 missed, 1 of the 18 misattributed.

Share this article