Who Gets Into Your SPF Record? A Guide to Email’s Cloud Supply Chain

Executive takeaway

Treat SPF as a map of authorized sending infrastructure, not proof that your email is protected. The supplied 2026 measurements show widespread adoption, substantial cloud dependencies, and persistent configuration gaps. SPF checks the technical return-address domain; DMARC connects authentication to the address readers see. Identify legitimate senders and assign accountable owners. Then test authorization, alignment, and lookup limits before tightening policy. Review permissions whenever vendors change. The goal is a small, justified, monitored sender ecosystem—not the longest possible SPF record.

Your SPF record is a vendor-access decision

Which outside systems should receive permission to send using your domain’s technical return address? That question turns an SPF change from routine administration into a vendor-access decision.

SPF, short for Sender Policy Framework, identifies infrastructure authorized to send for that return-address domain. The technical return address handles delivery failures; it is not necessarily the address readers see. As AutoSPF’s practitioner analysis emphasizes, publishing a record does not establish effective protection.

Think of SPF as a map of authorized infrastructure, not a complete inventory of email activity. A listed provider might send regularly, support occasional workflows, or remain from an abandoned service. Authorization alone cannot distinguish these possibilities.

Cloud services make that distinction consequential. An organization might use an office suite for employees, a marketing platform for campaigns, and separate software for sales messages. The DMARCguard supply-chain study examines provider references within SPF records, identifying dependencies beyond organizations’ own infrastructure.

An SPF include directs receivers to another domain’s SPF policy when evaluating authorization. It creates a dependency on externally maintained rules, not proof that every message represents legitimate business activity.

The governance implication is straightforward: every authorization needs a business purpose and an accountable owner. DNS administrators publish the setting. Business teams justify the sender’s access, while email and security teams assess its configuration.

Four questions should frame that decision:

Ownership: Who is accountable for the service and its continued need to send?
Scope: Which domain or subdomain should it use, and for what purpose?
Testing: How will legitimate messages be checked before permissions change?
Removal: What triggers withdrawal of authorization when the service is retired or replaced?

Mailbox-provider requirements increase the operational stakes. Mailgun’s overview describes authentication expectations involving SPF, DKIM, and DMARC, particularly for bulk senders. DKIM adds cryptographic signatures. DMARC connects authentication to the visible sender domain and its published policy.

These are provider requirements, not automatically legal obligations. Their applicability depends on the receiver’s rules and the sender’s circumstances. Authentication also does not guarantee inbox placement.

Publishing SPF, configuring it correctly, and enforcing authentication tied to the visible sender are separate achievements. Understanding those distinctions is the first step toward governing sender access.

What SPF checks—and what it does not

SPF checks a technical sending identity, not the brand name readers see. The relevant identity here is the envelope sender: the technical return address supplied during email transmission. It can differ from the visible From address displayed by an email application.

A message might display your company’s domain while using a platform’s domain for its return address. SPF’s authorization check concerns that envelope domain, not automatically the visible one.

The receiver compares the connecting server’s IP address against DNS-published SPF rules. Mechanisms such as ip4 and ip6 specify addresses directly; a and mx use addresses obtained through DNS. These rules determine whether the server is authorized for the checked domain.

An include references another domain’s SPF rules rather than listing every address locally. Referenced records can contain further includes, creating nested dependencies. The SPF supply-chain study maps these connections to external sending infrastructure.

A short record can therefore depend on a much larger authorization structure. Provider changes can alter which servers satisfy the local domain’s SPF check. Nested references also consume the evaluation budget discussed in the practical playbook.

SPF produces an authentication result, not a delivery command. Common outcomes include the following; this list is not exhaustive:

Pass: The connecting server is authorized for the checked domain.
Fail: The rules explicitly identify the server as unauthorized.
Softfail: The rules indicate that the server is probably unauthorized, using a weaker signal than fail.
Neutral: The domain makes no definite assertion about authorization.
Errors: Temporary failures or permanent configuration problems prevent a valid evaluation.

Receivers apply their own filtering policies to these results. As AutoSPF’s analysis explains, an authorization statement does not bind the receiver’s delivery decision. Neither pass nor fail determines the final outcome alone.

DMARC addresses the gap between technical authentication and the visible From domain through alignment. Alignment means the SPF-authenticated or DKIM-signing domain matches the visible From domain under DMARC’s rules. The supplied DMARC guidance connects authentication with protection against domain impersonation.

DKIM provides the alternative authentication route through a cryptographic signature associated with a signing domain. DMARC requires an aligned SPF pass or an aligned DKIM pass—not both. An SPF pass for an unrelated envelope domain therefore does not satisfy DMARC by itself.

For example, a platform could pass SPF for its own return-address domain while displaying your company’s From address. An aligned DKIM signature could still satisfy DMARC. This separates infrastructure authorization from authentication of the identity presented to readers.

Even aligned authentication does not establish that a message deserves trust. It answers an identity question, not whether the message’s claims are true.

Why SPF adoption has several different answers

SPF adoption has no single meaningful percentage without a defined population. The supplied 2026 measurements range from 47.4% to 93.2%, but they examine different groups. The denominator—the domains included in each calculation—shapes the result.

Spf Flattening 2013

Source: Defaults.Exposed, DMARCguard, and SpamCipher, 2026

Four headline measurements illustrate the variation:

47.4% across a broad census: Defaults.Exposed reports this rate among its graded domains. Its population is broader than samples focused on highly ranked websites or business email.
56.0% across complete Tranco: DMARCguard scanned 5,499,028 domains from the complete Tranco Top Sites list in February 2026. This is a website-ranking population, not every registered domain.
62.8% across the resolvable top million: SpamCipher examined a narrower, higher-ranked Tranco population later in 2026. Excluding unresolved domains also changes the denominator.
89.2% across B2B company domains: SpamCipher’s business-domain study examined 2,330,020 company domains receiving B2B email. This selection is relevant to business infrastructure, not representative of the whole internet.

The adoption comparison figure should label every percentage with its population. The accompanying statistical infographic should preserve those distinctions rather than present equivalent benchmarks.

Changing the denominator within one study substantially changes the answer. Shipmail’s November 2026 scan reports 75.4% SPF coverage across its full 9,999-domain set. Coverage reaches 93.2% among mail-receiving domains: a calculated 17.8-percentage-point difference.

Selecting domains with receiving-mail infrastructure plausibly explains some of that difference. However, receiving mail does not prove active sending. Nor does this comparison establish that receiving infrastructure causes SPF adoption.

Timing and lookup handling also limit comparisons. February and November observations are not simultaneous, and DNS configurations can change between scans. Excluding failed lookups changes the measured population. Without consistent methods and repeated observations of the same domains, these differences cannot establish a trend.

Record presence and record validity are separate measurements. Finding an SPF record does not establish that it evaluates correctly. The supplied evidence describes DMARCguard’s 56.0% as both publication and valid-SPF coverage. That definition needs clarification before strict comparison.

As an explicitly earlier comparison, the European Commission’s 2025 analysis reports approximately 88% SPF adoption among sampled EU country-code domains. It reports roughly 84% implementing “strict” SPF under its measurement framework. Different sampling and strictness definitions prevent direct ranking against the 2026 results.

Population composition offers a plausible explanation for variation, not evidence of geographic or organizational superiority. A useful benchmark should resemble the domains your organization manages. It should also distinguish publication, valid evaluation, and aligned authentication.

Spf Record Example 9711

Three major 2026 measurements show SPF adoption ranging from under half of all domains in a global census to over three‑fifths among Tranco‑ranked sites, underscoring how vantage point shapes apparent coverage. Method: I selected one SPF adoption statistic from each of three independent 2026 measurements: DMARCguard’s Tranco‑based scan, SpamCipher’s top‑million study, and the Defaults.Exposed global census.[5][8][11][12] Values are plotted as separate headline metrics rather than as parts of a whole, highlighting relative rather than aggregate coverage.

Two cloud giants anchor the sender ecosystem

Microsoft 365 and Google Workspace lead provider references in DMARCguard’s SPF Supply Chain 2026 analysis. Across 3,077,219 SPF records in its Tranco sample, Microsoft appears in 19.6% of SPF-enabled domains and Google in 13.6%. These findings identify prominent dependencies within that sample, not across every internet domain.

The percentages measure provider presence, not email volume. A domain contributes to Microsoft’s percentage regardless of how many messages Microsoft sends for it. The same domain can reference Google and other services, so these are not exclusive customer categories.

That possible overlap prevents calculation of a combined unique-domain share. Adding 19.6% and 13.6% gives 33.2%, but double-counts any domains referencing both. The supplied claim that the providers together cover roughly one-third of distinct SPF-enabled domains is therefore unsubstantiated.

The proposed 66.8% “other senders” remainder is likewise unsupported. Other services can appear alongside either giant rather than occupy a separate residual category. Calculating the share referencing neither requires knowing the overlap.

The provider figure should use separate bars and state that categories may overlap. A pie chart or stacked composition would falsely imply an exclusive market split.

A separate finding shows how external dependencies enter SPF records: includes account for 32.3% of mechanism occurrences. The DMARCguard analysis identifies include as the most frequently observed mechanism. Its denominator is mechanism occurrences—not domains, customers, or messages.

Includes let organizations reference provider-maintained infrastructure instead of updating every authorized address themselves. When a provider changes its published ranges, dependent domains can use those changes without editing their local records. This offers an operational benefit while retaining an external dependency.

That dependency can extend beyond the first provider reference. As AutoSPF’s practitioner discussion emphasizes, nested records can change while the local record remains untouched.

A cascading configuration problem is therefore a plausible risk mechanism, not a measured incident rate. An upstream error or expanded lookup chain could disrupt evaluation for dependent domains. Provider-presence percentages cannot establish how often this happens or whether either giant is less reliable.

These measurements identify where authorization dependencies concentrate. They do not show that concentration itself causes failures. Outsourcing infrastructure maintenance reduces local work, but it does not remove responsibility for deciding who should remain authorized.

Email Spf 9722

Within SPF‑enabled domains in the 5.5‑million‑domain Tranco scan, Microsoft 365 and Google Workspace together hold about one‑third of all include‑based authorizations, with the remaining two‑thirds split among many other providers. Method: I used provider‑level shares from DMARCguard’s SPF Supply Chain 2026 report, which lists Microsoft 365 at 19.6% and Google Workspace at 13.6% of SPF‑enabled domains.[3][10] I computed the residual “other senders” share as 100% minus the two reported percentages.[3] The donut segments are mutually exclusive parts of this 100% whole.

Your mailbox provider is not your complete sender list

Your mailbox provider is not necessarily your only outbound sender. MX records identify inbound destinations, such as mailbox providers or filtering gateways. SPF describes infrastructure authorized for an envelope-sender domain. The supplied authentication research distinguishes these inbound and outbound roles.

Consider an illustrative organization, not a measured configuration. Employees use Microsoft 365, marketing uses a campaign platform, and application notifications use a third service. Its MX records might identify Microsoft’s inbound infrastructure without revealing either specialist sender.

An MX inventory cannot substitute for an outbound sender inventory. Likewise, SPF records cannot establish whether every authorization remains necessary. They reveal neither business purpose nor accountable ownership. Sender discovery must connect technical records with the teams operating campaigns, support tools, and applications.

A practical inventory should connect each service to its purpose, identities, and authentication settings. The following fields are editorial recommendations informed by sender-governance guidance, not a prescribed standard:

Sender and purpose: Name the service and the business function it supports.
Technical return-address domain: Record the envelope-sender domain checked by SPF; do not assume it matches your main domain.
Visible From domain: Record the identity recipients see and DMARC seeks to protect.
Authentication configuration: Document SPF authorization, DKIM signing domains, and alignment with the visible From domain.
Accountable owner: Identify who confirms continued need and who resolves authentication problems.

An inventory also prevents overstatement about shared infrastructure. An SPF include does not itself demonstrate that every customer of that provider can impersonate your organization. Assessing that risk requires evidence about provider controls and permitted customer identities, which these measurements do not supply.

Record both sending identities rather than treating every authorization as equivalent. A provider using its own unrelated envelope domain may pass SPF without authenticating your visible domain. The inventory should show whether SPF or DKIM supplies the alignment required for DMARC.

A stricter SPF ending is not a delivery command

An SPF ending states an authorization policy; it does not command delivery. Receivers interpret the result alongside their own filtering rules. As AutoSPF explains, changing the ending changes the signal, not the receiver’s authority.

Create Spf Record 9317

Source: SpamCipher, 2026

The final all mechanism matches sending addresses not matched earlier. Its prefix determines the result for those remaining senders:

~all — softfail: The domain considers the sender probably unauthorized.
-all — hardfail: The domain explicitly declares the sender unauthorized, without guaranteeing rejection.
+all — pass: Any sender reaching this mechanism passes, defeating the intended restriction on otherwise unmatched senders.

Softfail dominates two reported 2026 distributions. SpamCipher’s top-million study reports 55.7% softfail and 38.7% hardfail among SPF-publishing domains. These are configuration measurements, not rejection rates or demonstrated protection outcomes.

The Defaults.Exposed census reports 55.3% softfail and 39.3% hardfail across SPF records in its graded domain set. The similar results support a narrow conclusion: both populations use softfail more often than hardfail. They do not establish identical practices across the wider internet.

DMARCguard’s Tranco-based study reports 53.5% softfail among SPF-enabled domains. The remaining 46.5% cannot automatically be labelled hardfail; other qualifiers and record states must be considered.

As a 2025 comparison, the European Commission study reports roughly 84% implementing strict SPF policy in its EU country-code-domain population. Its mecsa-st framework and sampling differ from the 2026 studies. “Strict” should not be treated as interchangeable with their -all percentages without confirming the definition.

Permissive endings pose a different problem from cautious failure signals. Defaults.Exposed counted 39,589 records ending in +all. An otherwise unlisted sending address passes when evaluation reaches that mechanism.

This undermines SPF’s role as a restricted sender list. However, calling +all always worse than no SPF overstates the evidence. Delivery consequences depend on receiver behavior and surrounding authentication controls.

Strict syntax cannot repair overbroad authorization. A sender matched earlier never reaches -all, so changing the ending cannot revoke that permission. Nor can it repair an evaluation error, such as exceeding the lookup limit.

A sound review therefore asks more than whether the record ends strictly. Authorization must be justified, evaluation must work, and authentication must align where SPF supports DMARC. Receivers still retain the final disposition decision.

Spf Lookup 6630

Side‑by‑side comparison of SPF adoption and policy endings across three 2026 datasets shows that both overall coverage and the balance between softfail and hardfail differ significantly between Tranco‑ranked, top‑million, and global‑census views. Method: I extracted SPF adoption percentages from DMARCguard’s Tranco scan, SpamCipher’s top‑million study, and the Defaults.Exposed census.[5][8][11] I then added softfail and hardfail shares where available: DMARCguard softfail shares from its supply‑chain report, SpamCipher’s policy breakdown from AutoSPF’s synthesis, and policy endings from Defaults.Exposed.[3][11][12] Cells marked “n/a” indicate values not reported in the underlying study.

The bigger gap lies between monitoring and enforcement

Publishing DMARC and requesting enforcement are different achievements. A record’s presence does not establish whether the domain requests action against messages that fail DMARC.

Across four 2026 measurements, enforcement trails adoption. Each pair below uses the study’s overall measured population, not only its DMARC adopters:

DMARCguard: 30.4% adoption and 12.8% enforcement in its 5.5-million-domain Tranco scan.
Defaults.Exposed: 24.8% adoption and 11.6% enforcement across its graded-domain census.
SpamCipher: 55.4% adoption and 19.7% enforcement among 2.33 million B2B company domains.
Shipmail: 82.9% adoption and 60.9% enforcement within its mail-receiving subset of top domains.

The figure’s enforcement among DMARC adopters measure requires a different denominator. Dividing enforcement by adoption within each population produces these approximate editorial calculations from rounded percentages:

DMARCguard: 12.8 ÷ 30.4 ≈ 42.1%.
Defaults.Exposed: 11.6 ÷ 24.8 ≈ 46.8%.
SpamCipher B2B domains: 19.7 ÷ 55.4 ≈ 35.6%.
Shipmail mail-receiving domains: 60.9 ÷ 82.9 ≈ 73.5%.

This distinction changes the comparison. B2B domains have higher adoption than DMARCguard’s population, but a smaller proportion of adopters publish enforcement policies. Shipmail’s selected mail-receiving population leads on both measures; it does not represent the whole internet.

DMARC policy values describe what domain owners request for failing messages:

p=none requests no DMARC-specific disposition and supports monitoring.
p=quarantine requests suspicious treatment, such as placement in a spam folder.
p=reject requests rejection.

These remain requests, not guaranteed outcomes. SPF failure also does not necessarily mean DMARC failure: an aligned DKIM pass can satisfy DMARC independently.

A DNS scan measures published settings, not whether every legitimate platform authenticates correctly. An enforcement policy therefore demonstrates policy intent, not complete operational readiness or uniform receiver behavior.

Self-reported adoption belongs in a separate evidence category. As a historical comparison, Mailgun’s 2024/2025 survey found that 53.8% of respondents reported implementing DMARC. Among reported DMARC users, 31.8% reported p=none. These answers describe respondents’ practices as reported, not directly observed 2026 DNS configurations.

Lacking enforcement does not make every domain inevitably exploitable; receivers can apply other protections. Conversely, passing authentication does not prevent every impersonation technique or establish message trustworthiness. The operational objective is reliable authentication of legitimate senders followed by deliberate enforcement—not publication alone.

Spf Record Checker 1917

Across four 2026 measurements, DMARC enforcement rates range from around 11–13% in broad domain scans to nearly 61% among top mail‑receiving domains, showing that protection lags adoption except in the most mature populations. Method: I selected DMARC enforcement percentages from DMARCguard’s Tranco scan, the Defaults.Exposed global census, Shipmail’s top‑10k mail‑receiving dataset, and SpamCipher’s B2B company‑domain study.[2][7][8][11] Each radial value represents the share of all measured domains in that population with a quarantine or reject DMARC policy, not just the share among DMARC adopters.

Decide which senders deserve authorization

Authorize a sender only when its business purpose and technical requirements are clear. Treat additions as access decisions with accountable owners, test evidence, and removal conditions.

Start by identifying systems sending on your organization’s behalf, including marketing, billing, support, and internal applications. This follows AutoSPF’s inventory guidance. The following admission questions translate that guidance into an operational decision process:

Is this sender necessary? Identify its messages and business purpose. Check whether an approved platform already meets the need.
Who owns it? Name a business owner for continued use and a technical owner for authentication. Record who approves changes and retirement.
Which domain must it use? Choose deliberately among the primary domain, a sending subdomain, and the provider’s domain.
How will it authenticate and align? Document the envelope sender, visible From domain, and DKIM signing domain. Test actual messages rather than relying solely on a successful setup screen.
Can the authorization be maintained? Check nested dependencies, lookup requirements, and provider change communications. Define testing and rollback before production approval.

Remove obsolete permissions after confirming that associated workflows have stopped or migrated. Investigate unfamiliar includes before deleting them; they may support legitimate but poorly documented services.

Separate sending purposes deliberately

Dedicated subdomains can clarify ownership and separate configuration for campaigns, notifications, or other functions. AutoSPF’s guidance recommends deciding which senders need the primary domain and which can use alternatives.

Domain separation is not automatic isolation. Design the visible From address, envelope sender, DKIM identity, and applicable DMARC policy together. Check whether alignment settings preserve the intended boundaries rather than assuming a new subdomain provides them.

Budget for evaluation, not vendor count

SPF limits DNS-lookup-causing mechanisms and modifiers to ten during evaluation, including nested references. One provider include can consume several terms in that budget. Ten vendors therefore do not equal ten lookups.

DMARCguard’s 2026 measurement reported 148,655 overruns among 3,077,219 SPF-enabled domains, approximately 4.8%. This describes its measured sample, not every internet domain.

Spf Record Example 1097

Source: DMARCguard, 2026

Exceeding the limit can produce a permanent error, or PermError, instead of the intended authorization result. This is an evaluation constraint, not a traffic-load failure. Sending fewer messages does not repair it.

Publish one SPF record per domain using SPF, combining approved authorizations rather than adding competing records. Test syntax, nested evaluation, and representative sending addresses before release. Then inspect authentication results from real messages.

Control changes rather than chasing stricter settings

Flattening replaces includes with explicit IP addresses or ranges. AutoSPF discusses this technique as a way to reduce lookup pressure. It also transfers responsibility for tracking infrastructure changes to whoever maintains the flattened record.

Flattening does not automatically narrow authorization; it may reproduce the same permission in another form. Someone must synchronize provider changes, remove stale entries, and test updates.

Treat SPF edits and DMARC enforcement changes as controlled releases with approval, monitoring, and rollback plans. Avoid changing several providers and enforcement settings simultaneously, which makes failures harder to attribute.

Begin DMARC deployment with reporting and identification of legitimate traffic, consistent with Valimail’s enforcement guidance. Resolve authentication and alignment problems before progressing toward quarantine or rejection. Check legitimate workflows throughout the transition.

The goal is controlled authorization and dependable authentication, not the strictest-looking record. Enforcement can strengthen protection against unauthenticated use of your domain without guaranteeing inbox placement.

Spf Lookup 6087

A practical decision tree helps teams decide whether a system truly needs authorization in the apex‑domain SPF record, can move to a subdomain, or should send only from its own domain. Method: I distilled common governance advice from AutoSPF, SpamCipher, Valimail, and Shipmail into a short decision tree.[2][5][6][10][12][14] The branches reflect questions about business need, ability to authenticate reliably, and alignment with DMARC strategy, not protocol details, making the guide accessible to both security and marketing stakeholders.

Keep sender permissions under review

Sender authorization is a continuing responsibility, not a completed DNS task. The operating model below synthesizes practitioner guidance and the measurement findings. It is not an experimentally proven intervention.

Managing SPF records and cloud sender permissions is essential for maintaining email security, preventing unauthorized sending, and protecting domain reputation.

Review permissions at vendor onboarding, material configuration changes, and offboarding. Choose a recurring review cadence based on sender complexity, change frequency, and operational capacity. This lifecycle approach builds on AutoSPF’s practitioner guidance without assuming one interval suits every organization.

Each review should answer questions appropriate to the event:

Onboarding: Is ownership documented, access justified, and authentication tested?
Configuration changes: Do revised includes, identities, or infrastructure alter authorization scope or authentication results?
Offboarding: Have obsolete permissions been removed without disrupting remaining legitimate senders?

Maintain a small operational scorecard rather than tracking record publication alone. Record each authorization’s owner, purpose, last review, and removal conditions. Monitor three additional measures:

Lookup headroom: Remaining capacity within SPF’s ten-term DNS-lookup budget, including nested dependencies.
Evaluation errors: Affected records, assigned investigators, and repair status.
DMARC failures by legitimate sender: Approved services needing authentication or alignment fixes.

Keep record validity, authentication success, and policy enforcement separate in reporting. Valimail’s 2026 report emphasizes the gap between monitoring and blocking policies. Operational reporting should also show whether legitimate traffic is ready for enforcement.

Monitor inbox placement separately from authentication. A passing result should not close a delivery investigation. Conversely, poor placement does not by itself establish an SPF fault.

Provider concentration creates a trade-off, not an automatic case for diversification. Fewer platforms concentrate dependencies; more platforms expand the permissions and configurations requiring maintenance. The operational inference is to add providers for justified business or resilience needs, not simply to increase their number.

Choose tools through demonstrations of observable capabilities. Ask vendors to show nested-lookup visibility, error alerts, per-sender authentication analysis, change history, and exportable evidence. Where automation changes DNS, require clear approval and recovery processes.

Market growth does not establish product effectiveness. The deliverability-tools market report provides commercial context, not experimental evidence that a tool improves operations. Evaluate products against your own sender inventory and failure scenarios.

Who gets into your SPF record—and who stays there? Every authorization needs a justified role, maintained authentication, and a removal process, with named owners accountable for all three.

Limitations

This synthesis relies on supplied research summaries. Original source text and measurement methods have not been independently inspected or verified.
Studies use different populations, dates, and definitions. Their percentages cannot establish a single global adoption rate or a common trend.
Microsoft and Google reference rates may overlap. Adding them does not establish their combined share of unique domains.
The supplied evidence describes DMARCguard’s 56.0% SPF rate as both publication and valid-SPF coverage. That ambiguity limits strict comparisons.
Most measurements and guidance come from commercial vendors. DNS records reveal published authorization, not actual sending volume, intended permissions, or demonstrated security outcomes.
The operational recommendations synthesize practitioner guidance and protocol constraints. The supplied evidence does not establish their effectiveness through controlled comparisons.