Skip to main content
La délivrabilité se joue dans le DNS avant qu’un seul octet de courrier ne circule. Un serveur destinataire interroge votre domaine et lui demande qui est autorisé à envoyer pour lui, ce message est-il intact et authentique, et puis-je vous joindre sur du TLS imposé. Il répond à ces questions uniquement à partir des enregistrements que vous publiez. Cette page est le contrat DNS de l’opérateur : ce qu’il faut publier pour un domaine de courrier, pourquoi chaque enregistrement existe, comment OxiMail le génère et le sert, et comment vérifier le résultat. Deux commandes encadrent tout le flux :
  • oximail setup provisionne le jeu complet d’enregistrements. Avec --cloudflare-token, il les écrit directement dans la zone via l’API Cloudflare (de façon idempotente : un enregistrement existant est laissé en place). Sans token, il vous indique de créer les enregistrements à la main.
  • oximail check-dns effectue des résolutions en direct et note le domaine. Il interroge via Cloudflare (1.1.1.1 / 1.0.0.1) avec la validation DNSSEC activée, en contournant délibérément les caches locaux périmés et les résolveurs split-horizon qui induisent en erreur pendant l’installation. Le rapport se termine par n/n -- Ready for production ou n/n -- Fix the items above.
Lancez oximail check-dns depuis le serveur après chaque changement DNS. Le DNSSEC est imposé sur les résolutions TXT : une zone au DNSSEC cassé remonte comme une erreur franche plutôt que d’accepter en silence des enregistrements falsifiés.

​
Le jeu d’enregistrements

Pour un domaine de courrier example.com servi par l’hôte mail.example.com à l’IP 203.0.113.10, le jeu complet provisionné par OxiMail est : Les sections ci-dessous expliquent les enregistrements qui portent une vraie politique. Les enregistrements MX, A et SRV sont mécaniques : publiez-les et vérifiez avec check-dns.

​
SPF

OxiMail publie un enregistrement SPF strict, à source unique :
ip4:203.0.113.10 autorise exactement votre hôte de courrier. -all est un échec strict : toute autre IP prétendant envoyer en tant que example.com est rejetée d’emblée. C’est le bon réglage par défaut pour un serveur auto-hébergé unique. Ajustez-le à la main si votre topologie est plus large :
  • Envoi depuis plusieurs IP (un hôte MX de secours, un relais séparé) : ajoutez chaque mécanisme ip4: / ip6:, par exemple v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all.
  • Relais via un tiers (un fournisseur transactionnel) : ajoutez son include: publié, par exemple include:_spf.example-relay.com.
  • Expéditeurs en IPv6 : SPF n’autorise que ce qu’il liste. Si votre MX envoie aussi en IPv6, ajoutez le mécanisme ip6: correspondant, sinon le courrier IPv6 échoue strictement au SPF chez le destinataire.
check-dns évalue SPF par la présence directe de l’IP et +all uniquement. Il ne descend pas dans les directives include: ou redirect=. Si vous dépendez d’un include:, vérifiez aussi l’alignement avec un validateur SPF externe.

​
DKIM

DKIM signe chaque message sortant avec une clé privée. Les destinataires récupèrent la clé publique dans le DNS et vérifient la signature. OxiMail signe au moment de la remise, dans le worker sortant (voir la couche SMTP). Générez la clé et relisez l’enregistrement à publier :
Cela écrit la clé privée dans /etc/oximail/dkim/example.com.default.key et imprime l’enregistrement DNS correspondant :
  • Le sélecteur est default. Le nom DNS est toujours <sélecteur>._domainkey.<domaine>, donc une rotation publie un nouveau sélecteur à côté de l’ancien, laisse les deux vérifier pendant la bascule, puis retire l’ancien enregistrement.
  • L’algorithme est RSA par défaut (k=rsa). L’assistant setup complet publie l’enregistrement RSA automatiquement quand il est lancé avec un token Cloudflare.
  • Sursignature. La liste h= de la signature nomme From, To et Subject une fois de plus, pour qu’un acteur en aval ne puisse pas injecter une seconde copie d’un en-tête critique pour l’affichage sans invalider la signature (RFC 6376 §8.15). Aucune action opérateur : c’est ainsi qu’OxiMail signe.
Côté entrant, dkim=fail dit pourquoi. Le motif de vérification voyage désormais à côté du verdict, jusque dans l’en-tête Authentication-Results et dans le résultat conservé par message. Une analyse après coup peut donc séparer des cas qu’un verdict nu confondait, et qui appellent des actions opposées : Le motif retenu est celui de la première signature non passante. Un pass n’en porte aucun, délibérément : une mauvaise signature à côté d’une bonne est normale, les listes de diffusion resignent, et dkim=pass reason=... se lirait comme un défaut là où il n’y en a pas.
Quand vous ajoutez un domaine de courrier après l’installation initiale, générez et publiez son enregistrement DKIM explicitement. Un domaine dont la clé existe mais dont l’enregistrement TXT default._domainkey est absent signera du courrier que les destinataires rejetteront ensuite en dkim=fail (aucune clé trouvée). Lancez oximail check-dns pour chaque domaine afin de confirmer que la vérification DKIM passe.

​
DMARC

DMARC indique aux destinataires quoi faire quand un message échoue à l’alignement SPF et DKIM, et où envoyer les rapports agrégés. Le réglage par défaut d’OxiMail est :
p=quarantine dirige le courrier en échec vers le dossier Indésirables du destinataire. Adaptez la politique à votre étape de déploiement :
  • p=none : surveillance seule. Publiez ceci d’abord si vous n’êtes pas sûr que vos SPF et DKIM sont corrects. Lisez les rapports agrégés rua, puis durcissez.
  • p=quarantine : le défaut d’OxiMail. Le courrier en échec est mis en indésirable, pas refusé.
  • p=reject : le courrier en échec est refusé au moment du SMTP. Côté réception, OxiMail respecte un p=reject de l’expéditeur avec un rejet 550 5.7.26 (voir la couche SMTP).
Assurez-vous que la boîte rua existe et est surveillée. C’est là que vous apprenez qu’une source légitime est en échec, avant que les destinataires ne cessent de voir votre courrier.

​
MTA-STS et TLS-RPT

MTA-STS (RFC 8461) vous permet d’exiger que les autres serveurs utilisent un TLS validé quand ils vous remettent du courrier, fermant la fenêtre de repli en clair que le simple STARTTLS opportuniste laisse ouverte. Il a trois parties mobiles, et OxiMail sert lui-même la politique :
  1. L’enregistrement TXT _mta-sts.example.com = v=STSv1; id=<AAAAMMJJ> annonce qu’une politique existe. L’id change chaque fois que la politique change.
  2. L’hôte de politique mta-sts.example.com (un CNAME vers votre hôte de courrier) est l’endroit où les expéditeurs récupèrent la politique en HTTPS.
  3. Le serveur sert /.well-known/mta-sts.txt à partir du bloc de configuration [mta_sts] :
  • enforce : les expéditeurs qui respectent MTA-STS refusent de vous remettre du courrier sur du TLS non validé.
  • testing : la politique est publiée mais les échecs sont signalés, pas imposés. Utilisez ce mode pendant la validation, puis passez à enforce.
  • none : retire la politique.
TLS-RPT (RFC 8460) est le compagnon qui vous donne de la visibilité :
Les destinataires envoient des rapports quotidiens des échecs de connexion TLS à l’adresse rua. C’est ainsi que vous détectez une politique mal configurée ou une tentative de repli active. Comme pour DMARC, surveillez cette boîte.

​
DANE (TLSA)

DANE (RFC 7672) est l’alternative à MTA-STS ancrée dans DNSSEC : un enregistrement TLSA sous _25._tcp.mail.example.com épingle votre certificat, de sorte qu’un expéditeur valide le TLS contre le DNS plutôt que contre une liste d’autorités de certification publiques. Il exige une zone signée DNSSEC. OxiMail impose DANE sur le chemin sortant par défaut, et tient vos enregistrements TLSA entrants à jour automatiquement après chaque renouvellement de certificat. Comme un certificat renouvelé change la valeur épinglée, cela exige un fournisseur DNS configuré :
Quand dane_enabled = true (le défaut), [dns] provider doit être renseigné, sinon le serveur refuse de démarrer (fail-loud, ADR-027). Sans fournisseur, un renouvellement ACME laisserait en silence vos enregistrements TLSA périmés et casserait le courrier entrant pour tout expéditeur qui valide DANE.
Les options de fournisseur :
  • cloudflare : republie automatiquement les nouveaux enregistrements TLSA via l’API Cloudflare après chaque renouvellement ACME. Recommandé.
  • manual : vous mettez à jour les enregistrements TLSA hors bande. Le renouvellement journalise un avertissement pour vous le rappeler.
  • rfc2136 : un embryon v1 qui se comporte actuellement comme manual (journalise le même avertissement). L’implémentation de la mise à jour dynamique est reportée.
Voir TLS et ACME pour l’émission et le renouvellement des certificats.

​
DNS inverse (PTR) et délivrabilité

Le DNS inverse est publié par celui qui contrôle le bloc d’IP (votre hébergeur : Hetzner, OVH, AWS…), pas dans la zone de votre domaine. C’est l’un des signaux de réputation les plus forts dont dispose un destinataire.
  • Réglez le PTR de 203.0.113.10 sur mail.example.com, le même nom que votre serveur utilise dans son HELO/EHLO SMTP. Beaucoup de gros destinataires rejettent ou pénalisent lourdement une divergence (absence de FCrDNS).
  • check-dns valide la vérification PTR quand l’enregistrement résout vers le domaine de courrier ou un sous-domaine de celui-ci. Pour un résultat optimal, faites-le résoudre exactement vers votre hôte de courrier et confirmez que l’enregistrement A direct pointe en retour vers la même IP.
  • Une IP neuve n’a aucune réputation d’envoi. Faites une montée en charge progressive et gardez un volume régulier. Un pic soudain depuis une IP froide ressemble à un hôte compromis.

​
Autodécouverte

Les clients de messagerie trouvent vos points d’accès à partir des enregistrements SRV et des CNAME autoconfig / autodiscover du tableau ci-dessus. Le oximail setup complet publie aussi un enregistrement CAA restreignant l’émission de certificats à Let’s Encrypt, ce qui durcit le domaine et correspond à la configuration ACME d’OxiMail. Aucun de ces enregistrements ne porte de politique ajustable : publiez-les et laissez check-dns confirmer.

​
Vérifier avec oximail check-dns

Le rapport exécute dix vérifications en direct (MX, DNS inverse PTR, SPF, DKIM, DMARC, TLS-RPT et les quatre enregistrements SRV) et imprime une ligne réussite/échec pour chacune :
La politique MTA-STS et les enregistrements TLSA DANE sont imposés par le serveur au moment de l’envoi et servis depuis l’hôte de politique, plutôt que re-vérifiés ici. Validez-les avec un vérificateur MTA-STS / DANE externe après publication. Échecs courants :
  • Divergence PTR : corrigez l’enregistrement inverse chez votre hébergeur, pas dans votre zone.
  • DKIM « no record » : vous avez généré la clé mais pas publié l’enregistrement TXT. Voir la section DKIM ci-dessus.
  • SPF « does not include IP » : votre IP d’envoi n’est pas listée. Ajoutez le mécanisme ip4: / ip6:.
  • « Lookup failed » : un délai de propagation (attendez et relancez) ou une zone au DNSSEC cassé (la résolution échoue franchement plutôt que de faire confiance à une réponse non validée).

​
Standards

  • RFC 7208 : Sender Policy Framework (SPF).
  • RFC 6376 : DomainKeys Identified Mail (DKIM).
  • RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC).
  • RFC 8461 : SMTP MTA Strict Transport Security (MTA-STS).
  • RFC 8460 : SMTP TLS Reporting (TLS-RPT).
  • RFC 7672 : SMTP Security via Opportunistic DANE TLS.
Pour savoir comment ces enregistrements sont consommés et imposés sur le fil, voir la couche SMTP. Pour l’émission des certificats, voir TLS et ACME. Pour le pipeline anti-spam que l’authentification alimente, voir anti-spam.