SPF Record Checker
Look up and validate your SPF record. Check syntax, count DNS lookups against the 10-lookup limit, and detect misconfigurations that could break your email delivery.
What is SPF?
SPF (Sender Policy Framework) is a DNS-based email authentication protocol defined in RFC 7208. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain by publishing a TXT record in DNS.
When a receiving mail server gets an email claiming to be from your domain, it looks up your SPF record and checks whether the sending server's IP address is listed as authorized. If it's not, the email may be marked as spam, quarantined, or rejected — depending on the receiving server's policy and your DMARC configuration.
A typical SPF record looks like this: v=spf1 include:_spf.google.com include:sendgrid.net ~all. This says: "Google and SendGrid are authorized to send email as my domain. Softfail everything else."
Why SPF matters
Without SPF, anyone can send email that appears to come from your domain. Phishing attacks, business email compromise, and brand impersonation all exploit domains without proper email authentication. SPF is your first line of defense.
But SPF is also fragile. Every time you add a new email service — HubSpot, Zendesk, Mailchimp, Salesforce — you add another include: to your SPF record. Each include triggers DNS lookups. Cross the 10-lookup limit, and your SPF record breaks silently. Every email you send starts failing authentication, and you won't know until deliverability drops or customers complain.
Security risks & attack vectors
DNS lookup limit exceeded
You added HubSpot 6 months ago and broke your SPF without knowing. Every email since has been failing authentication. The 10-lookup limit is cumulative across all nested includes.
+all misconfiguration
Using +all instead of ~all or -all means any server in the world is authorized to send as your domain. This completely negates SPF protection.
Stale includes from old services
You switched from Mailchimp to Brevo last year but forgot to remove the old include. It still counts toward your 10-lookup limit and authorizes servers you no longer use.
The set-and-forget trap
SPF records are configured once and then forgotten. But your email infrastructure changes constantly. New marketing tools, new CRM, new support desk — each one needs to be added to your SPF. And when you stop using a service, the old include stays behind, wasting precious DNS lookups.
The worst part? When your SPF breaks, there's no error message. No notification. Your emails just silently start failing authentication. Deliverability drops. Emails land in spam. Customers stop receiving invoices and notifications. And you don't find out for weeks.
Get alerted when your SPF record changes or breaks the lookup limit. Join the Sendvery beta.
Frequently asked questions
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Receiving servers check SPF to verify the sender is legitimate.
RFC 7208 limits SPF records to 10 DNS lookups. Mechanisms like include, a, mx, ptr, exists, and the redirect modifier each count as one lookup. Exceeding this limit causes a permanent error (permerror).
The +all mechanism tells receiving servers that ANY server is authorized to send email as your domain. This completely defeats the purpose of SPF. Use ~all (softfail) or -all (hardfail) instead.
Remove unused includes from old services, flatten your SPF record by replacing includes with IP addresses, or use an SPF flattening service that automatically maintains the record.
~all (softfail) suggests unauthorized senders should be treated with suspicion. -all (hardfail) says to reject unauthorized senders outright. ~all is safer during migration; -all provides stronger protection.
Want ongoing monitoring?
Checking once is a start. But email authentication breaks silently over time. Get alerted the moment something changes.
Free plan includes 1 domain. No credit card required.