Check your domain's published SPF record for configuration errors, included domains, DNS lookup limits, and other common SPF issues.
Also check: DMARC Record Checker · DKIM Record Checker.
Checking your SPF configuration only takes a few seconds:
example.com. You don’t need to enter https:// or an email address.If the checker reports a problem, review the affected part of your SPF record before making changes. SPF records often contain mechanisms added for third-party email services, so removing an unfamiliar entry without identifying what uses it could cause legitimate email to fail SPF authentication.
The SPF Checker examines the SPF configuration published in your domain’s DNS. Depending on the record it finds, there are several results and potential issues to look for.
An SPF record was found in DNS for the domain.
A valid SPF record begins with:
v=spf1
Finding a record does not necessarily mean the SPF configuration is correct. The policy can still contain syntax problems, unnecessary mechanisms, multiple nested include statements, or exceed SPF’s DNS lookup limit.
You should also confirm that the policy represents the services that are actually authorized to send email for your domain.
The checker could not find an SPF record for the domain.
If the domain sends email, check the documentation provided by your email service to determine which SPF mechanisms or include values are required.
Do not copy an SPF record from another domain or blindly use a generic example. Your SPF policy should reflect the services that actually send email for your domain.
A domain should not publish multiple separate SPF policies beginning with v=spf1.
For example, this is incorrect:
v=spf1 include:provider-a.example -all
and a second TXT record:
v=spf1 include:provider-b.example -all
Publishing multiple SPF records can cause SPF evaluation to return a permanent error (PermError).
If both services are legitimate senders, their required mechanisms normally need to be combined into a single SPF policy, such as:
v=spf1 include:provider-a.example include:provider-b.example -all
Always follow the SPF configuration instructions provided by the services you actually use.
SPF limits an evaluation to 10 DNS-querying terms.
Mechanisms such as:
include
a
mx
exists
and the redirect modifier can contribute to this limit.
An include can also reference another SPF policy containing additional DNS-querying mechanisms, so the effective lookup count can be higher than the number of include statements visible in your own record.
If SPF evaluation exceeds the permitted limit, it can return PermError.
A high lookup count is therefore worth investigating before it reaches the limit.
Many SPF records authorize third-party email services using the include mechanism.
For example:
v=spf1 include:_spf.example.com -all
This tells SPF evaluators to evaluate the referenced domain’s SPF policy as part of determining whether a sending source is authorized.
Seeing an unfamiliar included domain does not automatically mean there is a problem. It may belong to an email provider, marketing platform, help desk, CRM, transactional email service, or another application authorized to send mail for your organization.
Before removing an include, identify which service depends on it.
SPF (Sender Policy Framework) is an email authentication standard that allows a domain owner to publish which sending sources are authorized to send email for a domain.
The SPF policy is published as a TXT record in DNS.
A simple SPF record might look like:
v=spf1 include:_spf.example.com -all
When a receiving mail server evaluates SPF, it checks the connecting server’s IP address against the SPF policy associated with the relevant SMTP envelope identity.
If the sending source is authorized by the policy, SPF can pass. If it is not authorized, SPF returns another result according to the mechanisms and qualifiers in the policy.
SPF does not directly authenticate the visible From: address that users see in their email client. DMARC adds domain alignment so SPF and DKIM authentication can be connected to the visible sender domain.
An SPF record consists of mechanisms and qualifiers that describe which sending sources are authorized.
v=spf1Every SPF policy starts with:
v=spf1
This identifies the TXT record as an SPF version 1 policy.
includeThe include mechanism evaluates another domain’s SPF policy.
For example:
include:_spf.example.com
Email providers commonly use this mechanism so customers can authorize the provider’s sending infrastructure without maintaining lists of IP addresses themselves.
Each include can contribute to SPF’s DNS lookup limit, including DNS-querying mechanisms contained within the referenced policy.
ip4The ip4 mechanism authorizes an IPv4 address or network.
For example:
ip4:192.0.2.10
or:
ip4:192.0.2.0/24
These mechanisms are useful when you operate known outbound mail servers with stable IP addresses.
ip6The ip6 mechanism performs the equivalent function for IPv6 addresses or networks.
For example:
ip6:2001:db8::/32
aThe a mechanism can authorize IP addresses associated with a domain’s A or AAAA records.
Because it requires DNS resolution during SPF evaluation, it contributes to the DNS lookup limit.
mxThe mx mechanism can authorize IP addresses associated with the domain’s MX records.
It also requires DNS queries and contributes to SPF’s lookup limit.
-allThe -all mechanism produces an SPF Fail result when the sending source has not matched an earlier mechanism in the policy.
For example:
v=spf1 include:_spf.example.com -all
This does not itself guarantee that the receiving mail server will reject the message. The receiving system decides how SPF results contribute to its authentication and filtering decisions.
~allThe ~all mechanism produces an SPF SoftFail result for sending sources that have not matched an earlier mechanism.
For example:
v=spf1 include:_spf.example.com ~all
SoftFail is distinct from the explicit Fail result produced by -all. Receiving mail systems determine how they use the result.
Publishing multiple v=spf1 records does not create a combined SPF policy.
If several services need authorization, their required mechanisms generally need to be incorporated into a single SPF record.
SPF permits a maximum of 10 DNS-querying terms during an evaluation.
Complex policies containing multiple include, a, mx, exists, or redirect terms can exceed this limit, particularly when included policies reference additional policies of their own.
If the limit is exceeded, SPF evaluation can return PermError.
An SPF policy is only useful if it accurately represents your legitimate sending infrastructure.
Organizations often send email through more systems than expected, including:
Before tightening an SPF policy or removing mechanisms, identify all services that legitimately send email for the domain.
SPF policies can accumulate entries for services that are no longer used.
An obsolete include unnecessarily authorizes infrastructure and can also increase the complexity and DNS lookup count of the SPF policy.
Periodically review your SPF configuration and remove entries only after confirming that the associated service is no longer sending legitimate email.
FAQ
No. A domain should have a single SPF policy.
Publishing multiple TXT records beginning with v=spf1 can cause SPF evaluation to return PermError.
If multiple email services need to send mail for the domain, their required SPF mechanisms normally need to be combined into one policy.
SPF restricts the number of DNS-querying terms that can be used during an evaluation to 10.
Mechanisms including include, a, mx, and exists, along with the redirect modifier, can contribute to the limit.
The important detail is that nested policies count too. An include might lead to another SPF record that performs several additional DNS queries.
As a result, simply counting the number of include statements visible in your SPF record does not necessarily reveal the complete lookup cost.
If an SPF evaluation exceeds the permitted DNS lookup limit, it can return a permanent error (PermError).
This can prevent SPF from successfully authenticating legitimate email, so configurations approaching or exceeding the limit should be reviewed.
Both normally appear at the end of an SPF policy and determine the result for sending sources that did not match an earlier mechanism.-all produces an SPF Fail result.v=spf1 include:_spf.example.com -all~all produces an SPF SoftFail result.v=spf1 include:_spf.example.com ~all
Neither qualifier directly determines whether an email reaches the inbox, spam folder, or is rejected. Receiving systems decide how SPF results contribute to their overall authentication and filtering decisions.
SPF helps prevent unauthorized systems from successfully authenticating as permitted senders for a domain, but SPF alone does not fully protect the visible From: address against spoofing.
For stronger domain protection, SPF is normally deployed alongside DKIM and DMARC. DMARC checks whether SPF or DKIM authentication aligns with the domain shown in the visible From: address and allows the domain owner to publish a handling policy for messages that fail DMARC.
No. This checker analyzes the SPF policy published in your domain's DNS.
Whether a particular email passes SPF depends on factors including the sending server's IP address and the SMTP envelope identity used for that message.
To verify an actual email, send a test message through the relevant sending service and inspect its authentication results or message headers.
Check your SPF configuration whenever you add, remove, or change a service that sends email for your domain.
It is also worth reviewing SPF periodically because third-party services, legacy applications, and obsolete authorization mechanisms can accumulate as an organization's email infrastructure changes.
A correctly configured SPF policy is an important part of protecting your sending domain, but SPF works best alongside DKIM and DMARC.
DKIM adds cryptographic authentication to outgoing messages, while DMARC checks alignment with the domain visible to recipients and provides monitoring and policy controls
.
If you're configuring email authentication for a domain, read our How to Set Up SPF, DKIM, and DMARC for Email Authentication guide for the complete deployment process.
Try UptimeObserver now. Setup in 2 minutes.