SPF, DKIM et DMARC pour Zendesk.
Zendesk envoie vos réponses aux tickets, vos notifications et vos automatisations depuis votre adresse d'assistance (support@yourdomain.com) : l'authentifier est donc ce qui empêche ces messages d'atterrir dans les dossiers spam de vos clients ou de porter une étiquette « via zendesk.com ». L'authentification se répartit entre votre hébergeur DNS et le Centre d'administration Zendesk. SPF est un véritable include partagé — vous ajoutez include:mail.zendesk.com à l'unique enregistrement SPF de votre domaine — et DKIM se compose de deux enregistrements CNAME de « signature numérique » que vous publiez puis activez sous Canaux → Talk et e-mail → E-mail. DMARC est un troisième enregistrement, distinct, que Zendesk ne crée jamais pour vous. Un prérequis compte : l'authentification DNS ne s'applique que lorsque vous envoyez depuis un domaine e-mail externe qui vous appartient ; les adresses sur le domaine par défaut yourbrand.zendesk.com sont déjà signées par Zendesk et ne nécessitent rien.
Pourquoi authentifier Zendesk ?
Authentifier Zendesk n'est pas une simple formalité — cela détermine si vos réponses d'assistance atteignent réellement vos clients. Une file d'assistance active franchit facilement le seuil des 5 000 messages par jour qui, depuis février 2024, oblige les expéditeurs en masse Gmail et Yahoo à réussir SPF, DKIM et DMARC avec alignement ; Microsoft a commencé à appliquer des règles similaires aux expéditeurs à fort volume en 2025. Tant que vous n'authentifiez pas un domaine d'assistance externe, Zendesk envoie des réponses qui ne vous sont que faiblement attribuables : les destinataires voient une mention « via zendesk.com », votre adresse From n'est pas cryptographiquement la vôtre, DMARC ne peut pas passer, et toute plainte pour spam s'agrège contre l'infrastructure partagée de Zendesk au lieu de bâtir votre propre réputation. Il existe aussi une subtilité propre à Zendesk qui rend DKIM incontournable ici : le SPF de Zendesk ne s'aligne jamais sur votre domaine (il renvoie le courrier sur son propre Return-Path zendesk.com), donc contrairement à Google Workspace ou Microsoft 365, vous ne pouvez pas vous appuyer sur SPF pour porter DMARC — DKIM est le seul mécanisme qui s'aligne. Configurez l'include SPF, les deux CNAME DKIM et une politique DMARC, et vos réponses partent signées comme votre propre domaine, l'étiquette « via » disparaît, DMARC passe, et la réputation que vous bâtissez est la vôtre.
La réalité SPF pour Zendesk
Zendesk est un véritable fournisseur « include » — vous ajoutez un unique mécanisme partagé réel, include:mail.zendesk.com, à l'unique enregistrement SPF TXT de votre domaine, et Zendesk recommande officiellement l'enregistrement complet v=spf1 include:mail.zendesk.com -all (il recommande le hard fail -all pour la protection anti-usurpation la plus forte). Vérifié sur du DNS en direct, mail.zendesk.com se résout en un enregistrement plat contenant uniquement des plages ip4: et son propre ~all, sans includes imbriqués, il ne coûte donc exactement QU'UNE de vos 10 recherches DNS SPF. Voici la partie que presque tous les tutoriels omettent, et c'est la chose la plus importante à comprendre à propos du SPF de Zendesk : il passe mais il ne s'ALIGNE pas. Par défaut, Zendesk envoie le courrier sortant avec le Return-Path d'enveloppe (le MAIL FROM que les destinataires soumettent réellement au contrôle SPF) sur l'un des propres domaines de rebond zendesk.com de Zendesk, et non sur votre domaine — et Zendesk ne fournit aucun mécanisme pour déplacer ce Return-Path vers votre domaine. Le SPF authentifie donc contre l'infrastructure de Zendesk et passe, mais parce que le domaine contrôlé est un sous-domaine zendesk.com plutôt que votre domaine From, il n'est pas aligné, et DMARC ne comptabilise SPF que lorsqu'il est aligné. Cela signifie que include:mail.zendesk.com ne peut pas porter à lui seul une réussite DMARC. Il vaut tout de même la peine de l'ajouter — Zendesk le recommande, certains destinataires effectuent un contrôle SPF non aligné sur le domaine From visible, et cela évite les rebonds liés au SPF et le classement en spam — mais le mécanisme qui fait réellement passer DMARC pour Zendesk est l'alignement DKIM, pas SPF. Conservez exactement un enregistrement SPF sur le domaine (fusionnez l'include si vous envoyez déjà via Google Workspace, Microsoft 365, etc.), gardez include:mail.zendesk.com comme mécanisme de premier niveau dans cet enregistrement, et commencez par ~all plutôt que -all jusqu'à ce que tout autre expéditeur légitime soit énuméré.
Deux façons de le configurer
Domaine e-mail externe — include SPF + DKIM (recommandé)
- Les réponses proviennent de votre propre marque (support@yourdomain.com), pas d'une adresse zendesk.com
- DKIM signe comme d=yourdomain.com afin que DMARC passe via l'alignement DKIM
- Ajoutez include:mail.zendesk.com plus les deux CNAME DKIM zendesk1/zendesk2 à votre DNS
- Coûte une recherche DNS SPF ; les clés tournent automatiquement une fois les CNAME en service
Adresse par défaut yourbrand.zendesk.com — rien à configurer
- Zendesk authentifie et signe déjà son propre domaine zendesk.com
- Aucun enregistrement SPF, DKIM ou DMARC à publier de votre côté
- Mais les clients voient une adresse From générique zendesk.com au lieu de votre marque
- Aucun contrôle sur la réputation — vous partagez le domaine de Zendesk avec tous les autres locataires
Étape par étape
- 1
Ajoutez et vérifiez votre adresse d'assistance externe
Dans le Centre d'administration, ouvrez Canaux → Talk et e-mail → E-mail et ajoutez une adresse d'assistance sur votre propre domaine (par ex. support@yourdomain.com), puis vérifiez-la — soit en transférant le courrier entrant de cette boîte vers votre adresse yourbrand.zendesk.com, soit en connectant Google Workspace / Microsoft 365. C'est important car l'authentification DNS (include SPF + CNAME DKIM) ne s'applique qu'aux domaines externes ; les adresses sur le domaine par défaut yourbrand.zendesk.com sont déjà signées par Zendesk.
- 2
Ajoutez ou fusionnez l'include SPF
Sur votre domaine racine, ajoutez un enregistrement TXT avec v=spf1 include:mail.zendesk.com -all (Zendesk recommande le hard fail -all). Si un enregistrement SPF existe déjà, ne publiez pas un second — fusionnez include:mail.zendesk.com dans la ligne v=spf1 existante, en le gardant comme mécanisme de premier niveau, et utilisez ~all jusqu'à ce que tous les autres expéditeurs soient listés.
- 3
Ajoutez les deux enregistrements CNAME DKIM
Créez deux enregistrements CNAME : l'hôte zendesk1._domainkey.yourdomain.com pointant vers zendesk1._domainkey.zendesk.com, et l'hôte zendesk2._domainkey.yourdomain.com pointant vers zendesk2._domainkey.zendesk.com. Il y en a deux parce que Zendesk fait tourner les clés DKIM par sécurité. Ce doivent être des enregistrements CNAME, pas TXT — Zendesk détient les clés derrière ces noms d'hôte.
- 4
Publiez un enregistrement DMARC
Ajoutez un enregistrement TXT à _dmarc.yourdomain.com avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement — cela ne change rien à la distribution pendant que vous confirmez que Zendesk passe DKIM aligné sur votre domaine. Conservez un seul enregistrement _dmarc pour l'ensemble du domaine.
- 5
Attendez la propagation des enregistrements
Laissez au DNS quelques heures (parfois jusqu'à une journée) pour se propager avant l'étape suivante. N'activez PAS encore la signature DKIM dans Zendesk — l'activer avant que les CNAME ne se résolvent est la cause la plus fréquente d'échecs de distribution Zendesk.
- 6
Activez la signature DKIM (doit être l'étape finale)
De retour dans le Centre d'administration → Canaux → Talk et e-mail → E-mail, trouvez le paramètre DKIM / signature numérique et sélectionnez Domaine personnalisé pour DKIM, puis cliquez sur Enregistrer. Zendesk est explicite : ce doit être la dernière chose que vous faites — l'activer avant que les enregistrements CNAME de votre domaine ne soient en service provoquera des échecs de distribution.
- 7
Envoyez une réponse de test et lisez les en-têtes
Répondez à un ticket de test pour que Zendesk envoie un vrai message sortant, ouvrez-le dans Gmail, et utilisez ⋮ → Afficher l'original. Confirmez DKIM: PASS signé par yourdomain.com (sélecteur zendesk1 ou zendesk2) et DMARC: PASS. SPF affichera pass mais non aligné (Return-Path sur un domaine zendesk.com) — c'est attendu et sans conséquence ; c'est DKIM qui porte DMARC.
- 8
Répétez pour chaque marque et domaine d'assistance
Chaque adresse d'assistance externe sur un domaine différent a besoin de son propre include SPF, de ses propres CNAME DKIM zendesk1/zendesk2, de son propre enregistrement DMARC, et de l'option Domaine personnalisé pour DKIM activée. Authentifier un domaine ne couvre pas les autres.
Enregistrements à ajouter
Zendesk 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 |
|---|---|---|
| TXT | @ | v=spf1 include:mail.zendesk.com -allSPF racine — conservez un seul enregistrement SPF et fusionnez-y include:mail.zendesk.com. Il passe mais ne s'aligne PAS (le Return-Path de Zendesk est un domaine zendesk.com), il ne porte donc pas DMARC à lui seul. Coûte 1 recherche DNS. |
| CNAME | zendesk1._domainkey | zendesk1._domainkey.zendesk.comClé DKIM 1. Cette cible est la même pour chaque client Zendesk (pas une valeur propre à chaque compte) ; seul le domaine de l'hôte est le vôtre. Zendesk fait tourner la clé qui se trouve derrière automatiquement. |
| CNAME | zendesk2._domainkey | zendesk2._domainkey.zendesk.comClé DKIM 2 — les deux sont requises car Zendesk fait tourner les clés. Également une cible partagée, identique pour tous les clients. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn enregistrement DMARC par domaine. C'est ce qui porte la réussite DMARC pour Zendesk — via l'alignement DKIM. Commencez à p=none, puis durcissez vers quarantine/reject une fois DKIM confirmé. |
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 Zendesk sur ce budget.
Zendesk utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM est l'endroit où le courrier Zendesk gagne réellement sa réussite DMARC, c'est donc l'enregistrement qui compte le plus. Vous publiez deux enregistrements CNAME — zendesk1._domainkey.yourdomain.com → zendesk1._domainkey.zendesk.com et zendesk2._domainkey.yourdomain.com → zendesk2._domainkey.zendesk.com — puis vous activez la signature dans le Centre d'administration. Quelques particularités propres à Zendesk à connaître. Premièrement, ce sont des CNAME, pas des clés TXT que vous collez : Zendesk détient les clés privées et publie les clés publiques derrière zendesk1._domainkey.zendesk.com et zendesk2._domainkey.zendesk.com, il peut donc les faire tourner (environ tous les trimestres) sans que vous ayez à toucher au DNS à nouveau — la recherche CNAME se résout toujours vers la clé courante. Deuxièmement, les deux noms d'hôte pointent vers les mêmes cibles partagées zendesk.com pour chaque client ; il n'y a pas de valeur propre à chaque compte, alors n'essayez pas de personnaliser la cible ni d'y coller un identifiant de compte. S'il y a deux sélecteurs (zendesk1 et zendesk2), c'est précisément pour rendre cette rotation transparente — l'un est actif tandis que l'autre est préparé. Troisièmement, DKIM ne fonctionne que pour un domaine e-mail externe ; vous ne pouvez pas signer en DKIM, comme votre propre domaine, un courrier envoyé depuis une adresse yourbrand.zendesk.com. Enfin, publier les CNAME ne fait rien tant que vous n'activez pas la signature : allez dans Centre d'administration → Canaux → Talk et e-mail → E-mail et sélectionnez Domaine personnalisé pour DKIM, puis Enregistrer — mais seulement après que les CNAME se sont propagés, car l'activer trop tôt provoque des échecs de distribution. Une fois en service, Zendesk signe avec d=yourdomain.com, ce qui s'aligne sur votre domaine From et fait passer DMARC.
DMARC
DMARC est un enregistrement de politique distinct que Zendesk ne crée jamais pour vous — vous le publiez vous-même en tant qu'enregistrement TXT à _dmarc.yourdomain.com, en commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement : cela ne change rien à la distribution mais demande aux destinataires de vous envoyer des rapports agrégés afin que vous puissiez confirmer que le courrier Zendesk passe. La réserve propre à Zendesk est que votre réussite DMARC dépend entièrement de DKIM, car le SPF de Zendesk ne s'aligne jamais (son Return-Path se trouve sur un domaine de rebond zendesk.com). Ainsi, avant de durcir la politique, servez-vous des rapports rua pour vous assurer que Zendesk apparaît comme aligné DKIM et passant — si vous passez à p=quarantine ou p=reject alors que DKIM est mal configuré, SPF ne peut pas compenser et vos réponses d'assistance commenceront à être mises en quarantaine ou rejetées. Surveillez les rapports pendant une semaine ou deux, confirmez que Zendesk et tout autre expéditeur légitime s'alignent, puis passez à p=quarantine et finalement à p=reject. Conservez exactement un enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre d'expéditeurs que vous utilisez ; n'en ajoutez jamais un second uniquement pour Zendesk.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul statut du Centre d'administration — confirmez-le sur un vrai message. Répondez à un ticket de test pour que Zendesk envoie un e-mail sortant depuis votre adresse d'assistance externe, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original. Vous voulez DKIM: PASS avec signed-by: yourdomain.com (sélecteur zendesk1 ou zendesk2) et DMARC: PASS. SPF indiquera pass mais non aligné — le mailed-by/Return-Path sera un domaine zendesk.com — et c'est attendu pour Zendesk, pas une mauvaise configuration, alors ne cherchez pas à obtenir l'alignement SPF. Vous pouvez vérifier ponctuellement les enregistrements bruts avec dig CNAME zendesk1._domainkey.yourdomain.com (il doit se résoudre jusqu'à zendesk.com) et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que chaque enregistrement se résout et que votre SPF reste sous la limite des 10 recherches, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Zendesk devrait apparaître comme une source alignée DKIM et passante, même si son SPF est non aligné.
Pièges courants
- Configuration DNS
Activez DKIM en dernier. Zendesk est explicite : sélectionner Domaine personnalisé pour DKIM avant que vos CNAME zendesk1/zendesk2 ne se soient propagés provoquera des échecs de distribution — publiez et laissez le DNS se stabiliser (quelques heures à une journée) d'abord, puis basculez l'interrupteur.
- Couverture
Le SPF ne s'alignera pas, par conception. Zendesk renvoie le courrier sortant sur son propre Return-Path zendesk.com, donc include:mail.zendesk.com fait passer le contrôle SPF brut mais ne s'aligne jamais sur votre domaine et ne peut pas porter DMARC seul. C'est DKIM qui s'aligne — ne perdez pas de temps à forcer l'alignement SPF ; Zendesk n'offre aucun moyen de le faire.
- Couverture
DKIM ne fonctionne que sur un domaine e-mail externe. Un courrier envoyé depuis une adresse yourbrand.zendesk.com ne peut pas être signé comme votre domaine — vous devez d'abord ajouter et vérifier une adresse d'assistance sur votre propre domaine (support@yourdomain.com).
- Configuration DNS
Les cibles CNAME DKIM sont partagées, pas uniques. Les deux pointent vers zendesk1._domainkey.zendesk.com / zendesk2._domainkey.zendesk.com pour chaque client Zendesk — n'essayez pas d'ajouter un identifiant de compte ni de « personnaliser » la cible, et ne les publiez pas comme enregistrements TXT.
- Casse l'authentification
Conservez exactement un enregistrement SPF et gardez l'include en premier niveau. Si vous envoyez déjà via Google Workspace, Microsoft 365, etc., fusionnez include:mail.zendesk.com dans cette unique ligne v=spf1 — deux enregistrements SPF, c'est un PermError, et enfouir l'include dans une recherche imbriquée peut l'empêcher de se résoudre au premier niveau.
- Couverture
-all vs ~all. Zendesk recommande le hard fail -all, mais si votre SPF ne liste pas encore tous les expéditeurs légitimes, -all fera échouer durement cet autre courrier. Utilisez ~all jusqu'à ce que vous ayez énuméré tous les expéditeurs, puis durcissez vers -all.
- Configuration DNS
Doublement du champ hôte. De nombreux registrars ajoutent automatiquement votre domaine, donc saisir zendesk1._domainkey.yourdomain.com produit zendesk1._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement le libellé zendesk1._domainkey si le panneau ajoute le domaine pour vous.
- Configuration DNS
Plusieurs marques et domaines nécessitent chacun le jeu complet. Chaque domaine d'assistance externe a besoin de son propre include SPF, de ses propres deux CNAME DKIM, de son propre enregistrement DMARC, et de Domaine personnalisé pour DKIM activé — la configuration d'un domaine ne couvre pas les autres.
Construisez votre enregistrement SPF
Zendesk est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
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).
- 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 Zendesk — 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.