You sent the email from Salesforce. The copy was solid. The offer made sense. Then nothing happened.
That usually isn't a messaging problem. It's a trust problem. Mailbox providers don't care how polished your email looks if your domain hasn't clearly told them Salesforce is allowed to send on its behalf.
A salesforce spf record is one of those boring technical details that decides whether your email gets treated like a legitimate business message or like something that deserves the spam folder. If you're using Salesforce for outbound sales, notifications, or operational sends, you need this right before you obsess over subject lines, reply rates, or sequences.
Why Your Salesforce Emails Are Landing in Spam
Many organizations identify this issue in reverse. They observe low engagement, several spam complaints, or feedback from prospects stating, “your email went to junk.” Consequently, they begin revising templates while the underlying problem resides in DNS.
SPF is one of the first trust checks mailbox providers run. It tells receiving servers which systems are allowed to send mail for your domain. If Salesforce isn't authorized there, your message can look impersonated even when it's completely legitimate.
Why this matters more now
Salesforce isn't some niche sender. As of 2026, BuiltWith data shows 117,386 live websites use a Salesforce SPF record, and the United States accounts for 47.6% of those implementations according to BuiltWith's Salesforce SPF usage data. That scale tells you two things. First, mailbox providers see Salesforce traffic constantly. Second, your setup needs to match what trusted senders are already doing.
Google and Yahoo also raised the floor for authentication. If your setup is sloppy, you don't just get weaker placement. You risk rejection.
Practical rule: If your Salesforce email isn't authenticated, inbox providers won't give your content the benefit of the doubt.
What SPF actually does
Think of DNS like the guest list at the door of a private event. Your domain is the host. SPF is the list that says which mail servers are allowed inside wearing your company name.
If Salesforce isn't on that list, the receiving server sees a mismatch:
- Your From domain says one thing
- The sending infrastructure says another
- The mailbox provider assumes risk
That's why authentication comes before optimization. Before changing sequences, check the technical basics and review the reasons emails bypass the inbox. If you want a fast reality check, run a spam test on the MailGenius homepage and see what your current setup is signaling before you touch DNS.
Decoding the Correct Salesforce SPF Record For You
A lot of bad advice on this topic starts with “just add Salesforce to SPF” and stops there. That's how people end up pasting random record fragments into DNS and breaking mail for the rest of their stack.
The core Salesforce include typically required is include:_spf.salesforce.com. Salesforce has recommended that approach since at least 2014, and it became far more important after the February 2024 Google and Yahoo requirements that call for SPF or DKIM for all senders. Salesforce's own documentation also makes the risk plain: non-compliant mail can be rejected by major providers, as noted in Salesforce's SPF setup guidance.
What the record parts mean
Here's the plain-English version of a basic SPF record:
v=spf1means “this is an SPF record”include:means “also trust the systems listed in this other SPF definition”~allmeans “anything not listed should be treated as a soft fail”
This is not magic. It's just an authorization list.
SPF doesn't prove your email is good. It proves the sender had permission to use the domain.
The product confusion that trips people up
Many admins search for “salesforce spf record” as if every Salesforce product uses the same pattern. That's where confusion starts.
Sales Cloud and Service Cloud commonly use the standard Salesforce include in the domain's SPF record.
Marketing Cloud and Pardot often involve a different setup philosophy, usually with a dedicated sending subdomain and platform-specific authentication requirements. In those environments, blindly dropping the core Salesforce include into your root-domain SPF can be the wrong move or only a partial move.
Salesforce SPF Record by Product
| Salesforce Product | Typical SPF Value to Include | Common Scenario |
|---|---|---|
| Sales Cloud | include:_spf.salesforce.com |
Users sending one-to-one or workflow-based email from Salesforce under the company domain |
| Service Cloud | include:_spf.salesforce.com |
Support or case-related outbound email where Salesforce is sending on behalf of the business domain |
| Marketing Cloud | Varies by sending domain setup | Dedicated sending subdomain with platform-managed authentication requirements |
| Pardot | Varies by account and domain structure | Marketing automation tied to a sending subdomain, often separate from core corporate mail |
What works and what doesn't
What works is identifying which Salesforce product is sending mail and then matching DNS to that use case.
What doesn't work:
- Copying forum snippets without knowing your product
- Using the root domain for everything when marketing mail should live on a subdomain
- Assuming one Salesforce include covers every Salesforce tool
If you're in Sales Cloud, the standard include is usually the right starting point. If you're in Marketing Cloud or Pardot, slow down and confirm the sending domain model first.
How to Add Your Salesforce SPF Record Without Breaking Anything
The rule that gets ignored most often is simple. You can have only one SPF record for a domain. Not one for Google Workspace, one for Salesforce, one for Mailchimp, and one for whatever sales tool got added last quarter. One.
That means you don't “add another SPF record” for Salesforce. You merge Salesforce into the SPF record you already have.
Start with what already exists
Open your DNS provider. That might be Cloudflare, GoDaddy, Squarespace, Namecheap, or your registrar's DNS panel. Look for a TXT record on the root domain, often shown as @.
You're looking for the existing SPF line, usually something that starts with v=spf1.
If you already have one, edit it. If you don't, create one. But don't publish two TXT records that both claim to be SPF.
A safe way to think about the merge
Let's say your company already sends through Google Workspace and now also sends from Salesforce. Your SPF record needs to authorize both inside the same TXT entry.
That means the healthy end result looks like a single combined policy, not separate pieces scattered across DNS.
A practical workflow looks like this:
- Find the current SPF TXT record before changing anything
- Identify every real sender that uses your domain, not just Salesforce
- Insert the Salesforce include into the same record
- Save and validate after the DNS change publishes
The fastest way to wreck deliverability is to let three departments each publish their own SPF record.
What admins usually miss in DNS panels
Different DNS interfaces use different labels, which confuses people for no good reason.
- Host or Name field: usually
@for the root domain - Type: TXT
- Value: your single merged SPF string
- TTL: default is usually fine
If you want broader context on how SPF fits with the rest of authentication, this comprehensive guide to email deliverability audits helps connect the DNS work to actual inbox placement.
A walkthrough can also help if you're more visual:
The right mindset
Don't treat SPF like a checklist item. Treat it like a routing control for trust. Every sender you authorize should be there because it sends mail for your domain today.
Old vendors, abandoned tools, and duplicate includes create clutter. Clutter in SPF turns into failure later.
The Hidden Pitfall That Voids Your SPF Record
This is the part most guides skip because it's inconvenient. You can build what looks like a correct salesforce spf record and still fail authentication.
The reason is the 10 DNS lookup limit.
SPF doesn't just read one line and call it a day. Every time your record references other systems through mechanisms like includes, the receiving server has to go fetch those definitions. If the total lookup count goes over the protocol limit, SPF can return a permerror. At that point, the record isn't helping you. It's undermining you.
Why the lookup limit matters
Think of SPF like giving a receptionist a call list. If the list says, “ask this person, then ask that person, then ask three more people,” eventually the process becomes too long to trust. SPF has that same hard stop.
Services stack up fast. Google Workspace adds lookups. So do Microsoft 365, Help Scout, Zendesk, HubSpot, and Salesforce. One include doesn't look dangerous until five teams each add one more platform.
According to MassMailer's breakdown of Salesforce SPF issues, 15-20% of all SPF records exceed the 10-lookup limit, and that rises to 30% for companies using multiple email service providers. The same source says MailGenius audits found 40% of tested Salesforce domains failed because of this issue, with inbox rates dropping by up to 20%.
Signs you're dealing with a lookup problem
You don't need to be a DNS engineer to spot the pattern. Watch for these clues:
- Authentication passes inconsistently: one provider accepts the mail, another marks it suspicious
- You recently added another sending platform: deliverability slips right after that change
- Your SPF record looks crowded: multiple includes, extra mechanisms, and old vendors still present
If your SPF record reads like a vendor graveyard, the lookup limit is probably closer than you think.
What usually fixes it
The answer isn't “add more.” It's cleanup.
- Remove senders you no longer use: old ESPs shouldn't stay in SPF forever
- Consolidate where possible: fewer sending systems means fewer lookups
- Flatten carefully if needed: some teams use SPF flattening services when records get too complex
- Audit after every change: one new tool can push a stable record over the edge
A professional setup isn't the one with the most includes. It's the one that authorizes exactly what's needed and nothing extra.
How to Test and Verify Your Salesforce SPF Setup
Publishing the record is only half the job. DNS can look correct in your admin panel and still fail in practical application because of syntax mistakes, propagation issues, or a hidden conflict elsewhere.
The easiest way to confirm the fix is to send a real email from Salesforce and inspect what receiving systems see. That means testing the actual sending path, not just staring at your DNS screen and hoping for the best.
The practical check
A complete deliverability test gives you more than “SPF exists.” It tells you whether the message authenticated in transit and whether other issues are still dragging you toward spam.
One option is to use an SPF and DKIM checker to validate the authentication layer directly. For a wider deliverability test, send a message from Salesforce to the test address shown on the MailGenius homepage. That gives you a report on SPF, plus other technical and content signals that affect inbox placement.
The manual Gmail method
If you want a quick hands-on check, send a test email from Salesforce to a Gmail inbox and inspect the original message details. You're looking for authentication results in the headers.
Focus on:
- SPF result: you want to see
spf=pass - DKIM result: if configured, you want
dkim=pass - Alignment clues: confirm the authenticated domains match how you're presenting the sender
What to do if it still fails
If SPF doesn't pass, don't jump straight into rewriting the record from scratch. Work the problem in order:
- Check for multiple SPF records
- Review whether Salesforce was merged into the existing record
- Count the lookup load if several sending tools are involved
- Send another test after DNS updates settle
A passing SPF record in theory isn't enough. You want a passing SPF result on a real email sent from your Salesforce account.
That final verification is where many teams catch the mistake they were sure they didn't make.
Beyond SPF Your Next Steps for Flawless Delivery
SPF is the front door check. It matters, but it isn't the whole house.
For stronger protection, pair it with DKIM and DMARC. DKIM adds a cryptographic signature so receiving servers can verify the message wasn't altered. DMARC tells mailbox providers what policy to apply when authentication fails and helps you monitor misuse of your domain.
A simple way to explain the trio is this:
- SPF is the approved sender list
- DKIM is the tamper seal
- DMARC is the enforcement policy
If you're serious about inbox placement, don't stop at the salesforce spf record. Get the full authentication stack aligned, then keep it maintained as your tools change. Most deliverability problems aren't caused by one massive failure. They're caused by small technical cracks that go unnoticed until mailbox providers stop trusting you.
Run a free spam test at MailGenius before you send your next Salesforce campaign. It shows how mailbox providers evaluate your message, flags authentication issues like SPF problems, and gives you a clearer picture of what needs fixing to land in the inbox.