SPF Record Check
SPF Record Check helps you validate sender policy framework records, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
SPF (Sender Policy Framework) Check validates the SPF record in your domain's DNS, which specifies which mail servers are authorized to send emails on behalf of your domain.
Why It Matters
- →Email Authentication: Prevents spammers from spoofing your domain
- →Deliverability: Improves chances emails reach recipients' inboxes, not spam
- →Brand Protection: Protects your domain reputation from abuse
- →Compliance: Required by many email security standards
How to Read Results
- v=spf1: Version identifier - always starts with this
- include: Authorizes third-party services (e.g., Google Workspace)
- ip4/ip6: Authorizes specific IP addresses or ranges
- ~all or -all: Policy for unauthorized senders (soft-fail or hard-fail)
Technical Background
SPF (Sender Policy Framework, RFC 7208) is a DNS-based email authentication mechanism that allows domain owners to specify which IP addresses and mail servers are authorized to send email on behalf of their domain. An SPF record is a DNS TXT record published at the domain root (e.g., "v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all"). When a receiving mail server gets an email, it extracts the envelope sender domain and looks up the SPF TXT record. It then evaluates the mechanisms (all, include, a, mx, ip4, ip6, exists, redirect) in order: "include:" delegates to another domain's SPF, "ip4:/ip6:" authorizes IP ranges, "a" authorizes the domain's A record, "mx" authorizes the domain's MX servers. The qualifiers are: "+" pass, "-" fail, "~" softfail (accept but flag), "?" neutral. The "-all" or "~all" at the end is critical — it determines what happens to mail that matches no mechanism. SPF has a 10 DNS lookup limit (RFC 7208 §4.6.4) — exceeding it causes a "permerror". SPF alone does not prevent display name spoofing; it must be combined with DKIM and DMARC for complete email authentication.
SPF record syntax supports several mechanisms: ip4:/ip6: for direct IP authorization, a: for the domain A record, mx: for MX server IPs, include: for delegating to another domain policy, exists: for dynamic lookups, and redirect: for complete delegation to another domain policy. The 10 DNS lookup limit (RFC 7208 section 4.6.4) applies to include, a, mx, exists, and redirect mechanisms — exceeding it causes a permanent error (permerror) that triggers authentication failure. Organizations with complex email infrastructure must count lookups carefully. SPF flattening (pre-resolving all includes to static IPs) is a workaround but requires maintenance. Without SPF, anyone can send email appearing to be from your domain, enabling phishing attacks that damage your brand reputation and harm your recipients.
SPF alignment in DMARC context means the domain in the Mail From (envelope sender, RFC 5321.MailFrom) must match the From: header domain. Strict alignment requires an exact match; relaxed alignment (the default) allows subdomain matches. Organizations using email service providers must add include: mechanisms for each provider: include:_spf.google.com for Google Workspace, include:spf.protection.outlook.com for Microsoft 365, include:sendgrid.net for SendGrid. SPF record validation tools like mxtoolbox.com/spf and kitterman.com/spf/validate help verify syntax and lookup count compliance before publishing changes. Regular SPF audits catch accumulating include: entries from past vendor additions that were never cleaned up.
Common Errors and How to Fix Them
- ProblemTwo separate TXT records start with 'v=spf1' (one added for the mailbox provider, another for a marketing platform).
- FixRFC 7208 section 4.5 makes multiple SPF records a permerror, so receivers treat SPF as broken. Merge them into one: 'v=spf1 include:_spf.google.com include:servers.mcsv.net -all'.
- ProblemThe record needs more than 10 DNS-querying terms once nested includes are expanded, causing a permerror at receivers.
- FixRFC 7208 section 4.6.4 caps include, a, mx, ptr, exists and redirect at 10 lookups in total, nested ones included. Remove vendors you no longer use, replace 'a' and 'mx' with explicit ip4/ip6 ranges, or move bulk senders to a subdomain with its own SPF.
- ProblemThe policy ends in '+all', which authorizes every IP address on the internet.
- FixReplace it with '-all' (fail) or '~all' (softfail). '+all' makes the record worthless and is flagged as a critical issue by this checker.
- ProblemThe record still uses the 'ptr' mechanism copied from an old tutorial.
- FixRFC 7208 says 'ptr' SHOULD NOT be used: it is slow, unreliable and costs lookups. Replace it with the actual ip4:/ip6: ranges of your servers.
- ProblemAn include points to a vendor domain that no longer publishes SPF or no longer exists, generating void lookups.
- FixAn include whose target has no SPF record yields permerror, and more than two void lookups (NXDOMAIN or empty answers) also break evaluation. Delete includes left behind by cancelled services.
- ProblemA long record was pasted as one string over 255 characters and the DNS panel rejected or silently truncated it.
- FixSplit it into several quoted strings inside the same TXT record, for example "v=spf1 ip4:203.0.113.0/24 " "include:_spf.example.net -all". Strings are concatenated without spaces, so keep a space at the end of each chunk.
Frequently Asked Questions
Should I end my SPF record with ~all or -all?
Both are acceptable once DMARC is in place. '-all' asks receivers to fail unauthorized senders, but some reject at SMTP time before DMARC or DKIM can rescue legitimate forwarded mail. '~all' marks them as softfail and lets DMARC make the final decision. A common approach is ~all while you inventory senders, then -all when every legitimate source is listed.
Which mechanisms count toward the 10-lookup limit?
Only terms that trigger DNS queries: include, a, mx, ptr, exists and the redirect modifier. ip4, ip6 and all cost nothing. Every include is expanded recursively, so a single include for a large provider can consume three or four lookups by itself. This checker counts your top-level includes; remember that nested includes inside them also count toward the limit.
Does SPF check the From address that people see?
No. SPF validates the envelope sender (MAIL FROM, visible later as Return-Path) and optionally the HELO name. The visible From header can be anything. DMARC closes that gap by requiring the SPF-authenticated domain to align with the From domain, which is why a passing SPF result alone does not stop display-name spoofing.
Why does SPF fail when my mail is forwarded?
A forwarding server relays your message from its own IP address, which is not in your SPF record, so the receiver sees a fail or softfail. Forwarders that use SRS rewrite the envelope sender to avoid this. The practical fix on your side is to also sign with DKIM, because a DKIM signature survives plain forwarding and still satisfies DMARC.
Do subdomains inherit the SPF record of the parent domain?
No. SPF is looked up at the exact domain used in MAIL FROM, so news.example.com needs its own TXT record if it sends mail. Subdomains that never send should publish 'v=spf1 -all' to prevent abuse. DMARC behaves differently: it does fall back to the organizational domain's policy, adjustable with the sp tag.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/spf-check
curl -X POST https://epcybertools.com/api/tools/spf-check \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Look up SPF TXT record
dig TXT example.com | grep spf
# Short output
dig +short TXT example.com
# Query via specific resolver
dig @8.8.8.8 TXT example.com +short