SPF SPF Manager
Check your SPF

Security and reliability

We publish DNS records that decide whether your mail is accepted. Here is what runs where, and what we do when something goes wrong.

Last updated 2026-08-01

This page is incomplete.

Missing operator details: legal entity name, registered address and Chamber of Commerce number. Set the matching LEGAL_* environment variables before going live.

How your record is served

You publish one include in your own DNS. Behind it we publish a hub record and, when a domain needs more addresses than one record holds, a small number of shard records — each one a separate TXT record under our domain. Those are served by our DNS provider, not by the application: if this website were down, your record would still resolve.

Your own DNS stays yours. We never ask for access to it, and we cannot change it.

What we check before publishing

  • The record parses. If the flattened output does not split into valid TXT strings, nothing is published.
  • The result is not empty. Providers resolving to no addresses at all is treated as a failure, not as the truth.
  • The set did not collapse. More than a fifth of the authorized addresses disappearing in one check holds the publication for review. Providers have DNS hiccups; those must not stop a customer's mail.
  • It actually landed. After publishing we re-resolve the record from the outside and record whether it matches.

When something fails

Every failure mode leads to the same place: the last record we know to be good stays live. A stale record delivers mail. An empty or truncated one does not. If we cannot resolve a provider, if a publish fails, or if a domain's own SPF record disappears, we keep what is out there and tell you what happened.

Every published version is kept with the record it contained, and any of them can be put back in one action. Restoring republishes the stored record rather than re-resolving, because resolving again would faithfully reproduce whatever you are backing out of.

Accounts

There are no passwords to leak: signing in is a one-time link sent to your address, and you can add a passkey or an authenticator app on top. Sessions are cookie-based and scoped to this site. Card details never reach our servers — Stripe holds them.

Reporting something

If you find a security problem, write to privacy@flat-spf.com. Tell us what you found and how to reproduce it; we will confirm within two working days. Please do not test against other people's domains.