Do I need to add an SPF record for Intercom?

No. Intercom does not publish a shared SPF include for customer domains. It sets a custom Return-Path on its own infrastructure and you delegate that bounce subdomain via CNAME, so SPF aligns to your domain automatically. Leave your root v=spf1 record exactly as it is — Intercom adds zero lookups to it.

Why CNAMEs instead of pasting a DKIM TXT key?

CNAME delegation lets Intercom host and rotate the DKIM key and manage the return-path without you ever re-editing DNS. Your intercom._domainkey CNAME always resolves to Intercom's current key, so key rotations happen transparently and you avoid the errors that come from pasting long TXT values.

Will Intercom count against my 10-lookup SPF limit?

No. Because nothing is added to your root SPF record — alignment happens through the return-path CNAME on a subdomain — Intercom contributes zero of your ten allowed SPF DNS lookups. That's a real advantage over include-based senders.

Do I still need this if I already authenticated Google Workspace or Microsoft 365?

Yes. Intercom is a separate sending stream. Your Google or Microsoft DKIM and SPF only cover mail sent through them; Intercom mail needs its own intercom._domainkey CNAME and return-path CNAME to be authenticated and aligned. One shared DMARC record then covers all of them.

How long does verification take?

DNS changes can take up to 72 hours to propagate, though it's often minutes to a couple of hours. If Intercom's 'Validate authentication' fails right after you add the records, wait and retry rather than editing records that were copied correctly.

The values in this guide don't match what Intercom shows me — which do I use?

Always use the values in your own Authenticate-your-domain screen. The records here are illustrative; Intercom generates workspace- and region-specific targets (US intercom-mail.com, EU intercom-mail.eu, AU au.intercom-mail.com) and a unique return-path host label. Copy the Name and Value verbatim.

Is publishing Intercom's p=none DMARC record enough for Google and Yahoo?

It satisfies the 'must have a DMARC record' requirement to start, but p=none only monitors. Once your reports confirm Intercom and your other senders align, tighten to p=quarantine and then p=reject for real spoofing protection.

SPF setup guide

SPF, DKIM & DMARC for Intercom.

Intercom is one of your loudest sending channels: support replies from the Inbox, Fin AI resolutions, Series and outbound campaigns, and lifecycle messages all leave through it. For that mail to reach the inbox and satisfy Google, Yahoo, and Microsoft, it has to authenticate as YOUR domain, not as intercom-mail.com. Intercom does this with CNAME-based domain authentication: you verify a sending address, then publish a small set of CNAME records that delegate DKIM signing and the return-path to Intercom, plus a DMARC TXT record. This guide walks the exact modern setup — the dashboard path, each record's shape, why there is no SPF include to paste, and how to verify.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

IntercomSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Intercom?

If you send Intercom mail from an address on your own domain without authenticating it, receivers see a message that claims to be from you but carries no DKIM signature aligned to your domain and no aligned return-path — that fails DMARC and gets filtered to spam or rejected outright. Leaving the from-address as the default intercom-mail.com sender avoids that but hands your brand and trust to Intercom's shared domain. Since February 2024, Google and Yahoo formally require SPF, DKIM, and DMARC for anyone sending bulk mail (roughly 5,000+ messages/day), and Microsoft has followed. Completing domain authentication in Intercom gives you a DKIM signature that aligns to your domain, an SPF-aligned custom return-path, and a DMARC record that ties it together — the combination that earns inbox placement.

The SPF reality for Intercom

Intercom is a CNAME provider, not an SPF-include provider. There is NO shared string like "include:intercom.com" to add to your root SPF (v=spf1) record — publishing one does nothing useful and only eats into your 10-lookup SPF budget. Instead, Intercom sets a custom Return-Path (the envelope-sender / bounce domain) on every message it sends: a subdomain of YOUR domain that you delegate to Intercom with a CNAME. Because that subdomain CNAMEs to Intercom's own return-path host, the SPF check follows the chain to Intercom's SPF record and passes on Intercom's authorized sending IPs — and because the envelope domain is a subdomain of yours, it satisfies DMARC's relaxed SPF alignment against your From domain. Net effect: your root SPF record stays exactly as it is, and Intercom adds zero DNS lookups to it. If you already send via Google Workspace, Microsoft 365, or an ESP, leave those includes alone; Intercom lives entirely in the DKIM and return-path CNAMEs.

Step by step

Intercom > Settings > Channels > Email > Domains & addresses > Add/Edit address

1
Verify the sending address you'll use
Before you can authenticate a domain, Intercom needs to confirm you control a sending address on it (for example help@yourdomain.com or hello@yourdomain.com). Add or edit the address, and Intercom emails a verification link to that mailbox — click it, then return to Intercom. You can only authenticate domains for addresses you've verified this way.

Domains & addresses > select domain > Authenticate your domain

2
Open 'Authenticate your domain' to reveal your records
With the address verified, select the domain and click 'Authenticate your domain' (older workspaces show 'Finish setup'). Intercom generates the exact records for THIS workspace and domain: two CNAMEs (DKIM + custom return-path) and a DMARC TXT. Keep this screen open — you'll copy the Name/Host and Value/Target of each record verbatim.

Your DNS provider (Cloudflare, GoDaddy, Route 53, Namecheap, etc.)

3
Publish the DKIM CNAME
Create a CNAME whose host is the Intercom DKIM selector — intercom._domainkey.yourdomain.com — pointing to the DKIM target Intercom shows. This delegates DKIM key hosting to Intercom, so the signature (d=) aligns to your domain and Intercom can rotate keys later without you touching DNS again. It is a CNAME, never a TXT record.

Your DNS provider

4
Publish the custom Return-Path CNAME
Create the second CNAME exactly as Intercom lists it — a bounce/return-path subdomain of your domain pointing to Intercom's return-path host. This is what makes SPF align to your domain: Intercom stamps the envelope-sender to this subdomain, the SPF check follows the CNAME to Intercom's authorized infrastructure and passes, and DMARC sees an aligned domain. Skipping this leaves you with DKIM-only authentication.

Your DNS provider (existing v=spf1 TXT on the root)

5
Leave your root SPF record alone
Do not add an Intercom or SendGrid include to your v=spf1 record — Intercom does not use one for customer domains, and the return-path CNAME already handles SPF alignment. If a root SPF record exists for other senders (Google, Microsoft, an ESP), keep it as-is. Only revisit it if a checker later shows you exceeding 10 SPF lookups from your OTHER senders.

Your DNS provider (_dmarc TXT record)

6
Publish or tighten your DMARC record
If you have no DMARC record yet, add a TXT at _dmarc.yourdomain.com. Intercom offers a starter value of p=none (monitor only) — publish it to begin collecting reports, and always include a rua= mailbox so you receive aggregate data. If you already have DMARC, you don't need Intercom's copy; just confirm your existing policy still fits now that Intercom is an aligned source.

Your DNS provider's record editor

7
Handle provider-specific DNS quirks
On Cloudflare, set each CNAME to DNS-only (grey cloud, proxy OFF) or resolution breaks. On GoDaddy and some registrars, enter the Name without a trailing dot and without re-appending your domain if the panel adds it automatically; other panels need the fully-qualified name (intercom._domainkey.yourdomain.com). If a record with the same host already exists, remove it — a CNAME cannot coexist with another record at the same name.

Intercom > Domains & addresses > Validate authentication

8
Validate in Intercom and confirm alignment
Return to Domains & addresses and click 'Validate authentication'. DNS can take up to 72 hours to propagate (usually far less), so if it fails, wait and retry rather than re-editing correct records. Once green, send a test message and inspect the headers to confirm DKIM=pass and SPF=pass with domains that align to yours, and dmarc=pass.

Records to add

Intercom generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	intercom._domainkey.yourdomain.com	dkim.intercom-mail.comIllustrative. DKIM delegation via the intercom._domainkey selector. The exact Value is generated per workspace/domain and shown in your Authenticate-your-domain screen — copy it verbatim. Regional workspaces get different targets: EU workspaces resolve to intercom-mail.eu, AU workspaces to au.intercom-mail.com.
CNAME	<intercom-generated-label>.yourdomain.com	custom-return-path.intercom-mail.comIllustrative only. This is the custom Return-Path (bounce) CNAME that delivers SPF alignment. Intercom generates the exact host label AND target for your specific workspace/domain — the label is NOT a fixed word, so copy both from the Authenticate-your-domain screen verbatim rather than typing this example. It is a CNAME, never a TXT/SPF record.
TXT	_dmarc.yourdomain.com	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARC companion. Intercom pre-fills p=none (monitor only). Publish it if you have no DMARC yet, then tighten to quarantine/reject once reports look clean. If you already have a DMARC record, keep yours.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Intercom's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Intercom's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

Intercom uses CNAME-delegated DKIM rather than a self-hosted TXT key. You publish a single selector — intercom._domainkey.yourdomain.com — as a CNAME pointing to Intercom's DKIM host, and Intercom generates, hosts, and rotates the underlying key. Because the signing domain (d=) is your domain, every message is DKIM-signed and DKIM-aligned, which is the stronger of the two DMARC alignment paths and survives most forwarding. There's only one selector to add, and you never have to paste a long public-key string or update it when Intercom rotates keys — the CNAME resolves to whatever key Intercom currently publishes.

DMARC

DMARC is the record that turns Intercom's SPF and DKIM alignment into an enforced policy and gives you reporting. Intercom offers a starter TXT at _dmarc.yourdomain.com with p=none — publish that (with a rua= address) if you have no DMARC yet so you start receiving aggregate reports without risking legitimate mail. Once Intercom validates green and your reports confirm both the DKIM signature and the return-path align to your domain, step the policy up: p=none to p=quarantine, then p=reject once other legitimate senders (Google, Microsoft, ESPs) also pass. If you send more than ~5,000 messages/day across your domain, Google and Yahoo require at least a published DMARC policy. A single organizational DMARC record covers Intercom and every other sender — you do not add a separate one for Intercom.

Check it actually worked

Click 'Validate authentication' in Intercom > Domains & addresses; a green state means both CNAMEs resolved and DKIM/return-path are live. Then verify independently: send yourself a test message from Intercom and view the original/headers — you want DKIM=pass with d=yourdomain.com, SPF=pass with an envelope/return-path that is a subdomain of yourdomain.com, and dmarc=pass. You can also run your domain through an external SPF/DKIM/DMARC checker to confirm the intercom._domainkey CNAME and _dmarc TXT are visible in public DNS. Because propagation can take up to 72 hours, treat an early failure as 'not propagated yet' rather than a misconfiguration if the records were copied correctly.

Domain health check DMARC report analyzer

Common gotchas

Breaks auth
Do NOT add an SPF include for Intercom. Customer domains have no include:intercom string — Intercom aligns SPF through the custom Return-Path CNAME. Adding a bogus include (or copying intercom.com's own SendGrid include) does nothing and eats into your 10-lookup SPF budget.
DNS setup
All sending records are CNAMEs, not TXT. Only the DMARC record is a TXT. If your DNS panel forces you to pick a type, choose CNAME for the DKIM selector and the return-path host — pasting them as TXT will fail validation.
DNS setup
On Cloudflare, turn the proxy OFF (grey cloud / DNS-only) for both CNAMEs. An orange-cloud proxied CNAME resolves to Cloudflare instead of Intercom's mail host and breaks DKIM and return-path lookups.
DNS setup
Watch how your registrar handles the host field. Some panels (GoDaddy, Namecheap) auto-append your domain, so you enter only intercom._domainkey; others need the fully-qualified intercom._domainkey.yourdomain.com. Don't add trailing dots on GoDaddy, and don't double up the domain.
DNS setup
Skipping the return-path CNAME leaves you DKIM-only. Mail can still pass DMARC on DKIM alone, but you lose SPF alignment redundancy — and forwarded mail that strips DKIM will then fail. Publish both CNAMEs.
DNS setup
A CNAME can't coexist with another record at the same host. If an old intercom._domainkey or bounce-subdomain record exists (from a previous setup or another tool), delete it first, or the new CNAME won't take.
Coverage
Intercom's default DMARC is p=none — monitoring only. It gives you reports but zero spoofing protection. Once alignment is confirmed, move to p=quarantine then p=reject.
DNS setup
Region matters. US, EU (intercom-mail.eu), and AU (au.intercom-mail.com) workspaces get different CNAME targets. Always copy the exact Value from your own dashboard rather than reusing a value from a guide.

Build your SPF record

Intercom doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list