Aller au contenu

Configuration DNS pour HIN Gateway

Ce guide couvre tous les enregistrements DNS requis pour un déploiement fonctionnel de HIN Gateway. Configurez ces enregistrements avant d'installer HIN Gateway ou immédiatement après, selon le type d'enregistrement.

Tout au long de ce guide:

  • <HIN Gateway_IP> - l'adresse IP publique statique de votre serveur HIN Gateway (SERVER_STATIC_IP dans customer-config.sh)
  • <MAIL_HOSTNAME> - le FQDN du relais HIN Gateway (ex. mail.example.ch ; configuré via la page /mail du tableau de bord)
  • <YOUR_DOMAIN> - votre domaine de courrier (ex. example.ch ; configuré via la page /mail du tableau de bord)

Résumé des enregistrements

Enregistrement Nom Valeur Requis Quand
A <MAIL_HOSTNAME> <HIN Gateway_IP> Oui Avant l'installation
MX <YOUR_DOMAIN> <MAIL_HOSTNAME> (priorité 15) Oui Avant l'installation
SPF <YOUR_DOMAIN> ip4:<HIN Gateway_IP> ajouté au TXT Oui Avant l'installation
PTR <HIN Gateway_IP> <MAIL_HOSTNAME> Recommandé Avant l'installation
DMARC _dmarc.<YOUR_DOMAIN> v=DMARC1; p=none; ... Recommandé Après l'installation
DKIM selector._domainkey.<YOUR_DOMAIN> Depuis M365/fournisseur Recommandé Après l'installation

Pour les déploiements multi-domaines, répétez les enregistrements MX, SPF, DMARC et DKIM pour chaque domaine répertorié dans MAIL_DOMAINS.

Enregistrements requis

Enregistrement A

Créez un enregistrement A pointant le nom d'hôte du courrier HIN Gateway vers l'IP publique du serveur:

<MAIL_HOSTNAME>.    A    <HIN Gateway_IP>

Exemple:

mail.example.ch.    A    128.140.117.200

Si HIN Gateway dispose d'une adresse IPv6, ajoutez également un enregistrement AAAA:

mail.example.ch.    AAAA    2a01:4f8:c012:1234::1

Pourquoi: Les serveurs de courrier externes se connectent à ce nom d'hôte pour livrer les courriels. Sans l'enregistrement A, l'enregistrement MX ci-dessous n'est pas résolvable.

Enregistrements MX

Ajoutez un enregistrement MX pour HIN Gateway avec une priorité plus élevée (nombre inférieur) que le serveur de courrier existant. Cela garantit que les courriels entrants atteignent d'abord HIN Gateway pour le traitement S/MIME avant d'être transférés vers Exchange ou votre plateforme de courrier.

<YOUR_DOMAIN>.    MX    15    <MAIL_HOSTNAME>.

Conservez l'enregistrement MX existant d'Exchange / serveur de courrier avec une priorité inférieure (nombre supérieur):

<YOUR_DOMAIN>.    MX    20    <YOUR_DOMAIN>.mail.protection.outlook.com.

Exemple (ensemble MX complet):

example.ch.    MX    15    mail.example.ch.
example.ch.    MX    20    example-ch.mail.protection.outlook.com.

Info

Un numéro MX inférieur signifie une priorité plus élevée. HIN Gateway avec la priorité 15 reçoit les courriels avant Exchange Online avec la priorité 20.

Pourquoi: HIN Gateway intercepte les courriels entrants, traite S/MIME, puis les transfère au prochain MX (Exchange). Le deuxième enregistrement MX est également utilisé par Stalwart pour savoir où relayer les courriels traités.

Important: Si HIN Gateway est le seul enregistrement MX pour un domaine, Stalwart filtrera son propre nom d'hôte et n'aura pas de cible de livraison. Conservez toujours un deuxième MX pointant vers votre serveur de courrier réel.

Enregistrement SPF

Ajoutez l'IP du serveur HIN Gateway et l'IP du scelleur HIN à l'enregistrement SPF de votre domaine afin que les courriels sortants relayés via celui-ci réussissent les vérifications SPF chez le destinataire.

Si vous utilisez M365 / Exchange Online:

<YOUR_DOMAIN>.    TXT    "v=spf1 ip4:<HIN Gateway_IP> ip4:<HIN_SEALER_IP> include:spf.protection.outlook.com -all"

Si vous n'utilisez pas M365 / Google Workspace:

<YOUR_DOMAIN>.    TXT    "v=spf1 ip4:<HIN Gateway_IP> ip4:<HIN_SEALER_IP> -all"

Exemple:

example.ch.    TXT    "v=spf1 ip4:128.140.117.200 ip4:193.247.208.66 include:spf.protection.outlook.com -all"

Pourquoi l'IP du scelleur HIN est requise

Lorsque HIN Gateway produit un message SCELLÉ (chiffré) pour un destinataire non-HIN, le dernier saut sortant vers le destinataire est le scelleur HIN, pas votre HIN Gateway ou M365. Sans l'IP du scelleur dans votre enregistrement SPF, chaque message sortant SCELLÉ échouera au SPF chez le destinataire et - car il n'y a pas de signature DKIM sur la charge utile SCELLÉE - DMARC échouera également. Les destinataires avec DMARC strict (Gmail, Outlook avec application p=reject, Proofpoint) rejetteront ou classeront le message comme indésirable.

IPs du scelleur à ajouter dans SPF:

HIN publie plus d'un hôte de scellement (ex. mx1, mx2, mx3), incluez toutes leurs IPs. Résolvez-les avec dig +short mx hin.ch suivi de dig +short A <chaque-mx>. Jusqu'à ce que vous ayez la liste complète, laissez la politique SPF à ~all (échec doux) au lieu de -all (échec dur) afin que les courriels SCELLÉS légitimes via une IP de scelleur non répertoriée ne soient pas catégoriquement rejetés.

Limite de recherche SPF

La chaîne include: totale dans un enregistrement SPF doit rester en dessous de 10 recherches DNS. L'ajout d'entrées ip4: ne compte pas dans cette limite. Vérifiez votre nombre avec MXToolbox SPF lookup.

Comment HIN Gateway utilise SPF: Le démon mtaconf résout l'enregistrement SPF de chaque domaine pour remplir automatiquement la liste des IP autorisées à relayer via HIN Gateway sans authentification. C'est ainsi que les IP sortantes de Microsoft 365 sont automatiquement mises sur liste blanche - elles apparaissent dans la chaîne include:spf.protection.outlook.com.

Enregistrements recommandés

PTR (DNS inversé)

Configurez l'enregistrement DNS inversé (PTR) pour l'IP HIN Gateway afin qu'il corresponde à <MAIL_HOSTNAME>:

200.117.140.128.in-addr.arpa.    PTR    mail.example.ch.

Ceci est configuré chez votre fournisseur d'hébergement (Hetzner, Azure, AWS, etc.), pas dans le panneau DNS de votre bureau d'enregistrement de domaine. La plupart des fournisseurs ont un paramètre "DNS inversé" ou "rDNS" dans la page de gestion du serveur/IP.

Pourquoi: De nombreux serveurs de courrier récepteurs (y compris Gmail et Outlook) vérifient que l'enregistrement PTR de l'IP de connexion résout un nom d'hôte, et que ce nom d'hôte résout la même IP (DNS inversé à confirmation directe / FCrDNS). Un PTR manquant ou non correspondant est un fort signal de spam et peut entraîner des échecs de livraison.

Enregistrement DMARC

Publiez une politique DMARC pour chaque domaine d'envoi. Commencez par p=none (surveillance uniquement), puis renforcez après avoir confirmé l'alignement:

_dmarc.<YOUR_DOMAIN>.    TXT    "v=DMARC1; p=none; rua=mailto:postmaster@<YOUR_DOMAIN>"

Exemple:

_dmarc.example.ch.    TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.ch"

Une fois que les rapports agrégés DMARC confirment que SPF et/ou DKIM réussissent constamment, renforcez la politique:

  1. p=none - surveillance uniquement (commencez ici)
  2. p=quarantine - les courriels suspects vont dans les spams
  3. p=reject - les courriels non autorisés sont rejetés

Pourquoi: DMARC lie SPF et DKIM ensemble et indique aux destinataires quoi faire avec les courriels qui échouent aux deux. Même p=none suffit pour effacer la bannière "nous ne pouvons pas vérifier cet expéditeur" d'Outlook, tant que SPF réussit.

Vérifiez votre enregistrement DMARC: MXToolbox DMARC lookup

Enregistrements DKIM

Si votre domaine est un domaine accepté dans M365 ou Google Workspace, activez la signature DKIM dans le centre d'administration et publiez les enregistrements CNAME comme indiqué:

Exemple M365:

selector1._domainkey.<YOUR_DOMAIN>.    CNAME    selector1-<YOUR_DOMAIN_DASHED>._domainkey.<TENANT>.onmicrosoft.com.
selector2._domainkey.<YOUR_DOMAIN>.    CNAME    selector2-<YOUR_DOMAIN_DASHED>._domainkey.<TENANT>.onmicrosoft.com.

Note

La publication des enregistrements CNAME seuls ne suffit pas - la signature DKIM doit également être activée dans le centre d'administration M365 (portail Defender > Authentification des courriels > DKIM).

Pourquoi: DKIM prouve que le corps du message n'a pas été altéré pendant le transit. Combiné avec SPF et DMARC, il fournit la plus forte authentification de l'expéditeur.

Configuration multi-domaines

Pour les déploiements gérant plusieurs domaines de courrier (configurés via la page /mail du tableau de bord), chaque domaine a besoin de son propre ensemble d'enregistrements DNS.

Enregistrements par domaine

Pour chaque domaine configuré:

Enregistrement Requis
MX pointant vers <MAIL_HOSTNAME> Oui
SPF incluant ip4:<HIN Gateway_IP> Oui
DMARC (_dmarc.<domain>) Recommandé
DKIM (de votre fournisseur de courrier) Recommandé

L'enregistrement A et l'enregistrement PTR sont partagés (ils pointent vers le serveur HIN Gateway, pas vers des domaines individuels).

Routage de courrier par domaine

Les enregistrements MX de chaque domaine indiquent à HIN Gateway où livrer les courriels traités. Si différents domaines utilisent différents serveurs Exchange:

domain1.ch    MX    15    mail.domain1.ch.
domain1.ch    MX    20    exchange1.domain1.ch.

domain2.ch    MX    15    mail.domain2.ch.
domain2.ch    MX    20    exchange2.domain2.ch.

Alternativement, configurez des cibles de relais explicites par domaine via la page /mail du tableau de bord (champ hôte de relais par domaine) pour remplacer le routage basé sur MX.

Vérification

Après avoir configuré tous les enregistrements, vérifiez-les:

# Enregistrement A
host <MAIL_HOSTNAME>
# Attendu: <MAIL_HOSTNAME> a l'adresse <HIN Gateway_IP>

# Enregistrements MX
host -t mx <YOUR_DOMAIN>
# Attendu: Les enregistrements MX de HIN Gateway et d'Exchange sont répertoriés

# Enregistrement SPF
host -t txt <YOUR_DOMAIN> | grep v=spf1
# Attendu: L'enregistrement SPF inclut ip4:<HIN Gateway_IP>

# PTR (DNS inversé)
host <HIN Gateway_IP>
# Attendu: <HIN Gateway_IP> → <MAIL_HOSTNAME>

# DNS inversé à confirmation directe (FCrDNS)
host $(host <HIN Gateway_IP> | awk '{print $NF}' | sed 's/\.$//')
# Attendu: résout en <HIN Gateway_IP>

# DMARC
host -t txt _dmarc.<YOUR_DOMAIN>
# Attendu: v=DMARC1; p=...

# DKIM (M365)
host -t cname selector1._domainkey.<YOUR_DOMAIN>
# Attendu: CNAME vers le onmicrosoft.com de votre locataire

Exemple de sortie:

$ host mail.example.ch
mail.example.ch a l'adresse 128.140.117.200

$ host -t mx example.ch
example.ch le courrier est géré par 15 mail.example.ch.
example.ch le courrier est géré par 20 example-ch.mail.protection.outlook.com.

$ host -t txt example.ch | grep v=spf1
example.ch texte descriptif "v=spf1 ip4:128.140.117.200 include:spf.protection.outlook.com -all"

$ host 128.140.117.200
200.117.140.128.in-addr.arpa pointeur de nom de domaine mail.example.ch.

$ host -t txt _dmarc.example.ch
_dmarc.example.ch texte descriptif "v=DMARC1; p=none; rua=mailto:postmaster@example.ch"

Outils en ligne:

Dépannage

"Client host rejected: Access denied" (554 5.7.1)

Stalwart rejette le serveur expéditeur car son IP n'est pas dans la liste de relais autorisée. Cela signifie généralement:

  • L'enregistrement SPF de votre domaine n'inclut pas la plage IP du serveur expéditeur
  • La configuration du courrier n'a pas été rechargée depuis la mise à jour de l'enregistrement SPF

Rechargez la configuration du courrier via la page /mail du tableau de bord (soumettez à nouveau la configuration) ou redémarrez le conteneur: docker compose restart stalwart

Courrier marqué comme spam / "ne peut pas vérifier l'expéditeur"

  • SPF est manquant ou n'inclut pas l'IP HIN Gateway - ajoutez ip4:<HIN Gateway_IP> à votre enregistrement SPF
  • DMARC n'est pas publié - ajoutez au moins v=DMARC1; p=none
  • L'enregistrement PTR est manquant ou ne correspond pas - configurez le DNS inversé chez votre fournisseur d'hébergement
  • DKIM n'est pas activé dans votre locataire M365/fournisseur

La recherche MX ne renvoie que HIN Gateway

Si HIN Gateway est le seul MX pour un domaine, Stalwart filtre son propre nom d'hôte et n'a pas de cible de relais. Ajoutez un deuxième enregistrement MX pointant vers votre serveur de courrier:

example.ch.    MX    15    mail.example.ch.          ← HIN Gateway (entrant)
example.ch.    MX    20    example-ch.mail.protection.outlook.com.  ← Exchange (cible de relais)

Nombre de recherches SPF dépassé (> 10)

Chaque include: dans l'enregistrement SPF déclenche des recherches DNS supplémentaires. La chaîne totale doit rester en dessous de 10. Solutions:

  • Utilisez des entrées ip4: / ip6: au lieu de include: lorsque c'est possible (elles ne comptent pas)
  • Aplatissez les inclusions imbriquées à l'aide d'un outil comme SPF Flattener
  • Supprimez les entrées include: inutilisées d'anciens fournisseurs

Port 25 bloqué par le fournisseur d'hébergement

Certains fournisseurs de cloud (Azure, certains plans Hetzner) bloquent le port 25 sortant par défaut. Vérifiez auprès de votre fournisseur et demandez une exception. Cela affecte à la fois la livraison entrante (serveurs externes se connectant à votre HIN Gateway) et le relais sortant (HIN Gateway livrant aux cibles MX).