Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Separate customer intake from outbound authentication
An Intercom email channel has two distinct jobs: bringing customer messages into the workspace and sending authenticated replies. Forwarding success proves the first job, not the second. This guide covers a custom work address used for Intercom support replies and outbound support messages. The retrieved documentation does not support mailing-list forwarding or outbound mailing-list addresses, and developer workspaces cannot send outbound email. Channel setup and sending limitations.
Before beginning, name the support-channel owner, email-provider administrator and DNS administrator. Record the workspace, brand, address, current forwarding destination and existing domain authentication. Retain a working customer-contact route during the change. If several brands share one domain, determine whether a DNS edit affects all of them before approving it.
Add the sender and publish its record set
Go to Settings > Channels > Email > Domains & addresses, add or edit the work address and complete its verification email. Configure and verify forwarding when the address will receive customer mail; outgoing-only use can skip forwarding. Choose Authenticate your domain to obtain the account's records. The manual setup supplies one DKIM CNAME, one custom Return-Path CNAME and a DMARC TXT record. Publish the appropriate records and run Validate authentication. Intercom setup.
Keep an explicit mapping of each record's purpose, full owner, type and target or value. A CNAME target is not TXT content. Check whether the DNS host appends the zone and ensure no existing integration occupies the proposed owner. Resolve a collision before replacing anything. When the domain already has DMARC, review the existing policy instead of adding a second policy or blindly replacing it with the setup example.
Intercom also offers automatic DNS setup through Entri and an optional Valimail reporting integration. The latter can create a third-party account when enabled. Treat these as separate authorization and data-handling choices; the manual route avoids making them an incidental part of a DNS change. Setup options.
Verify the custom Return-Path rather than adding SPF
Intercom says it handles SPF through the custom Return-Path CNAME, with no separate customer SPF record required unless otherwise advised. Its troubleshooting instructions require CNAME records for both DKIM and Return-Path, warn about doubled domain names, and direct Cloudflare users to DNS-only records. DNS visibility can take up to 72 hours, but the platform's validation still needs to be run. Intercom authentication troubleshooting.
The Return-Path and visible From serve different roles. A successful SPF check evaluates the envelope domain; DMARC then evaluates its relationship to the From domain. DKIM provides a second possible aligned path through the signature's d= domain. Inspect those actual domains rather than assuming a valid CNAME proves the finished message is aligned. Strict alignment can matter when a subdomain is used. SPF, DKIM and DMARC.
Keep the domain's wider enforcement plan intact. A support-channel change should not silently weaken protection for employee email or disrupt other legitimate services. Review reporting destinations and ensure the organization can access and act on the resulting reports.
Test a customer conversation end to end
Before diagnosing outbound failure as a DNS issue, confirm the Messenger is installed on the website or app: Intercom states this is required for outbound email functionality to work properly. Outbound prerequisites.
Original acceptance worksheet: send a harmless message from a controlled external mailbox to the support address, verify its arrival in the intended workspace and brand, then reply through Intercom. Separately test any outbound support workflow that will use the address. For each received copy, retain the From domain, Return-Path, trusted SPF identity and result, every DKIM d=/s= pair, and trusted DMARC result. Record the workflow and time alongside the raw message source.
Accept the rollout only after the intended sender is used, an aligned authentication path passes at the receiver, replies return to the correct conversation and no forwarding loop is present. A green platform status and a correct customer-intake path are useful evidence, but neither replaces received-message inspection.
If verification fails, compare published owners, types, targets and DNS-only behavior before repeatedly editing records. If a sender belongs to the wrong workspace, correct the address configuration rather than modifying unrelated DNS. Pause the new route and keep customer intake operational while investigating.
This is a documentary procedure. No Intercom tenant, authoritative DNS answer or received conversation was tested; live evidence and human SME review remain pending.