SPF Trust Surface
developer/v1/security/spf-trust-surfaceRecursively resolves the SPF 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.
What It Does
Fetches and parses the apex SPF record, then follows each include: directive recursively up to a configurable depth (default 3, max 10 per RFC 7208). 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).
Why It's Useful
The SPF 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.
Use Cases
Third-Party Risk Management
Inventory every vendor authorized via SPF so each can be tracked in the vendor risk register alongside the rest of the supply chain.
Email-infrastructure vendors no longer hide in include: chains where they escape risk review.
Post-Incident Containment
After a vendor (e.g., Mailchimp) is breached industry-wide, identify every owned domain whose SPF authorizes that vendor to send email.
Rapid blast-radius identification during vendor incidents.
SPF Cleanup
Identify stale vendors in the SPF include chain — providers no longer used whose includes still grant sending rights.
Reduce attack surface by removing unused third-party sender authorizations.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
domain | string | Required | The domain whose SPF trust surface should be enumeratedExample: example.com |
Response Fields
| Field | Type | Description |
|---|---|---|
domain | string | The queried domain |
has_spf | boolean | Whether the domain publishes an SPF record |
include_tree | object | Recursive tree of includes with each level's record |
vendors | array | Flat vendor list: name, type, trust, include_path, mechanism_count |
unique_vendors | number | Count of distinct authorized vendors |
dns_lookup_count | number | Total DNS lookups (against the RFC 7208 §4.6.4 limit of 10) |
exceeds_rfc_limit | boolean | True when total DNS lookups exceed 10 — receivers return PermError and ignore the entire SPF record |
void_lookup_count | number | NXDOMAIN / empty-answer lookups encountered during expansion (RFC 7208 §4.6.4 SHOULD limit is 2) |
exceeds_void_limit | boolean | True when void_lookup_count > 2. Google and Microsoft enforce this even when total lookups stay under 10. |
authorized_ipv4_count | number | Unique IPv4 CIDRs / literals authorized after full expansion (deduplicated across vendors) |
authorized_ipv6_count | number | Unique IPv6 CIDRs / literals authorized after full expansion (deduplicated) |
dnssec_validated | boolean | Whether the apex SPF TXT lookup carried the DNSSEC AD bit |
flattening_recommendations | array | Per-include flattening guidance — each entry: include, lookups_consumed (against the 10-limit), unique_ips_authorized, vendor (classified or null), recommendation ("remove" | "flatten_inline" | "keep"), rationale. Ranked highest-cost-first so the top entry is the most impactful change. |
ip_overlaps | array | IP CIDRs shared between two or more top-level includes — typically a sign of redundant authorisation (SES regions, M365 + EOP). Each entry: vendors (string[]), overlap_cidrs (string[]), total_overlapping_ips (number). Largest overlap first. |
risk_signals | array | Risk signals: vendor concentration, excessive vendors, etc. |
recommendations | array | Remediation steps |
Code Examples
curl "https://api.edgedns.dev/v1/security/spf-trust-surface" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d "domain=example.com"const response = await fetch(
'https://api.edgedns.dev/v1/security/spf-trust-surface?domain=example.com',
{
headers: {
'Authorization': 'Bearer YOUR_API_KEY'
}
}
);
const data = await response.json();
console.log(data);import requests
response = requests.get(
'https://api.edgedns.dev/v1/security/spf-trust-surface',
headers={'Authorization': 'Bearer YOUR_API_KEY'},
params={
'domain': 'example.com'
}
)
data = response.json()
print(data)Read the full SPF Trust Surface guide
Why it matters, real-world use cases, parameters, response fields, and how to call it from Claude, ChatGPT, or Gemini via MCP.
Read the guide →Related Endpoints
External References
Learn more about the standards and protocols behind this endpoint.
Try This Endpoint
Test the SPF Trust Surface endpoint live in the playground.