SPF Record Checker
Validate your SPF record syntax, check DNS lookup count, and identify configuration issues that could affect email delivery.
What is an SPF Record?
SPF (Sender Policy Framework) is an email authentication protocol that lets domain owners specify which mail servers are authorized to send email on behalf of their domain. It works by publishing a DNS TXT record that lists the approved sending sources.
How SPF Works
When a receiving mail server gets an email, it looks up the SPF record for the sender's domain. It then checks whether the sending server's IP address matches one of the authorized sources listed in the record. If it does, the email passes SPF authentication. If not, it may be flagged or rejected.
Common SPF Issues
- Too many DNS lookups - SPF has a limit of 10 DNS lookups per evaluation. Exceeding this causes a permanent error (permerror) and SPF will fail.
- Missing authorized senders - If you use third-party services (Google Workspace, SendGrid, Mailchimp, etc.), they must be included in your SPF record.
- Multiple SPF records - A domain must have exactly one SPF TXT record. Having multiple records causes failures.
- Using +all - The "+all" mechanism authorizes every server to send email for your domain, which defeats the purpose of SPF entirely.
SPF Record Syntax
An SPF record always starts with v=spf1 and ends with an "all" mechanism. Common mechanisms include:
include:- Authorize a third-party sender (e.g.,include:_spf.google.com)ip4:- Authorize a specific IPv4 address or rangeip6:- Authorize a specific IPv6 address or rangea- Authorize the domain's A record IPmx- Authorize the domain's MX record IPs~all- Soft fail for unauthorized senders (recommended)-all- Hard fail for unauthorized senders (strictest)
Need to create an SPF record? Try our SPF Record Generator.
Frequently Asked Questions
An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. It starts with v=spf1 followed by mechanisms that define allowed senders. Without an SPF record, your emails are more likely to be rejected or marked as spam, and your domain becomes vulnerable to spoofing attacks. As of 2025, major providers like Google and Microsoft require SPF authentication for reliable email delivery.
Enter your domain name into our SPF record checker tool above. The tool performs a DNS lookup to retrieve and display any published SPF TXT records, validates the syntax, counts DNS lookups, and flags any errors that could impact email deliverability. You can also manually check by running nslookup -type=txt yourdomain.com in a command prompt.
An SPF check failure means the sending server's IP address is not listed as an authorized sender in your domain's SPF record. With a hard fail (-all), the receiving server will typically reject the email with a 550 error. With a soft fail (~all), the message may be accepted but marked as spam. If you also have DKIM and DMARC configured, a DKIM pass can allow the email through even if SPF fails.
The SPF specification (RFC 7208) limits each SPF record to a maximum of 10 DNS lookups during evaluation, including all nested lookups from include, a, mx, ptr, exists, and redirect mechanisms. Exceeding this limit causes an SPF PermError, which means all emails fail SPF authentication. To fix it, remove unused include statements, replace them with direct ip4 or ip6 entries where possible, and eliminate the ptr mechanism.
No, you must not have more than one SPF record per domain. Publishing multiple SPF records (multiple TXT records starting with v=spf1) will cause SPF to return a PermError for every email sent from that domain, effectively failing authentication for all messages. If you need to authorize additional sending services, combine all entries into a single SPF record using include mechanisms.
SPF verifies that the sending server is authorized to send email for your domain (checks the "where"). DKIM uses cryptographic signatures to ensure the email content has not been tampered with in transit (checks the "what"). DMARC builds on both SPF and DKIM by defining a policy for how receiving servers should handle authentication failures and provides reporting. All three work together as complementary layers, and implementing all three is now considered mandatory for reliable email delivery.
SPF record changes typically propagate within a few minutes to a few hours, though full global DNS propagation can take up to 24-48 hours depending on your DNS provider and TTL (Time To Live) settings. To speed up propagation, set a lower TTL value (such as 300 seconds) before making changes, and use an SPF checker to verify the updated record is visible.
This is a common SPF record for domains using Google Workspace. The v=spf1 declares it as an SPF version 1 record. The include:_spf.google.com mechanism authorizes all of Google's mail servers to send email on behalf of your domain. The ~all qualifier is a soft fail, meaning emails from servers not listed in the record should be flagged as suspicious. If you use additional email services beyond Google, add their include mechanisms to this same record.
The most common SPF errors include syntax mistakes (missing v=spf1 prefix), exceeding the 10 DNS lookup limit, having multiple SPF records on the same domain, and missing include statements for third-party senders. Use our SPF record checker to identify the specific errors, then correct your DNS TXT record. Ensure you have exactly one SPF record, verify every sending service is listed, and always end with a -all or ~all mechanism.
No, an SPF record alone is not sufficient to prevent email spoofing. SPF only validates the envelope sender (MAIL FROM) address, not the visible "From" header that recipients see. To fully protect your domain, you need to implement SPF together with DKIM and DMARC. DMARC specifically aligns the visible "From" domain with SPF and DKIM results. Since 2024, Google, Microsoft, and Yahoo require all three protocols for bulk senders.