Why are we getting DNS resolution failures with outlook.com when sending email?

Key findings

• Inconsistent DNS responses: Microsoft's authoritative DNS servers may sometimes return a small number of MX records (e.g., two) and other times a much larger set (e.g., 29 or 30) for the same domain, such as outlook-com.olc.protection.outlook.com.
• UDP truncation: Large DNS responses, especially those exceeding 512 bytes, can cause UDP truncation where the server sets the TC (Truncated) bit in the response, indicating that the client should retry the query over TCP.
• MTA handling issues: Some Mail Transfer Agents (MTAs) or local resolvers may not properly handle truncated DNS responses, failing to retry over TCP. This can lead to the MTA incorrectly concluding that no mail hosts exist for the domain.
• Bounce message: The common bounce message associated with this issue is unable to route: no mail hosts for domain, even when valid MX records exist and are accessible via TCP.
• DNS query limits: Public DNS servers like Google (8.8.8.8) and Cloudflare (1.1.1.1) might have query limits, which could exacerbate intermittent resolution problems.

Key considerations

• EDNS0 support: Ensure your DNS resolver or MTA is configured to support EDNS0 (Extension Mechanisms for DNS 0), which allows for larger UDP packet sizes and can prevent truncation. Adding options edns0 to /etc/resolv.conf or configuring edns-udp-length in your MTA (e.g., PowerMTA) can help.
• Comprehensive DNS diagnostics: Use tools that show the full DNS response, not just the answer section. This helps identify issues like truncated responses or incorrect delegation. Consider internal troubleshooting for intermittent email delivery failures.
• Network packet filtering: Investigate if packet filters or firewalls in your infrastructure (e.g., AWS Security Groups) are interfering with larger UDP DNS responses, potentially causing truncation or dropped packets.
• MTA vendor support: Engage your MTA vendor's support if you suspect their DNS resolution code is not correctly handling truncated responses or retrying over TCP. This is critical for resolving problems like hidden SPF DNS timeouts at Microsoft.
• Microsoft's requirements: Microsoft is continuously updating its sender requirements. High-volume senders must meet strict criteria, and DNS configuration is a critical component for ensuring deliverability. For more information, refer to Outlook’s New Requirements for High-Volume Senders.

Key opinions

• Intermittent issues: Some marketers observe DNS resolution failures with Outlook.com where the MX hostname returns but does not resolve to an IP address, with resolutions working at times and failing at others. This often leads to bounce messages like "unable to route: no mail hosts for domain".
• Affected domains: The problem isn't limited to Outlook.com. Other domains with a large number of MX records, like johnlewis.co.uk or waitrose.co.uk (returning 16+ MX records), can experience 100% bounce rates due to similar DNS resolution issues.
• Infrastructure specific: Initially, the issue appeared prevalent among ESPs hosted on AWS infrastructure, although later testing revealed it to be a more general PowerMTA configuration problem, affecting non-AWS setups as well. This highlights the importance of understanding deliverability issues with Microsoft Outlook and Hotmail.
• DNS resolver choice: Switching to different public DNS resolvers like Google (8.8.8.8, 8.8.4.4) or Cloudflare (1.1.1.1) initially showed similar problems, indicating the issue isn't solely tied to a specific public DNS service.

Key considerations

• Logging DNS resolutions: Marketers are advised to enable verbose logging of DNS resolutions on their mail servers (e.g., using log-resolution in PowerMTA) to capture full DNS query and response details during failures.
• MTA configuration: A crucial step is to add the edns-udp-length 2048 option to PowerMTA configuration. This increases the UDP buffer size for DNS queries, preventing truncation and improving resolution for domains with many MX records.
• Monitoring bounce rates: Closely monitor bounce rates to Outlook.com and other major ISPs. Sudden spikes in no mail hosts for domain errors often indicate underlying DNS resolution problems that need immediate attention. These issues contribute to poor email deliverability to Microsoft inboxes.
• Understanding error messages: Error 550; 5.7.515 and similar messages from Outlook can point to issues beyond simple DNS, including DKIM and DMARC failures, requiring a holistic approach to troubleshooting. Refer to external guides for understanding error 550; 5.7.515.

Key opinions

• DNS delegation understanding: Experts emphasize that understanding DNS delegation is key. Using dig without +short is crucial to see the AUTHORITY SECTION and delegation details, which can reveal issues not apparent otherwise.
• Transient authoritative issues: There might be transient problems with Microsoft's authoritative DNS servers, leading to inconsistent responses (e.g., sometimes two answers, sometimes 29 or 30 for the same query), which can destabilize resolution.
• Truncated responses and TCP retry: A key finding is that some large DNS responses might be truncated (TC bit set), requiring the resolver to retry over TCP. If the resolver or MTA does not correctly perform this TCP retry, it can lead to routing failures. This issue can also affect DKIM temporary error rates with Microsoft.
• Multi-layered problem: The issue is often a combination of Microsoft's DNS inconsistencies, the DNS resolution chain truncating large responses, and the MTA's DNS handling code failing to properly manage truncated or missing answers (leading it to think there are zero MX records).

Key considerations

• Advanced DNS tools: Utilize advanced DNS diagnostic tools like dnstrace or dnsviz.net to trace the full delegation path and identify inconsistencies or truncation. This is essential for a complete picture, beyond simple dig or nslookup outputs.
• MTA resolver behavior: Investigate how the MTA's internal DNS resolver handles responses, particularly truncated ones. If it does not correctly initiate a TCP retry, this is a significant flaw requiring a fix. This is especially true when troubleshooting DMARC, SPF, and DKIM alignment.
• Test cases for truncation: Set up controlled DNS zones with numerous MX records to intentionally provoke large responses (e.g., tupid.org with 30+ MX records). This allows for repeatable testing to confirm if response size is the root cause of truncation and bounce messages like "no mail hosts for domain".
• Network layer inspection: If console dig commands on the mail server work, but the MTA still fails, consider using packet sniffers like Wireshark to inspect DNS traffic at the network interface level. This can reveal if intermediate network devices or firewalls are interfering with DNS responses. This is important when seeing SPF TempError in DMARC reports.

Key findings

• SPF DNS lookup limits: SPF records are limited to 10 DNS lookups. Exceeding this limit can cause SPF validation failures, especially with providers like Outlook.com, which can lead to emails being rejected. Flattening your SPF record can help reduce lookups.
• Reverse DNS (rDNS): Proper reverse DNS setup for your mail server's IP address is essential for email authentication and deliverability. Many mail servers perform rDNS checks to verify the sending server's identity.
• EDNS0 and UDP packet size: DNS extensions (EDNS0) allow for larger UDP packet sizes beyond the traditional 512 bytes. Resolvers and network devices must support EDNS0 to properly handle large DNS responses without truncation, which can impact email routing.
• Microsoft's new requirements: Microsoft has introduced new requirements for high-volume senders, which include strict adherence to email authentication standards (SPF, DKIM, DMARC) and proper DNS configuration.

Key considerations

• DNS behavior in cloud environments: Cloud providers like AWS (specifically Route 53) have particular DNS behaviors that can affect how DNS queries are resolved from within their networks. Understanding these behaviors is important, especially concerning EDNS0. More information can be found in the AWS Route 53 Developer Guide.
• DNS query analysis: When diagnosing DNS issues, technical documentation suggests tracing the full query path from the root nameservers down to the authoritative server. This ensures that all delegation steps are correctly handled, which is critical for complying with Outlook's new sender requirements.
• Email ecosystem health: Strengthening the email ecosystem involves ensuring that all DNS components, including authoritative servers, recursive resolvers, and MTAs, are configured to handle modern DNS responses robustly. This is vital for overall inbox placement and avoiding the impact of blocklists or blacklists.
• MTA resolver options: Mail server software (MTAs) often has configurable options for DNS resolution, such as specifying UDP buffer sizes or how truncated responses are handled. These settings should be reviewed and optimized to prevent intermittent failures. Checking Google Postmaster Tools can offer additional insights into DNS resolution issues from Google's perspective.