Both mean "nothing else is authorised". The difference is the instruction to the receiver: ~all is a soft fail, which typically means accept but mark suspicious, while -all is a hard fail asking the receiver to reject. Once DMARC is enforcing, the practical gap narrows considerably, because DMARC policy takes over. Start at ~all while you verify nothing legitimate is missing, then move to -all.

Yes, and you should. Subdomains do not inherit the parent domain's SPF record. If you send from mail.example.com it needs its own SPF record. A subdomain with no SPF record has no SPF protection at all.

Almost always alignment. SPF authenticates the Return-Path domain, but DMARC requires that domain to match the visible From: domain. Third-party senders often use their own bounce domain, which passes SPF while failing alignment. DKIM usually solves this, because DKIM alignment is easier to satisfy — check yours with the DKIM checker.

No. Each sending domain gets its own SPF record listing only the provider that actually sends from it. Copying your main domain's record onto sending domains drags in includes for tools those domains never use, wastes lookups, and widens your authorised sender set for no benefit.

Paste the domain into the box above, or query it directly with dig +short TXT example.com on macOS and Linux, or nslookup -type=TXT example.com on Windows. SPF sits on the root domain, so unlike DMARC there is no _dmarc-style subdomain to remember. Among the TXT records returned, the SPF record is the one starting v=spf1.

Something like v=spf1 include:_spf.google.com ~all. It always opens with v=spf1, lists mechanisms authorising senders in the middle, and closes with an all term that decides what happens to everything else. Length is not a quality signal — a short record with one include is usually healthier than a long one carrying vendors nobody uses any more.

No, and this is the single most damaging SPF mistake. Two TXT records starting v=spf1 produce a permerror, and SPF fails for every message rather than falling back to either record. It happens when someone adds a record for a new tool instead of merging its include into the existing one. The fix is to combine all includes into a single record and delete the extra.

Three things, in order of frequency: two SPF records on the same domain, more than ten DNS-lookup-consuming mechanisms, or a syntax error such as a missing colon, a stray space, or smart quotes pasted from a document. All three produce the same outcome — SPF fails everywhere until corrected. The lookup counter diagnoses the ten-lookup case specifically.

SPF permits a maximum of ten mechanisms that require DNS resolution during evaluation — each include:, a, mx and redirect= counts, and includes nest so a single vendor can consume three or four. Past ten, the record returns permerror. Remove vendors you no longer use first; that alone usually resolves it without any restructuring.

Flattening replaces include: statements with the literal IP ranges they currently resolve to, eliminating lookups. It works, but it makes your record a snapshot — when a vendor changes their sending infrastructure, your record silently stops authorising them and mail starts failing. If you flatten, it needs automated monitoring. Pruning unused includes is almost always the better first move.

Only on subdomains that actually send mail, and each one needs its own record — SPF is not inherited from the parent domain. A subdomain with no SPF record returns none rather than falling back to the root. Worth noting the reverse case too: a non-sending subdomain can be locked down with v=spf1 -all.

Because SPF is checked against the Return-Path address, which recipients never see, while DMARC is checked against the visible From address. When a sending platform uses its own Return-Path domain, SPF passes for that domain and DMARC still fails, since neither passing domain matches yours. Either publish DKIM under your domain or configure a custom Return-Path — one aligned pass is enough. Check the policy side with the DMARC checker.

As long as the TTL on the TXT record — typically five minutes to an hour — plus however long resolvers hold the old answer. Lower the TTL before making changes if you expect to iterate. If a change appears not to have taken, re-check from a second resolver before assuming the edit failed.

Yes — enter one domain per line and each is looked up and evaluated separately. Email addresses work too, with the domain extracted automatically. Across a sending fleet this is how you find the domains still carrying an include for a tool you stopped using, or the one that quietly ended up with two records.