SPF record checker

An SPF (Sender Policy Framework) record is a DNS TXT record published at your domain's root that lists all the IP addresses and mail servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks this record to verify the sender is legitimate. SPF helps prevent email spoofing and improves deliverability.

Simply enter your domain name (e.g., company.com) into the InboxKit SPF Checker tool above and click 'Check SPF Record'. We will query your DNS, retrieve the SPF TXT record, parse all mechanisms and modifiers, count DNS lookups, and report on your configuration's validity with actionable recommendations.

A soft fail (~all) tells receiving servers to accept emails from unauthorized IPs but mark them as suspicious or potential spam. This is the recommended setting for most domains during initial rollout, as it prevents legitimate emails from being rejected outright while still providing protection against spoofing. Once you have verified all legitimate senders, you can move to a hard fail (-all).

Common reasons for invalid SPF records include: exceeding the 10 DNS lookup limit (include, a, mx, redirect each count as one lookup), syntax errors in the record, having multiple SPF records (you can only have one per domain), missing the 'v=spf1' version prefix, or referencing non-existent include domains. Our tool provides detailed error messages to help you fix these issues.

The SPF specification (RFC 7208) limits the number of DNS-querying mechanisms to 10 per SPF evaluation. Mechanisms that trigger lookups include: 'include', 'a', 'mx', 'redirect', and 'exists'. IP-based mechanisms like 'ip4' and 'ip6' do not count. Exceeding this limit causes a 'permerror' result, effectively breaking your SPF. Use our checker to count your current lookups.

No, you can only have one SPF TXT record per domain. Having multiple SPF records will cause a 'permerror' and your SPF will fail validation entirely. If you need to authorize multiple senders, combine them into a single record using 'include' mechanisms. For example: v=spf1 include:_spf.google.com include:sendgrid.net ~all

These are SPF qualifiers that define the policy for emails from unauthorized senders. '-all' (hard fail) instructs receivers to reject unauthorized emails outright. '~all' (soft fail) marks them as suspicious but still delivers them, often to spam. '?all' (neutral) takes no stance. '+all' (pass all) allows any sender -- this is dangerous and should never be used. Most organizations should use ~all during testing and -all in production.

DMARC uses SPF as one of its two authentication mechanisms (the other being DKIM). For DMARC to pass via SPF, two things must be true: the SPF check itself must pass (the sending IP is authorized), and the SPF domain must align with the From header domain. Alignment can be relaxed (subdomain match allowed) or strict (exact match required). Even if SPF fails, DMARC can still pass if DKIM succeeds.

To authorize a third-party sender (like SendGrid, Mailchimp, or HubSpot), add their SPF include mechanism to your existing record. For example, to add SendGrid: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Each provider publishes their own SPF include domain -- check their documentation. Be mindful of the 10 DNS lookup limit when adding multiple includes.

When SPF fails, the result depends on your SPF policy qualifier. With '-all', the email may be rejected entirely. With '~all', it is typically delivered to spam. The SPF result is also fed into DMARC evaluation -- if both SPF and DKIM fail with DMARC alignment, the DMARC policy (none/quarantine/reject) determines the final outcome. Failed SPF can also negatively impact your domain's sending reputation over time.