Zendesk active le profil Minimal : un SPF en échec peut bloquer vos messages au support

Vous avez écrit au support d'un éditeur et vous attendez toujours une réponse. Depuis le 23 septembre 2026, votre message a peut-être fini hors de la file des tickets. Zendesk fait passer au profil « Minimal » les comptes qui n'avaient activé aucun contrôle de l'expéditeur. Avec ce profil, un SPF en échec sans DKIM valide suffit pour qu'un email ne devienne jamais un ticket.

⚡TL;DR

• Depuis le 23 septembre 2026, les comptes Zendesk dont l'authentification des expéditeurs était désactivée basculent progressivement vers le profil « Minimal ».
• Pour ce profil, un SPF en échec est pire qu'un SPF absent : sans DKIM valide, le premier envoie l'email dans les tickets suspendus, le second le laisse passer avec un drapeau.
• Vérifiez le SPF et la signature DKIM de votre domaine. Si vous administrez Zendesk, surveillez la vue « Suspended tickets ».

Ce que change le profil Minimal par défaut

Zendesk a annoncé le 18 juin 2026 une nouvelle règle de sécurité pour l'authentification des expéditeurs. L'annonce officielle, mise à jour le 28 septembre 2026, décrit un déploiement en deux phases.

La phase 1 concerne les nouveaux comptes. Ils sont déjà créés avec le profil « Minimal » par défaut. La phase 2 vise les comptes existants dont l'authentification des expéditeurs est désactivée : Zendesk leur applique « Minimal » comme profil par défaut.

Le calendrier de cette phase 2 porte deux dates de fin sur la même page. Le tableau indique un début le 23 septembre 2026 et une fin le 22 octobre 2026. Le texte, lui, parle d'un déploiement progressif du 23 septembre au 16 décembre 2026. Nous citons les deux, car la page officielle ne dit pas laquelle prévaut. Un compte encore désactivé aujourd'hui peut donc basculer dans les semaines qui viennent, sans date précise.

L'administrateur du compte garde la main. Il peut désactiver l'authentification ou choisir un profil plus strict : « Native traffic » ou « Native and forwarded traffic (ARC) ». Une règle ne bouge pas : pour les emails envoyés par les agents, l'authentification reste toujours active et ne se désactive pas.

Suspendu, signalé ou accepté : les trois issues

La documentation Zendesk sur l'authentification des emails entrants présente « Minimal » comme le profil le moins strict. Il croise deux résultats. Le SPF vérifie que le serveur qui envoie le message figure dans la liste publiée par le domaine de l'expéditeur. Le DKIM vérifie une signature cryptographique ajoutée à l'envoi.

Résultat SPF	Résultat DKIM	Issue dans Zendesk
En échec	Absent ou en échec	Suspendu : vue « Suspended tickets », cause « Email authentication failed »
Non configuré pour le domaine expéditeur	En échec	Accepté, marqué « Potential spoofing » (usurpation possible)
Tous les autres cas	Tous les autres cas	Accepté

Un message suspendu ne devient pas un ticket. Il reste dans la vue « Suspended tickets » (tickets suspendus), avec la cause « Email authentication failed » (échec de l'authentification de l'email). Aucun agent ne le verra dans sa file habituelle.

La deuxième ligne mérite qu'on s'y arrête. Un domaine qui ne publie aucun SPF, avec une signature DKIM en échec, passe quand même. L'agent voit un avertissement, mais il reçoit le ticket.

Pourquoi un SPF en échec est pire qu'un SPF absent

Regardons la situation depuis le client, pas depuis l'éditeur. Vous écrivez depuis votre domaine au support d'un logiciel qui tourne sur Zendesk. Votre domaine publie un SPF, mais le serveur qui a remis votre message n'y figure pas : un nouveau prestataire d'envoi oublié, un include retiré par erreur. Le SPF échoue. Si votre message n'a pas de signature DKIM valide, Zendesk le suspend. Vous attendez une réponse ; l'éditeur, de son côté, n'a aucun ticket à traiter.

Le même message, venu d'un domaine sans SPF et avec le même DKIM en échec, serait arrivé avec le drapeau « Potential spoofing ». Pour ce profil, un SPF en échec pèse donc plus lourd qu'un SPF absent.

N'en concluez pas qu'il faut retirer votre SPF. Sans lui, votre domaine devient plus facile à usurper, et DMARC perd l'un des deux mécanismes sur lesquels il s'appuie. La bonne réponse consiste à réparer le SPF et à signer vos messages en DKIM. Dans le profil « Minimal », un DKIM valide suffit à éviter la suspension, même quand le SPF échoue.

Les transferts rendent ce point encore plus concret. Beaucoup d'éditeurs publient une adresse de support sur leur propre domaine, puis la redirigent vers Zendesk. Le serveur qui remet votre message à Zendesk n'est alors plus le vôtre, et votre SPF échoue souvent sans que votre enregistrement soit en cause. La signature DKIM, elle, reste valide tant que le relais ne modifie pas le message. C'est elle qui porte le message jusqu'au ticket.

Quoi vérifier, côté expéditeur puis côté admin Zendesk

Côté expéditeur, commencez par le SPF. Dressez la liste des services qui envoient des emails avec votre domaine : messagerie, CRM, facturation, outil de campagnes email. Chacun doit être autorisé par votre enregistrement. Le vérificateur SPF de CaptainDNS lit l'enregistrement publié, développe les include et teste si une adresse IP donnée est autorisée.

Vérifiez ensuite que chaque flux sortant porte une signature DKIM valide, faite avec votre domaine et pas seulement avec celui du prestataire. Une signature alignée sur votre domaine est celle que DMARC prend en compte. Si un message récent à un support est resté sans réponse, faites ces deux contrôles avant de le renvoyer : un nouvel envoi dans les mêmes conditions subira le même sort.

Côté admin Zendesk, la consigne de l'éditeur tient en une phrase : « Monitor your Suspended tickets view regularly », autrement dit surveillez régulièrement la vue des tickets suspendus. Zendesk ajoute que les problèmes de spam se règlent à la source (« Spam issues must be resolved at the source »). Un client légitime qui apparaît dans cette vue avec la cause « Email authentication failed » n'est pas forcément en faute : son SPF ou son DKIM est peut-être à corriger, mais un transfert peut aussi casser son SPF. Vérifiez d'abord vos propres redirections, puis prévenez-le par un autre canal s'il doit corriger son domaine.

Si votre adresse de support est un alias transféré vers Zendesk, regardez aussi le profil « Native and forwarded traffic (ARC) ». Il est plus strict que « Minimal », mais il s'appuie sur ARC, un mécanisme qui conserve les résultats d'authentification d'un relais à l'autre.

Un DKIM valide évite la suspension même quand le SPF échoue. Testez chaque sélecteur utilisé par vos services d'envoi.

Ce que cet article n'est pas

Ce billet ne détaille pas les règles que Gmail impose aux expéditeurs : notre article sur le durcissement des règles d'envoi Gmail de novembre 2025 les traite à part.

Ce n'est pas non plus un dépannage SPF. Pour une erreur de syntaxe, un mécanisme mal écrit ou le dépassement des 10 requêtes DNS, lisez le guide SPF PermError. Les signatures en échec ont leur propre article : DKIM fail, toutes les causes et comment les corriger.

Enfin, ce billet ne compare pas les outils de support du marché. Il s'en tient à Zendesk et à son profil « Minimal », d'après les deux pages officielles citées plus bas.

FAQ

Mon mail au support Zendesk n'a pas reçu de réponse, a-t-il été suspendu ?

C'est possible si le SPF de votre domaine a échoué et que votre message n'avait pas de DKIM valide. Il se trouve alors dans la vue « Suspended tickets » de l'éditeur, avec la cause « Email authentication failed ». Vérifiez votre SPF et votre DKIM, puis contactez l'éditeur par un autre canal.

Pourquoi un SPF en échec bloque-t-il alors qu'un SPF absent passe ?

Dans le profil « Minimal », Zendesk suspend un email quand le SPF échoue et que le DKIM est absent ou en échec. Si le domaine n'a pas configuré de SPF et que le DKIM échoue, l'email est accepté avec le drapeau « Potential spoofing ». Réparez votre SPF plutôt que de le supprimer.

Quand mon compte Zendesk basculera-t-il en Minimal ?

Les nouveaux comptes y sont déjà. Pour les comptes existants dont l'authentification est désactivée, la page officielle indique un début le 23 septembre 2026, avec une fin au 22 octobre 2026 dans son tableau et au 16 décembre 2026 dans son texte. Zendesk ne précise pas laquelle prévaut.

Comment éviter la suspension quand un mail est transféré ?

Signez vos messages avec un DKIM valide et aligné sur votre domaine : il reste valide si le relais ne modifie pas le message, alors que le SPF échoue souvent après un transfert. Côté admin, le profil « Native and forwarded traffic (ARC) » tient compte des messages transférés.

Sources : annonce Zendesk sur la nouvelle norme d'authentification des expéditeurs et documentation Zendesk sur l'authentification des emails entrants (SPF, DKIM, DMARC et ARC).