Validate your Sender Policy Framework record
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsSPF (Sender Policy Framework) tells receiving mail servers which hosts may send email for your domain. A broken SPF record — duplicated, too many DNS lookups, or missing an 'all' mechanism — causes legitimate mail to land in spam. IPeek finds your SPF record, parses every mechanism and flags the issues that hurt deliverability.
SPF lives as a TXT record on your root domain, beginning with v=spf1. When a server receives mail claiming to be from you, it looks up that record and checks whether the sending IP is authorized. A record like v=spf1 include:_spf.google.com ip4:198.51.100.10 -all means "allow Google's hosts and this one IP, reject everything else." Mechanisms are evaluated left to right; the first match wins. The trailing all mechanism is the catch-all that decides the default outcome for any host not explicitly listed.
The all mechanism sets your policy: -all is a hardfail (reject unlisted senders), ~all is a softfail (accept but mark suspicious), and +all allows anyone — never use it. SPF also caps DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) at 10 total lookups; exceed it and the result is permerror, treated as a failure. Nested includes count too, so adding several vendors quietly burns through the budget. IPeek counts every lookup and warns before you hit the ceiling.
SPF alone is not enough. It authenticates the envelope sender (the return-path), not the visible From address users see, so spoofers can pass SPF while forging your brand. DMARC closes that gap by requiring alignment between the SPF domain and the From domain, and by pairing SPF with DKIM so either can authenticate a message. Treat SPF as one of three layers: SPF authorizes hosts, DKIM signs content, and DMARC ties them to your From domain and enforces policy.
SPF allows a maximum of 10 DNS-querying mechanisms per evaluation. The include, a, mx, ptr, exists, and redirect mechanisms each consume lookups, and nested includes count toward the same limit. Exceeding 10 produces a permerror, which receivers treat as an authentication failure. Flatten or consolidate includes to stay under the cap.
The difference is enforcement. -all is a hardfail telling receivers to reject mail from any host not listed in your record, while ~all is a softfail telling them to accept it but treat it as suspicious. Use ~all while testing, then move to -all once you've confirmed every legitimate sender is authorized. Avoid +all, which authorizes anyone.
An SPF record alone doesn't guarantee inbox placement. Common causes include exceeding the 10-lookup limit (permerror), a missing or overly permissive all mechanism, a sending host that isn't actually authorized, or duplicate SPF records on the same domain. SPF also doesn't protect your visible From address — you need DKIM and DMARC alongside it for strong deliverability.
No. A domain must publish exactly one SPF (v=spf1) TXT record. Two or more SPF records cause a permerror, and receivers may reject or fail authentication for your mail. If you need to authorize multiple senders, combine them into a single record using additional include or ip4/ip6 mechanisms rather than adding a second record.
No. SPF authenticates the envelope sender (the return-path or MAIL FROM), not the From header your recipients actually see. This is why SPF alone can't stop spoofing of your brand. DMARC adds SPF alignment, requiring the SPF domain to match the visible From domain, which is what closes the gap between protocol-level checks and what users read.