Why does an HTML email deliver internally but not externally?

Internal email systems often have less stringent security checks and may whitelist their own domain, allowing even poorly formatted or unauthorized emails to pass through. External mail servers, however, employ robust spam filters and authentication protocols, rejecting anything that appears suspicious, including HTML emails with issues like broken image links or authentication failures.

What common issues with HTML emails cause them to be blocked externally?

Issues with HTML coding (e.g., local image URLs, messy code, missing plain-text version), email authentication failures (SPF, DKIM, DMARC), poor sender reputation, or being listed on an email blocklist (blacklist) are common causes. Recipient-side spam filters and quarantine systems can also silently drop or hold messages.

How can I diagnose why my HTML email isn't reaching external inboxes?

Start by checking your ESP's delivery reports. Send a test email to your own external, personal email address (e.g., Gmail, Outlook.com). If the email is still not received, ask the external recipient to check their organization's quarantine folder or contact their IT department for assistance, as they have access to detailed mail logs.

Is a quarantine folder different from a spam folder?

Yes, a quarantine folder is typically different from a regular spam or junk folder. It's often managed by the recipient's IT department or email security gateway (like Proofpoint or Mimecast) and holds emails deemed highly suspicious before they even reach a user's spam folder. Users may need IT intervention to access or release these messages.

Why did my HTML email get delivered internally but not to external recipients? - Troubleshooting - Email deliverability - Knowledge base

It can be perplexing when your carefully crafted HTML email delivers perfectly to internal colleagues but vanishes without a trace when sent to external recipients. You see a 100% delivery rate in your email service provider (ESP) dashboard, yet external contacts confirm they never received the message, even in their spam folder. This scenario is frustratingly common and points to a fundamental difference in how internal and external email flows are handled.

Internal email delivery often operates within a trusted, less scrutinized environment. Your organization's email server knows and trusts its own domain and internal users, often bypassing many of the rigorous security checks that external emails undergo. However, when that same email leaves your network, it enters a hostile internet landscape where it faces a barrage of filters and security protocols implemented by recipient mail servers.

The divergence of internal and external email flows

When an email is sent internally, it typically stays within your organization's mail infrastructure. It doesn't have to contend with public email authentication protocols like SPF, DKIM, or DMARC in the same stringent way, nor does it pass through external spam filters that are designed to protect against unsolicited messages from outside your network. This means that even if your HTML email has hidden issues, they might not be flagged when sent to a colleague.

External mail, conversely, is subjected to a gauntlet of checks. Recipient mail servers, such as those operated by

Microsoft and other providers, implement sophisticated security gateways, like Proofpoint, to scrutinize every incoming message. These gateways perform extensive checks on sender reputation, email authentication, and content to determine if an email is legitimate or potential spam. The rules applied here are far stricter and can easily block messages that would sail through internal systems.

Internal email flow

Trust-based: Messages often bypass extensive authentication and content checks due to inherent trust within the organizational network.
Bypass security: Internal filters are generally more lenient, focusing on internal policy compliance rather than external threat protection.
Quarantine impact: Less likely to be quarantined by internal systems unless it violates specific internal rules.

External email flow

Strict validation: Undergoes rigorous SPF, DKIM, and DMARC checks, content scanning, and sender reputation analysis.
Comprehensive filtering: External spam filters and security gateways actively detect and block suspicious emails.
Higher quarantine risk: More likely to be quarantined or rejected entirely by the recipient's mail security system.

The HTML content of your email, while fine for internal viewing, can become a red flag externally. Issues such as improper HTML structure, invalid image URLs, or even the absence of a plain-text version can trigger sophisticated spam filters. These filters are not just looking for malicious content, but also for common characteristics of poorly constructed or suspicious emails, often associated with spam.

A crucial factor for external deliverability is your sender reputation. If your domain or IP address has a poor reputation, or if it's listed on an email blocklist (also known as a blacklist), external mail servers are likely to reject your emails. Internal systems typically don't check public blocklists, which explains why your messages deliver internally but fail externally.

Decoding common reasons for external blocking

One of the most common culprits for HTML email delivery issues to external recipients is the HTML itself. Errors flagged by email testing tools, such as problems with the plain text part or invalid image URLs, are critical. If you copied HTML from a previous campaign, especially if tracking URLs were involved, these elements might not be correctly configured for a new send, leading to rendering issues or outright blocking by recipient servers.

External mail filters are highly sensitive to email authentication. If your domain's SPF, DKIM, or DMARC records are misconfigured or fail validation, it's a strong indicator to the recipient server that your email might be spoofed or unauthorized. This can lead to immediate rejection or quarantine. While internal systems might overlook these failures, external servers typically do not.

Common HTML pitfalls to avoid

Local image URLs: Linking to images stored on an internal file server instead of publicly accessible web servers will cause images to break for external recipients.
Missing plain text: Emails should always include a plain-text alternative. Filters often flag HTML-only emails as suspicious, as this is a common spamming technique.
Poorly structured HTML: Complex, messy, or malformed HTML can confuse email clients and spam filters, leading to display issues or outright blocking. Avoid copying from Word documents.
External fonts/CSS: Relying heavily on externally hosted elements can increase load times or trigger security alerts, impacting deliverability.

Your sender reputation is paramount. Factors like past spam complaints, low engagement rates, or being listed on a public blocklist (or blacklist) can severely impact your external email deliverability. While internal mail flows aren't concerned with these public reputation metrics, external mail servers heavily rely on them to protect their users. You can learn more about why emails go to spam from this Kinsta guide.

Even if your email passes initial checks, recipient-side filters can still quarantine or silently drop messages. Many organizations use advanced spam and security solutions that can move suspicious emails to a separate quarantine folder, which is different from a user's regular spam folder. Users may not even be aware of these quarantined messages, making them appear as if they simply vanished.

Example SPF recordDNS

v=spf1 include:_spf.example.com ~all

Practical steps to diagnose your issue

The first step is to thoroughly check your ESP's delivery reports. While a 100% delivery rate might seem positive, it only indicates that the email was accepted by the recipient's mail server. It doesn't guarantee inbox placement. If there were no bounces, it suggests the email was received by the destination server but likely filtered before reaching the inbox. You can consult Microsoft's documentation on non-delivery reports for more context.

Next, send a small test campaign to your own personal email address, preferably one hosted by a major provider like Gmail or Outlook.com, and which is external to your work domain. This bypasses any internal whitelisting that might be masking issues and allows you to observe how external filters treat your email. If it lands in spam or is blocked, you'll have a clearer indication of the problem. If it passes, then the issue might be specific to the recipient's domain.

Beyond the spam folder

When emails disappear without a trace and aren't in the spam folder, they might be held in a quarantine folder managed by the recipient's IT department. This is common for organizations using advanced email security solutions like Proofpoint or Mimecast. Recipients might not have direct access to this folder and may need to contact their IT team to retrieve or release messages. This is a common reason emails are not received with no bounce errors.

If testing reveals no obvious issues on your end, obtaining the original email headers from a successful internal delivery (or even a personal external delivery) can provide crucial clues. These headers contain a detailed log of the email's journey and any authentication results or filtering decisions made along the way. While they might seem technical, they can reveal subtle configuration issues or flags that caused the external blocking.

Finally, if you're on good terms with the external recipients, encourage them to contact their IT department. Their IT team has access to mail logs and quarantine reports that can pinpoint exactly why the email was blocked or redirected. Often, they can release the email or whitelist your sending domain if the content is deemed legitimate. This collaborative approach is often the quickest way to resolve deliverability issues with specific B2B clients.

Navigating external email complexities

The distinction between internal and external email delivery is significant, especially concerning HTML emails. While HTML formatting itself is rarely the sole cause of blocking, underlying issues like broken image links, missing plain text, or incorrect sender authentication can trigger external spam filters, even if your internal systems are forgiving. Ensuring your HTML is clean and standards-compliant, and that your email authentication is robust, are foundational steps.

Proactive troubleshooting, including sending test emails to external addresses and working with recipients' IT teams, is essential for diagnosing and resolving these elusive deliverability problems. Understanding that external email is subject to far greater scrutiny is key to improving your inbox placement and ensuring your messages reach their intended audience, regardless of their destination.

Views from the trenches

Best practices

Always include a plain-text version alongside your HTML email to improve deliverability and accessibility across different clients.

Host all images and external resources on publicly accessible web servers, ensuring their URLs are valid and functional.

Regularly test your emails with external services to identify rendering issues or potential spam flags before sending campaigns.

Common pitfalls

Copying and pasting HTML directly from word processors or internal documents, which often introduces messy, non-standard code.

Using local file paths or internal network URLs for images and other assets, making them inaccessible to external recipients.

Neglecting to check your sender reputation and ignoring any warnings about your domain or IP being listed on blacklists (blocklists).

Expert tips

Consider sending a very small test campaign to a personal Gmail or Outlook.com address to observe how external filters react.

Ask recipients who didn't receive the email to check their organization's email quarantine, as it's often separate from the spam folder.

Analyze the original email headers from a successfully delivered message to uncover detailed delivery paths and any filtering decisions.

Marketer view

Marketer from Email Geeks says HTML by itself should not cause a problem, but copying HTML code from previously flagged spam messages or using externally hosted fonts and images might create issues. They advised checking if all unreceived emails were from the same provider, like Gmail or Microsoft.

2020-07-07 - Email Geeks

Expert view

Expert from Email Geeks says it is rare for content-based issues to cause mail to completely vanish, so it's important to first check if recipients looked in spam folders or by subject line. The next steps depend on the content, recipient domains, and any previous issues.

2020-07-07 - Email Geeks