> ## Documentation Index > Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt > Use this file to discover all available pages before exploring further. # Authentification et sécurité du courrier > Les enregistrements DNS qui autorisent, authentifient et sécurisent votre courrier : MX, PTR, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DANE et le jeu d'autodécouverte. Provisionnez-les avec oximail setup et vérifiez-les avec oximail check-dns. 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 : | Enregistrement | Nom | Valeur | Rôle | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **MX** | `example.com` | `mail.example.com` (priorité 10) | Là où le monde remet votre courrier. Un MX de secours utilise la priorité 20. | | **A** | `mail.example.com` | `203.0.113.10` | L'adresse de l'hôte de courrier. | | **SPF** | `example.com` (TXT) | `v=spf1 ip4:203.0.113.10 -all` | Autorise votre IP à envoyer, refuse strictement toutes les autres. | | **DKIM** | `default._domainkey.example.com` (TXT) | `v=DKIM1; k=rsa; p=` | La clé publique que les destinataires utilisent pour vérifier votre signature. | | **DMARC** | `_dmarc.example.com` (TXT) | `v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com` | Que faire du courrier qui échoue à l'alignement SPF et DKIM, et où envoyer les rapports. | | **MTA-STS** | `_mta-sts.example.com` (TXT) | `v=STSv1; id=` | Annonce que vous publiez une politique MTA-STS. | | **Hôte de politique MTA-STS** | `mta-sts.example.com` (CNAME) | `mail.example.com` | Là où le fichier de politique est servi (`/.well-known/mta-sts.txt`). | | **TLS-RPT** | `_smtp._tls.example.com` (TXT) | `v=TLSRPTv1; rua=mailto:tls-reports@example.com` | Là où les destinataires signalent les échecs de connexion TLS. | | **CAA** | `example.com` | émission restreinte à `letsencrypt.org` | Restreint l'autorité de certification autorisée à émettre pour le domaine. | | **autoconfig** | `autoconfig.example.com` (CNAME) | `mail.example.com` | Auto-configuration des clients façon Thunderbird. | | **autodiscover** | `autodiscover.example.com` (CNAME) | `mail.example.com` | Auto-configuration des clients façon Outlook. | | **SRV** | `_submission._tcp` (587), `_imaps._tcp` (993), `_caldavs._tcp` (443), `_carddavs._tcp` (443), `_autodiscover._tcp` (443) | priorité/poids + port vers `mail.example.com` | Permet aux clients de découvrir les points d'accès soumission, IMAP, CalDAV, CardDAV et autodiscover. | 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 : ```text theme={null} example.com. TXT "v=spf1 ip4:203.0.113.10 -all" ``` `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](../architecture/oximail-smtp)). Générez la clé et relisez l'enregistrement à publier : ```bash theme={null} oximail setup dkim --domain example.com --selector default ``` Cela écrit la clé privée dans `/etc/oximail/dkim/example.com.default.key` et imprime l'enregistrement DNS correspondant : ```text theme={null} default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..." ``` * Le **sélecteur** est `default`. Le nom DNS est toujours `._domainkey.`, 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 : | Ce qui a échoué | Ce que cela veut dire pour vous | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | La signature est cryptographiquement invalide | Un signal d'abus. Rien à corriger chez vous. | | Le corps a été modifié en transit | En général un équipement intermédiaire ou un gestionnaire de liste entre l'expéditeur et vous. | | Aucune clé publique n'a été trouvée | Un problème de DNS chez l'expéditeur, pas chez vous. | | La signature est datée dans le futur | **Votre horloge retarde.** Voir la note sur l'horloge dans [l'exploitation](./operations#quand-quelque-chose-ne-va-pas). | 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 : ```text theme={null} _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` `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](../architecture/oximail-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=` 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]` : ```toml theme={null} [mta_sts] mode = "enforce" # "enforce" | "testing" | "none" (défaut : enforce) mx = "mail.example.com" max_age = 604800 # durée de cache de la politique en secondes (défaut : 7 jours) ``` * **`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é : ```text theme={null} _smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ``` 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é : ```toml theme={null} [smtp] dane_enabled = true # défaut [dns] # Requis quand dane_enabled = true. Valeurs : "cloudflare" | "rfc2136" | "manual" provider = "cloudflare" cloudflare_api_token = "votre-token-api" ``` 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](./tls-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 ```bash theme={null} oximail check-dns --domain example.com --ip 203.0.113.10 --selector default ``` 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 : ```text theme={null} DNS Check Report for example.com Expected IP: 203.0.113.10 DKIM selector: default ------------------------------------------------------------ ✅ MX: Found: mail.example.com (priority 10) ✅ rDNS (PTR): PTR records: mail.example.com ✅ SPF: SPF record includes IP 203.0.113.10: v=spf1 ip4:203.0.113.10 -all ✅ DKIM: Found DKIM record at default._domainkey.example.com ✅ DMARC: Found: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com ... ------------------------------------------------------------ 10/10 -- Ready for production ``` 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](https://www.rfc-editor.org/rfc/rfc7208) : Sender Policy Framework (SPF). * [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376) : DomainKeys Identified Mail (DKIM). * [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) : Domain-based Message Authentication, Reporting, and Conformance (DMARC). * [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461) : SMTP MTA Strict Transport Security (MTA-STS). * [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460) : SMTP TLS Reporting (TLS-RPT). * [RFC 7672](https://www.rfc-editor.org/rfc/rfc7672) : SMTP Security via Opportunistic DANE TLS. Pour savoir comment ces enregistrements sont consommés et imposés sur le fil, voir [la couche SMTP](../architecture/oximail-smtp). Pour l'émission des certificats, voir [TLS et ACME](./tls-acme). Pour le pipeline anti-spam que l'authentification alimente, voir [anti-spam](./anti-spam).