Les 7 enregistrements DNS dont tout expéditeur d'email auto-hébergé a besoin

L'email a ceci d'inhabituel qu'une configuration d'expéditeur complète comporte sept enregistrements DNS distincts répartis sur trois ou quatre types d'enregistrements. Loupez-en un et le câble continue de faire passer les messages, mais les fournisseurs de messagerie vous déclasseront silencieusement vers le dossier spam. Publiez les sept et vous franchissez le seuil « tout ce que Google demande » du /guide/email-deliverability.

L'ordre compte : SPF et DKIM doivent être posés avant que DMARC ne commence à imposer l'alignement, sinon du courrier légitime part en quarantaine. La règle en vigueur chez tous les fournisseurs est aussi « attendez la propagation DNS » — laissez au moins 30 minutes entre la publication d'un enregistrement et la demande de re-vérification au fournisseur de messagerie.

Les enregistrements MX (RFC 1035 §3.3.9) indiquent au monde où livrer le courrier entrant pour votre domaine. Même si votre domaine d'envoi est « outbound only » (vous ne lisez pas les réponses dessus), un enregistrement MX reste exigé — de nombreux fournisseurs de messagerie dégradent la réputation des domaines sans MX, en partant du principe que les expéditeurs légitimes acceptent les réponses. Un seul enregistrement pointant sur n'importe quel serveur de mail joignable suffit, même si ce serveur ne livre que vers une boîte postmaster.

SPF (RFC 7208) est un unique enregistrement TXT qui liste les IPs autorisés à envoyer pour le domaine. Règle dure : le total des lookups DNS récursifs doit rester sous 10 (RFC 7208 §4.6.4). Chaque include: en consomme un ; les includes imbriqués comptent cumulativement. Les mécanismes ip4: / ip6: coûtent zéro lookup, donc rabattez les anciens includes en plages IP explicites si votre compteur grimpe.

Terminez par -all (hard-fail) une fois que vous avez vérifié que toutes les sources d'envoi légitimes sont couvertes. Si vous n'êtes pas encore sûr, démarrez en ~all (soft-fail) et resserrez en -all après deux semaines de rapports DMARC propres.

DKIM (RFC 6376) publie la moitié publique d'une paire de clés de signature comme enregistrement TXT à {selector}._domainkey.{domain}. Le « selector » est un identifiant que vous choisissez — spécifique au vendor ou arbitraire. Pour SES, AWS vous donne trois CNAMEs qui résolvent vers des enregistrements TXT gérés par AWS (afin qu'AWS puisse faire tourner les clés sans que vous touchiez au DNS) :

Pour Postal auto-hébergé ou Postfix+OpenDKIM, vous générez la paire de clés localement, configurez le MTA pour signer, et publiez la moitié publique en TXT :

Quel que soit le chemin pris, vérifiez avec dig TXT {selector}._domainkey.{domain} avant de déclarer DKIM terminé.

DMARC (RFC 7489) se place à _dmarc.{domain}. Sauter la rampe en p=none est l'erreur la plus fréquente — passer direct à p=reject sur un domaine dont vous ne maîtrisez pas encore tous les flux de mail rejettera silencieusement du courrier légitime (forwarders, mailing lists, expéditeurs CRM tiers).

Lisez les rapports agrégés XML quotidiens qui atterrissent dans votre boîte rua entre les étapes. Des outils comme le DMARC analyzer de Postmark ou Parsedmarc auto-hébergé les visualisent ; le XML brut est dense mais lisible.

Par défaut, le pixel d'ouverture et les URLs de tracking de clic AcelleMail viennent du domaine primaire de votre installation. Les fournisseurs de messagerie aiment voir des domaines racine cohérents entre le From, les clics de liens et l'URL de désabonnement — tous sur le même domaine enregistré. Côté image de marque, des liens pointant sur tracker.yourcompany.com envoient aussi un meilleur signal de confiance que des liens vers links.acellemail.com.

Une fois le CNAME résolu, AcelleMail réécrit toutes les URLs de tracking de clic dans les messages sortants pour l'utiliser. Le domaine du lien de désabonnement suit la même règle (et le même CNAME).

MTA-STS (RFC 8461) dit aux autres expéditeurs « exigez toujours TLS en livrant vers mon MX ». Sans cela, un attaquant sur le chemin peut rétrograder un handshake TLS-capable en cleartext. Avec, le serveur d'envoi refuse de livrer si TLS ne peut être établi. L'implémentation, c'est un TXT qui pointe sur un fichier de politique hébergé :

Faites tourner la politique en mode: testing la première semaine, puis basculez en mode: enforce. Beaucoup d'expéditeurs bulk zappent MTA-STS — le déployer est un signal de confiance gratuit.

BIMI (Brand Indicators for Message Identification) est le plus jeune des sept et le seul qui ne soit pas encore une RFC finalisée, mais il est supporté par Gmail, Yahoo, Apple Mail, Fastmail et d'autres clients en production. Le deal : publier un TXT pointant sur un logo SVG et (en option) un Verified Mark Certificate (VMC), et les clients qui le supportent affichent le logo à côté de vos messages dans la liste de la boîte de réception.

Préconditions : une politique DMARC d'au moins p=quarantine (BIMI n'est pas honoré sous p=none), et le SVG doit être SVG Tiny Portable / Secure (SVG-PS). L'acceptation varie : Gmail exige un VMC payant (1 500 $/an via DigiCert / Entrust) pour l'affichage complet en liste de boîte ; Yahoo et Apple acceptent BIMI sans VMC. Des hausses de taux d'ouverture de 5-20 % sont fréquemment rapportées dans les études de cas publiées.

Après publication, envoyez-vous un test et inspectez les en-têtes. Gmail web : ouvrez le message, cliquez sur le menu trois-points, « Afficher l'original ». Cherchez :

Trois verdicts pass : c'est la barre. Tout en dessous — fail, softfail, neutral — signifie qu'un enregistrement est faux, que le DNS n'a pas encore propagé, ou que le corps du mail est modifié en transit (rare). Recoupez avec la spec canonique de l'en-tête Authentication-Results (RFC 8601) si un verdict est ambigu.