Why does SFMC show email as delivered when it's not in inbox, spam or quarantine?
Matthew Whittaker
Co-founder & CTO, Suped
Published 9 Jul 2025
Updated 15 Aug 2025
8 min read
It is a frustrating scenario many of us in email marketing face: Salesforce Marketing Cloud (SFMC) reports an email as 'delivered', yet it's nowhere to be found in the recipient's inbox, spam, or even quarantine folders. This discrepancy can be incredibly confusing and lead to significant deliverability challenges. Understanding why this happens is crucial for diagnosing and resolving these elusive email delivery issues.
The core of the problem lies in the definition of 'delivered' from the perspective of an email service provider (ESP) like SFMC. It doesn't always align with the end-user experience. This article will explore the nuances of email delivery status, common reasons for missing emails, and actionable steps to troubleshoot these issues.
When your ESP reports an email as delivered, it generally means that the email has been successfully handed over to the recipient's mail transfer agent (MTA) or mail server. At this point, the sending server has completed its part of the transaction, and the receiving server has accepted responsibility for the email. It's like a postal service confirming a package arrived at the local sorting facility, but not necessarily at the recipient's front door.
The true meaning of 'delivered'
Once an email is accepted by the recipient's mail server, several things can happen before it reaches the end user's inbox (or not). The journey doesn't end with SFMC's 'delivered' status.
Even after acceptance, the receiving server's internal filters continue to scrutinize the email. This includes content analysis, sender reputation checks, and authentication verification. If an email triggers too many red flags, it might be subjected to further processing, quarantined for review, or even silently dropped, meaning it disappears without a trace or a bounce message back to the sender.
Recipient mail servers have varying policies for handling suspicious emails. For example, Google generally tries very hard not to throw an email away. If they accept it, it will eventually go to the user, though delays of several hours can occur. Conversely, other providers, particularly Microsoft (including Office 365), may silently drop messages if the spam score is too high. Individual Office 365 tenants can also configure their settings to discard emails.
Beyond server-side filtering, user-configured inbox rules can redirect or delete emails before they are seen. If a user has an automated rule that moves specific emails to a hidden folder or deletes them outright, the email could be 'delivered' by SFMC and accepted by the recipient's MTA, but never reach a visible inbox or spam folder.
The silent drop: when emails disappear
Silent email drops are a significant challenge because they offer no feedback to the sender. This means you won't see a bounce, and the email won't appear in spam or quarantine. This usually happens when an email fails to pass certain security or spam checks after being initially accepted by the receiving server.
One common culprit is an organization's internal email security appliances or mail filters. These systems might perform their own comprehensive spam analysis even after the main mail server has accepted the message. If an email exceeds their internal spam thresholds, it can be deleted without notification to the sender or recipient.
DMARC policies at the recipient's domain can also lead to silent drops. If a domain has a DMARC policy set to reject (p=reject) and your email fails DMARC authentication, the receiving server is instructed to discard the message entirely, not just move it to spam or quarantine. While SFMC might initially report it as delivered, the ultimate fate is a complete rejection without a bounce. You can learn more about how to safely transition your DMARC policy to quarantine or reject.
Understanding DMARC policies
DMARC allows domain owners to specify what mail receivers should do with unauthenticated emails purporting to be from their domain. A policy of p=reject means the receiving server should not accept the email.
When emails sent from SFMC aren't reaching their intended recipients, even after appearing as 'delivered,' a systematic approach is needed for troubleshooting. This often involves collaborating with the recipient's IT team, especially for corporate domains.
Start by requesting the recipient's IT team to perform a message trace. If they manage their own Exchange server, they should be able to track the full process of the email from the moment it hits their Mail Exchange (MX) record. This can reveal if the email was indeed accepted, if it was then filtered, quarantined internally, or deleted.
For ongoing issues, especially with corporate domains, consider asking the recipient's IT team to allowlist your sending IP addresses and sending domains. This tells their mail system to trust emails coming from your specific sources, often bypassing internal spam filters that might otherwise silently drop messages. You can learn more about allowlisting delivery IP addresses.
Also, it's vital to ensure your email authentication records (SPF, DKIM, DMARC) are correctly configured. Misconfigurations can severely impact deliverability, leading to emails being flagged as suspicious and potentially dropped. Regularly check your DMARC reports to identify any authentication failures.
Typical problems
SFMC status: Shows 'delivered' but recipient cannot find the email.
Recipient server: Accepted the email, but it didn't reach the inbox.
Lack of feedback: No bounce message, spam folder, or quarantine.
Common causes
Internal filters: Aggressive anti-spam or security appliances.
User rules: Client-side inbox rules redirecting or deleting emails.
DMARC policy: Recipient's DMARC policy set to p=reject for unauthenticated emails.
Ultimately, getting to the bottom of these issues requires patience and a structured approach. It's often not an SFMC problem, but rather how the recipient's mail system handles the email after accepting it.
Collaborating with IT teams for deeper investigation
To effectively troubleshoot these elusive deliverability issues, having the right information is key. When communicating with the recipient's IT team, especially if they manage their own mail servers (like an on-premise Exchange server), here's what to provide and ask for:
Sending details: Provide the exact sending IP addresses used by SFMC for your sends, the sending domain, sender email address, recipient email address, subject line, and the precise send time (including timezone).
Email headers: If any similar emails *did* get through to that domain, ask for the full email headers. This can reveal authentication results (SPF, DKIM, DMARC), spam scores, and the path the email took.
Message trace: Request a full message trace from their mail server logs for the specific missing emails. This will show the exact journey of the email after it was accepted by their MTA, including any filtering or deletion events.
Spam filter settings: Inquire about their internal spam or security filters' thresholds and rules that might be configured to silently drop emails.
For ongoing issues with Microsoft inboxes, remember that their policies can be quite strict, often leading to silent drops if sender reputation or email content are highly suspect.
Ensuring your emails reach the inbox
The problem of emails marked 'delivered' by SFMC yet not visible to recipients highlights a critical distinction: an ESP's delivery confirmation merely signifies successful handoff to the receiving server. It does not guarantee inbox placement, nor does it account for post-acceptance filtering by the recipient's system. Addressing these issues requires a multi-faceted approach focusing on proper authentication, sender reputation, and direct collaboration with recipient IT teams to trace the email's full journey and adjust their internal filtering if necessary. Consistent monitoring of your email program and staying informed about ISP policies are also vital for long-term deliverability success.
Views from the trenches
Best practices
Maintain strong sender reputation by only sending to engaged recipients.
Regularly monitor your domain's authentication (SPF, DKIM, DMARC) for proper configuration.
Segment your audience and personalize content to reduce spam complaints.
Common pitfalls
Misinterpreting 'delivered' status as guaranteed inbox placement.
Ignoring DMARC reports which provide insights into authentication failures.
Failing to communicate with recipient IT teams for corporate deliverability issues.
Expert tips
Use Google Postmaster Tools and Microsoft SNDS to gain insights into your sending reputation and deliverability issues with these major providers.
Implement BIMI to enhance brand trust and visibility in the inbox, which can positively influence deliverability.
Regularly test your email content against spam filters using an email deliverability tester.
Marketer view
Marketer from Email Geeks says delivered typically means the message was sent to the mail transfer agent for sending, not necessarily to the recipient domain. The message could be in a queue for delivery, held in a recipient's mail quarantine, held for spam analysis, deleted by a filter, or sorted to a different folder by a user's inbox rule.
2020-06-09 - Email Geeks
Expert view
Expert from Email Geeks says email deliverability also depends on the receiving infrastructure. Google tries very hard not to discard emails and if accepted, they will eventually reach the user, though delays of several hours can occur.
