> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # SPF, DKIM, DMARC et reverse DNS : sortir le courrier de votre VPS des indésirables > Les quatre vérifications que Gmail et les autres font avant d'accepter votre courrier, comment les passer sur un VPS Debian ou Ubuntu, et comment le prouver avec dig. *Publié le 24 septembre 2026* Depuis février 2024, Gmail exige de **tout** expéditeur vers ses adresses personnelles une authentification SPF ou DKIM, des DNS direct et inverse valides pour l'adresse d'envoi, et une connexion TLS. Au-delà de 5 000 messages par jour, il faut SPF **et** DKIM, plus DMARC. Yahoo a publié des règles du même ordre. Depuis novembre 2025, Google ne se contente plus de classer en indésirables : les messages non conformes subissent des rejets temporaires ou définitifs. Un serveur de messagerie sur un VPS n'y échappe pas. Voici les quatre enregistrements qui font la différence, dans l'ordre où les poser, et la façon de vérifier chacun. ## Ce que vérifie le serveur qui reçoit | Vérification | Question posée | Enregistrement | | ------------ | --------------------------------------------------------------------------------------------------- | ---------------------------------- | | Reverse DNS | L'adresse IP qui se connecte a-t-elle un nom, et ce nom pointe-t-il vers elle ? | `PTR` sur l'IP, `A` sur le nom | | SPF | Cette IP a-t-elle le droit d'envoyer pour ce domaine ? | `TXT` sur le domaine | | DKIM | Le message a-t-il été signé par le domaine, et n'a-t-il pas été modifié ? | `TXT` sur `._domainkey` | | DMARC | Le domaine visible dans `From:` correspond-il à celui qui a passé SPF ou DKIM, et que faire sinon ? | `TXT` sur `_dmarc` | Les exemples qui suivent utilisent `example.com`, le serveur `mail.example.com` et l'adresse `203.0.113.42`. Remplacez-les par les vôtres. ## 0. Avant tout : le port 25 sortant Tout ce qui suit ne sert à rien si votre serveur ne peut pas joindre les autres. Beaucoup d'hébergeurs bloquent le port 25 en sortie par défaut. C'est le cas chez nous : les ports **25, 465 et 587** sortants sont fermés sur tout nouveau VPS, et s'ouvrent sur demande pour un usage raisonnable (serveur personnel, notifications applicatives), jamais pour de l'envoi en masse. Le détail est dans la [documentation réseau](https://help.onetsolutions.net/fr/vps/network#ports-email). Testez depuis le VPS : ```bash theme={null} # Doit afficher « succeeded » ou « open » ; un délai dépassé signale un blocage nc -vz -w 5 gmail-smtp-in.l.google.com 25 ``` ## 1. Nom d'hôte, enregistrement A et reverse DNS Trois valeurs doivent concorder : le nom que votre serveur annonce dans son `HELO`, l'enregistrement `A` de ce nom, et le reverse DNS (`PTR`) de l'adresse IP. ```bash theme={null} # Le nom annoncé par Postfix dans son HELO postconf myhostname # attendu : myhostname = mail.example.com ``` S'il est faux, corrigez-le : ```bash theme={null} sudo postconf -e 'myhostname = mail.example.com' sudo systemctl reload postfix ``` Côté DNS, il faut un `A` pour `mail.example.com` vers `203.0.113.42`, et un `MX` du domaine vers `mail.example.com`. Le reverse DNS, lui, ne se pose pas dans votre zone : l'adresse IP appartient à votre hébergeur, c'est lui qui le fixe. Chez nous, il se règle depuis la console ; la procédure est dans la [documentation Reverse DNS](https://help.onetsolutions.net/fr/vps/reverse-dns). Si nous hébergeons la zone DNS de votre domaine, l'onglet **Domaine** de votre instance, profil **Un site web et la messagerie**, écrit le `A` de `mail`, le `MX` (priorité 10 vers `mail.example.com`), les enregistrements SPF et DMARC décrits plus bas, et règle le reverse DNS de l'IP. Un aperçu montre tout avant écriture, y compris vos `MX` actuels s'ils vont être remplacés. Voir [l'annonce](/fr/domaine-lie-au-vps) et la [documentation](https://help.onetsolutions.net/fr/vps/redirect-my-domain). Seul DKIM reste à votre charge : section 3. Vérifiez que l'aller et le retour concordent : ```bash theme={null} dig +short -x 203.0.113.42 # attendu : mail.example.com. dig +short A mail.example.com # attendu : 203.0.113.42 dig +short MX example.com # attendu : 10 mail.example.com. ``` ## 2. SPF : qui a le droit d'envoyer Un seul enregistrement `TXT` à la racine du domaine. Pour un serveur qui est à la fois le site et la messagerie : ```text theme={null} example.com. IN TXT "v=spf1 a mx -all" ``` `a` autorise l'adresse du `A` de `example.com`, `mx` celles des serveurs `MX`, et `-all` déclare que rien d'autre n'envoie pour ce domaine. C'est l'enregistrement qu'écrit le profil messagerie de la console. Si un autre service envoie aussi en votre nom (messagerie hébergée, outil de newsletter), ajoutez son mécanisme `include:` dans **le même** enregistrement, pas dans un second. ```bash theme={null} dig +short TXT example.com | grep spf1 # une seule ligne attendue ``` SPF vérifie l'adresse d'enveloppe (`MAIL FROM`), pas l'en-tête `From:` que lit votre correspondant. C'est DMARC, section 4, qui relie les deux. ## 3. DKIM : signer ce qui part DKIM est le seul des quatre que la console ne peut pas écrire pour vous : la clé privée est générée sur votre serveur et ne doit jamais le quitter. Vous publiez uniquement la clé publique. Sur Debian ou Ubuntu avec Postfix, OpenDKIM fait le travail : ```bash theme={null} sudo apt install opendkim opendkim-tools # Paire de clés RSA 2048 bits, sélecteur « s2026 » sudo opendkim-genkey -b 2048 -d example.com -D /etc/dkimkeys -s s2026 -v sudo chown opendkim:opendkim /etc/dkimkeys/s2026.private ``` La commande produit `s2026.private` (la clé privée) et `s2026.txt` (l'enregistrement DNS à publier). Le sélecteur est un nom libre ; mettre l'année dedans simplifie la rotation plus tard. Dans `/etc/opendkim.conf`, renseignez le domaine, le sélecteur et la clé, et remplacez la ligne `Socket` existante par un port local, que Postfix atteint même depuis son chroot : ```text theme={null} Domain example.com Selector s2026 KeyFile /etc/dkimkeys/s2026.private Socket inet:8891@localhost ``` Puis branchez Postfix sur le milter : ```bash theme={null} sudo postconf -e 'smtpd_milters = inet:localhost:8891' sudo postconf -e 'non_smtpd_milters = $smtpd_milters' sudo postconf -e 'milter_default_action = accept' sudo systemctl restart opendkim postfix ``` Publiez le contenu de `s2026.txt` en `TXT` sur `s2026._domainkey.example.com` : ```bash theme={null} sudo cat /etc/dkimkeys/s2026.txt ``` ```text theme={null} s2026._domainkey.example.com. IN TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqh..." ``` Une clé 2048 bits dépasse les 255 caractères qu'autorise une chaîne `TXT` : le fichier la découpe en plusieurs chaînes entre guillemets. Elles forment un seul enregistrement, pas plusieurs. Une fois publié, vérifiez qu'il revient entier et qu'il correspond à la clé privée : ```bash theme={null} dig +short TXT s2026._domainkey.example.com sudo opendkim-testkey -d example.com -s s2026 -k /etc/dkimkeys/s2026.private -vvv # attendu en fin de sortie : « key OK » ``` La mention `key not secure` qui peut précéder signale seulement que la zone n'est pas signée DNSSEC. Elle n'empêche pas DKIM de fonctionner. ## 4. DMARC : relier le tout et dire quoi faire en cas d'échec DMARC exige que le domaine de l'en-tête `From:` soit aligné sur celui qui a passé SPF ou DKIM, publie ce que le destinataire doit faire sinon, et où vous envoyer les rapports. ```text theme={null} _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com" ``` * `p=quarantine` : un message non conforme va en indésirables. `p=none` ne demande rien ; `p=reject` le fait refuser. * `rua=` : l'adresse qui reçoit les rapports agrégés quotidiens (XML compressé) des grands fournisseurs. **Cette boîte doit exister.** C'est l'enregistrement que pose le profil messagerie de la console. Il suppose que tout ce qui envoie en votre nom passe déjà SPF ou DKIM. Si d'autres services envoient pour votre domaine et que vous n'en êtes pas sûr, commencez par `p=none`, lisez les rapports une ou deux semaines, puis montez. ```bash theme={null} dig +short TXT _dmarc.example.com ``` ## 5. Vérifier de bout en bout Les enregistrements peuvent être justes et le message échouer quand même. Envoyez un vrai message à une adresse Gmail, **en passant par votre Postfix** pour qu'il soit signé : ```bash theme={null} sudo apt install swaks swaks --server 127.0.0.1 --from test@example.com --to vous@gmail.com ``` Dans Gmail, ouvrez le message, menu **⋮**, **Afficher l'original**. Vous devez lire `PASS` sur les trois lignes SPF, DKIM et DMARC. Le détail est dans l'en-tête `Authentication-Results` : ```text theme={null} Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=s2026 ... spf=pass (google.com: domain of test@example.com designates 203.0.113.42 as permitted sender) ... dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com ``` Côté serveur, le journal d'OpenDKIM confirme la signature : ```bash theme={null} sudo journalctl -u opendkim --since "10 min ago" | grep "DKIM-Signature field added" ``` ## Pièges courants **Deux enregistrements SPF.** Un domaine ne doit en porter qu'un. Avec deux `TXT` commençant par `v=spf1`, le résultat est une erreur permanente, et SPF échoue pour tout le monde. Fusionnez-les. **Plus de dix recherches DNS.** Chaque `include`, `a`, `mx`, `ptr`, `exists` et `redirect` coûte une requête, et les `include` imbriqués comptent aussi. Au-delà de dix, SPF renvoie une erreur permanente. Trois ou quatre services tiers suffisent à y arriver. **`-all` ou `~all`.** `-all` (échec) dit que rien d'autre n'envoie ; `~all` (échec partiel) le dit sans l'imposer. Certains destinataires rejettent sur un échec SPF avant même d'évaluer DKIM, ce qui pénalise le courrier transféré. Si des messages de votre domaine sont souvent relayés, `~all` avec DKIM et DMARC en place est un compromis courant. **DMARC en `p=none` pour toujours.** `p=none` sert à observer. Il satisfait la lettre des exigences, mais ne protège pas votre domaine contre l'usurpation. Fixez-vous une date pour passer à `quarantine`. **Reverse DNS et HELO qui divergent.** Un `PTR` générique de l'hébergeur, un `PTR` vers un nom sans `A` en retour, ou un `myhostname` resté à `localhost` ou au nom d'installation : chacun suffit à faire douter le destinataire. **IPv6 oublié.** Si votre VPS a une adresse IPv6, Postfix l'utilise volontiers pour joindre Gmail, et cette adresse doit alors avoir son propre `PTR` et être couverte par SPF (le mécanisme `a` inclut les `AAAA` du domaine). Vérifiez avec `dig -x` sur l'adresse IPv6. À défaut, faites préférer IPv4 à Postfix : ```bash theme={null} sudo postconf -e 'smtp_address_preference = ipv4' sudo systemctl reload postfix ``` **Le nom `mail` sans SPF.** Les destinataires peuvent aussi vérifier SPF sur le nom annoncé en `HELO`. Un `TXT` `"v=spf1 a -all"` sur `mail.example.com` règle le cas. ## Pour aller plus loin * [Faire pointer un domaine vers un VPS](https://help.onetsolutions.net/fr/vps/redirect-my-domain) : les enregistrements que la console écrit pour vous. * [Reverse DNS (PTR)](https://help.onetsolutions.net/fr/vps/reverse-dns) : régler et vérifier le PTR de votre IP. * [Ports email](https://help.onetsolutions.net/fr/vps/network#ports-email) : conditions d'ouverture du port 25. * [Sécurité renforcée sur un VPS Linux](/fr/securite-renforcee-sur-un-vps-linux-conseils-et-outils-pour-proteger-vos-donnees-sensibles) pour la couche du dessous. Besoin d'ouvrir le port 25 ou d'un coup de main sur la configuration ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.