SPF (Sender Policy Framework)

TL;DR

SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain — preventing email spoofing and improving inbox placement. As of February 2024, Google and Yahoo require SPF for all senders sending more than 5,000 messages per day. SPF misconfiguration is one of the most common causes of cold email going to spam (Google Gmail Sender Guidelines 2024; RFC 7208).

What is SPF?

SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email using your domain name. When a receiving mail server gets an email claiming to be from rep@gangly.com, it checks Gangly's SPF record to verify that the sending server is on the authorized list. If it is, the email passes the SPF check. If it isn't, the email may be flagged, rejected, or routed to spam.

SPF was designed to prevent email spoofing — where spammers send emails that appear to come from legitimate domains they don't control. It was defined in RFC 7208 (2014) and is now one of three required email authentication standards (alongside DKIM and DMARC) for legitimate senders.

For SDRs sending cold email from a company domain, SPF is not something the rep configures — it's a DNS record that the company's IT team or domain admin sets up once and maintains. But understanding what it does and whether it's configured correctly is essential context for diagnosing deliverability problems.

How SPF works

1. The sending company (e.g., Gangly) creates a TXT record in their domain's DNS settings that lists which servers are authorized to send email for gangly.com. Example: 'v=spf1 include:_spf.google.com include:sendgrid.net ~all'. This record says: Gmail's servers and SendGrid's servers are authorized; everything else should be treated with suspicion.

2. When a receiving server gets an email from rep@gangly.com, it looks up gangly.com's DNS to find the SPF record.

3. It checks whether the IP address of the sending server matches the list of authorized senders in the SPF record.

4. If it matches → SPF PASS. The authentication check succeeds and the email proceeds to other filtering checks. If it doesn't → SPF FAIL (hard failure) or SPF SOFTFAIL (treated as suspicious, not definitively failed). DMARC policy then determines what happens with the failed message.

Common SPF setup mistakes

1. Too many DNS lookups. The SPF standard limits records to 10 DNS lookups. Teams using multiple email services (Google Workspace, Salesforce email, SendGrid, HubSpot) can exceed this limit — causing SPF to fail even when all services are legitimately authorized. Use SPF flattening tools (EasyDMARC, Dmarcian) to consolidate.

2. Missing ~all or -all at the end. The SPF record must end with either ~all (softfail — treat unauthorized senders with suspicion) or -all (hardfail — reject unauthorized senders outright). Missing this qualifier means the record doesn't enforce anything. Best practice for cold email senders: ~all while validating, -all once all sending services are confirmed.

3. Not updating SPF when adding new sending services. Every new email service added (CRM email integration, marketing automation, new sending domain) must be added to the SPF record. An SPF record from 2021 may not include services added since then.

4. Not verifying SPF is passing. Set up SPF and never check that it's actually working. Use MXToolbox SPF checker or the Google Postmaster Tools 'Authentication' section to verify SPF is passing on actual sends.

SPF, DKIM, and DMARC together

SPF alone is not sufficient for full email authentication. SPF only validates the sending server's IP — it doesn't validate the message content hasn't been altered in transit (that's DKIM's job) and it doesn't tell receiving servers what to do with messages that fail authentication (that's DMARC's job). All three records must be configured and passing for optimal inbox placement.

The 2024 Google and Yahoo sender requirements make this explicit: SPF or DKIM is required for all senders; both SPF and DKIM plus DMARC are required for senders above 5,000 messages/day. Cold outbound teams should configure all three regardless of current volume — the setup takes 30–60 minutes once and protects inbox placement permanently.

See DKIM → and DMARC →

At a glance

Category: Outreach
Related: 4 terms

Frequently asked questions

What is SPF in email?

Sender Policy Framework — a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. Receiving servers check SPF to verify that an email claiming to be from your domain actually comes from an authorized server. Prevents spoofing and is one of three required authentication standards (with DKIM and DMARC) for cold email senders.

How do you set up SPF?

Add a TXT record to your domain's DNS settings (in your domain registrar or DNS host). The record format: 'v=spf1 [authorized servers] ~all'. Replace [authorized servers] with include statements for each email service you use (e.g., 'include:_spf.google.com' for Google Workspace). Verify setup with MXToolbox.com SPF Checker. Takes 30–60 minutes; DNS propagation takes up to 48 hours.

What happens if SPF fails?

The receiving server applies your DMARC policy to determine action: if DMARC policy is 'none', the email may still be delivered but reputation is affected. If DMARC policy is 'quarantine', the email routes to spam. If DMARC policy is 'reject', the email is not delivered. An SPF failure without DMARC configured results in increased spam routing risk without explicit rejection.

Does SPF prevent all email spoofing?

SPF prevents spoofing of the envelope-from address (the server handshake address). It does not protect the header-from address (the 'From' address the recipient sees), which is what DMARC adds on top of SPF and DKIM. SPF + DKIM + DMARC together provide comprehensive protection against most spoofing scenarios. SPF alone is a partial solution.

See it in the product