SPF, DKIM et DMARC pour Intercom.
Intercom est l'un de vos canaux d'envoi les plus sollicités : les réponses du support depuis l'Inbox, les résolutions de Fin AI, les Series et les campagnes sortantes, ainsi que les messages liés au cycle de vie transitent tous par lui. Pour que ces e-mails atteignent la boîte de réception et satisfassent Google, Yahoo et Microsoft, ils doivent s'authentifier en tant que VOTRE domaine, et non en tant qu'intercom-mail.com. Intercom procède pour cela via une authentification de domaine basée sur des CNAME : vous vérifiez une adresse d'expédition, puis vous publiez un petit ensemble d'enregistrements CNAME qui délèguent la signature DKIM et le return-path à Intercom, ainsi qu'un enregistrement TXT DMARC. Ce guide détaille la configuration moderne exacte — le parcours dans le tableau de bord, la forme de chaque enregistrement, pourquoi il n'y a aucun include SPF à coller, et comment vérifier.
Pourquoi authentifier Intercom ?
Si vous envoyez des e-mails Intercom depuis une adresse de votre propre domaine sans l'authentifier, les destinataires reçoivent un message qui prétend venir de vous mais ne porte aucune signature DKIM alignée sur votre domaine ni return-path aligné — cela échoue à DMARC et se retrouve filtré vers les spams ou purement et simplement rejeté. Conserver l'adresse d'expéditeur par défaut intercom-mail.com évite ce problème, mais confie votre marque et votre réputation au domaine partagé d'Intercom. Depuis février 2024, Google et Yahoo exigent formellement SPF, DKIM et DMARC pour toute personne envoyant des e-mails en masse (environ 5 000 messages/jour ou plus), et Microsoft a suivi. Compléter l'authentification de domaine dans Intercom vous procure une signature DKIM alignée sur votre domaine, un return-path personnalisé aligné SPF et un enregistrement DMARC qui relie le tout — la combinaison qui garantit le placement en boîte de réception.
La réalité SPF pour Intercom
Intercom est un fournisseur de type CNAME, et non un fournisseur d'include SPF. Il n'existe AUCUNE chaîne partagée du type "include:intercom.com" à ajouter à votre enregistrement SPF racine (v=spf1) — en publier une n'apporte rien d'utile et grignote simplement votre budget SPF de 10 recherches. À la place, Intercom définit un Return-Path personnalisé (le domaine de l'expéditeur d'enveloppe / de rebond) sur chaque message qu'il envoie : un sous-domaine de VOTRE domaine que vous déléguez à Intercom via un CNAME. Comme ce sous-domaine pointe en CNAME vers l'hôte de return-path d'Intercom, la vérification SPF suit la chaîne jusqu'à l'enregistrement SPF d'Intercom et réussit sur les IP d'envoi autorisées d'Intercom — et comme le domaine d'enveloppe est un sous-domaine du vôtre, il satisfait l'alignement SPF relâché de DMARC par rapport à votre domaine From. Effet net : votre enregistrement SPF racine reste exactement tel quel, et Intercom n'y ajoute aucune recherche DNS. Si vous envoyez déjà via Google Workspace, Microsoft 365 ou un ESP, ne touchez pas à ces include ; Intercom réside entièrement dans les CNAME de DKIM et de return-path.
Étape par étape
- 1
Vérifiez l'adresse d'expédition que vous allez utiliser
Avant de pouvoir authentifier un domaine, Intercom doit confirmer que vous contrôlez une adresse d'expédition sur ce domaine (par exemple help@yourdomain.com ou hello@yourdomain.com). Ajoutez ou modifiez l'adresse, et Intercom envoie un lien de vérification à cette boîte aux lettres — cliquez dessus, puis revenez dans Intercom. Vous ne pouvez authentifier que les domaines des adresses vérifiées de cette façon.
- 2
Ouvrez 'Authenticate your domain' pour révéler vos enregistrements
Une fois l'adresse vérifiée, sélectionnez le domaine et cliquez sur 'Authenticate your domain' (les anciens espaces de travail affichent 'Finish setup'). Intercom génère les enregistrements exacts pour CET espace de travail et ce domaine : deux CNAME (DKIM + return-path personnalisé) et un TXT DMARC. Gardez cet écran ouvert — vous copierez le Name/Host et la Value/Target de chaque enregistrement mot pour mot.
- 3
Publiez le CNAME DKIM
Créez un CNAME dont l'hôte est le sélecteur DKIM d'Intercom — intercom._domainkey.yourdomain.com — pointant vers la cible DKIM affichée par Intercom. Cela délègue l'hébergement de la clé DKIM à Intercom, de sorte que la signature (d=) s'aligne sur votre domaine et qu'Intercom puisse effectuer une rotation des clés ultérieurement sans que vous ayez à retoucher le DNS. C'est un CNAME, jamais un enregistrement TXT.
- 4
Publiez le CNAME de Return-Path personnalisé
Créez le second CNAME exactement tel qu'Intercom le liste — un sous-domaine de rebond/return-path de votre domaine pointant vers l'hôte de return-path d'Intercom. C'est ce qui permet à SPF de s'aligner sur votre domaine : Intercom estampille l'expéditeur d'enveloppe avec ce sous-domaine, la vérification SPF suit le CNAME jusqu'à l'infrastructure autorisée d'Intercom et réussit, et DMARC voit un domaine aligné. L'omettre vous laisse avec une authentification DKIM uniquement.
- 5
Ne touchez pas à votre enregistrement SPF racine
N'ajoutez pas d'include Intercom ou SendGrid à votre enregistrement v=spf1 — Intercom n'en utilise pas pour les domaines clients, et le CNAME de return-path gère déjà l'alignement SPF. Si un enregistrement SPF racine existe pour d'autres expéditeurs (Google, Microsoft, un ESP), conservez-le tel quel. Ne le réexaminez que si un vérificateur montre ultérieurement que vous dépassez les 10 recherches SPF à cause de vos AUTRES expéditeurs.
- 6
Publiez ou renforcez votre enregistrement DMARC
Si vous n'avez pas encore d'enregistrement DMARC, ajoutez un TXT sur _dmarc.yourdomain.com. Intercom propose une valeur de départ p=none (surveillance uniquement) — publiez-la pour commencer à collecter des rapports, et incluez toujours une boîte aux lettres rua= afin de recevoir des données agrégées. Si vous avez déjà un DMARC, vous n'avez pas besoin de la copie d'Intercom ; confirmez simplement que votre politique existante convient toujours maintenant qu'Intercom est une source alignée.
- 7
Gérez les particularités DNS propres à chaque fournisseur
Sur Cloudflare, réglez chaque CNAME sur DNS-only (nuage gris, proxy OFF), sinon la résolution est rompue. Sur GoDaddy et certains registrars, saisissez le Name sans point final et sans réajouter votre domaine si le panneau le fait automatiquement ; d'autres panneaux exigent le nom pleinement qualifié (intercom._domainkey.yourdomain.com). Si un enregistrement portant le même hôte existe déjà, supprimez-le — un CNAME ne peut pas coexister avec un autre enregistrement portant le même nom.
- 8
Validez dans Intercom et confirmez l'alignement
Retournez dans Domains & addresses et cliquez sur 'Validate authentication'. Le DNS peut mettre jusqu'à 72 heures à se propager (généralement bien moins), donc en cas d'échec, patientez et réessayez plutôt que de réécrire des enregistrements corrects. Une fois au vert, envoyez un message de test et inspectez les en-têtes pour confirmer DKIM=pass et SPF=pass avec des domaines qui s'alignent sur le vôtre, ainsi que dmarc=pass.
Enregistrements à ajouter
Intercom génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| CNAME | intercom._domainkey.yourdomain.com | dkim.intercom-mail.comÀ titre indicatif. Délégation DKIM via le sélecteur intercom._domainkey. La Value exacte est générée par espace de travail/domaine et affichée dans votre écran Authenticate-your-domain — copiez-la mot pour mot. Les espaces de travail régionaux obtiennent des cibles différentes : les espaces de travail EU se résolvent vers intercom-mail.eu, les espaces de travail AU vers au.intercom-mail.com. |
| CNAME | <intercom-generated-label>.yourdomain.com | custom-return-path.intercom-mail.comÀ titre purement indicatif. Il s'agit du CNAME de Return-Path (rebond) personnalisé qui assure l'alignement SPF. Intercom génère le libellé d'hôte exact ET la cible pour votre espace de travail/domaine spécifique — le libellé n'est PAS un mot fixe, alors copiez les deux depuis l'écran Authenticate-your-domain mot pour mot plutôt que de saisir cet exemple. C'est un CNAME, jamais un enregistrement TXT/SPF. |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comComplément DMARC. Intercom pré-remplit p=none (surveillance uniquement). Publiez-le si vous n'avez pas encore de DMARC, puis renforcez vers quarantine/reject une fois que les rapports semblent propres. Si vous avez déjà un enregistrement DMARC, conservez le vôtre. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Intercom sur ce budget.
La configuration recommandée de Intercom ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
Intercom utilise un DKIM délégué par CNAME plutôt qu'une clé TXT auto-hébergée. Vous publiez un seul sélecteur — intercom._domainkey.yourdomain.com — sous forme de CNAME pointant vers l'hôte DKIM d'Intercom, et Intercom génère, héberge et effectue la rotation de la clé sous-jacente. Comme le domaine de signature (d=) est votre domaine, chaque message est signé DKIM et aligné DKIM, ce qui constitue le plus solide des deux chemins d'alignement DMARC et survit à la plupart des redirections. Il n'y a qu'un seul sélecteur à ajouter, et vous n'avez jamais à coller une longue chaîne de clé publique ni à la mettre à jour lorsqu'Intercom effectue une rotation de clés — le CNAME se résout vers la clé qu'Intercom publie à un instant donné.
DMARC
DMARC est l'enregistrement qui transforme l'alignement SPF et DKIM d'Intercom en une politique appliquée et vous fournit des rapports. Intercom propose un TXT de départ sur _dmarc.yourdomain.com avec p=none — publiez-le (avec une adresse rua=) si vous n'avez pas encore de DMARC, afin de commencer à recevoir des rapports agrégés sans risquer vos e-mails légitimes. Une fois qu'Intercom valide en vert et que vos rapports confirment que la signature DKIM et le return-path s'alignent tous deux sur votre domaine, renforcez la politique : de p=none à p=quarantine, puis p=reject une fois que vos autres expéditeurs légitimes (Google, Microsoft, ESP) réussissent également. Si vous envoyez plus de ~5 000 messages/jour sur l'ensemble de votre domaine, Google et Yahoo exigent au minimum une politique DMARC publiée. Un seul enregistrement DMARC organisationnel couvre Intercom et tous les autres expéditeurs — vous n'en ajoutez pas un distinct pour Intercom.
Vérifiez que tout fonctionne réellement
Cliquez sur 'Validate authentication' dans Intercom > Domains & addresses ; un état vert signifie que les deux CNAME se sont résolus et que le DKIM/return-path sont actifs. Vérifiez ensuite de manière indépendante : envoyez-vous un message de test depuis Intercom et affichez l'original/les en-têtes — vous voulez obtenir DKIM=pass avec d=yourdomain.com, SPF=pass avec une enveloppe/un return-path qui est un sous-domaine de yourdomain.com, et dmarc=pass. Vous pouvez également passer votre domaine dans un vérificateur SPF/DKIM/DMARC externe pour confirmer que le CNAME intercom._domainkey et le TXT _dmarc sont visibles dans le DNS public. Comme la propagation peut prendre jusqu'à 72 heures, considérez un échec précoce comme un 'pas encore propagé' plutôt que comme une erreur de configuration, dès lors que les enregistrements ont été copiés correctement.
Pièges courants
- Casse l'authentification
N'ajoutez PAS d'include SPF pour Intercom. Les domaines clients n'ont pas de chaîne include:intercom — Intercom aligne SPF via le CNAME de Return-Path personnalisé. Ajouter un include bidon (ou copier l'include SendGrid propre à intercom.com) n'apporte rien et grignote votre budget SPF de 10 recherches.
- Configuration DNS
Tous les enregistrements d'envoi sont des CNAME, pas des TXT. Seul l'enregistrement DMARC est un TXT. Si votre panneau DNS vous force à choisir un type, choisissez CNAME pour le sélecteur DKIM et l'hôte de return-path — les coller en TXT fera échouer la validation.
- Configuration DNS
Sur Cloudflare, désactivez le proxy (nuage gris / DNS-only) pour les deux CNAME. Un CNAME proxifié en nuage orange se résout vers Cloudflare au lieu de l'hôte de messagerie d'Intercom et casse les recherches DKIM et de return-path.
- Configuration DNS
Surveillez la façon dont votre registrar gère le champ hôte. Certains panneaux (GoDaddy, Namecheap) ajoutent automatiquement votre domaine, si bien que vous ne saisissez que intercom._domainkey ; d'autres exigent le nom pleinement qualifié intercom._domainkey.yourdomain.com. N'ajoutez pas de point final sur GoDaddy, et ne dupliquez pas le domaine.
- Configuration DNS
Omettre le CNAME de return-path vous laisse en DKIM uniquement. Le courrier peut tout de même passer DMARC sur le seul DKIM, mais vous perdez la redondance d'alignement SPF — et le courrier redirigé qui supprime la signature DKIM échouera alors. Publiez les deux CNAME.
- Configuration DNS
Un CNAME ne peut pas coexister avec un autre enregistrement portant le même hôte. Si un ancien enregistrement intercom._domainkey ou de sous-domaine de rebond existe (issu d'une configuration précédente ou d'un autre outil), supprimez-le d'abord, sinon le nouveau CNAME ne prendra pas.
- Couverture
Le DMARC par défaut d'Intercom est p=none — surveillance uniquement. Il vous fournit des rapports mais aucune protection contre l'usurpation. Une fois l'alignement confirmé, passez à p=quarantine puis p=reject.
- Configuration DNS
La région compte. Les espaces de travail US, EU (intercom-mail.eu) et AU (au.intercom-mail.com) obtiennent des cibles CNAME différentes. Copiez toujours la Value exacte depuis votre propre tableau de bord plutôt que de réutiliser une valeur tirée d'un guide.
Construisez votre enregistrement SPF
Intercom n'a pas besoin d'un include: SPF sur votre domaine racine — utilisez le générateur pour assembler un enregistrement propre et unique pour vos autres expéditeurs, en le limitant à une seule ligne.
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).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
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 listSPF Intercom — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.