DNS Record Explainer

v=spf1
Protocol version. Always "v=spf1" for SPF records. No variation here.

include:_spf.google.com
Pulls in Google's SPF record wholesale. Your DNS resolver fetches _spf.google.com's SPF record and treats those mechanisms as if they were inline. Google publishes multiple IP ranges here; you're delegating to their maintenance. Common for Gmail/Google Workspace customers.

include:mailgun.org
Same pattern for Mailgun's infrastructure. If you're sending via Mailgun's SMTP, their IPs need to be authorized. Mailgun maintains this list.

~all
Soft fail on everything else. Mail from IPs not matching the includes gets a "softfail" result, not a hard reject. Receiving servers treat softfail differently depending on their policy—many deliver anyway, some flag for review. This is the cautious landing gear.

• The record will work but has weak rejection posture. ~all allows mail from unauthorized sources through on permissive receivers. If you want strict enforcement, use "-all" (hard fail). Evaluate your actual sending sources first—you can't switch to "-all" safely without knowing all legitimate senders.

• No "a" or "mx" mechanisms. Your A/MX records aren't authorized to send mail from your domain. If your domain's mail server sends on behalf of itself, you need "a" or "mx:yourdomain.com" added. Check whether you actually send directly.

• Both includes are external dependencies. If Google or Mailgun change their infrastructure and don't update their SPF records, your mail could silently fail. Monitor for include bloat—every include consumes one of the 10 DNS lookups SPF allows per query. You're at 2; room to spare, but not infinite.

• No "ptr" (not recommended anyway), no "ip4/ip6" hardcodes. Clean.

SPF prevents spoofing by letting receiving mail servers verify that a sending IP is authorized by the domain's DNS administrator. Without it, anyone can claim to be [email protected] from any IP. Gmail, Outlook, and enterprise mail systems check SPF during inbound filtering. A missing or malformed SPF record means legitimate mail may land in spam or bounce entirely if the receiver enforces strictly. Pair this with DKIM and DMARC for full authentication coverage.

→ /tools/spf-checker run the live checker on a real domain → /blog/spf-10-dns-lookup-limit