Home/Knowledge Hub/Salesforce Explained: Why Your Scan Found This CRM Giant
← Back to Knowledge Hub

Salesforce Explained: Why Your Scan Found This CRM Giant

DNS & Network·June 5, 2026·7 min read

Salesforce is a CRM platform that can send email from your domain. A TechSpy scan detects it via SPF records and website scripts.…

What Is Salesforce?

You ran a TechSpy scan on your domain, expecting to see DNS settings and maybe a few warnings. Then you saw something that stopped you: “Salesforce” flagged in the results. You don’t use Salesforce—or maybe you do, but you never thought of it as something that would show up in an email security report. Either way, now you’re here, trying to figure out what a customer relationship platform has to do with your email setup.

Salesforce is a cloud-based platform that helps businesses manage their relationships with customers. It’s not one tool, but a suite of modules that handle different parts of that relationship. The three most common are:

When any of those services send an email that looks like it came from your domain (e.g., @yourcompany.com), the internet needs a way to verify that Salesforce is allowed to do that. That permission lives in your domain’s SPF record, which is exactly where TechSpy looks. The scan also checks for Salesforce’s website tracking scripts, which is a separate signal that your company is using the platform.

  • Sales Cloud — where your sales team tracks leads, deals, and follow-ups. It can send automated emails directly to prospects and customers.
  • Service Cloud — where support agents log cases, manage tickets, and send status updates. Those update emails can also come from your domain.
  • Marketing Cloud — the engine behind newsletters, drip campaigns, and promotional emails. It often adds a tracking script to your website so you can see who opened what.

Real-World Analogy

Think of Salesforce as the back-office system of a hotel. Sales Cloud is the front desk booking reservations and confirming by email. Service Cloud is the concierge handling guest requests and sending reply confirmations. Marketing Cloud is the team sending out “stay with us again” offers, and they put a tracking pixel on the hotel’s website to see who clicked through. If one of those teams sends an email that says it’s from the hotel’s domain, the guest’s email provider checks the hotel’s “approved senders” list (the SPF record) to see if that team is allowed. If the list includes Salesforce, the email gets through.

How Salesforce Appears in Your Scan

Here’s what happens, step by step, in a way that doesn’t require you to understand a technical acronym:

1. Your company decides to use Salesforce (maybe years ago, maybe just last week).

2. Someone in IT—or a Salesforce consultant—adds a line of text to your domain’s DNS settings. That line is basically a guest list entry: “Salesforce’s email servers are allowed to send email pretending to be from us.”

3. At the same time, someone might embed a small piece of Salesforce’s code on your website. That code helps Marketing Cloud track who visits your site and opens your emails.

4. When you run a TechSpy scan, the tool checks your domain’s public DNS records and looks at your website’s code. If it finds that guest list entry or that tracking script, it flags “Salesforce” so you know it’s there.

This matters because if your company is actually using Salesforce to send emails, you need that guest list entry to be correct. If you’re no longer using Salesforce, leaving that entry in is like keeping an old contractor’s key card active—it’s a potential risk, and it’s clutter you don’t need.

Technical Details
SPF records: Salesforce’s email-sending services use two main mechanisms. For Sales Cloud and Service Cloud, you’ll typically see . For Marketing Cloud (formerly ExactTarget), the include is .
Website tracking: Marketing Cloud loads a script like or . TechSpy checks for known Salesforce domains in your site’s script sources.
Subdomain usage: Salesforce may handle bounces and tracking on subdomains like or , which require additional DNS records (CNAMEs) that your scan might also surface.
SPF record length: DNS has a 10-lookup limit for SPF. Each counts as a lookup, so adding Salesforce, Google, and others can cause limits to be hit, breaking email authentication.

Why It Matters for Your Business

When Salesforce is configured correctly, the emails your teams send through it land in customers’ inboxes instead of spam folders. That means follow-ups get read, support updates get seen, and marketing campaigns actually reach people. For a business that relies on repeat customers or sales pipelines, that’s the difference between a closed deal and a missed connection.

When the configuration is wrong—either missing the necessary SPF entry or keeping a stale one from a previous setup—problems start quietly. Emails might fail SPF checks, causing some inbox providers to reject them outright or flag them as suspicious. You might never know until a sales rep tells you, “The customer said they never got my email.” Meanwhile, an old Salesforce SPF include that should have been removed is technically a security loose end: it allows a third-party service you no longer control to send mail from your domain. In the unlikely event that a dormant Salesforce account gets compromised, an attacker could use that authorization to impersonate your brand.

This should catch the attention of more than just IT. Marketing teams need to know that their campaign deliverability depends on this record being accurate. Sales directors should care that automated outreach isn’t silently failing. Even executives should care because email is how critical business communication happens, and a misconfiguration can quietly damage sender reputation across all your email channels.

Common Issues and Warning Signs

When a Salesforce-related flag appears in your scan, the root cause is usually one of a few common scenarios. It might be a perfectly normal integration that you just never heard about, or it could be a forgotten setup from a past project. Here’s what those situations look like in practice.

Common Issues

You see an SPF include for Salesforce, but your team swears you don’t use it. This often means someone once connected a small part of Salesforce (like a trial or a single department’s Marketing Cloud), the project ended, and no one cleaned up the DNS.
Your Marketing Cloud emails from Salesforce go to spam, but you know the content is fine. The SPF record is probably missing the correct Marketing Cloud include, so receivers can’t authenticate the mail.
Your IT team mentions the SPF record is “too long” or “over the lookup limit.” This happens when your domain has SPF includes for multiple email providers (Google, Microsoft, Salesforce, SendGrid, etc.), and adding another could break authentication for all of them.
A support email from Service Cloud bounces with an “SPF fail” error. The include for Salesforce is present, but it might be the wrong one (e.g., using when Marketing Cloud needs ).
You find a Salesforce tracking script on your website, but the marketing team says they’ve switched to a different tool. The script is still collecting data and potentially conflicting with your current analytics.

How to Fix or Improve the Situation

Most fixes take a few minutes once you know who manages your DNS. The approach depends on whether your organization actually uses Salesforce today. The steps below walk you through both paths.

Need a complete picture? A TechSpy scan doesn’t just spot Salesforce—it checks your whole email setup for weak spots. Run it again after you make your changes, or forward the scan results to whoever manages your domain.

<!-- self-check: layer1_readable=true | fix_doable=true | no_padding=true | jargon_expanded=true -->

1Confirm whether your company currently uses any Salesforce email services. Ask your sales, service, and marketing managers: “Do we send any automated emails from Salesforce that use our company domain name?” If the answer is yes, go to step 2. If no, or if no one is sure, go to step 3.
2If you use Salesforce, verify your SPF record includes the correct entry. For Sales or Service Cloud emails, add to your existing SPF record. For Marketing Cloud emails (ExactTarget), also add . Do not remove your other email provider includes (like Google or Microsoft) unless you’re sure you don’t need them. If you don’t manage your own DNS, forward the exact names of these includes to your IT team or hosting provider and ask them to add them.
3If you don’t use Salesforce anymore, or the integration is abandoned, remove the corresponding statement from your SPF record. This eliminates an unnecessary authorization and can help keep your SPF record under the lookup limit. Again, hand this to your DNS manager if you don’t have direct access.
4For the website script: if Marketing Cloud is no longer active, ask your web developer to remove the script that calls the Salesforce domain (e.g., extinfer from or ). Be cautious not to remove other analytics scripts by mistake.
5After making changes, run another TechSpy scan to confirm the Salesforce flag clears (if you removed) or shows as correctly configured (if you added). This gives you confidence that the next email your team sends will pass authentication checks.

See how your domain's configuration stacks up.

Get a free scan — no sign-up, no credit card.

Scan Your Domain Free →