Comment surveiller les enregistrements MX et la santé du serveur de courrier

L'infrastructure de courrier électronique est l'une des parties les plus fragiles et les moins surveillées d'un service web typique. Les enregistrements MX sont modifiés lors d'une migration de fournisseur et ne sont jamais vérifiés. Les enregistrements SPF croissent jusqu'à dépasser la limite de 10 recherches et échouent silencieusement. Les clés DKIM tournent et la clé publique dans DNS n'est jamais mise à jour. Le résultat est une défaillance d'envoi intermittente ou complète qu'aucune surveillance au niveau de l'application ne détectera. Ce guide couvre ce qu'il faut surveiller aux niveaux DNS et SMTP pour que les défaillances surgissent avant que le client ne s'en aperçoive.

Ce qui peut mal se passer avec les enregistrements MX

Un enregistrement MX dirige les expéditeurs vers le serveur de courrier qui accepte les e-mails pour votre domaine. De mauvais enregistrements MX signifient qu'aucun e-mail n'arrive.

Les modes de défaillance courants : l'enregistrement MX a été mis à jour lors d'un changement de fournisseur, mais l'ancien enregistrement n'a pas été supprimé, produisant des serveurs concurrents. Une faute de frappe dans le nom d'hôte MX (mailserver.example.com au lieu de mailservers.example.com) route silencieusement tout vers un serveur inexistant. L'enregistrement MX pointe vers un nom d'hôte qui n'a pas d'enregistrement A. Chacun de ces cas produit une défaillance d'envoi partielle ou complète qu'un test côté boîte de réception détectera mais qu'une vérification DNS seule ne détectera pas.

Les quatre enregistrements DNS à surveiller

Quatre enregistrements DNS couvrent ensemble la configuration de la santé des e-mails. Surveillez tous les quatre pour chaque domaine à partir duquel vous envoyez.

• MX : les serveurs de courrier eux-mêmes. Alertez si l'enregistrement change de manière inattendue ou si le nom d'hôte résolu n'a pas d'enregistrement A.
• SPF (TXT à la racine) : quels serveurs sont autorisés à envoyer. Alertez sur les modifications et sur les enregistrements qui incluent plus de 10 recherches DNS imbriquées (un tue-livraison).
• DKIM (TXT à ._domainkey) : la clé publique qui vérifie les signatures sortantes. Alertez sur les modifications ; l'absence de DKIM signifie que la plupart des fournisseurs réduisent la confiance.
• DMARC (TXT à _dmarc) : la politique de gestion des défaillances SPF et DKIM. Alertez sur les modifications et sur les politiques trop permissives (p=none en production).

Vérifications au niveau SMTP au-delà du DNS

La surveillance au niveau DNS détecte les erreurs de configuration. La surveillance au niveau SMTP détecte un serveur de courrier qui est configuré correctement mais qui n'est pas réellement exécuté. Les deux sont nécessaires.

La vérification : ouvrez une connexion TCP au serveur de courrier sur le port 25 ou 587. Lisez la bannière SMTP (220 mail.example.com ESMTP). Fermez la connexion proprement. Exécutez toutes les heures. La vérification est légère et détecte l'échec où le serveur s'est écrasé mais le DNS pointe toujours dessus. Ajoutez la vérification TLS sur le port 587 si vous utilisez STARTTLS ; la plupart des serveurs de courrier modernes le font.

Surveillance de livraison de bout en bout

Les vérifications DNS et SMTP vous indiquent que l'infrastructure est active. Les vérifications de bout en bout vous indiquent que les e-mails sont réellement livrés. Deux modèles couvrent les cas courants.

• Test aller-retour : envoyez un e-mail de test de votre application à une boîte aux lettres que vous contrôlez (une adresse Gmail, une boîte aux lettres Mailosaur, une adresse interne). Vérifiez qu'il arrive dans quelques minutes.
• Outil externe : les services comme GlockApps, MXToolbox Inbox Insight et Mail-Tester notent la livraison entre les fournisseurs de boîte aux lettres. Vaut la peine de s'exécuter mensuellement si le courrier électronique est un facteur important du trafic.
• Boucle de rétroaction client : abonnez une adresse dédiée à votre propre liste de marketing. Si l'adresse de test cesse de recevoir votre courrier, les clients aussi.

Détecter les défaillances de recherche SPF 10

Les enregistrements SPF qui incluent plus de 10 recherches DNS (en comptant tous les includes, redirections et mécanismes a/mx) sont silencieusement rejetés par les serveurs de courrier récepteurs. Mode de défaillance classique : chaque nouveau SaaS que vous autorisez à envoyer en votre nom (Mailchimp, Customer.io, Sendgrid) est ajouté à vos includes SPF. Après le onzième, la livraison baisse silencieusement.

Surveillez le nombre de recherches SPF, pas seulement le contenu de l'enregistrement. Les outils comme dmarcian et le testeur SPF de Postmark rapportent le nombre. Alertez à 8 pour vous donner de la marge. Aplatissez l'enregistrement (remplacez les directives include : par leurs adresses IP résolues) si vous êtes près de la limite. Maintenez la version aplatie avec automation ; l'aplatissement manuel s'écarte.

Une pile de surveillance pour l'infrastructure e-mail

La configuration utile minimale : un moniteur MX sur le domaine apex, un moniteur SPF (contenu d'enregistrement TXT + nombre de recherches), un moniteur DKIM sur le sélecteur que vous utilisez réellement, un moniteur DMARC sur _dmarc, un moniteur de bannière SMTP sur le serveur de courrier principal sur le port 587. Ajoutez un test aller-retour de bout en bout une fois par jour à une boîte aux lettres que vous vérifiez réellement. Total : six moniteurs. Couverture totale : la plupart de la surface de défaillance des e-mails. Coût mensuel total sur une offre Pro : bien moins que ce que vous dépensez pour le café.