Authenticate an Intercom sending domain with the two CNAME records generated by your workspace: one for DKIM and one for the custom return path. Keep a valid DMARC policy at the appropriate domain. For this custom-return-path workflow, Intercom says you do not need a separate SPF TXT addition. Finish validation in Intercom, then check a newly delivered message rather than treating a green dashboard as proof of alignment. Intercom authentication troubleshooting
This guide covers customer-owned addresses used for Intercom support replies and outbound messages. It does not configure a mailbox service, a Help Center website domain, or an external SMTP server. Intercom does not support custom SMTP connections for this email-channel workflow. Email channel scope
Before changing DNS
Identify the workspace, brand, exact From address and authoritative DNS zone. A registrar and DNS host can be different companies. Export existing records and retain their TTLs, especially the current SPF policy, DKIM selectors, return-path records and DMARC policy. Include parent-domain DMARC settings when the sender uses a subdomain.
Use a company-owned address you can verify. Public mailbox addresses and Google Groups or mailing-list addresses are not supported for outbound authentication. Authentication and reset require the Can manage general and security settings permission. Sending from a custom address separately requires Can send outbound emails from custom addresses. Developer workspaces cannot send outbound email, regardless of DNS correctness. The reviewed documentation does not establish a universal plan entitlement or regional DNS target; use the controls and values actually offered in your workspace rather than guessing a plan upgrade or substituting a regional hostname.
Intercom also lists an installed Messenger on your website or app as a prerequisite for outbound email functionality. Confirm this application setup before diagnosing an outbound failure as DNS.
For inbound support, forwarding gets customer messages into Intercom. Domain authentication authorizes outgoing messages. Test these as separate paths. For outbound-only use, the setup permits skipping forwarding. Do not move your domain's MX records just to authenticate Intercom.
Add and verify the sending address
Open Settings > Channels > Email > Domains & addresses. Add a new work address or edit the existing address. Open Intercom's verification message in that mailbox and follow the verification link. Request another message if necessary. Then choose Authenticate your domain to obtain the DNS records for that domain.
Use the manual DNS option when you need to review every proposed change. Intercom also documents automatic setup through Entri and an optional Valimail reporting integration. Those are separate third-party choices, not prerequisites for copying the manual records. Do not enable an extra reporting account or replace an established reporting destination inadvertently. Connection and authentication options
Keep a configuration worksheet with a row for each record: purpose, complete DNS owner, type, target, original value, requested replacement and approver. This makes a later brand addition or workspace migration much safer than a screenshot with no domain context.
Publish the DKIM and return-path CNAMEs
Copy each name and value from Intercom exactly. Publish the DKIM entry as CNAME, not as a TXT record containing the target hostname. Publish the custom-return-path entry as a separate CNAME at its supplied owner. Do not copy another customer's target or infer a workspace identifier from a tutorial.
If the DNS host appends your zone automatically, enter only the relative owner it expects. Otherwise use the full owner. A duplicated suffix such as name.example.com.example.com creates a different record that Intercom cannot validate. The destination must remain the complete provider target; it is not a URL and should not start with https://.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
A CNAME cannot share its owner with ordinary TXT, MX, A or AAAA records. If the proposed owner is already used, stop and establish what depends on it. Do not delete an existing DKIM key or bounce host just to clear the warning. Request a supported alternative or coordinate the migration. On Cloudflare, leave these authentication aliases DNS-only rather than proxied, and do not flatten them: the requested CNAME answer must remain visible. Intercom DNS troubleshooting
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
DKIM publishes information used to verify signatures, not the private signing key. The selector and signing domain in a delivered message identify the lookup as selector._domainkey.signing-domain. With a CNAME workflow, that owner delegates the lookup to the provider. DKIM specification
Understand what SPF checks here
SPF evaluates the SMTP envelope MAIL FROM domain, usually visible in the delivered Return-Path, not simply the address readers see in From. Intercom's return-path CNAME is therefore an authentication component, not a cosmetic branding record.
The current troubleshooting instructions say that custom-return-path authentication handles SPF without a separate SPF TXT record. Another Intercom help page mentions include:sparkpostmail.com as an authorization alternative. For the two-CNAME workflow described here, follow the more specific no-extra-SPF instruction; do not add an apex include speculatively or replace the existing mailbox provider's policy. Official SPF explanation
If support gives account-specific instructions requiring an SPF change, review the complete existing policy first. There must be one SPF TXT policy per owner, not one per vendor. Keep legitimate mechanisms, put additions before the terminal all, and evaluate the ten DNS-lookup-term limit, including nested includes. SPF terms use spaces, not semicolons. SPF requirements
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Keep DMARC safe while adding Intercom
DMARC succeeds when either SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment generally allows domains with the same organizational domain; strict alignment requires exact domain equality. A custom return-path subdomain may satisfy relaxed SPF alignment without satisfying strict aspf=s. A passing aligned DKIM signature can independently satisfy DMARC. Current DMARC standard, RFC 9989
Before publishing anything, query _dmarc at the actual From domain and inspect applicable parent policies. An apparently missing subdomain record does not prove that no policy applies. Preserve existing p=reject, p=quarantine, reporting recipients, alignment settings and subdomain controls. Do not add a second DMARC TXT record, or introduce p=none below an enforced parent merely to make onboarding easier.
If no established or inherited policy applies and a monitored introduction is appropriate, create a TXT record with owner _dmarc.example.com for From domain example.com. In that zone a relative owner is usually _dmarc. A minimal monitoring value is v=DMARC1; p=none. This is syntax guidance, not a customer record to publish unchanged. For a sending subdomain, use _dmarc beneath that exact domain instead.
DMARC tags are separated by semicolons. To request aggregate reports, append ; rua=mailto:YOUR-AUTHORIZED-REPORT-ADDRESS, replacing the entire placeholder with an approved destination. Use commas between multiple reporting URIs. External reporting destinations may need authorization records supplied by the reporting operator. Reporting can reveal mail infrastructure and traffic patterns, so retain the approved recipients. Aggregate reporting specification
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.
Monitoring does not request rejection of impersonation attempts. Move to enforcement only after reviewing every legitimate sending service. RFC 9989 supersedes RFC 7489 and removes pct; do not base a new staged rollout on that retired tag.
Activate the address and validate independently
Return to Intercom after the records resolve and complete Finish setup / Validate authentication as shown in your interface. Intercom allows up to 72 hours for DNS propagation and verification. Waiting will not repair a misspelled owner or wrong target.
Then enable the address for teammate outbound use and select the intended sending address and brand. For Fin, select the Inbound address sending option, then choose the verified Fin email address under Settings > Workspace > Brands for the intended brand. These choices matter: authenticating support@example.com does not mean an outbound campaign automatically uses it. Outbound address and brand settings
Use these read-only command patterns, replacing every capitalized placeholder before running:
dig +short NS YOUR-ZONE
dig @AUTHORITATIVE-NS CNAME DKIM-OWNER +noall +answer
dig @AUTHORITATIVE-NS CNAME RETURN-PATH-OWNER +noall +answer
dig @1.1.1.1 CNAME DKIM-OWNER +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Both aliases should answer with the exact targets from Intercom. Follow the DKIM alias to its TXT public key and inspect SPF at the actual envelope domain from the delivered message. Compare authoritative and recursive responses before blaming propagation. These checks establish DNS publication, not successful signing.
Send an authorized new support reply and an outbound message to a controlled external mailbox. Include each active brand. In raw headers record From, Return-Path, DKIM d= and s=, and Authentication-Results. Trust only the results added by the receiving system you control or recognize, not an arbitrary header supplied by the sender. Authentication-Results trust boundaries
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Acceptance requires the intended From address, the expected branded DKIM signature passing with alignment, and dmarc=pass for that From domain. Record whether SPF and DKIM each pass and align separately. Investigate SPF fail, permerror or temperror even if aligned DKIM carries DMARC; do not mark the intended custom-return-path setup complete while its SPF is broken. Keep message time and route with the evidence. Inbox placement, reputation and content filtering remain separate questions.
Troubleshoot the specific failure
DNS exists but Intercom will not validate: Check the authoritative zone, CNAME type, proxy setting and duplicated suffix. Compare both aliases, not just the DKIM selector. Then re-run provider validation.
The sender does not belong to the app: Check workspace membership and the selected sender address. A DNS change cannot grant a different workspace permission to use an address.
Authentication passes but replies use the wrong address: Inspect workspace sending-address settings, teammate aliases and brand defaults. Inspect the actual message rather than a display name.
SPF passes but DMARC fails: Compare the envelope and From domains; then check DKIM alignment. A pass for an unrelated domain is not sufficient. Do not weaken DMARC as a diagnostic shortcut.
Diagnose raw SPF independently at the actual envelope smtp.mailfrom, even when aligned DKIM yields DMARC pass. fail or softfail means the connecting sender was not authorized by the evaluated policy: check authorization and the actual route. temperror indicates transient evaluation trouble such as DNS unavailability. permerror indicates a permanent policy error, such as malformed syntax, duplicate SPF policies or exceeding the evaluated lookup budget. Do not add an unnecessary root SPF include to repair an error at Intercom’s managed return-path identity. SPF result meanings.
Mail is deferred despite correct authentication: Preserve the receiver's exact SMTP response. A rate limit, reputation block or recipient problem needs different handling from a DNS failure. Intercom's outbound API IP ranges are not a fixed allowlist for its email infrastructure.