Dynamic SPF flattening: how it works and what you hand over

Why do SPF records hit the 10-lookup limit?

Each include costs a DNS lookup, and so does every include inside it. Receivers stop evaluating an SPF record after 10 lookups and return a permanent error (permerror) instead of a pass (RFC 7208, section 4.6.4).

The terms that cost a lookup are include, a, mx, ptr, exists and redirect, wherever they sit in the chain of records. Microsoft 365's include costs 1, because its record is a plain list of addresses. Mailgun's costs 5, because its record leads on to 4 more records (both checked on 22 October 2026).

A provider that adds an include to its own record spends one of your lookups too, even though you changed nothing. The free SPF Checker counts your lookups and shows the include tree. Our guide What is SPF? covers the basics.

What does flattening an SPF record do?

Flattening replaces each include with the addresses behind it, written as ip4: and ip6: terms, which cost no lookups.

The result is a copy of your providers' addresses as they were on the day you flattened. The free SPF Flattener shows what a flattened version of your record looks like, and offers one to publish only when it means the same as your record and stays within 10 lookups. It is the last fix suggested in how to fix SPF too many DNS lookups, after removing senders you no longer use and giving a sender a subdomain of its own.

Why does a flattened record go stale?

Providers change the address ranges they publish, and a copy in your DNS does not change when theirs do.

On 22 October 2026 we looked at a record that had copied its providers' addresses into a chain of 7 records on its own domain. It lacked 2 ranges that Mailgun publishes today (204.220.90.0/23 and 204.220.92.0/22) and 1 that Amazon SES publishes (98.77.0.0/16). Mail sent from those ranges with that domain as the return path does not pass SPF.

It also still listed 10 address blocks that are registered to Mailgun, according to the regional internet registries' public RDAP records, but that Mailgun's SPF record does not list today. A copy keeps authorising those blocks, whoever uses them now. Both providers' records are public, so you can check this yourself. The 2 Mailgun ranges are in the TXT record of _spf1.mailgun.org, which mailgun.org includes through _spf.mailgun.org, and the Amazon SES range is in the one at amazonses.com.

Whether a stale copy hurts depends on the mail. DMARC passes when SPF or DKIM passes in alignment (RFC 9989, section 5.3.5), so mail with aligned DKIM carries on passing, and mail that depends on SPF does not. Our guide on why DMARC fails covers alignment.

How does Dynamic SPF work?

You publish one include, once, that points at a record we serve. We keep that record current: once an hour we look up each of your senders' own DNS records and update ours when they change.

v=spf1 include:_s7f2k9xab0c.spf.shieldmarc.com ~all

The name after _s is issued when you start, and your own all mechanism carries over. Receivers follow the include like any other. It costs 1 lookup, plus 1 for each extra record we need when your ranges do not fit in one, plus the lookups of any per-message senders we carry through.

These rules keep a refresh from breaking mail that is already on its way:

• Additions are served at the next refresh. A range a provider adds is published at the next hourly refresh, once at least 2 of our 3 resolvers (our own, Cloudflare's and Google's) see it. One resolver's answer is not enough to authorise an address. Receivers may cache our records for 5 minutes, so a change reaches them soon after we publish it.
• Removals wait 72 hours. A range a provider stops publishing stays in our record for 72 hours, because a provider may move its traffic between ranges over hours or days and mail already on its way must still pass.
• An outage is not a removal. If a provider's DNS does not answer, or answers with no addresses, we treat the check as failed: we keep serving what we had and do not start the 72 hours. A check counts when at least 2 of our 3 resolvers answer.
• A sharp shrink is held. If a provider's list shrinks by more than 30% in one refresh, we keep serving what we had, still add any new ranges, and email you and our team. If the ranges are still missing after 10 days, they are removed and we tell you.
• Per-message senders are carried through. Salesforce publishes a single exists: term that receivers work out for each message, so there is no list of addresses to copy (checked on 22 October 2026). We keep its include in our record, after your address ranges, and the receiver does that lookup. We carry at most 2 such senders.
• Relay services stay on your list. Services such as Exclaimer hand your mail back to your mailbox provider to send, so DMARC reports, which name only the last server that handed a message over, do not show them. We do not offer a relay for removal because it looks unused.
• Nothing unsafe is published. We refuse to publish a record that would authorise no address, or that would need more than 10 lookups, and the page says why. After a publish, an hourly refresh reads each record back from 2 public resolvers and checks it against what we meant to publish.

What does setup show before you switch?

Setup shows what your record costs receivers today, what the same senders would cost with Dynamic SPF, and the senders it would start with, before anything is published or changed in your DNS.

• Lookups today against with Dynamic SPF. Two tiles show how many of the 10 DNS lookups your record uses now and would use with Dynamic SPF, counted the way receivers count them. The page flags a record at 8 or more lookups, and one over the limit. If part of your record cannot be read, the count says it is a minimum.
• Whether your record is already flattened. If your SPF points at a chain of records on your own domain that holds copied addresses, setup reads the chain and compares its ranges with what each provider we know publishes today. It treats a provider as copied when the chain holds at least three quarters of that provider's ranges, and skips a provider whose matching ranges another one it has matched already publishes, so a copy of one service is not read as a larger service that includes it. From then on we follow each provider's own record instead of your copy. A chain that uses exists:, macros, redirect= or anything else an address list cannot carry stays as one sender, as it stands.
• Each risk it finds. Ranges a provider publishes that your copy lacks, listed by address. Ranges in your copy that are registered to a provider that does not list them today. Addresses that none of the matched providers publishes are labelled with what setup can tell. That may be your own server (from your domain's A and MX records, or a reverse DNS name that resolves back to the address), the organisation the block is registered to, private or reserved address space that cannot send mail over the internet, or no match at all. A block registered to a cloud platform is not called a provider's old range, because the registration does not say who uses it.
• What stays authorised. What no provider publishes stays as the address you had, so unpacking does not remove an address your record authorises today. Before you publish, the page compares the addresses your record authorises now with the addresses we would serve, and names any that would stop passing.

Before anything is published, you check each sender setup found. Setup lists the services by name, with your own servers and addresses in a group. You confirm each service, keep or remove each address, and publishing stays closed until none is left to check. A Confirm all button confirms the rest in one go, and first lists any entries setup flagged, so a bulk click never hides them. Each sender shows its exact address ranges, with any range your copy lacked marked new, and a sender you add yourself is confirmed as you add it.

To add a sender, type a service's name, such as Mailchimp or SendGrid, or an include:, ip4: or ip6: term. A domain can list up to 50 senders.

How do I set it up?

You start it from the dashboard, check each sender, publish our record, then change one TXT record at your DNS host. It works for a domain you have verified in ShieldMarc. The steps in order:

1. Start. Open Dynamic SPF in the dashboard, pick the domain and press Start. This stores nothing in your DNS: it sets up the sender list from the record you publish today.
2. Check each sender. Confirm or remove each one, as above.
3. Publish our record. Press Publish our record. This creates our record in our DNS. Your own DNS does not change yet.
4. Change one TXT record at your DNS host. The page shows the exact edit: the TXT record on @, its current value and the new value. If the domain has a second SPF record, it tells you to delete it, because receivers treat 2 as a permanent error (RFC 7208, section 4.5). It also links to your DNS host's console where we know the address, straight to your domain's records for hosts such as Cloudflare and GoDaddy.
5. Wait for it to go live. Your domain goes live when at least 2 of the 3 resolvers we ask show your SPF record naming ours, and it is the only SPF record on the domain. DNS edits usually show within a few minutes. The page checks every 20 seconds for up to 10 minutes while it is open, we also check hourly, and we email you when it is live.

From then on, adding or removing a sender in ShieldMarc changes your record within the hour, with no DNS edit. ShieldMarc also suggests services it sees sending as your domain in your DMARC reports and failing SPF, with a button to add each one.

What are the trade-offs?

Once we host your SPF, your SPF result depends on our DNS answering and on us keeping the record correct.

Our records sit in the shieldmarc.com zone, which is served from Cloudflare's DNS network and signed with DNSSEC, so validating resolvers can check the answers (checked on 22 October 2026). If receivers cannot read a record, they get a temporary SPF error rather than a fail. DMARC passes when SPF or DKIM passes in alignment (RFC 9989, section 5.3.5), so mail with aligned DKIM still passes DMARC whatever happens to SPF. Our guide to SPF hard fail vs soft fail shows the same rule at work for forwarded mail.

Once your DMARC reports have arrived, setup shows what share of your mail from the last 7 days carried aligned DKIM, so you can judge that before you switch.

A mistake on our side would reach your mail, which is why the rules above exist. Dynamic SPF is also new, and our comparison pages say how other vendors' hosted SPF differs.

How do I leave?

You can leave at any time. We give you a record built from your current senders to publish instead. We keep serving ours until your DNS has moved, and remove it 24 hours after your DNS stops using it, so no resolver still holding your old record is caught out.

The record is built from the senders as they stand now, not from the record you had when you joined, so senders you added in ShieldMarc are in it and ones you removed are not. We count its lookups against the limit of 10. If it is over, the page names senders your DMARC reports have not seen lately as candidates to drop, and does not propose one that is still sending.

Owners and admins can ask to leave, and can cancel the request. The page keeps the record you had before the switch for reference.

Which plans include Dynamic SPF?

Dynamic SPF is included in the Professional plan, at £50 a month billed annually (£70 a month billed monthly), and in the MSP plan, at £100 a month billed annually (£130 a month billed monthly). Prices exclude VAT. Starter does not include it, and the pricing page also lists it under Enterprise.

Dynamic SPF starts when you subscribe, not during the free trial. New accounts get a 30-day free trial with no card, and the free SPF Flattener shows what a flattened version of your record looks like in the meantime.

Frequently asked questions

Sources and further reading

• RFC 7208: Sender Policy Framework (SPF)
  Section 4.5 makes more than one SPF record a permanent error. Section 4.6.4 sets the limit of 10 DNS lookups and asks receivers to stop at 2 lookups that return nothing. Section 8.6 lets a receiver accept a message or temporarily reject it on a temporary error.
  rfc-editor.org/rfc/rfc7208
• RFC 9989: DMARCbis, which replaced RFC 7489 in May 2026
  Section 5.3.5 passes a message when an authenticated identifier aligns with the author domain, which is why aligned DKIM carries a message when SPF does not.
  rfc-editor.org/rfc/rfc9989
• RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP)
  The format of the regional internet registries' public records of who an address block is registered to, which setup reads to label an address.
  rfc-editor.org/rfc/rfc9083
• Public DNS records used above
  On 22 October 2026 we looked up the TXT records of mailgun.org, _spf.mailgun.org, _spf1.mailgun.org, _spf2.mailgun.org, _spf.eu.mailgun.org, amazonses.com, _spf.salesforce.com and spf.protection.outlook.com, and the NS and DS records of shieldmarc.com.