Why is my Intercom subdomain authentication failing even after DNS records are added?

Key findings

• DNS records present: Even when DNS records (like CNAMEs for DKIM) appear to be correctly published and propagated for a subdomain, the sending platform may still report it as unauthenticated.
• DMARC is not always the culprit: Contrary to some assumptions (particularly from system operations teams), DMARC is typically not the direct cause of a subdomain authentication failure on platforms like Intercom and is rarely the solution to such specific issues.
• Platform-side validation: A common cause for authentication failure, despite correct DNS setup, is a bug or issue within the sending platform's (e.g., Intercom's) internal validation routine. This can prevent the platform from correctly recognizing the added DNS records. In such cases, the problem lies with the service provider, not your DNS configuration. You can learn more about how DNS issues can affect email delivery.
• Propagation time: While immediate failures might be due to propagation, issues persisting for over a week usually indicate a deeper problem beyond simple DNS caching or update delays. DNS records typically propagate globally within 24-48 hours. If the issue persists beyond this timeframe, it warrants further investigation. DmarcDkim.com highlights waiting 24-48 hours for propagation.

Key considerations

• Verify record syntax: Double-check that the CNAME records provided by Intercom are entered precisely as instructed, including any trailing dots or specific sub-subdomains.
• Check DNS server consistency: Ensure that both your primary domain and the subdomain are using the same, or at least correctly configured and synchronized, DNS servers. Discrepancies can lead to inconsistent record resolution.
• Contact support: If DNS records appear correct and sufficient time has passed for propagation, the most effective next step is to open a support ticket with the email sending platform (e.g., Intercom). Provide them with the exact DNS records you've added and the subdomain in question.
• Isolate the issue: If a primary domain authenticates but a subdomain does not, despite similar DNS setup, it strongly suggests a platform-specific issue or a subtle difference in how the subdomain's DNS is managed. This might include issues with what DNS records are needed for email sending subdomains.
• Try re-verifying: Sometimes, simply logging out and back into the platform, or deleting and re-adding the records (if the platform allows without generating new ones), then attempting verification again, can resolve minor UI or session-related glitches.

Key opinions

• Subdomain specificity: Marketers often find that issues with subdomains, even when the main domain is authenticated, suggest a specific configuration oversight for the subdomain. This is often the case when setting up email subdomains.
• Platform validation challenges: Many marketers suspect that the sending platform's internal verification system might be at fault, rather than their own DNS setup, particularly after extensive troubleshooting and propagation time.
• DNS provider variations: Different DNS providers can handle CNAME records or propagation in slightly varied ways, which might lead to unexpected authentication issues on certain platforms.
• Confirmation of records: Despite a platform showing 'unauthenticated,' external DNS lookups might confirm the records are indeed present, adding to the confusion and pointing towards internal platform issues.

Key considerations

• Patience with propagation: While frustrating, allowing sufficient time for DNS changes to propagate (at least 24-48 hours) is a crucial first step before escalating. However, as Bubble Forum users note, persistent errors after this time point to other issues.
• DNS record format: Ensure that the DNS records are formatted exactly as specified by the platform, paying close attention to subdomains and the exact target values.
• Support escalation: Do not hesitate to contact the platform's support team with detailed information, including screenshots of your DNS settings and the unauthenticated status. This is especially true when domain verification with TXT records fails.
• Re-attempting verification: Simple actions like re-clicking the 'verify' button, logging out and back in, or even briefly deleting and re-adding the DNS records (if safe to do so) can sometimes refresh the platform's validation.

Key opinions

• DNS server variations: Experts often check if different DNS servers are being used for the main domain versus the subdomain, as this can lead to propagation discrepancies or inconsistent record resolution.
• Platform validation routine: A frequent expert opinion is that the problem might be with the sending platform's validation routine itself, suggesting it could be 'borked' or buggy and failing to correctly detect valid DNS records. This can be complex, as DKIM validations can fail intermittently.
• DMARC's role (or lack thereof): Many experts strongly assert that DMARC is rarely the solution to direct subdomain authentication issues, correcting a common misconception among system administrators. More about DMARC can be found in a simple guide to DMARC, SPF, and DKIM.
• MTA or key issues: Experts may suggest the problem could be on the Mail Transfer Agent (MTA) side or that a new DKIM key might be needed from the service provider if the current one is somehow invalid or problematic.

Key considerations

• In-depth DNS checks: Conduct thorough DNS lookups for both the primary domain and the problematic subdomain to confirm the presence and correct values of all required CNAME and TXT records.
• Engage platform support: If external DNS tools confirm records are present but the platform shows otherwise, it's critical to open a detailed support ticket with the platform. Provide them with your specific DNS entries and the domain/subdomain details.
• Consider browser/session issues: Sometimes, interface-related problems (browser caching, session issues) can prevent the platform's UI from refreshing its authentication status. Advise logging out and back in, or trying a different browser.
• New key or re-entry: As a last resort before deeper investigation, experts might suggest requesting new authentication keys from the platform or deleting and re-entering existing DNS records to trigger a fresh validation attempt.

Key findings

• Specific DNS record types: Documentation consistently specifies the need for CNAME records for domain authentication, especially for features like DKIM and custom sending domains (e.g., Mini Course Generator documentation). These records are crucial for establishing trust and verifying sender identity.
• Propagation guidance: Most documentation advises users to wait a certain period (e.g., 24-48 hours) for DNS changes to propagate globally before expecting authentication to complete. This is a standard step in any DNS configuration process.
• Exact record values: Platforms provide precise record names and target values that must be entered into the DNS provider's settings. Any deviation, even minor, can lead to authentication failure. For example, Customer.io documentation emphasizes adding four DNS records for each sending domain.
• Troubleshooting advice: Documentation often includes a troubleshooting section that suggests re-checking records, ensuring no typos, and contacting support if issues persist after propagation. Some platforms, like Intercom (as referenced in the Slack thread), provide explicit instructions on how to verify your domain.

Key considerations

• Subdomain handling: Pay close attention to how the platform's documentation instructs the entry of subdomain records. Some DNS providers automatically append the root domain, requiring only the subdomain prefix (e.g., 'intercom._domainkey' instead of 'intercom._domainkey.updates.example.com').
• CNAME vs. TXT for verification: While some services use TXT records for initial domain verification, CNAMEs are common for email authentication (DKIM) and custom sending domains. Understand the specific record type required for each purpose, especially when dealing with subdomains where SPF resolution can sometimes fail with CNAMEs.
• Firewall or proxy interference: Occasionally, corporate firewalls or DNS proxies might interfere with the platform's ability to query DNS records, even if they are publicly accessible. Documentation may suggest testing from different networks or using specific DNS lookup tools.
• Role of MTA records: While less common for authentication failures, some platforms require specific MX records for subdomains or specific CNAMEs to redirect mail handling, which, if misconfigured, can impact sending capabilities indirectly.