Configuration DNS de la messagerie Yandex 360 : MX, SPF, DKIM et DMARC

Étapes

1. Ajoutez et confirmez le domaine. Ajoutez le domaine dans l'interface d'administration et confirmez-le avec l'enregistrement TXT qu'elle affiche (d'autres méthodes sont aussi proposées).
2. Créez les boîtes aux lettres. Créez chaque adresse avant de déplacer les MX.
3. Publiez l'enregistrement MX. Supprimez les anciens enregistrements MX et ajoutez un enregistrement de priorité 10 qui pointe vers mx.yandex.net.
4. Publiez SPF. Ajoutez un enregistrement TXT à l'apex : v=spf1 redirect=_spf.yandex.net. Si d'autres services envoient pour le domaine, utilisez include:_spf.yandex.net avec leurs include et terminez l'enregistrement par ~all, car redirect ne peut pas être combiné avec all.
5. Publiez DKIM. Copiez la clé publique depuis l'interface d'administration dans un enregistrement TXT sous mail._domainkey.
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

• Ajouter d'autres expéditeurs après redirect=. Tout ce qui suit un redirect est ignoré, à moins de réécrire l'enregistrement avec include:.
• 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.