Hosted SPF: What It Is and How It Works

Hosted SPF means a provider maintains your SPF sender list in its own DNS zone, and your domain publishes only an include, redirect or macro pointer to it. It uses standard RFC 7208 features, not a new protocol.

This article covers what sits in your DNS and what sits in the provider's. It also explains how hosted services cope with the 10-lookup limit, and where the approach can hurt you.

What is hosted SPF?

Hosted SPF is an arrangement where the list of servers allowed to send for your domain lives in DNS zones run by a service provider. Your own domain publishes only a pointer to that zone. A receiver follows the pointer and evaluates the provider's data as if it were yours.

SPF is defined in RFC 7208. "Hosted" is not a separate protocol. It is a way of using the include mechanism, the redirect modifier, or macros.

How does hosted SPF work?

Your domain publishes one TXT record containing an include: or redirect= that names a hostname controlled by the provider. A receiving server queries that hostname, reads the SPF data there, and uses it to decide whether the sending IP is authorised for your domain.

With include, your record keeps its own final qualifier:

example.com.  IN  TXT  "v=spf1 include:spf.hosted.example.net -all"

With redirect, the provider's record replaces yours entirely, including its final all mechanism:

example.com.  IN  TXT  "v=spf1 redirect=spf.hosted.example.net"

The hostname spf.hosted.example.net is a placeholder. On the provider's side it holds a normal SPF TXT record:

spf.hosted.example.net.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:mail.example.org ~all"

When the provider adds or removes a sender, they change their zone and your DNS stays untouched.

Some setups put a CNAME on a subdomain of your own, such as _spf.example.com, pointing to the provider, and your apex record includes that name. When you switch providers you still edit the CNAME and wait out its TTL, but the apex SPF record stays the same. A CNAME cannot coexist with other records on the same name, so use a dedicated label.

How do hosted SPF services get around the 10-lookup limit?

Hosted SPF services usually work around the limit in one of two ways. Flattening replaces nested includes with literal ip4 and ip6 ranges. Macro records instead answer a DNS query for each sending IP. Neither raises the limit. Both keep your evaluation under it.

RFC 7208 allows at most 10 DNS-querying terms per evaluation. The include, a, mx, ptr, exists and redirect terms all count, and nested includes count too.

Flattening. The provider resolves the includes of your senders and publishes the resulting addresses directly. Literal IP mechanisms cost no lookups, so only your own include is counted:

spf.hosted.example.net.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/25 ip6:2001:db8::/32"

The catch is freshness. If a sender changes its IP ranges, the flattened copy is wrong until the provider re-resolves it. That is why flattening only works well when the service keeps it updated continuously.

Macros. RFC 7208 section 7 defines macros that expand at evaluation time. In this model your record contains one exists term, and %{i} expands to the connecting IP address:

example.com.  IN  TXT  "v=spf1 exists:%{i}._spf.hosted.example.net -all"

For a message from 192.0.2.10, the receiver queries 192.0.2.10._spf.hosted.example.net. The provider's DNS answers with an A record if that IP is authorised, which makes the exists term match, and with NXDOMAIN otherwise. However many senders you have, the evaluation costs one lookup. The trade-off is that the sender list is no longer visible in a single TXT record, so auditing it means asking the provider.

What happens past the limit. When evaluation reaches an eleventh lookup, the result is a permerror. That is not the same as fail. A sender matched earlier in the record can still pass at some receivers, but you cannot rely on it. Treat SPF as unreliable once you cross the line, because DMARC treats it as not passing.

Record size. A single TXT string is limited to 255 characters, so long records are split into several strings. RFC 7208 also advises keeping SPF answers under 512 bytes, so they fit in a UDP response without truncation and a fallback to TCP. Heavily flattened records can approach that size.

Why do teams use hosted SPF?

Teams use it for two reasons: to stay under the lookup limit using the techniques above, and for change control. Marketing, support and billing tools each ask you to add their own include. If every change needs a DNS ticket, SPF drifts out of date. A hosted record lets an approved person change the sender list without touching your zone.

If you simply include a provider whose record is nested and unflattened, nothing is saved. Its lookups still count against your domain's budget of 10, along with the one spent on your pointer.

What are the risks of hosted SPF?

The main risks are dependency, trust and visibility. You delegate the authority to say who may send as your domain, so the provider's availability and hygiene directly affect your mail. Each risk below is manageable if you know about it before you sign up.

• Availability. If the provider's DNS is unreachable, receivers may get a temperror and handle your mail unpredictably.
• Trust. Anyone who can edit the hosted data can authorise senders for your domain. Check how access is controlled and logged.
• Lock-in. A pointer hard-coded to a vendor hostname means editing DNS and waiting out the TTL to leave. A CNAME on your own subdomain only keeps the apex record unchanged.
• Over-authorisation. SPF authorises IP addresses, not individual users. Shared sending infrastructure can authorise more IPs than you intend. SPF evaluates the MAIL FROM identity, and RFC 7208 recommends checking the HELO identity too.
• Stale flattening. A flattened copy that is not refreshed can authorise the wrong addresses or miss new ones.
• Silent breakage. A change in the hosted zone can break SPF without any change in your DNS.

Reporting is how you notice. DMARC monitoring collects and visualises aggregate reports, so you can see which sources pass or fail SPF after a hosted record changes. yourDMARC provides this monitoring for your domains.

How do you set up hosted SPF?

Choose a provider, confirm the hostname or macro domain they give you, replace your current SPF TXT record with a single pointer, and verify the result. Keep only one SPF record per domain, because two records cause a permerror.

1. Inventory your senders. List every system that sends as your domain, including mail platforms, CRMs, ticketing tools and on-premises servers.
2. Record your current SPF. Save the existing TXT value so you can roll back.
3. Get the hostname to include, redirect to, or use in the macro.
4. Lower the TTL on the existing record a day or so before the change.
5. Publish the pointer as a single TXT record at the domain apex.
6. Verify. Run the free domain scanner to check the published SPF, DKIM and DMARC records. Then count the lookups yourself by following each include and redirect, since the 10-lookup budget is easy to miscount.
7. Watch reports. Review DMARC aggregate data for a few weeks to catch senders you missed.

The DMARC record lookup shows what policy you currently publish. DMARC passes only when SPF or DKIM passes and aligns with the visible From domain. A hosted record that authorises a third party's envelope domain may therefore still not satisfy DMARC on its own.

Is hosted SPF the same as dynamic SPF?

No. Hosted SPF describes where the record lives, which is a provider's zone. Dynamic SPF usually describes how the answer is produced: records built from macros (RFC 7208 section 7) or generated per query rather than served as a fixed TXT string.

The two overlap. A macro-based hosted setup like the exists:%{i} example above is both. A hosted record that is a plain flattened TXT string is hosted but not dynamic. For more on how the dynamic approach behaves, read our guide to dynamic SPF.

When is hosted SPF not the right choice?

It is not the right choice when your sender list is short and stable. With two or three services well below the lookup limit, a hand-written record is simpler, has no third-party dependency and is easy to audit. Our compliance overview explains why correct SPF and DKIM matter for bulk-sender requirements.

A useful test: if you cannot name who can change your SPF data and how those changes are logged, do not hand it to anyone yet.

Key takeaways

• Hosted SPF means a provider maintains the sender list in its own DNS zone, and your domain publishes only an include, redirect or macro pointer.
• It uses standard RFC 7208 features, not a new protocol.
• Providers stay under the 10-lookup limit by flattening includes into ip4/ip6 ranges or by serving macro records that answer per sending IP.
• Past the limit SPF returns a permerror, which is unreliable, and DMARC treats it as not passing.
• Publish exactly one SPF record per domain, and keep answers under 512 bytes.
• The risks are dependency, who can edit the record, stale flattening, lock-in and silent breakage.
• A CNAME on your own subdomain keeps the apex record stable, but switching providers still means a DNS edit.
• Watch DMARC aggregate reports to catch failing senders after any change.
• Small, stable sender lists are usually better served by a simple hand-written record.