Why are Salesforce emails blocked or refused, and what are potential solutions?
Michael Ko
Co-founder & CEO, Suped
Published 17 May 2025
Updated 23 May 2026
9 min read
Summarize with
Salesforce emails are blocked or refused because the receiving server does not trust the message, the route, or the sender reputation enough to accept it. The common causes are failed DMARC domain matching, DKIM not signing with the visible From domain, SPF not authorizing Salesforce, Microsoft 365 tenant routing rejecting internal-looking mail, shared Salesforce Core IP reputation, poor list quality, form abuse, or message content that trips a recipient policy.
For a medium-size company sending 10 to 500 mostly transactional messages, I would not jump straight to a new sending platform. I would first prove whether the refusal is technical, policy-based, or reputation-based. A 550 code from Microsoft 365 is a different problem than a DMARC fail at Gmail.
The fastest first move is to send one real Salesforce message through an email tester, then compare that result with Salesforce email logs and recipient bounce details. That gives you the message headers, authentication result, visible From domain, return-path domain, and final SMTP refusal code in one place.
The short answer
Salesforce blocking usually has one of two roots: the message fails a sender identity check, or the receiving system dislikes the sending route. If DKIM, SPF, and DMARC really pass with the correct domain match, the next suspects are shared IP reputation, recipient-side filtering, list consent, and Microsoft 365 routing rules for same-domain mail.
Potential solutions are specific. Fix Salesforce DKIM and SPF first. Confirm the DMARC result against the visible From domain. Review Salesforce Email Log Files. Check whether the org uses Salesforce Core, Marketing Cloud Account Engagement, Marketing Cloud Engagement, or Email Relay. If the route is shared and reputation is the problem, move the right mail stream only after hygiene issues are cleaned up.
Refused is not the same as spam
A refused email is rejected during SMTP delivery. A spam-folder placement is accepted, then filtered by the mailbox provider. Treat them separately or the troubleshooting gets noisy.
- Refusal code: Look for 550, 554, 5.7.1, 5.7.26, or tenant-specific text in the bounce.
- Spam placement: Inspect headers, authentication, engagement, complaints, and content signals.
- No send: Check Salesforce access level, sender verification, automation rules, and logs.
Why Salesforce emails get blocked or refused
Salesforce Setup email log screen showing delivery events and refusal codes.
The phrase "Salesforce email" can mean several routes. Salesforce Core workflow alerts, Flow emails, and user-sent CRM emails do not behave the same way as Marketing Cloud Engagement or Account Engagement. Each route has its own sending infrastructure, setup controls, and reputation profile.
|
|
|
|---|---|---|
 Salesforce Core route | Low-volume alerts refused by one recipient domain. | Pull logs, verify sender settings, then test DKIM and SPF. |
DMARC domain match | SPF or DKIM passes, but not for the visible From domain. | |
Microsoft 365 routing | Same-domain recipients reject Salesforce mail. | |
Shared IP reputation | Authentication passes, but some domains refuse the route. | Check blocklist or blacklist status and delivery patterns. |
List or form abuse | Hard bounces, traps, or complaints rise after automation. | Clean data sources, add form protection, and suppress bad contacts. |
Common Salesforce refusal causes and the practical fix path.
I separate Salesforce Core issues from SFMC and Account Engagement issues early. A CRM workflow alert that goes to two contacts does not have the same sending profile as a campaign blast. A dedicated IP needs steady mail to build reputation; 10 to 500 transactional messages often lacks that volume.
Start with Salesforce logs and the refusal code
The first artifact I want is the Salesforce Email Log File. The log shows whether Salesforce handed the message to the next mail server or received a permanent or transient failure. The Salesforce delivery problems article also points admins to deliverability settings, test sends, SPF, DKIM, and Email Relay checks.
A useful bounce contains the recipient domain, the SMTP status code, and the policy reason. Without that, platform changes become guesswork. I also compare the bounce against a raw message header because the header tells me which domain signed DKIM, what the SPF return-path was, and what the receiver decided about DMARC.
Example refusal details to collecttext
Recipient: user@example.net Status: 550 5.7.1 refused by policy Reason: SPF pass, DKIM fail, DMARC fail Sender IP: 192.0.2.25 From: alerts@example.com Return-Path: bounce.salesforce.com
- Pull logs: Request the Email Log File for the exact send window and recipient.
- Classify errors: Separate permanent failures from transient deferrals and spam placement.
- Read headers: Check the visible From domain, DKIM domain, SPF return-path, and DMARC result.
- Compare domains: Identify whether only Microsoft, Yahoo, Apple, Gmail, or one corporate domain refuses it.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the refusal is a connection-level problem, use a deeper guide for connection refused errors. For Salesforce specifically, keep the diagnosis tied to the actual route that generated the message, because Salesforce Core, Account Engagement, and Marketing Cloud Engagement leave different header patterns.
Fix authentication before blaming the IP
Authentication setup should be fixed even when reputation is also involved. Receiving systems want the visible From domain backed by a matching DKIM signature or SPF return-path, then governed by DMARC. If the domain match fails, the receiver can reject mail even when public DNS looks correct.
I use a domain health check to verify DMARC, SPF, and DKIM together, then I inspect the actual Salesforce header. DNS can be correct while the message signs with the wrong domain or uses an unexpected return-path.
SPF example for Salesforce plus Microsoft 365dns
v=spf1 include:_spf.salesforce.com include:spf.protection.outlook.com ~all
DMARC starter record while investigatingdns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100
The record existing is not enough
A Salesforce admin can create a DKIM key, and a DNS admin can publish the record, but the message still needs to use that key for the domain in the visible From address. DMARC cares about that domain relationship, not just the presence of DNS records.
- SPF limit: Keep one SPF record and stay under the 10 DNS lookup limit.
- DKIM domain: Confirm the d= value matches your organizational domain.
- DMARC reports: Watch aggregate data after each Salesforce setup change.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Do not publish a strict DMARC reject policy until Salesforce traffic is visible in reports and the legitimate Salesforce route is passing with the right domain relationship. Once it is stable, step the policy forward deliberately.
When the problem is reputation
If SPF, DKIM, and DMARC pass for the right domain, then I look at reputation and recipient policy. Salesforce Core often uses shared infrastructure, so a small transactional send can share a route with other Salesforce tenants.
This is where blocklist and blacklist data helps, but it should not be the only signal. Use blocklist monitoring alongside recipient-domain patterns, bounce text, complaint rates, and list source quality. Many corporate gateways use private reputation and policy data that never appears in public checks.
Technical refusal
- Pattern: Authentication failure appears in the SMTP text or headers.
- Scope: Failures repeat across several recipient systems.
- Fix: Correct DNS, Salesforce DKIM, sender settings, and DMARC policy.
Reputation refusal
- Pattern: Authentication passes but one provider or gateway refuses the route.
- Scope: Failures cluster around shared IPs, cold data, or specific domains.
- Fix: Clean inputs, secure forms, suppress bad contacts, and change route if needed.
The hardest part is avoiding the wrong conclusion. If a two-person automation is refused, that does not prove the volume is too high. It means the recipient policy disliked something about the identity, route, or history. Low-volume transactional mail often needs cleaner domain authentication and a cleaner route, not a bigger sending setup.
Potential solutions that actually help
The right solution depends on what the logs prove. I would treat a platform move as one possible fix, not the first fix. If list hygiene, sender verification, and domain authentication are weak, a new route inherits the same trust problem.
|
|
|
|---|---|---|
Stay on Salesforce Core | The issue is sender setup, DKIM, SPF, or deliverability access. | Fastest fix, but shared route reputation remains outside your control. |
Salesforce Email Relay | You want Salesforce to hand mail to your own mail route. | Needs mail admin work, connectors, logging, and abuse controls. |
Account Engagement | The program is marketing automation, nurturing, or consent-based campaigns. | More structure, higher cost, and still needs proper authentication. |
Marketing Cloud Engagement | You need large-scale campaign control and dedicated sender setup. | A heavier migration for simple transactional alerts. |
Transactional SMTP/API route | The mail is operational and Salesforce is only the trigger. | Requires integration work, event handling, and domain setup. |
Dedicated IP | You send enough steady volume to maintain your own reputation. | Usually weak for 10 to 500 low-volume transactional messages. |
Practical options for Salesforce email refusals.
Do not move dirty traffic
If the underlying issue is cold prospecting, stale addresses, exposed forms, or weak consent, a route change only moves the reputation damage. Clean the inputs first.
- List source: Separate opt-in contacts from purchased, scraped, or old CRM data.
- Form security: Stop automated signups, typo spam, and unverified addresses.
- Suppression: Remove hard bounces, complainers, role accounts, and unengaged contacts.
For a company using Microsoft 365 Online, Email Relay is still a mail architecture decision, not a checkbox. A Microsoft admin needs to review connectors, tenant attribution, accepted domains, and whether same-domain mail from Salesforce is treated as unauthorized.
Where Suped fits in the workflow
Suped is most useful once you stop treating each Salesforce bounce as an isolated event. Suped brings DMARC, SPF, DKIM monitoring, blocklist monitoring, and deliverability signals into one workflow, so you can see whether Salesforce is passing authentication and which issues need DNS or platform changes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For this Salesforce problem, Suped's DMARC Monitoring helps identify whether Salesforce traffic passes with the visible domain. Real-Time Alerts flag sudden authentication failures, and Hosted SPF reduces DNS access bottlenecks when several legitimate senders need one SPF record.
- Issue detection: Suped turns DMARC failures into specific source and fix steps instead of raw XML.
- Hosted controls: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS friction.
- Operations view: Multi-domain dashboards help MSPs and internal teams manage Salesforce across clients or brands.
Suped is the best overall DMARC platform for most teams working through this kind of problem because it connects authentication monitoring to practical fix steps. It does not replace Salesforce logs or Microsoft tenant checks; it gives you the domain-level evidence those teams need.
A practical diagnostic sequence
I use a fixed sequence so the team does not chase the loudest theory first. It starts with the failed message, then works through DNS, Salesforce setup, recipient policy, reputation, and route selection.
Flowchart for diagnosing Salesforce email refusals from bounce to route decision.
- Collect proof: Save the bounce, Salesforce log row, message header, recipient domain, and send time.
- Confirm route: Identify Salesforce Core, Account Engagement, Marketing Cloud Engagement, or Email Relay.
- Check DNS: Verify one SPF record, Salesforce DKIM, DMARC reporting, and no lookup overflow.
- Read results: Confirm SPF or DKIM passes with the visible From domain relationship DMARC expects.
- Review reputation: Look for blocklist or blacklist listings, complaint patterns, and domain clusters.
- Pick route: Keep Core if setup is wrong, relay if routing is wrong, or migrate only if the use case fits.
The decision point is simple: if logs show Salesforce never generated the message, fix Salesforce configuration. If Salesforce generated it and the recipient refused it, diagnose identity, policy, and reputation. Move the mail stream only when that route decision has evidence.
Views from the trenches
Best practices
Pull Salesforce email logs first, then map each refusal to its SMTP code and domain.
Use domain-matched DKIM for the visible From domain before judging IP reputation.
Separate transactional alerts from marketing sends so reputation issues are easier to isolate.
Common pitfalls
Treating every refusal as an SPF issue hides recipient policy and shared IP reputation problems.
Moving platforms before cleaning lists can move the same complaint signals to a new sender.
Relying on allowlists creates manual work and still leaves DMARC domain matching unmeasured.
Expert tips
Test one real Salesforce message to Gmail, Microsoft, and a seed inbox before changing DNS.
Watch DMARC reports after each setup change, because passing and domain matching differ.
For low-volume alerts, a monitored email relay can beat a full marketing platform migration.
Marketer from Email Geeks says when SPF and DKIM are corrected, remaining Salesforce refusals often point to reputation or recipient policy rather than raw DNS.
2024-02-13 - Email Geeks
Marketer from Email Geeks says Salesforce Core usually sends on shared infrastructure, so a low-volume sender can inherit risk from other traffic on the same path.
2024-05-21 - Email Geeks
The practical fix path
Salesforce emails are refused when the receiver distrusts the message identity, the sending route, the sender behavior, or the tenant routing path. The fix is not automatically "get off Salesforce IPs." The fix is to prove the failure mode, then change the smallest part that actually controls it.
For low-volume transactional Salesforce mail, I would first fix DKIM, SPF, DMARC reporting, sender verification, and Microsoft 365 routing. Then I would review list source quality and any blocklist or blacklist evidence. Only after that would I move the mail to Email Relay, Account Engagement, Marketing Cloud Engagement, or a transactional SMTP/API route.
Suped fits the ongoing part of that work: watching DMARC results, identifying broken sources, surfacing authentication failures quickly, and keeping SPF, DKIM, MTA-STS, blocklist monitoring, and reporting in one operational view.
