Intercom email can use custom support addresses, automatic forwarding, outbound messages, custom return paths, DKIM, DMARC, and link branding. Review the exact channel and DNS flow before changing a support or lifecycle sender domain.
Scan the Intercom sending domain first
Check public DMARC, SPF, DKIM, MX, BIMI, MTA-STS, and TLS-RPT signals before editing Intercom email-domain authentication records.
01$0Free scan
Check the public sender-auth records mailbox providers expect.
02$0Shareable action plan
Keep one URL with evidence, owner steps, and decisions.
03$49$49 fix plan
Add human review, provider context, and verification steps.
Optional. Most first scans can run with just the domain.
Checks Gmail, Yahoo, and Microsoft sender requirementsPublic DNS onlyNo mailbox login needed
Example result72/100Needs attention
Review DMARC policy strength before a high-volume send.
Public DNS evidence
DMARC/SPF/DKIM status and caveats are visible before you pay.
Owner-ready next step
The audit adds provider context and a verification checklist.
Get the exact fix plan for your domain.$49 readiness audit: prioritized owner actions, DNS evidence, and verification checks.
Intercom support and outbound email can share a domain with Google Workspace, Microsoft 365, Zendesk, billing tools, marketing platforms, and transactional senders. DMARC enforcement should wait until those senders are mapped and aligned.
Intercom's normal authentication flow is not a simple root SPF include. It relies on DKIM, a custom return-path, a DMARC TXT policy, and Intercom workspace validation for the email address and channel.
Setup areas to review
Authenticate the email support domain: Intercom recommends using your own domain for support addresses and requires custom domains and addresses to be set up, verified, and authenticated before they can be selected for outbound sending.
Move away from shared setup domains: Intercom says its shared intercom-mail.com domain is useful for initial setup and testing, but is not recommended for long-term use because of deliverability risk.
Copy the three Intercom DNS records: Manual authentication provides two CNAME records and one TXT record. Copy the exact Name and Value shown in Intercom, because the workspace and domain settings are the source of truth.
Use the DKIM CNAME for DMARC alignment: Intercom says the first CNAME configures DKIM for mail sent through Intercom, allowing the Intercom email path to be DKIM-aligned for DMARC.
Use the custom return-path CNAME for SPF alignment: Intercom says the second CNAME configures the return-path address and allows mail sent from Intercom to be SPF-aligned for DMARC. Intercom handles SPF and does not ask for a generic SPF TXT include in normal setup.
Publish the DMARC TXT record cautiously: Intercom's manual flow includes a TXT record for DMARC and recommends DMARC even below Google and Yahoo high-volume thresholds. Existing DMARC records should be reviewed, not overwritten blindly.
Check Gmail and Yahoo compliance signals: Intercom documents Google and Yahoo requirements around SPF, DKIM, DMARC, one-click unsubscribe, fast unsubscribe processing, and keeping complaint rates below 0.3% for high-volume senders.
Avoid DNS-provider entry mistakes: Intercom warns that some DNS systems append the domain automatically, and some providers reject underscores in CNAME names. Do not duplicate the domain name in the host field.
Separate link branding from authentication: Intercom link branding for email assets uses a custom CNAME and SSL so links and images appear on your domain. That is different from DKIM, return-path, and DMARC authentication.
Confirm workspace and channel settings: A public DNS scan cannot prove the email address is verified, the Reply address is set correctly, or the message is using the email channel rather than another Intercom channel.
Avoid unsupported forwarding shortcuts: Intercom forwarding is separate from sender authentication. Mailing lists, Google Groups, and similar group-forwarding paths are not a safe substitute for a verified support address and tested automatic forwarding.
DNS record examples and caveats
These examples show record shapes only. Intercom account screens and current official docs are the authority for generated Names, Values, workspace validation, Reply address behavior, and whether link branding is configured.
Intercom DKIM CNAME shape:intercom._domainkey.example.com -> provider-generated Intercom target. Use the exact CNAME Name and Value from Intercom. Public DNS readiness still needs Intercom validation.
Intercom custom return-path CNAME shape:provider-generated return-path host -> provider-generated Intercom target. This is the SPF-alignment path for Intercom mail. Do not invent a root-domain SPF include.
DMARC TXT monitoring shape:v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Use reporting and header evidence before moving an Intercom sender domain toward enforcement.
Email asset link-branding CNAME shape:links.example.com -> provider-generated Intercom asset target. This can improve link trust, but it is separate from sender authentication and may also require SSL setup.
Safe verification sequence
List Intercom support addresses, outbound From addresses, brands, and Fin email paths.
Confirm the workspace is a production workspace and not a developer workspace.
Confirm each custom address is set up, verified, and authenticated in Intercom.
Copy the Intercom DKIM CNAME, return-path CNAME, and DMARC TXT values exactly.
Check whether your DNS provider needs shortened or fully qualified hostnames.
Validate authentication in Intercom after DNS propagation.
Send a real Intercom email and inspect DKIM, return-path, SPF, and DMARC headers.
Confirm marketing and subscription emails render one-click unsubscribe where required.
Review DMARC reports before tightening the policy beyond p=none.
Intercom authentication FAQ
Do I need to add Intercom to my root SPF TXT record?
Not from a generic guide. Intercom says it handles SPF through a custom return-path on sent email, and the custom return-path CNAME is what aligns SPF for DMARC in the normal email-domain authentication flow.
What DNS records does Intercom ask for?
Intercom's manual email-domain authentication flow provides two CNAME records, for DKIM and custom return-path, plus one TXT record for DMARC. Copy the exact Name and Value shown in Intercom.
Can Intercom pass DMARC?
Intercom says it supports DMARC when DKIM and return-path records are correctly configured. A complete review still needs Intercom validation and a real sent-message header.
Can I keep using an intercom-mail.com address?
Intercom uses shared intercom-mail.com domains for initial setup and testing, but does not recommend that configuration for long-term use because of deliverability risk. Authenticate your own domain for production support and outbound email.
Why can my DNS be correct but Intercom still not send?
Developer workspaces cannot send outbound email, and production workspaces still require the address, channel, Reply address, and workspace settings to be valid. DNS alone is not the whole Intercom sending path.
Is Intercom link branding the same as email authentication?
No. Link branding uses a custom domain for email assets such as links, images, and unsubscribe URLs. Sender authentication uses the DKIM, return-path, and DMARC records in the email-domain flow.
Can I use a dedicated IP or custom SMTP server in Intercom?
Intercom documentation says dedicated IP addresses are not available and custom SMTP is not supported. Review the current Intercom docs and your plan before designing around either option.
Can a scanner fully verify Intercom setup?
A scanner can inspect public DNS and common Intercom signals, but it cannot prove Intercom workspace validation, address verification, channel selection, Reply address settings, or inbox placement.
Turn the scan into an Intercom fix list
SenderReady readiness audits organize public DNS findings, Intercom-specific review steps, and cautious next actions for the domain owner or DNS admin. The report is a diagnostic aid, not a deliverability guarantee.