SPF record checker

What this checker looks at

• Presence and duplicates. A domain needs exactly one TXT record starting with v=spf1. None means receivers cannot verify your senders; two or more is a permanent error that most receivers score as a fail.
• The 10-lookup limit. Every include, a, mx, ptr, exists and redirect costs a DNS lookup, and the includes inside your includes count too. The checker follows the whole chain and shows where the lookups go.
• Void lookups. An include that points at a domain with no SPF record is wasted and counts toward a separate limit of two.
• The all mechanism. +all lets anyone send as your domain, ?all protects nothing, ~all and -all are the correct endings.
• Deprecated and unknown terms. ptr is flagged, and anything that is not a valid mechanism is reported, because receivers stop evaluating at an unknown term.

How to read the result

The banner at the top is the summary. Green means the record is valid and within limits. Amber means it works today but something should be tidied, such as a lookup count close to the limit or a dead include. Red means receivers are already treating the record as broken: no record, two records, more than 10 lookups, or +all. The lookup chain table under the findings shows each domain the checker followed and how many lookups it added, so you can see which include is expensive.

Common fixes

• Over 10 lookups: remove includes for services you stopped using, and replace a or mx with ip4 or ip6 where the addresses are stable. Our guide to fixing too many DNS lookups walks through counting by hand.
• Two records: merge the mechanisms from both into one record and delete the other. Never publish two.
• No record: publish one at the root of the domain. If you send through OquMail, the record is shown in your dashboard; the SPF setup guide covers adding it at common registrars.
• Third-party senders: add each one as a single include, and read how to add senders without breaking the limit.

Questions

Does SPF alone stop spoofing?

No. SPF checks the server that delivered the message against the envelope sender, not the From address people see. Pair it with DKIM and a DMARC policy; the DMARC checker shows whether that policy exists.

Why does my record look fine but mail still fails SPF?

Usually because the message was sent by a server that is not in the record: a website contact form, a CRM, a newsletter tool, or a mail app using Gmail's servers with your address. The failing message's headers name the sending IP; add that service as an include or change where it sends from.

Is anything stored?

No. The lookups run in your browser against public DNS over HTTPS. OquMail never sees the domains you check.