A broken control panel need not interrupt SPF checks. Stopped updates can leave a flattened record out of date. Unavailable hosted DNS can prevent receivers from checking it at all. These are different failures, with different consequences.
With a hosted flattening service, your email still travels through your existing email providers. The flattening provider has two continuing jobs: keep the address list current and make its published SPF record available through DNS. Its control panel is a separate part of the service.
Three different things can go wrong
You cannot sign in
A control panel outage can leave the published record untouched. Receivers can still read it, and automatic updates may still run. You lose the ability to change your setup through the panel, but the login problem alone need not interrupt SPF checks.
Automatic updates stop
An ordinary SPF include lets receivers follow a provider's current record. Flattening resolves those references ahead of time, so the resulting address list needs refreshing when the provider changes its sending ranges.
If that process stops while DNS continues serving the last published list, messages from addresses already listed can still pass SPF. A newly introduced address may be missing; a retired address may remain authorised. Keeping the previous list buys continuity, but it cannot keep that list current indefinitely.
Receiving services cannot read the record
When your SPF policy refers to a hosted flattened record, receivers need access to that record. If its DNS service stops answering, a receiver without a usable cached copy may be unable to complete the SPF check.
Flattening removes the original provider include chains from that part of the check. It still depends on reachable DNS for your own record and the hosted record you reference.
Three outages, three different effects
Read the diagram as text
- Control panel unavailable: the published record may still answer and automatic updates may still run.
- Updates stopped: the last published record remains available, but it can become outdated as providers change addresses.
- Hosted DNS unavailable: a receiver without a usable cached answer may be unable to complete SPF.
Why some messages may arrive and others may not
Different receivers may have different cached copies. One can continue using a recent answer while another needs a fresh response from the unavailable DNS service. Some resolvers can serve expired DNS data during an outage, but that behaviour cannot be assumed everywhere.
The SPF standard distinguishes a temporary lookup error from a result saying the sending address is unauthorised. Receivers also apply their own handling policies, so an outage can cause delays or rejection without affecting every message in the same way.
Evidence that separates the failures
| What you see | Evidence to collect |
|---|---|
| The control panel will not load | Check whether the hosted SPF TXT record is still available independently of the panel. |
| Some new sending addresses fail | Compare the provider's current address list with the published flattened list and its last successful update. |
| SPF checks show temporary DNS errors | Capture the queried name, DNS response and time. Test authoritative DNS as well as cached recursive answers. |
The DNS propagation checker can show whether locations return different TXT answers. It cannot establish whether refresh jobs are running or whether every sending address remains authorised.
Keep the affected message's authentication result too. A DNS timeout, an SPF fail and a lookup-limit error lead to different investigations.
Fresh addresses and available DNS
Both are necessary for hosted flattening to keep doing its job. A perfectly current address list is little use if receivers cannot retrieve it. A record that always answers can still authorise the wrong addresses if its updates have stopped.
Emailmetry's safeguards include checking updates before publication and keeping its published record available separately from the control panel. Retaining an earlier checked record supports continuity when an update cannot be verified, with the same limitation: it will not include addresses added after that version was published.
Sources and further reading
Sources reviewed 12 September 2026.