SPF Trust Surface: a beginner's guide

Your SPF trust surface is the complete list of every mail server, third-party SaaS, and authorized sender that is allowed to send email claiming to be from your domain. It's not just the direct entries in your SPF record — it's the full, expanded list after every `include:` mechanism has been resolved all the way down. A single line like `v=spf1 include:_spf.google.com include:mailgun.org include:sendgrid.net -all` expands out to hundreds of actual IP addresses under Google, Mailgun, and SendGrid control. Every one of those IPs is now cryptographically authorized to send mail as your brand. Most organizations have no idea how large their trust surface actually is.

You should care because every `include:` is a delegated-trust relationship, and delegated trust is where email-security incidents start. If Mailgun is compromised and an attacker gains the ability to send arbitrary email through Mailgun's infrastructure, they can send email as your domain — because you told the internet that Mailgun-originated mail is legitimately yours. Every stale include you forgot to remove (the email-marketing platform you cancelled last year, the CRM you migrated off of, the transactional-email SaaS the team never fully deprecated) is a permanent foothold in your authentication perimeter. SPF trust-surface analysis is how you see the size and shape of that perimeter clearly enough to shrink it.

The five things every SPF trust-surface check looks at:

• Every authorized sender after full recursion. Expand every `include:` all the way to concrete IP ranges. A three-line SPF record can expand to hundreds of CIDRs.

• The DNS-lookup count against the 10-limit. RFC 7208 caps SPF at 10 DNS lookups; every `include:` counts, and nested includes count too. Exceeding 10 produces PermError and disables SPF entirely.

• Unknown or unexpected senders. Every entry should map to a vendor you actually use. A `mailchimp.net` include on a domain whose team has never touched Mailchimp is either a leftover or an incident.

• Coverage by third-party compromise. If any of the included vendors has had a public breach (Mailgun, Mailchimp, SendGrid all have), your trust surface was briefly shared with the attackers.

• The all-qualifier. A record ending in `-all` (strict reject) is the only configuration that actually enforces the surface. `~all` (soft-fail) and `?all` (neutral) are mostly advisory.

Three questions an SPF trust-surface check answers:

• How many unique IP addresses are currently authorized to send email as my domain?

• Does every one of those entries correspond to a vendor I'm still actively using?

• Am I under the 10-DNS-lookup limit, or am I about to silently disable SPF the next time I add a sender?

The cost of a bloated trust surface is the slow accumulation of vendors you're cryptographically trusting without meaning to. The fix is a quarterly trust-surface audit: enumerate every authorized sender, confirm each one is still in use, and prune the includes that no longer map to active vendors. The M3AAWG Sender Best Common Practices covers the operational discipline; RFC 7208 covers the formal rules.

In one sentence: Map every sender authorized by your [SPF (Sender Policy Framework)](/guides/spf-record-setup-guide) include chain

Recursively resolves the SPF (Sender Policy Framework) include tree to enumerate every third-party service authorized to send email on behalf of the domain. Classifies each sender into a provider (Google, Microsoft 365, SendGrid, Mailgun, AWS SES, Mailchimp, etc.), grades trust, and reports the full attack surface if any include is compromised.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Fetches and parses the apex SPF (Sender Policy Framework) record, then follows each include: directive recursively up to a configurable depth (default 3, max 10 per the official internet standard). Each terminal record's mechanisms (ip4, ip4-cidr, ip6, a, mx, exists) are enumerated. Terminal-host names are classified against a provider pattern library (Gmail, O365, SendGrid, Mailgun, SES, Mailchimp, HubSpot, Salesforce Marketing Cloud, Pardot, etc.) with trust levels. Returns the tree of includes, the flat vendor list with classification, and risk signals (stale senders, excessive vendors, concentration).

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the SPF Trust Surface tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

The SPF (Sender Policy Framework) lookup count tells you whether your policy validates. The trust surface tells you what happens if any of those vendors get breached. A domain with SendGrid + Mailchimp + Pardot has three attacker paths to send spoofed mail — each a separate third-party vendor to monitor. This endpoint makes that implicit trust relationship explicit.

Picture this in real life. Imagine a security lead. Here's the situation they're walking into: Inventory every vendor authorized via SPF (Sender Policy Framework) so each can be tracked in the vendor risk register alongside the rest of the supply chain. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the SPF Trust Surface tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the SPF Trust Surface tool is built for you:

• Will the emails I send actually reach the inbox, or are they going to spam?

• Can someone else send phishing emails pretending to be my domain?

• Have I set up the three rulebooks (SPF, DKIM, DMARC) that mailbox providers now require?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, and brand teams protecting against phishing. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and your real emails risk landing in the spam folder while scammers find it easier to impersonate your brand. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the SPF Trust Surface tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security lead, a incident responder, and an email admin — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Third-Party Risk Management

Imagine you're a security lead. Inventory every vendor authorized via SPF (Sender Policy Framework) so each can be tracked in the vendor risk register alongside the rest of the supply chain.

Why it matters: Email-infrastructure vendors no longer hide in include: chains where they escape risk review.

Story 2: Post-Incident Containment

Imagine you're an incident responder. After a vendor (e.g., Mailchimp) is breached industry-wide, identify every owned domain whose SPF (Sender Policy Framework) authorizes that vendor to send email.

Why it matters: Rapid blast-radius identification during vendor incidents.

Story 3: SPF Cleanup

Imagine you're an email admin. Identify stale vendors in the SPF (Sender Policy Framework) include chain — providers no longer used whose includes still grant sending rights.

Why it matters: Reduce attack surface by removing unused third-party sender authorizations.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the SPF Trust Surface tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• When setting up email on a brand-new domain.

• After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, etc.).

• When a customer reports that your emails are landing in their spam folder.

• Before a security audit, a SOC 2 review, or a major marketing campaign.

If you can see yourself in even one of those bullets, the SPF Trust Surface tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the SPF Trust Surface tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the SPF Trust Surface tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with SPF Trust Surface. If you're already running this check, the related ones often answer the next question that comes up:

• SPF Check — Validate SPF record syntax, DNS lookups, and policy

• Email Spoofability Score — Composite spoofability score across SPF/DMARC/DKIM

• Email Hosting — Detect email service provider

• DNS Supply Chain — Map third-party vendors via SPF, NS, CAA, and TXT records

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check SPF Trust Surface and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

SPF (Sender Policy Framework) — A list, published in your DNS, of which servers are allowed to send email pretending to be you. Helps stop spammers from forging your address.

CIDR (Classless Inter-Domain Routing) — A shorthand way of describing a range of IP addresses, like 192.168.1.0/24. The number after the slash says how many addresses are in the range.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.