SPF Record Checker

An SPF record is a DNS TXT entry that lists the mail servers permitted to send email for a domain. When a receiving server gets a message, it looks up the sender's domain in DNS, finds the SPF record, and checks whether the sending IP address appears in that list. If it does not, the receiver applies the qualifier defined by the all mechanism, which may cause the message to be rejected or flagged.

SPF evaluation has a hard limit of 10 DNS-resolving lookups. Mechanisms like include: , a , and mx each trigger one lookup when a receiving server evaluates your record. Exceeding 10 causes a permerror, which many servers treat as a failure regardless of whether the sending IP is actually authorized. The checker reports your current count and issues a warning when it exceeds 8, giving you a margin to act before hitting the limit.

The qualifier on the all mechanism defines what receiving servers should do with mail that does not match any listed sender. A ~all softfail signals that the domain owner considers the mail suspicious but leaves the final decision to the receiver, so many servers still accept it. A -all hardfail explicitly instructs receivers to reject non-matching mail. The checker notes which qualifier your record uses and flags softfail as a weaker policy.

RFC 7208 states that a domain must have at most one TXT record beginning with v=spf1 . When a receiving server finds multiple SPF records, it cannot determine which one to use and must return a permerror. This means legitimate mail may be rejected even though a valid record exists. The fix is to merge all authorized senders into a single record and delete the duplicate.

This tool queries the domain's DNS for a TXT record starting with v=spf1 , then parses and validates the mechanisms and qualifiers in that record. SPF authenticates the sending server's IP address. The DKIM checker queries a selector-specific DNS record and validates the public key used to verify a cryptographic signature attached to the message body and headers. The two records address different aspects of email authentication and are both needed for a complete setup.

The ptr mechanism works by performing a reverse DNS lookup on the sending IP and then a forward lookup to confirm the result. This requires multiple DNS queries, is slow, and is considered unreliable because reverse DNS records are not always accurate or present. RFC 7208 explicitly discourages its use. The checker warns when it appears in a record so you can replace it with a more precise mechanism like ip4: or include: .

Yes. SPF records are looked up for the exact domain used in the SMTP envelope sender address. A subdomain like mail.example.com has its own DNS zone and may have a separate SPF record, or none at all. You can enter any fully qualified domain name into the checker and it will query that specific name. If no record exists for the subdomain, the tool reports that no SPF record was found rather than falling back to the parent domain.

A dig TXT example.com command returns the raw record text but does nothing with it. You would then need to manually count DNS lookups, identify each mechanism and qualifier, and check for known problems. This tool performs the same DNS query, then automatically parses every mechanism, counts lookups, applies validation rules, and surfaces errors and warnings. It is useful when you want structured analysis without writing your own parsing logic.

SPF checks the envelope sender address used during the SMTP connection, not the From header visible to recipients. An attacker can spoof the visible From address while using a domain that passes SPF for the envelope. DMARC closes this gap by requiring alignment between the envelope domain and the From header. For full protection, SPF should be paired with DKIM and a DMARC policy. You can validate your DMARC setup with the DMARC Checker .

The tool performs a live DNS query for the domain you enter and returns the results to your browser. Domain names entered into the checker are not stored or logged after the lookup completes. DNS records are publicly accessible by design, so querying a domain's SPF record does not expose any private information. You can review the site's full data practices on the privacy policy page .

If the checker finds no v=spf1 TXT record, receiving servers have no SPF policy to evaluate. Most will treat this as a neutral result, but some apply stricter handling. You should add an SPF record through your DNS provider listing all servers authorized to send mail for your domain. At minimum, a record like v=spf1 -all signals that your domain sends no email, which prevents spoofing for domains used only for receiving.

DNS changes propagate based on the TTL (time to live) value set on your TXT record. Most DNS providers set a default TTL of 3600 seconds (one hour), meaning resolvers that have cached the old record will continue using it for up to that duration. After the TTL expires, resolvers fetch the new record. You can run the checker again after your expected propagation window to confirm the updated record is live.