Salesforce Emails Going to Spam: What to Fix

Do not index

Salesforce is usually sending as the company domain without an aligned DKIM signature, so DMARC fails while the same message from Gmail or Outlook passes. The practical fix starts with comparing the headers of a Salesforce send and a mailbox send, then activating the company-domain DKIM key on the sending path that failed.

A sales representative sends a follow-up from Salesforce, gets no reply, and assumes the buyer has gone quiet. Meanwhile, the same note sent directly from the representative's mailbox reaches the inbox. Before anyone rewrites the sequence or changes DNS, the administrator needs to establish which server transmitted each message.

Table of Contents

Why does Salesforce email go to spam when Outlook works?How each Salesforce CRM path authenticates Separate transmission from placement What do we check first on both messages?Read the evidence in diagnostic order Header results on the mailbox send versus Salesforce How do you align DKIM and DMARC, and which Salesforce settings must match?Create, activate, and retest the company key Salesforce settings that must match the sending path What still filters mail once authentication passes?Apply provider rules to the affected stream Keep separate products in scope Which mistakes keep mail in spam after a partial fix?Stop treating partial evidence as a finished repair Keep the operational signals visible What do teams ask after the DKIM fix?Should Bounce Management be turned off?Is Email Relay safer than a direct send?How fast do sales emails recover?When should you bring in a deliverability expert?Establish ownership beyond the incident

Why does Salesforce email go to spam when Outlook works?

Salesforce and Outlook can display the same From address while using different mail servers and authenticated identities. The message text hasn't changed, but the evidence available to the receiving server has.

A common failure is a Salesforce message signed for a Salesforce domain rather than the company domain the buyer sees. That signature can pass DKIM without satisfying DMARC alignment. However, a missing company-domain signature doesn't automatically mean DMARC fails: an aligned SPF pass can also satisfy DMARC.

How each Salesforce CRM path authenticates

Identify the sending route before changing authentication records.

Path	Who transmits	What usually aligns	Typical spam cause
Salesforce direct send	Salesforce mail servers	Active company-domain DKIM; SPF must authorize the actual sending infrastructure	No active company DKIM and no aligned SPF identity
Email Relay	Company mail server	Relay preserves the From address and an aligned SPF or DKIM identity	Header rewriting breaks authentication, or relay security checks prevent transmission
Gmail or Outlook integration	The user's mailbox, when sending through the connected account	Authentication used by normal mailbox mail	If this path passes, investigate the different Salesforce route rather than assuming a content problem

An integration interface isn't proof of the sending route. Logging mailbox activity in Salesforce and transmitting through the connected mailbox are different operations. The received headers settle which happened.

Salesforce's email security guidance distinguishes direct sending from Email Relay and documents relay controls involving TLS, certificate and hostname validation, domain checks, the X-SFDC-LK organization identifier, and DKIM verification. If only relayed messages fail, inspect those controls and any rewriting on the company server.

Separate transmission from placement

A successful Salesforce send or downstream server acceptance doesn't establish inbox placement. The recipient's provider can accept the message and then place it in spam. Conversely, a relay connection failure prevents delivery rather than merely changing the folder.

For a broader explanation of the receiving side, Networking2000's guide to email deliverability provides useful context alongside the Salesforce-specific investigation.

Start with matched Salesforce and mailbox tests to the same controlled inbox. Salesforce Help should supply the current Setup paths, because menu locations and available controls can change.

What do we check first on both messages?

The first useful evidence is the full received message, not its activity entry in Salesforce. Preserve both originals so an administrator can compare the sending hosts, authentication results, and bounce identities without relying on screenshots of the message body.

Use a short, identical note and the same visible From address where possible. Keep attachments and tracking differences out of the initial comparison so the sending path remains the main variable.

Read the evidence in diagnostic order

Send the matched notes. Use Salesforce and the representative's normal mailbox to reach the same controlled destination. Record whether each lands in the inbox, spam, or nowhere.

Open the full headers. Inspect the received original rather than the Salesforce status or a forwarded copy.

Identify the transmitting server. Read the Received chain alongside the receiver's authentication results. Establish whether Salesforce, the company relay, or the mailbox provider handed over the message.

Read SPF with its domain. In Authentication-Results, inspect spf= and smtp.mailfrom. A pass establishes authorization for that identity, not necessarily alignment with the visible From.

Read the DKIM signing domain. Inspect dkim= and the signature's d= value. A valid signature for an unrelated platform domain doesn't authenticate the company's visible identity for DMARC.

Check the DMARC result. Look for dmarc= and header.from. Determine whether either passing mechanism aligns with that domain.

Choose the correction. If only the Salesforce route fails, correct that route's authentication or evaluate a properly configured relay. Template edits won't repair an identity mismatch.

Header results on the mailbox send versus Salesforce

The following is a diagnostic example, not a claim that every Salesforce message has these results.

Check	Mailbox send that reaches the inbox	Broken Salesforce direct send	What it means
Sending host	Google, Microsoft, or company mail server	Salesforce mail server	Establishes the transmitting route
SPF	Pass with an aligned identity	Pass for an unrelated Salesforce identity, or fail	SPF won't satisfy DMARC unless it passes and aligns
DKIM `d=`	Company domain	Salesforce signing domain	The passing signature doesn't align with the buyer-visible domain
DMARC	Pass	Fail	Neither authentication mechanism supplies an aligned pass
Return-Path	Company or otherwise aligned domain	Salesforce bounce domain	Identifies bounce handling and helps explain SPF alignment

Don't use open rates to resolve this comparison. Privacy behavior and filtering make opens an unreliable substitute for header evidence.

If the message never arrives, retain the complete bounce or deferral response, including its status code, diagnostic text, destination provider, and timestamp. A temporary deferral and a permanent policy rejection require different actions; the guide to why emails are being blocked helps frame that investigation.

After the matched-message test, expand the review to other domains, automated sends, and recipient providers using an email deliverability audit checklist. Otherwise, fixing a representative's manual send can leave service alerts on a broken route.

How do you align DKIM and DMARC, and which Salesforce settings must match?

A company-domain DKIM key that exists but isn't active doesn't solve the problem. The useful endpoint is a newly received Salesforce message with a passing, aligned signature, not a completed configuration screen.

Verify that the DKIM signing domain aligns with the visible From domain and that SPF authorizes the actual Salesforce sending route. The free DKIM checker from our sister tool mailX helps inspect the published key, but received-message headers remain necessary to prove Salesforce used it.

Create, activate, and retest the company key

The Salesforce administrator should create the DKIM key for the domain used in the From address, following the current Salesforce Help instructions. The DNS owner then publishes the records Salesforce provides, without substituting records from another product or sending domain.

Once those records resolve, activate the key in Salesforce. Then send a fresh message rather than replying in an existing thread, which can obscure which message supplied the authentication evidence.

The receiving server's results should show the expected signing domain, a passing signature, and a DMARC pass. If the result still names an unrelated signing domain, check the actual From address, key activation, and route before making further DNS changes.

Salesforce's DMARC guidance states that at least one of SPF or DKIM must pass and align with the visible From domain, and recommends DKIM as the preferred alignment method. Both mechanisms don't have to align for DMARC to pass.

SPF authorization still deserves review. Include Salesforce in the existing authorization where the actual sending identity requires it, but don't assume that authorizing Salesforce makes its bounce domain align with the company From address. That distinction prevents a technically valid SPF change from being mistaken for a completed fix.

Salesforce settings that must match the sending path

Setting	What it controls	What breaks if wrong
DKIM key for the company domain	The domain used for the configured signature	Without an aligned signature, DMARC must rely on aligned SPF
SPF authorization for Salesforce	Which servers may send for the SPF identity	Unauthorized infrastructure fails SPF; authorization alone doesn't establish alignment
Email Relay routing	Whether Salesforce hands mail to the company server	Rewriting can break authentication; TLS or hostname failures can stop transmission
Bounce Management	How returns and invalid-address feedback are processed	Disabling it can remove bounce-handling information the team needs
Enable compliance with standard email security mechanisms	Salesforce's documented email-security handling	Changing it outside the documented fallback can alter the intended sending behavior
Email deliverability access level	Which categories of outbound email the organization permits	A restrictive level can prevent sends; a broad level isn't an inbox-placement fix

Access to Send Email is a permission gate, not a reputation control. Check whether the organization permits the intended email category before investigating missing messages. Don't change the access level merely because an already-received message landed in spam.

Likewise, the setting sometimes described as sender ID or email-security compliance isn't a universal spam switch. Administrators should use its exact current label in Salesforce Help and change it only for the documented sending configuration.

The broader email authentication review should include every legitimate sender using the company domain. Otherwise, a CRM repair can leave another application generating failures under the same visible identity.

Keep the change record with the fresh headers and the responsible DNS and Salesforce owners. Without that evidence, a later relay change or new sending domain can recreate the same fault while the team assumes authentication is already finished.

What still filters mail once authentication passes?

A Salesforce message can pass authentication and still land in spam because providers also assess complaints, bounces, engagement, and sending patterns. A sales follow-up to an active contact may perform differently from bulk outreach to an old prospect list, even when both use the same correctly configured domain.

Apply provider rules to the affected stream

Google's sender policy sets bulk-sender requirements from February 2024 for senders delivering at least 5,000 messages daily to Gmail accounts, including authentication and unsubscribe requirements. The policy advises keeping daily user-reported spam below 0.1%. It also says senders should prevent the rate from reaching 0.3% or higher. For bulk senders at or above that higher threshold, mitigation eligibility requires a spam rate below it for seven consecutive days. These are Gmail-specific operational limits; other providers may assess messages differently.

Compare provider results separately. A successful Gmail test does not explain a Microsoft 365 rejection, and a message reaching one mailbox does not establish that a larger Salesforce audience is healthy.

Use audience definitions that reflect how recipients obtained the message and whether they still engage:

Active customer conversations: Recipients with an ongoing sales or service relationship. Keep these messages separate from unnecessary campaign-volume changes.

Permission-based marketing: Recipients who requested marketing and can unsubscribe. Review consent and complaints alongside campaign results.

Inactive or uncertain-source contacts: Addresses without recent meaningful interaction or clear acquisition records. Reduce or pause distribution while investigating the source.

Invalid or complaining recipients: Suppress them from further applicable campaigns so another automation does not reintroduce them.

The CloudOrbis spam filtering guide provides recipient-side context for teams coordinating with customer IT departments. Individual recipient exceptions do not address reputation problems affecting the sender more broadly.

Keep separate products in scope

Marketing Cloud Engagement and Account Engagement have separate sending configurations and reporting. A Salesforce CRM DKIM key doesn't automatically authenticate those systems. Review the sending domain, complaints, and volume plan for each affected product.

Inspect content as well as the sending path. A spam words checker can flag wording for editorial review. Check whether the offer is clear and relevant, and whether the audience expects the message. Unwanted mail can put the domain used for legitimate sales and support conversations at risk.

Which mistakes keep mail in spam after a partial fix?

Common mistakes usually involve declaring success too early. A published key, a passing platform signature, or an accepted SMTP transaction answers only part of the delivery question.

Salesforce's deliverability guidance recommends evaluating metrics every three to six months, removing recipients who complain, checking data quality, and reviewing spam-like content. That routine review interval isn't an incident-response schedule.

Stop treating partial evidence as a finished repair

Authenticating the wrong identity: A platform-domain pass doesn't prove the company From address is aligned. Validate the key against the live sender rather than the product name.

Using an allowlist instead of fixing the sender: Salesforce warns that incomplete or outdated allowlists can block its mail. Recipient exceptions also leave everyone outside that exception exposed to the original problem.

Testing through a forwarding address: Forwarding can change authentication outcomes. Use a directly controlled destination first, then investigate forwarding as a separate route.

Trusting sent counts or opens: Neither establishes inbox placement. Retain provider responses, received headers, and actual folder observations.

Restoring the full audience immediately: A corrected signature doesn't repair stale addresses or recipient objections. Reintroducing risky segments can continue the complaints that caused filtering.

Keep the operational signals visible

In Marketing Cloud Engagement, the Complaint Data View supports complaint investigation; other Salesforce products expose their own relevant reporting. Review complaints, hard bounces, and unsubscribes together, and make suppression changes before the next affected campaign.

Don't substitute an email warmup discussion for an unresolved alignment failure or unwanted sending. Increasing activity without fixing those causes exposes more recipients to the same fault.

That approach protects healthy service and sales streams while the affected campaign is repaired. Broad, simultaneous changes make it harder to identify what worked and can create new support tickets.

What do teams ask after the DKIM fix?

Should Bounce Management be turned off?

Use the SPF-alignment alternative only when DKIM cannot be configured and the Salesforce administrator follows Salesforce's documented requirements, including disabling Enable compliance with standard email security mechanisms. If DKIM is available, an active company-domain key avoids relying on that fallback and keeps the intended bounce-handling workflow in place. These settings address alignment and bounce processing; they do not determine whether a message reaches the inbox.

Is Email Relay safer than a direct send?

Choose the route by comparing a Salesforce message with a mailbox-sent message delivered to the same inbox. In the received headers, check the sending IP, the SPF result and its domain, the DKIM signature and signing domain, and the DMARC result and alignment. Also compare the visible From address and any evidence that an intermediary changed the message or signature. Those fields show which path produced the failure. A relay is useful only if its headers and authentication match the intended setup; direct sending depends on the Salesforce path passing those checks.

How fast do sales emails recover?

There is no universal recovery deadline. If the fault was limited to authentication, new messages using the corrected route may pass those checks, while providers can still filter by reputation and recipient behavior. For bulk mail, review complaints, invalid recipients, and engagement before expanding sends. A clean test confirms that the configuration works for that message and inbox. It does not establish that every buyer will receive future mail.

When should you bring in a deliverability expert?

Bring in a deliverability expert when repeated incidents cannot be traced to one change in Salesforce. Ambiguous relay behavior or provider-specific blocks often require coordination across Salesforce, DNS, mailbox administration, and recipient selection.

Escalation makes sense when:

Authentication remains inconsistent: Active keys produce different outcomes across users, From domains, or automated sends.

A migration is approaching: Relay, domain, or platform changes need a documented baseline and rollback plan.

Providers defer or reject mail: The team must distinguish rate controls, authentication faults, recipient policy, and reputation restrictions.

Ownership is fragmented: No one oversees how audience choices, DNS, Salesforce settings, and provider feedback interact.

Bulk campaigns affect essential communication: Sales and service messages share an identity with a stream generating complaints.

Establish ownership beyond the incident

A useful diagnosis compares one Salesforce send with one message sent from a mailbox to the same inbox. Check the received headers, then match the company's DKIM key and Salesforce settings to the path that failed. This separates a Salesforce routing or identity issue from broader reputation and recipient problems.

MailAdept embeds a dedicated deliverability expert in the customer's team to audit the setup, address inbox-placement issues, and monitor sending domains, with 12+ daily checks per domain and a weekly expert review. Calls with experts are included in every plan. The client remains responsible for recipients, sending behavior, content, and legal compliance.

Treat Salesforce spam placement as a sending-path investigation. Match the route to the company identity, then confirm the result with a fresh received message. Keep bulk campaigns and Salesforce sending products aligned with their own audiences and reputation signals.

MailAdept offers a free deliverability audit to assess authentication, relay behavior, and sender reputation. Visit MailAdept to get a second review of the setup and its message headers.