Configuration DNS de Zoho Mail : MX, SPF, DKIM et DMARC

Étapes

1. Ajoutez et vérifiez le domaine. Ajoutez le domaine dans la console d'administration Zoho Mail et publiez l'enregistrement TXT (ou CNAME) de vérification qu'elle affiche.
2. Créez les utilisateurs et les alias. Créez chaque adresse avant de déplacer les MX.
3. Publiez les enregistrements MX. Supprimez les anciens enregistrements MX et ajoutez les trois enregistrements Zoho avec les priorités 10, 20 et 50.
4. Publiez SPF. Copiez la valeur SPF depuis la console d'administration : le nom de l'include: diffère d'un centre de données Zoho à l'autre. Gardez un seul enregistrement SPF.
5. Ajoutez un sélecteur DKIM. Dans la console d'administration, créez un sélecteur, publiez l'enregistrement TXT sous <selector>._domainkey, puis vérifiez-le dans la console pour que Zoho commence à signer.
6. Ajoutez DMARC et contrôlez. Publiez un enregistrement DMARC avec p=none, puis lancez les vérifications de cette page.

DMARC

DMARC est identique chez tous les fournisseurs : un enregistrement TXT sous _dmarc.example.com. Commencez par p=none et une adresse de rapport, afin de recevoir des rapports sans affecter la livraison.

Lisez les rapports pendant quelques semaines. Lorsque chaque expéditeur légitime réussit SPF ou DKIM avec un domaine aligné, passez à p=quarantine, puis à p=reject. Passer à reject avant que DKIM soit activé pour tous les expéditeurs est la façon habituelle de perdre des e-mails légitimes.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Facultatif : MTA-STS, TLS-RPT et BIMI

MTA-STS demande aux serveurs expéditeurs d'exiger TLS lorsqu'ils vous livrent des e-mails. Il lui faut un enregistrement TXT et un fichier de politique servi en HTTPS sous mta-sts.example.com ; la politique doit lister exactement les hôtes MX de votre fournisseur.

TLS-RPT demande aux expéditeurs de signaler les échecs de livraison TLS à une adresse que vous choisissez. Un seul enregistrement TXT, sans effet sur la livraison.

BIMI permet à certains fournisseurs de messagerie d'afficher votre logo. Il exige DMARC en quarantine ou en reject, et la plupart des fournisseurs exigent aussi un certificat de marque vérifiée.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Conseils sur le TTL

Avant de modifier les enregistrements MX d'un domaine qui reçoit déjà des e-mails, abaissez leur TTL à 300 secondes et attendez que l'ancien TTL soit écoulé. Les résolveurs prennent alors en compte les nouveaux enregistrements en quelques minutes.

Quand la nouvelle configuration fonctionne depuis quelques jours, remontez le TTL : 3600 secondes est une valeur courante. Les enregistrements SPF, DKIM et DMARC changent rarement et peuvent rester à 3600.

Combien de temps prennent les modifications ?

Vos serveurs de noms faisant autorité répondent avec le nouvel enregistrement dès que votre hébergeur DNS l'a publié. Un résolveur qui a mis l'ancienne réponse en cache la garde jusqu'à l'expiration de l'ancien TTL ; un nom qui n'existait pas auparavant peut être mémorisé comme absent pendant la durée de cache négatif de votre enregistrement SOA.

Il n'existe aucun moment où une modification est présente partout à la fois. L'outil de propagation montre ce que répond un ensemble fixe de résolveurs publics au moment de la vérification, sous forme d'un décompte tel que « 9 résolveurs sur 12 », et rien de plus.

Les fournisseurs recontrôlent vos enregistrements à leur propre rythme ; un bouton de vérification dans l'interface peut donc rester rouge un moment alors que le DNS est déjà correct.

Erreurs fréquentes

• Utiliser les noms d'hôte en .com pour un compte hébergé dans une autre région. Les e-mails sont alors refusés, car le domaine n'est pas connu dans ce centre de données.
• Deux enregistrements SPF. Un domaine ne peut avoir qu'un seul enregistrement TXT commençant par v=spf1 ; un second fait échouer SPF avec une erreur permanente. Fusionnez les mécanismes include: dans un seul enregistrement.
• Laisser les enregistrements MX de l'ancien fournisseur à côté des nouveaux. Les e-mails sont alors livrés à l'un ou à l'autre, selon la priorité et le hasard.
• Saisir le nom complet dans un champ d'hôte qui ajoute le domaine, ce qui produit google._domainkey.example.com.example.com. Recherchez l'enregistrement après l'avoir enregistré.
• Une clé DKIM coupée en deux. Les valeurs TXT longues doivent être découpées en chaînes entre guillemets de 255 caractères au plus ; la plupart des hébergeurs DNS le font pour vous, certains non.
• Plus de dix requêtes DNS dans SPF après l'ajout de plusieurs mécanismes include:. La vérification SPF les compte.
• Un enregistrement MX qui pointe vers un CNAME ou vers une adresse IP. Il doit pointer vers un nom d'hôte qui possède des enregistrements A ou AAAA.