Why do Microsoft 365 emails to Mailgun bounce with a 'Connection refused' error?
Matthew Whittaker
Co-founder & CTO, Suped
Published 23 May 2025
Updated 25 Aug 2025
11 min read
Dealing with email delivery issues can be incredibly frustrating, especially when you encounter cryptic error messages like 'Connection refused'. Recently, I came across a scenario where emails sent from Microsoft 365 accounts to a specific subdomain hosted on Mailgun were consistently bouncing with this error. What made it particularly perplexing was that other email sources could deliver to the same subdomain without a hitch. This pointed to a very specific configuration problem rather than a general block or server outage. The bounce message itself often contained 450 4.4.316 Connection refused [Message=Socket error code 10061], indicating that the recipient server was actively rejecting the connection attempt.
Initially, my thoughts drifted to common issues like IP blocklists (blacklists), firewall restrictions, or even an incorrectly configured SMTP server. However, the fact that only Microsoft 365 traffic was affected, and to just one subdomain, suggested something more nuanced. It was clear that a deeper dive into the DNS configuration, specifically how the subdomain was set up to handle incoming mail, was necessary. This isn't just a generic email failure, it's a targeted refusal, implying a specific rule or misconfiguration is at play.
My investigation focused on uncovering the underlying cause of this selective connection refusal. Understanding such errors is crucial for maintaining good email deliverability, especially when relying on third-party services like Mailgun for critical email infrastructure. This particular incident highlighted a lesser-known but critical DNS misconfiguration that can wreak havoc on email flow.
Understanding 'Connection refused' in email delivery
A 'Connection refused' error, particularly with a socket error code, means that the sending server tried to establish a connection with the recipient server, but the recipient server actively denied it. It is not a timeout or a temporary issue, it's a definitive no. This can happen for several reasons, but in the context of email, it often points to a problem at the network or initial connection phase, before any email content is even exchanged. It is like knocking on a door and having it slammed in your face immediately.
When Mailgun is involved, it usually acts as the receiving mail server for your domain or subdomain. If Microsoft 365 is sending, it looks up the MX (Mail eXchanger) records for the recipient domain to find where to send the email. If the MX records point to Mailgun's servers, then the refusal is coming from somewhere in the path to Mailgun. This specific bounce is distinct from other common bounces like "invalid recipient" or "mailbox full," which occur later in the SMTP conversation. You can learn more about general email delivery errors in this guide on why emails fail to send.
One common reason for such a refusal, especially when involving specific senders like Microsoft 365 and external services, can be an improperly configured firewall or network access control list (ACL) on the recipient side. However, when other senders are delivering successfully, it points away from a blanket block. The issue at hand often relates to how DNS records are set up, specifically when a CNAME record clashes with other record types for the same hostname. For broader troubleshooting, you can refer to our guide on how to troubleshoot 'connection refused' email delivery errors.
Understanding 450 4.4.316
This specific error code indicates an intermediate or transient problem that prevented the email from being delivered immediately. While it suggests a temporary failure, a persistent 'Connection refused' for specific senders usually points to a deeper, underlying configuration issue that needs to be addressed rather than waiting for it to resolve on its own. It's often related to the initial TCP handshake between the servers.
The CNAME conundrum: a deep dive into DNS conflicts
The root cause in this particular case, and a common culprit for 'Connection refused' errors in complex DNS setups, was an improperly configured CNAME record. A CNAME (Canonical Name) record is used to alias one domain name to another. The fundamental rule of DNS is that if a hostname has a CNAME record, it should not have any other record types, such as A, MX, or TXT records. This is specified in RFC 1034. Violating this rule creates a conflict, as different DNS resolvers may interpret the records differently, leading to unpredictable behavior.
In the scenario I encountered, the subdomain on Mailgun had both MX records pointing to Mailgun's servers for email routing, and a CNAME record that aliased the subdomain to a Cloudflare IP address. When Microsoft 365's mail servers tried to resolve the MX records for the subdomain, they might have received the CNAME's target IP (the Cloudflare IP) instead of the actual Mailgun mail servers. If that Cloudflare IP was not configured to accept incoming mail for that subdomain, it would simply refuse the connection. This could also explain situations where invalid domain name errors appear.
The issue became apparent because Microsoft 365's DNS resolvers might behave differently than other mail services, perhaps being stricter or resolving in an order that prioritizes the CNAME over the MX records. This kind of DNS conflict is a classic example of why proper DNS hygiene is critical for email deliverability. It can lead to varied delivery outcomes depending on the sender's mail server configuration, making troubleshooting quite challenging. For instance, Microsoft Defender for Office 365 also monitors mail flow intelligence that can detect such anomalies.
The issue
DNS conflict: A subdomain has both CNAME and MX records.
Inconsistent resolution: Different sending mail servers (e.g., Microsoft 365) may resolve the domain differently due to the conflicting records.
Connection refused: If the CNAME's target IP (e.g., Cloudflare proxy) isn't an active mail server for the domain, it rejects incoming mail connections.
The fix
Remove conflicting CNAME: Ensure the subdomain only has MX records (and potentially A records if it hosts a website directly, but not a CNAME).
Verify DNS propagation: Allow time for DNS changes to propagate globally.
Test from affected senders: Confirm that Microsoft 365 emails are now delivering successfully.
Diagnosing the DNS conflicts
Diagnosing these DNS conflicts requires a careful examination of your domain's DNS records. I typically start by using a DNS lookup tool to check all records for the problematic subdomain. I am specifically looking for the presence of both MX records and a CNAME record on the exact same hostname. This is a red flag. If your subdomain is mail.example.com, you shouldn't have both an MX record and a CNAME record for mail.example.com.
The output from a DNS lookup will clearly show all configured records. If you see something like this, it's a strong indicator of a CNAME conflict. The CNAME essentially tells any querying server, "don't look for other records here, just go to this other name instead." This can lead to the MX records being ignored or improperly resolved by some mail transfer agents (MTAs), particularly from providers with stricter DNS validation, like Microsoft 365. This might also contribute to broader issues where domains do not exist in bounce messages.
Another diagnostic step involves checking the A records for the CNAME target. If your CNAME points to proxy.cloudflare.com, you need to ensure that the IP address this proxy resolves to is indeed configured to handle email for your specific subdomain on Mailgun. Often, Cloudflare proxying for a subdomain can interfere with direct MX lookups, especially if the subdomain is intended to primarily serve email and not web traffic. This is a subtle yet critical detail often overlooked in complex DNS setups.
Example DNS lookup commandsbash
dig MX mail.example.com
dig CNAME mail.example.com
dig A mail.example.com
Steps to resolve and communicate the issue
The primary solution is to resolve the DNS conflict. This typically means removing the problematic CNAME record from the subdomain that has MX records. If the subdomain is solely for email, it should only have MX records pointing to Mailgun. If it needs to serve web content via a CNAME, then you'll need to use a different subdomain for email, or consider an A record pointing directly to the web server if that's an option, avoiding the CNAME clash. Keep in mind that Mailgun has documentation on relaying issues which can be helpful.
Once the CNAME record is removed, it's crucial to allow sufficient time for DNS propagation. This can take anywhere from a few minutes to several hours, depending on your DNS provider and global DNS cache updates. After propagation, Microsoft 365 should correctly resolve the MX records and establish a connection with Mailgun's mail servers directly. This is a common solution for many Microsoft domain blocking issues.
If you are working with a CRM vendor that handles the Mailgun integration, clearly communicate the specific DNS conflict (CNAME and MX records on the same hostname). Provide them with the technical details and emphasize that the CNAME record needs to be removed or moved to a different, non-mail-enabled hostname. This precise diagnosis is often the key to getting unresponsive support teams to understand the actual issue and implement the correct fix.
Issue
Root cause
Solution
DNS CNAME conflict
CNAME and MX records on same hostname.
Remove the CNAME record or use a different subdomain for email.
Firewall/ACL block
Recipient server's firewall blocking sender's IP.
Whitelist sender IPs on the recipient's firewall.
Sender IP blocklisted
Sending IP is listed on a public blocklist (or blacklist).
To prevent similar 'Connection refused' errors in the future, especially when integrating with third-party email providers like Mailgun, I always recommend strict adherence to DNS best practices. This includes carefully reviewing all DNS records when setting up new subdomains or making changes to existing ones. Always remember the fundamental rule: a hostname with a CNAME record should not have any other record types. This applies to MX records, A records, and even TXT records in some cases, although TXT records are generally more tolerant. Also, ensure your SPF and DKIM records are correctly configured, as these are vital for authentication. Consult our simple guide to DMARC, SPF, and DKIM for more details.
Regularly monitoring your email logs and bounce messages is also crucial. Tools that provide clear diagnostics can help identify issues before they escalate. Pay close attention to error codes and descriptions, as they often contain clues about the root cause. If you notice a sudden increase in bounces, particularly from a specific provider or with a consistent error message, investigate immediately. This proactive approach can help you pinpoint issues like sudden increases in Microsoft bounces.
Finally, when using services like Cloudflare with proxying enabled, be acutely aware of how it interacts with mail-related DNS records. For subdomains intended for email, it's generally best to keep them unproxied (DNS-only) in Cloudflare to ensure MX records are directly discoverable by sending mail servers. This avoids an unnecessary layer that could misdirect mail traffic and lead to 'Connection refused' errors. DNS configuration is foundational to email deliverability, and even subtle misconfigurations can have significant impacts, sometimes contributing to SPF DNS timeouts with Microsoft.
Views from the trenches
Best practices
Always check for CNAME conflicts with other record types, especially MX records, on the same hostname.
Ensure your DNS records are configured precisely according to the email service provider's (e.g., Mailgun) instructions.
Monitor DNS propagation after making changes to ensure they are visible globally and resolving correctly.
Proactively test email delivery from various providers, including Microsoft 365, after any significant DNS or email setup changes.
Maintain separate subdomains for web traffic (with CNAMEs) and email traffic (with MX records) if possible, to avoid conflicts.
Common pitfalls
Overlooking that a CNAME record on a hostname should not coexist with other records, leading to unpredictable DNS resolution.
Assuming that a 'Connection refused' error is always a network-level firewall block without investigating DNS configuration.
Relying solely on external vendors to troubleshoot complex DNS issues without providing specific technical details and context.
Forgetting to account for DNS propagation delays, leading to premature re-testing and frustration.
Not understanding how CDNs or proxies (like Cloudflare) interact with mail-related DNS records, potentially misdirecting email.
Expert tips
Use a tool to query DNS records directly and verify that only one record type (e.g., MX) exists for the hostname receiving email.
If using Cloudflare, confirm that any subdomain handling email has its proxy status set to 'DNS only' (grey cloud) to ensure direct mail routing.
When communicating with a vendor, specifically mention the RFC guideline regarding CNAME exclusivity to emphasize the technical violation.
If immediate resolution is needed, consider temporarily setting up a new, clean subdomain for email while the primary one is being fixed.
Review your DNSSEC implementation if enabled, as misconfigurations here can also lead to connection failures and DNS resolution issues.
Marketer view
Marketer from Email Geeks says they found the root cause to be a CNAME configured for a subdomain that also had MX records, which they had not realized before.
2024-08-12 - Email Geeks
Marketer view
Marketer from Email Geeks clarifies that the rule is to never have a CNAME for a hostname that has any other records, as this violates DNS specs and causes hard-to-diagnose errors.
2024-08-12 - Email Geeks
Summary of connection refused errors
The 'Connection refused' error from Microsoft 365 to Mailgun is often a symptom of underlying DNS misconfigurations, specifically the forbidden coexistence of CNAME and MX records on the same hostname. By understanding the strict rules of DNS and meticulously configuring your records, you can avoid these frustrating bounces and ensure reliable email delivery. Always double-check your DNS setup, especially for subdomains, and be prepared to educate your vendors on the precise technical issues when necessary. Proactive DNS management is a cornerstone of robust email deliverability.
Microsoft 365 accounts to a specific subdomain hosted on 
Mailgun were consistently bouncing with this error. What made it particularly perplexing was that other email sources could deliver to the same subdomain without a hitch. This pointed to a very specific configuration problem rather than a general block or server outage. The bounce message itself often contained 450 4.4.316 Connection refused [Message=Socket error code 10061], indicating that the recipient server was actively rejecting the connection attempt.
Cloudflare IP address. When Microsoft 365's mail servers tried to resolve the MX records for the subdomain, they might have received the CNAME's target IP (the Cloudflare IP) instead of the actual Mailgun mail servers. If that Cloudflare IP was not configured to accept incoming mail for that subdomain, it would simply refuse the connection. This could also explain situations where invalid domain name errors appear.
