Why is my Intercom subdomain authentication failing even after DNS records are added?
Matthew Whittaker
Co-founder & CTO, Suped
Published 17 Apr 2025
Updated 16 Aug 2025
6 min read
Dealing with email authentication failures for a subdomain, especially when your main domain is working perfectly, can be incredibly frustrating. I've seen this issue come up time and again, particularly with platforms like Intercom. You've diligently added the required DNS records, waited for propagation, and yet, the platform still shows Unauthenticated. This often points to subtle misconfigurations or underlying issues that aren't immediately obvious.
My goal here is to walk you through the common pitfalls and advanced troubleshooting steps, providing clarity on why your Intercom subdomain might be struggling with authentication. We’ll cover everything from fundamental DNS checks to less apparent issues, aiming to get your emails flowing securely.
When you authenticate a domain with Intercom, you're primarily establishing trust that Intercom is authorized to send emails on your behalf. This is crucial for email deliverability and ensuring your messages don't land in spam folders. The process typically involves adding specific DNS records, usually CNAME records, to your domain's DNS zone file.
For Intercom, these records often include a DKIM record (typically a CNAME pointing to an Intercom-hosted DKIM key) and sometimes a tracking CNAME. DKIM, or DomainKeys Identified Mail, adds a digital signature to your outgoing emails, allowing receiving servers to verify that the email truly came from your domain and hasn't been tampered with. The tracking CNAME helps Intercom manage link tracking for emails sent through their platform.
It's important to understand that while DKIM and SPF are about email authentication, the specific CNAME records Intercom asks for also serve to connect your domain to their service for various functionalities. The authentication failure implies that Intercom's system cannot verify the presence or correctness of these records in your DNS settings.
Common reasons for subdomain authentication failures
Several factors can cause your Intercom subdomain authentication to fail even after adding the DNS records. The most common culprit is often simply DNS propagation delays. While you might add records instantly, it can take anywhere from a few minutes to 72 hours for these changes to update across the internet's DNS servers. If you're checking too soon, it might still show as unauthenticated.
Another frequent issue stems from incorrectly entered CNAME records. This could involve typos in the host or target values, adding an extra period at the end of the domain name (some DNS providers automatically append this, others require it), or including the full domain when only a subdomain portion is needed. For example, if Intercom asks for intercom._domainkey.yoursub.yourdomain.com, you might only need to enter intercom._domainkey.yoursub depending on your DNS provider's interface.
Common CNAME pitfalls
Trailing dot confusion: Some DNS providers automatically add the root domain and a trailing dot to your entries. If you include it, it creates a duplicate, like sub.domain.com.domain.com.
Conflicting records: An existing A, AAAA, or even another CNAME record on the exact same subdomain can prevent the Intercom CNAME from resolving. You generally cannot have multiple record types for the same hostname.
Cloudflare proxying:If you are using Cloudflare, ensure the CNAME record for Intercom authentication is set to DNS Only (gray cloud) rather than Proxied (orange cloud).
Troubleshooting DNS records for Intercom
The first step is always to go back and meticulously check the DNS records you've entered against what Intercom provided. Even a single character can lead to failure. Here’s a typical example of what the Intercom DKIM CNAME might look like:
Once you've confirmed the visual accuracy, use a DNS lookup tool to verify that the CNAME records are resolving correctly. You should see the CNAME pointing to the Intercom-provided target, and for DKIM, that target should then resolve to a TXT record containing the public key. If your DNS provider is showing the CNAME but Intercom isn't verifying it, there might be an issue with how the record is being served or interpreted.
DNS Record Type
Host/Name
Value/Target
CNAME
intercom._domainkey.yoursubdomain
xxxxxxxxxxxxxxxxxxxxxxxx.dkim.intercom.io
CNAME
outbound.intercom.yoursubdomain
rp.yourdomain-xxxxxxxxxxxx.intercom-mail.com
Advanced troubleshooting and specific cases
Sometimes the issue isn't as simple as a typo. If your main domain authenticates but the subdomain doesn't, it could indicate different DNS server configurations or even a DNS provider-specific quirk. It's also worth noting that DMARC is generally not the direct cause of a DKIM CNAME authentication failure with a provider like Intercom. DMARC relies on SPF and DKIM passing alignment, but it doesn't prevent the initial DKIM record from being recognized.
DNS configuration issues
Propagation delays: DNS changes can take time. Wait at least 24-48 hours before assuming a problem if everything looks correct.
Incorrect CNAME entry: Double-check for typos, extra characters, or missing dots. Ensure the host and value exactly match Intercom's instructions.
Conflicting records: An A record or another CNAME on the same subdomain will prevent proper resolution. Only one record type should exist for that specific host.
Platform-side or unusual issues
Intercom validation bug: Sometimes the issue is on Intercom's end, where their validation system might have a temporary bug or glitch.
DNS provider's specific handling: Certain DNS providers (like Cloudflare with its proxying) require specific configurations to allow CNAMEs to resolve for email authentication.
Caching/session issues: Your browser or the Intercom interface might be caching old information. Try logging out and back in, or using an incognito window.
If you've checked all these common points and your subdomain is still unauthenticated, it's time to consider that the problem might lie beyond your direct DNS configuration. I’ve seen cases where a platform's own validation routine had a temporary glitch, causing valid records to be rejected. This is why thorough testing and patience are key, but also knowing when to seek direct support.
What to do when all else fails
After exhausting all DNS checks and waiting for sufficient propagation time (at least 48 hours is a good benchmark), if your Intercom subdomain authentication is still failing, the next logical step is to contact Intercom support directly. Provide them with the exact records you've added, your subdomain, and details of any troubleshooting steps you've already taken. They can check their internal systems to see if the records are being recognized on their end or if there's an issue with their validation process.
Before reaching out, a simple trick that sometimes works is to delete the problematic DNS records and then re-add them, ensuring you save all changes carefully. You could also try clicking the Verify authentication button again in the Intercom interface, or even log out and back in to refresh your session. Ultimately, in a number of cases I've encountered, the problem was a bug within the platform itself that required a fix from their engineering team.
Views from the trenches
Best practices
Always verify DNS records using a public lookup tool before contacting support.
Confirm that the CNAME records provided are exactly matched to your DNS entries.
Ensure the DNS records are configured for 'DNS Only' if using Cloudflare's proxying.
Common pitfalls
Assuming DMARC is the cause of a basic DKIM CNAME authentication failure.
Not waiting long enough for DNS changes to fully propagate across global servers.
Having conflicting A or AAAA records on the same subdomain as your CNAME.
Expert tips
If the primary domain works but the subdomain does not, check for differing DNS servers.
Consider that the issue might be a bug within the Intercom validation routine.
Attempt to delete and re-add the DNS records, then re-verify in the interface.
Marketer view
Marketer from Email Geeks says they were having issues with a DNS record to authenticate a subdomain to send on their behalf from Intercom, despite the main domain working. Sys Ops were asking about DMARC, but it didn't seem to be required by Intercom's documentation.
2022-01-19 - Email Geeks
Marketer view
Marketer from Email Geeks states the main domain was teamwork.com and the subdomain updates.teamwork.com, with the subdomain experiencing the authentication failure.
2022-01-19 - Email Geeks
Resolving your Intercom authentication issues
Intercom subdomain authentication failures can be challenging to diagnose, especially when DNS records appear to be correctly set up. The solution often boils down to precise DNS configuration, adequate propagation time, and a diligent check for conflicting records or subtle typos. In some cases, the problem might even stem from a bug or a temporary glitch within Intercom's own validation system, as seen in real-world scenarios.
By systematically checking your DNS records, understanding common pitfalls, and knowing when to escalate to Intercom support, you can successfully navigate these authentication hurdles and ensure your subdomain is correctly configured for optimal email delivery. Remember, patience and methodical troubleshooting are your best tools in resolving these complex issues.
