SPF, DKIM, DMARC et reverse DNS : sortir le courrier de votre VPS des indésirables

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 `<sélecteur>._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. Testez depuis le VPS :

# 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.

# Le nom annoncé par Postfix dans son HELO
postconf myhostname
# attendu : myhostname = mail.example.com

S’il est faux, corrigez-le :

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.

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 et la documentation. Seul DKIM reste à votre charge : section 3.

Vérifiez que l’aller et le retour concordent :

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 :

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.

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 :

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 :

Domain      example.com
Selector    s2026
KeyFile     /etc/dkimkeys/s2026.private
Socket      inet:8891@localhost

Puis branchez Postfix sur le milter :

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 :

sudo cat /etc/dkimkeys/s2026.txt

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 :

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.

_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.

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é :

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 :

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 :

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 :

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 : les enregistrements que la console écrit pour vous.
Reverse DNS (PTR) : régler et vérifier le PTR de votre IP.
Ports email : conditions d’ouverture du port 25.
Sécurité renforcée sur un VPS Linux pour la couche du dessous.

Besoin d’ouvrir le port 25 ou d’un coup de main sur la configuration ? Notre équipe est disponible depuis votre espace client.

Vue d'ensemble

Annonces produits

Hébergement web

Conseils & comparaisons

Paiement

Avis de sécurité

SPF, DKIM, DMARC et reverse DNS : sortir le courrier de votre VPS des indésirables

Ce que vérifie le serveur qui reçoit

0. Avant tout : le port 25 sortant

1. Nom d’hôte, enregistrement A et reverse DNS

2. SPF : qui a le droit d’envoyer

3. DKIM : signer ce qui part

4. DMARC : relier le tout et dire quoi faire en cas d’échec

5. Vérifier de bout en bout

Pièges courants

Pour aller plus loin

​Ce que vérifie le serveur qui reçoit

​0. Avant tout : le port 25 sortant

​1. Nom d’hôte, enregistrement A et reverse DNS

​2. SPF : qui a le droit d’envoyer

​3. DKIM : signer ce qui part

​4. DMARC : relier le tout et dire quoi faire en cas d’échec

​5. Vérifier de bout en bout

​Pièges courants

​Pour aller plus loin

Ce que vérifie le serveur qui reçoit

0. Avant tout : le port 25 sortant

1. Nom d’hôte, enregistrement A et reverse DNS

2. SPF : qui a le droit d’envoyer

3. DKIM : signer ce qui part

4. DMARC : relier le tout et dire quoi faire en cas d’échec

5. Vérifier de bout en bout

Pièges courants

Pour aller plus loin