Learn how SPF authentication uses DNS records to authorize sending servers, prevent email spoofing, and improve Salesforce email deliverability.

Salesforce Sent Your Email—But Your DNS Never Approved It. Here’s How SPF Fixes That.

When you send an email from Salesforce, the message leaves Salesforce’s mail servers—not yours. Without SPF, the recipient’s server has no way to confirm that Salesforce is authorized to send on your domain’s behalf. The result: your perfectly crafted campaign lands in spam or gets rejected entirely. SPF authentication solves this by publishing a DNS record that explicitly lists every server permitted to send email for your domain. Gmail and Yahoo now require SPF for all senders, and organizations sending mass emails through Salesforce face immediate deliverability consequences without it. SPF is the first layer of email authentication—and without it, DKIM and DMARC have nothing to build on.

What Is SPF Authentication?

SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208 that allows domain owners to specify which mail servers are authorized to send email on their behalf. It works by publishing a DNS TXT record containing a list of approved IP addresses and sending domains. When a recipient’s mail server receives an email, it checks the return-path (envelope-from) domain’s SPF record to verify that the sending server’s IP address is on the authorized list.

If the IP matches, the email passes SPF—confirming the sending server is legitimate. If it doesn’t match, the server applies the SPF policy: hard fail (-all) tells servers to reject unauthorized emails, soft fail (~all) marks them as suspicious, and neutral (?all) takes no action. As Cloudflare’s SPF reference explains, SPF records act like a guest list at the door—only servers on the list get through. SPF works alongside DKIM and DMARC as one of three foundational authentication protocols that inbox providers evaluate before delivering your emails.

How SPF Works: The Verification Process

The SPF verification process happens automatically for every inbound email, typically in milliseconds. When your Salesforce org sends an email, the recipient’s mail server extracts the domain from the return-path address (the envelope-from, not the visible From header). It then performs a DNS lookup for a TXT record on that domain. The server parses the SPF record, compares the sending server’s IP address against the authorized IP ranges, includes mechanisms, and other directives in the record, and returns a pass, fail, soft fail, or neutral result.

A key distinction: SPF checks the envelope-from domain, not the From header that recipients see. This matters because Salesforce, by default, uses its own domain (*.bnc.salesforce.com) as the return-path when Bounce Management and Email Security Compliance are enabled. This means Salesforce’s own SPF record handles validation—but it also means SPF won’t align with your visible From domain for DMARC purposes unless you configure DKIM as well. Understanding this interaction between SPF, the return-path, and DMARC alignment is critical for organizations managing email deliverability in Salesforce.

Setting Up SPF for Salesforce

Configuring SPF for Salesforce requires adding Salesforce’s sending infrastructure to your domain’s DNS record. Salesforce provides a dedicated include mechanism: include:_spf.salesforce.com. This single includes directive references Salesforce’s full range of sending IP addresses, so you don’t need to list individual IPs. For detailed setup steps, see our Salesforce email authentication guide. Salesforce’s official SPF documentation covers the include mechanism in detail.

If you don’t have an existing SPF record, create a new DNS TXT record: v=spf1 include:_spf.salesforce.com ~all. If you already have an SPF record (for Google Workspace, Microsoft 365, or other services), add the Salesforce include before the “all” mechanism: v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all. Critical rule: never create multiple SPF records for the same domain. Having two SPF TXT records causes a PermError that invalidates all SPF checks, breaking authentication for every email you send. Consolidate all authorized senders into a single record. Once validated, consider changing ~all (soft fail) to -all (hard fail) for stricter enforcement.

The 10-Lookup Limit and SPF Record Management

SPF records have a strict 10 DNS lookup limit defined in the RFC specification. Every “include,” “a,” “mx,” and “redirect” mechanism in your record triggers a DNS lookup—and each included domain can have nested includes that count against your total. Exceeding 10 lookups causes a PermError, which means SPF fails for all emails, effectively disabling authentication for your entire domain. This is the most common SPF misconfiguration in organizations with complex email infrastructure.

Organizations using Salesforce alongside Google Workspace, Microsoft 365, marketing automation platforms, and transactional email services can quickly hit this limit. Strategies to stay within 10 lookups include: replacing “include” directives with direct IP4/IP6 ranges where possible (these don’t count as lookups), removing senders you no longer use, consolidating services that share IP infrastructure, and using SPF flattening tools that resolve includes into static IP lists. Audit your SPF record regularly—any time you add a new sending service, verify the total lookup count using free tools like MXToolbox. For Salesforce-specific email security configuration, ensure Salesforce’s include doesn’t push you past the limit when combined with other providers.

SPF, DKIM, and DMARC: The Authentication Stack

SPF alone is insufficient for complete email authentication. It verifies the sending server but doesn’t check message integrity, doesn’t survive forwarding, and doesn’t tell inbox providers what to do when checks fail. That’s why SPF, DKIM, and DMARC work as an integrated stack. DKIM adds a cryptographic signature that verifies the message content hasn’t been altered and survives forwarding. DMARC ties both protocols together with policy enforcement and alignment requirements.

DMARC alignment is where SPF’s relationship with Salesforce gets nuanced. DMARC requires either SPF or DKIM to “align” with the visible From header domain. Since Salesforce uses its own return-path domain by default, SPF passes, but doesn’t align with your From domain for DMARC purposes. This is why configuring DKIM in Salesforce (Setup → DKIM Keys) is essential—it provides the aligned authentication that DMARC needs. For the complete three-protocol configuration, follow our step-by-step authentication guide. Gmail and Yahoo require all three protocols for bulk senders, making this stack non-negotiable for protecting open rates and inbox placement.

Common SPF Failures and Troubleshooting

The most frequent SPF failures fall into four categories. Multiple SPF records: having two TXT records starting with “v=spf1” for the same domain causes an immediate PermError—merge them into one. Exceeding 10 lookups: count every include, a, mx, and redirect mechanism; use an SPF checker tool to validate. Missing authorized senders: if you add a new email service (marketing tool, transactional platform, or CRM add-on) without updating SPF, those emails fail authentication and may bounce or land in spam.

Forwarding failures are SPF’s inherent limitation. When an email is forwarded, the forwarding server’s IP replaces the original sender’s IP. Since the forwarder isn’t listed in your SPF record, the check fails. This is why DKIM—which survives forwarding—is essential alongside SPF. If you use email relay in Salesforce, ensure your relay server’s IP is included in your SPF record. For sudden deliverability drops, check SPF alignment first: use email header analysis to confirm SPF pass/fail status, verify your DNS record hasn’t been accidentally modified, and cross-reference with bounce reason codes that may indicate authentication failures.

SPF Monitoring with Native Salesforce Platforms

SPF is only effective when it’s continuously monitored—not just configured once. DNS records change when teams add new services, domain configurations shift during migrations, and third-party include lists evolve. Native Salesforce email platforms like MassMailer provide built-in authentication monitoring that tracks SPF, DKIM, and DMARC pass rates directly within your Salesforce dashboard, alongside campaign performance metrics. Instead of relying on external SPF checker tools and manual DNS audits, teams get real-time visibility into authentication health.

MassMailer automatically verifies domain authentication, alerts teams when SPF records are misconfigured or when new sending sources aren’t covered, and provides deliverability diagnostics that connect authentication status to email tracking data. For organizations scaling beyond Salesforce’s 5,000 daily email limit, MassMailer’s dedicated IP addresses and automated warm-up further depend on solid SPF configuration—because inbox providers evaluate authentication pass rates as a core component of sender reputation scoring.

Is your SPF record silently breaking every time you add a new sending service? MassMailer monitors SPF, DKIM, and DMARC authentication in real time, catches misconfigurations before they impact deliverability, and keeps your Salesforce emails trusted by every inbox provider. Install MassMailer free for 15 days and protect your sender reputation today →

Key Takeaways

  • SPF publishes a DNS TXT record listing every server authorized to send email for your domain—recipient servers check this list before delivering your messages.
  • For Salesforce, add include:_spf.salesforce.com to your existing SPF record; never create multiple SPF records for the same domain or authentication breaks entirely.
  • The 10 DNS lookup limit is the most common SPF misconfiguration; exceeding it causes a PermError that disables SPF for all emails from your domain.
  • SPF checks the envelope-from address, not the visible From header—Salesforce’s default return-path means SPF alone won’t satisfy DMARC alignment without DKIM.
  • SPF fails when emails are forwarded because the forwarding server’s IP isn’t in your record—this is why DKIM (which survives forwarding) is essential alongside SPF.
  • Gmail and Yahoo require SPF, DKIM, and DMARC for all bulk senders—missing any one protocol degrades deliverability and increases spam filtering risk.