SPF Record Check

• What This Tool 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 the 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.