Email authentication for Intercom: SPF, DKIM and DMARC

9 May 2026 · 16 min read

Intercom is unusual among support and messaging platforms in one good way: it gives you everything you need to pass DMARC properly, including a custom return-path that makes SPF align. Most help-desk tools (Zendesk being the classic example) lock the envelope sender to their own domain, so SPF can never align and you are forced to lean entirely on DKIM. Intercom does not do that. When you authenticate a custom email domain in Intercom, you publish two CNAME records: one sets up DKIM signing with your domain, and the second sets a custom return-path on your domain so that SPF aligns too. That means Intercom email can pass DMARC on both mechanisms, which is the most resilient position you can be in.

This guide is specific to Intercom: the real selector it uses, the two CNAMEs it asks you to publish, why you do not add an include: to your own SPF record, how the custom return-path produces SPF alignment, and the order of operations that gets you to p=reject without dropping a single onboarding email, product notification or support reply.

How Intercom sends your email

Intercom sends a lot of different message types from your domain: outbound campaigns and series, product tours and onboarding sequences, transactional notifications, and one-to-one replies from the Inbox when an agent answers a conversation by email. All of these can be sent from an address on your own domain, for example team@yourdomain.com or support@yourdomain.com, once you have authenticated the domain.

Before you authenticate, every one of those messages relays through Intercom's mail infrastructure, and the two technical headers that DMARC actually inspects belong to Intercom, not you:

The Return-Path (the envelope MAIL FROM, which is the domain SPF checks) sits on an Intercom-owned bounce domain. SPF passes for that envelope, but because the envelope domain does not match your From domain, SPF is not aligned.
The DKIM signature, if you have configured nothing, is signed with an Intercom selector on an Intercom domain (d= is an intercom-mail.com style domain), so DKIM is not aligned to your From domain either.

DMARC does not care that SPF passed or that the message carried a valid DKIM signature. It cares about alignment: the domain that authenticated has to match the domain in the visible From header that your recipient sees. With nothing configured, Intercom mail from your domain can fail DMARC outright the moment you enforce, because neither mechanism is aligned. If you want the underlying mechanics, DMARC alignment explained covers exactly how relaxed and strict alignment are evaluated.

The fix is to authenticate the domain in Intercom, which publishes the two CNAMEs that bring both mechanisms into alignment with your domain.

The mental model for Intercom: unlike a locked-return-path sender, Intercom hands you an aligned return-path as well as DKIM. You get two independent paths to a DMARC pass. Configure both and your Intercom traffic is about as bulletproof as authenticated mail gets.

Step 1: authenticate your domain in Intercom

You do not hand-craft Intercom's records. Intercom generates them per workspace, with values that are specific to your account, and you copy them into your DNS. To start:

In Intercom, open Settings.
Go to the email/domains area: Settings → Channels → Email, then the Domains or Sender addresses section (Intercom's navigation labels shift over time, but it lives under email settings).
Add your sending domain (for example yourdomain.com) and start the custom email domain / DNS authentication flow.

Intercom then shows you a small set of records to publish:

Two CNAME records. One configures DKIM so your outbound Intercom mail is signed with your domain. The other configures a custom return-path so the envelope sender lands on your domain and SPF aligns.
One TXT record for your DMARC policy (Intercom suggests a starter value; more on why you should treat that carefully below).

Intercom deliberately uses CNAMEs rather than TXT for DKIM and the return-path. The reason matters: a CNAME points back at an Intercom-managed host, so when Intercom rotates the underlying DKIM private keys or changes bounce infrastructure, the live key updates on their side and you never have to touch DNS again. If they handed you a raw TXT public key, every rotation would be a manual DNS change and an outage risk. For the wider context on why selectors and rotation work this way, see DKIM selectors explained and DKIM key rotation.

Step 2: publish the DKIM CNAME

The first CNAME sets up DKIM signing. Intercom signs with the selector intercom, so the record you publish is for the host intercom._domainkey under your domain. The exact target is shown in your Intercom dashboard and is workspace-specific, but the shape is always the same:

intercom._domainkey.yourdomain.com.  CNAME  <intercom-supplied-target>.intercom-mail.com.

A concrete, illustrative example (your real target will differ, copy it from Intercom):

Type:   CNAME
Name:   intercom._domainkey.yourdomain.com
Value:  dkim.intercom-mail.com

Specifics that trip people up:

It is a CNAME, not a TXT. A frequent mistake is to paste Intercom's target into a TXT record. DKIM here is delivered as a CNAME that chains to Intercom's published key. A TXT with the same value will not validate.
Match the trailing-dot convention of your DNS host. Some panels want intercom._domainkey (host only, the zone is appended automatically), others want the fully qualified intercom._domainkey.yourdomain.com. Do not double up the domain.
Keep it DNS-only, not proxied. If your DNS sits behind a CDN or reverse proxy with a per-record proxy toggle (for instance an orange-cloud switch), the DKIM CNAME must be DNS-only. A proxied DKIM CNAME will not resolve to the key and DKIM will fail.
Selector is intercom. When you later verify with a tool, you query the intercom selector against your domain. Do not invent a different selector name.
Sending from a subdomain. If your Intercom From address lives on a subdomain (say hello@mail.yourdomain.com), publish the selector under that subdomain: intercom._domainkey.mail.yourdomain.com. The selector host always tracks the From domain Intercom signs for.

Once published, confirm the CNAME resolves before you do anything else in Intercom. The DKIM checker lets you query the selector directly: enter intercom as the selector and your domain, and confirm a valid key returns via the CNAME chain. DNS propagation can take from a few minutes to a day depending on your TTL, so do not rush.

Step 3: publish the custom return-path CNAME (this is what makes SPF align)

This is the record that sets Intercom apart from locked-return-path senders, and it is the one people most often skip because they assume SPF is handled by an include:. It is not. The second CNAME points a hostname on your domain at Intercom's bounce infrastructure. Once it is live, Intercom stamps the envelope MAIL FROM (the Return-Path) with an address on your domain rather than on an Intercom domain. Because the envelope domain now matches your organisational domain, SPF aligns.

The record shape (again, copy the exact host and target from your Intercom dashboard):

Type:   CNAME
Name:   <intercom-return-path-host>.yourdomain.com
Value:  <intercom-supplied-target>.intercom-mail.com

Why this is the elegant part:

You do not add include:_spf.intercom.com (or anything similar) to your own SPF record. Intercom handles SPF for you. Because the return-path domain is delegated to Intercom via this CNAME, the SPF record that gets evaluated for the envelope is Intercom's, published on Intercom's side. You are not spending one of your own SPF DNS lookups on Intercom at all.
This keeps you well clear of the SPF 10-lookup limit. SPF allows a maximum of ten DNS lookups across your whole record, and stacking provider include: mechanisms is the usual way teams blow past it and trigger a PermError that breaks SPF for every sender on the domain. Because Intercom uses a delegated return-path instead of asking you to add an include, it does not consume any of your ten lookups. If your own SPF record is already crowded from other senders, read the SPF 10-lookup limit and consider SPF flattening; our hosted SPF product keeps a flattened record under the limit automatically.

After publishing, confirm the return-path CNAME resolves (most DNS lookup tools, or your registrar's own checker, will show the CNAME chain). Intercom's own domain-verification screen will also tell you whether it considers the record valid. The custom return-path is what turns your DMARC reports from "SPF: pass, aligned: fail" into "SPF: pass, aligned: pass" for Intercom traffic.

A quick contrast worth internalising: with locked-return-path support tools such as Zendesk you cannot set a custom return-path, so SPF alignment is impossible and DKIM is your only path. With Intercom you get both. That redundancy matters because the two mechanisms fail in different situations, which is the subject of the next section.

Step 4: verify, then activate the sender in Intercom

The single most important sequencing rule: publish DNS first, confirm both CNAMEs resolve, then verify and activate the domain inside Intercom. If you activate sending before the records are live and propagated, Intercom can start sending with a configuration recipients cannot fully verify, which dents deliverability on exactly the high-intent onboarding and transactional mail you least want to land in spam.

Once both CNAMEs resolve cleanly, click Verify (or Authenticate) in Intercom's domain screen. When it goes green, Intercom signs outbound mail with d=yourdomain.com and a selector of intercom, and it stamps the Return-Path on your domain.

Now send a real test: trigger an outbound message or reply to a test conversation, send it to an address you control at a major mailbox provider, open the raw message and inspect the Authentication-Results header. You are aiming for something like:

spf=pass (sender IP is ...) smtp.mailfrom=<return-path-host>.yourdomain.com
dkim=pass header.d=yourdomain.com header.s=intercom
dmarc=pass (p=NONE) header.from=yourdomain.com

What to confirm in those lines:

dkim=pass header.d=yourdomain.com header.s=intercom. If header.d shows an intercom-mail.com style domain instead of yours, custom DKIM did not engage, almost always because the CNAME was not resolving when you activated. Re-check DNS and re-verify.
smtp.mailfrom= ending in your domain, not an Intercom domain. That confirms the custom return-path is in effect and SPF is aligned. If it still shows an Intercom domain, the return-path CNAME is missing or not yet propagated.
dmarc=pass. With both mechanisms aligned, DMARC passes comfortably.

Paste the raw headers into the DMARC checker results context or use the DMARC report analyzer once aggregate data starts arriving to confirm alignment at scale rather than from a single test.

Why having both SPF and DKIM aligned actually matters

It is tempting to think one aligned mechanism is enough, and for a single direct send it is: DMARC passes if either SPF or DKIM passes and aligns. But the two mechanisms break under different conditions, and Intercom mail meets both conditions in the wild.

Forwarding breaks SPF. When a recipient's organisation forwards your message, the forwarding server becomes the new envelope sender, so the SPF check no longer maps to Intercom, and SPF alignment is lost on the forwarded copy. DKIM survives forwarding as long as the signed headers and body are not altered. Onboarding and support email gets forwarded inside customer organisations constantly, so DKIM is your safety net there. See forwarding and DMARC and DKIM alignment and forwarding.
Body or header modification can break DKIM. Some mailing lists and a few aggressive security gateways rewrite subjects, append footers or re-encode the body, which invalidates the DKIM signature. In those cases an aligned SPF result (which Intercom's custom return-path gives you) can be the mechanism that carries the DMARC pass.

Because Intercom lets you align both, your mail keeps passing DMARC across far more real-world delivery paths than a single-mechanism setup would. That is the whole reason to bother publishing the second CNAME rather than stopping at DKIM.

Step 5: read your DMARC reports and inventory every other sender

Before you tighten your policy, you need evidence that Intercom is aligning and that you have not forgotten another service that sends as your domain. Your From domain is almost certainly used by more than Intercom: a marketing platform, your own mail server, an invoicing tool, a CRM, perhaps a separate transactional provider. DMARC enforcement blocks anything that is not aligned, so you must inventory everything first. This is the step that prevents the classic self-inflicted outage.

DMARC aggregate reports (RUA) are how you build that inventory. Start your DMARC record in monitoring mode. If Intercom suggested a DMARC TXT value during setup, do not just accept it blindly: make sure it points the rua at a mailbox you actually collect and parse, and that the policy starts at none while you are still discovering senders. A sensible starting record:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r

Notes specific to the Intercom situation:

p=none collects data without affecting delivery. Stay here until Intercom and every other sender show aligned passes across your normal volume.
adkim=r and aspf=r (relaxed alignment) are correct here. Intercom signs and sets the return-path on your organisational domain, so relaxed alignment passes cleanly. You do not want strict alignment unless every sender uses the exact same hostname, which is rarely true once several tools are involved. Understanding your DMARC record walks through each tag.
fo=1 requests a failure report whenever any mechanism fails, which helps you see at a glance whether Intercom is passing on both SPF and DKIM or only one.

If you do not yet have a DMARC record, generate one with the DMARC generator and confirm what is actually published with the DMARC checker.

Aggregate reports arrive as XML and are painful to read by hand. Feed them into the DMARC report analyzer to see, per source, whether SPF and DKIM passed and aligned. For Intercom you want to see its sending sources showing both SPF aligned: pass and DKIM aligned: pass. If you only see DKIM aligning and SPF still failing, your return-path CNAME is missing or not propagated, go back to Step 3. For help reading that first report, see reading your first DMARC report.

For ongoing visibility rather than a one-off check, our monitoring ingests your aggregate reports continuously and alerts you when a source like Intercom stops aligning, for example after a key rotation hiccup or an accidental DNS edit. That is the difference between hearing about a broken signature from a dashboard and hearing about it from a customer who never received their onboarding email.

Step 6: move to quarantine, then reject

Only when your reports show Intercom and every other legitimate sender aligned over a representative window (a week or two that includes your normal volume, including any large campaign sends) should you tighten the policy. Rushing this is how teams block their own mail.

Step up gradually. First, sample quarantine:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; fo=1

The pct=25 tag applies the quarantine policy to a quarter of failing mail, so any sender you missed gets a soft landing in spam rather than a hard block while you confirm. DMARC pct sampling explains how to use this safely. Watch your reports for a few days, raise to pct=100, and once that is clean, move to full enforcement:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; fo=1

At p=reject, unauthenticated mail using your domain is refused outright. Because Intercom is aligned on both SPF and DKIM, your campaigns, product notifications and support replies sail through. Anyone spoofing your domain does not. For the full staged playbook, see reaching p=reject without breaking email and the broader enforcement journey. For why mailbox providers now expect this, Gmail, Yahoo and Microsoft require DMARC and the 2024 to 2025 sender requirements lay out the deadlines and thresholds, including the 5,000-messages-per-day rule that makes a published DMARC policy mandatory for high-volume senders.

Common Intercom pitfalls

Adding an SPF include for Intercom. You do not need include: anything for Intercom in your own SPF record. SPF alignment comes from the return-path CNAME, not from your SPF record. Adding a redundant include just wastes one of your ten lookups.
Skipping the return-path CNAME. If you only publish the DKIM CNAME, DKIM aligns but SPF does not. You will still pass DMARC on most direct sends, but you lose the SPF safety net for messages where DKIM is broken by forwarding-list rewrites. Publish both CNAMEs.
Pasting CNAME targets into TXT records. Both Intercom records are CNAMEs. A TXT with the same value will not validate for DKIM or set the return-path.
Proxying the CNAMEs. If your DNS is behind a proxy with a per-record toggle, set both Intercom CNAMEs to DNS-only. Proxied DKIM or return-path records will not resolve to Intercom's hosts.
Activating in Intercom before DNS propagated. Confirm both CNAMEs resolve first with the DKIM checker and your DNS host's lookup, then click Verify in Intercom.
Wrong selector when verifying. The selector is intercom. Querying any other selector against your domain will return nothing and make you think DKIM failed when it did not.
Forgetting the subdomain. If your Intercom From address is on a subdomain, both CNAMEs and your subdomain DMARC record need to account for that subdomain. A subdomain inherits the organisational DMARC policy unless you set an sp tag; see the subdomain policy tag.
Other senders on the same domain. Intercom aligning is necessary but not sufficient. Inventory every sender via aggregate reports before you enforce, or you will block your own billing, marketing or transactional mail. DMARC common mistakes catalogues the rest.
d= shows an Intercom domain in test headers. That means custom DKIM did not engage. Re-check the intercom._domainkey CNAME and re-verify in Intercom.

The practical takeaway

Intercom is one of the cleaner senders to authenticate, because it gives you both halves of DMARC instead of forcing you onto DKIM alone. Authenticate your custom email domain in Intercom, publish the DKIM CNAME (selector intercom, host intercom._domainkey.yourdomain.com), publish the custom return-path CNAME that delegates your envelope sender to Intercom so SPF aligns, and verify in Intercom only after both records resolve. Do not add an Intercom include: to your own SPF record; the return-path CNAME does that job without costing you a DNS lookup. Confirm in the raw headers that header.d is your domain and smtp.mailfrom ends in your domain, then use your DMARC reports to inventory every other sender before stepping from p=none through p=quarantine to p=reject.

Start by checking what is live today with the DKIM checker (selector intercom), the SPF checker and the DMARC checker, then watch your aggregate data in the DMARC report analyzer. If you would rather not babysit selectors, return-path propagation and the staged rollout yourself, our done-for-you DMARC service configures Intercom alignment on both mechanisms, keeps your SPF record flattened and within the lookup limit, and takes your domain to enforcement safely with continuous monitoring so you hear about a broken signature before your customers do.