01 - Les records DNS : MX, SPF, DKIM et DMARC

Ce que tu vas apprendre

Les 5 records DNS indispensables pour un serveur mail
La syntaxe exacte de chaque record
Pourquoi chaque record compte pour la delivrabilite

Prerequisites

Un nom de domaine avec acces a la zone DNS
00 - Introduction : le contexte de la serie

Le DNS, c'est 80% du travail

Je t'annonce la couleur : si tes DNS sont mal configures, rien d'autre ne compte. Ton serveur mail peut etre parfait, tes certificats SSL impeccables, ta config Postfix optimisee. Si tes records DNS sont faux, tes emails finissent en spam. Ou pire, ils ne partent pas du tout.

La bonne nouvelle, c'est qu'il y a exactement 5 records a configurer. Pas plus, pas moins.

1. Le record A : pointer vers ton serveur

D'abord, il faut que mail.tondomaine.fr pointe vers l'IP de ton VPS.

textmail    IN    A    203.0.113.42

Remplace 203.0.113.42 par l'IP de ton VPS. Ce record dit simplement "le sous-domaine mail est a cette adresse". C'est la base.

2. Le record MX : ou envoyer les emails

Le record MX (Mail eXchanger) dit au monde entier : "pour envoyer un email a quelqu'un@tondomaine.fr, contactez ce serveur".

text@    IN    MX    10    mail.tondomaine.fr.

Le 10 c'est la priorité. Si tu as un seul serveur mail (et c'est probablement le cas), la valeur n'a pas d'importance. Le point final apres le hostname est obligatoire dans la zone DNS, il indique que c'est un nom de domaine absolu.

Sans record MX, personne ne peut t'envoyer d'email. C'est aussi simple que ca.

3. Le record SPF : qui a le droit d'envoyer

SPF (Sender Policy Framework) est un record TXT qui liste les serveurs autorises a envoyer des emails pour ton domaine. Quand Gmail recoit un email de @tondomaine.fr, il vérifié le SPF pour savoir si le serveur qui l'a envoye avait le droit.

text@    IN    TXT    "v=spf1 mx a:mail.paltemps.fr -all"

Decodage :

v=spf1 : version du protocole
mx : les serveurs listes dans les records MX sont autorises
a:mail.paltemps.fr : ce hostname spécifique est autorise
-all : tout le reste est interdit (hard fail)

Le -all est important. Certains guides recommandent ~all (soft fail), mais en 2026 c'est trop laxiste. Avec -all, tu dis clairement : "si l'email ne vient pas de mes serveurs, c'est un faux". Les serveurs de reception respectent ca.

Sans SPF, n'importe qui peut envoyer un email en se faisant passer pour ton domaine. Et les serveurs de reception le savent, donc ils mettent tes vrais emails en spam par precaution.

4. Le record DKIM : la signature cryptographique

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique a chaque email sortant. Le serveur de reception vérifié cette signature avec ta clé publique publiee dans le DNS. Si la signature colle, l'email n'a pas ete modifie en transit.

On va générer la clé DKIM dans l'article sur docker-mailserver. Pour l'instant, sache que le record ressemble a ca :

textmail._domainkey    IN    TXT    "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhki..."

Le sélecteur mail._domainkey est le nom par défaut utilise par docker-mailserver. La valeur p= c'est ta clé publique en base64. Elle est longue. C'est normal.

Si tu veux comprendre le chiffrement asymetrique derrière DKIM, j'ai un article la-dessus dans ma serie sur la cryptographie : TLS, HTTPS et certificats.

Sans DKIM, les serveurs de reception ne peuvent pas vérifier l'intégrité de tes emails. Ca te coûte facilement 2 points sur mail-tester.com.

5. Le record DMARC : la politique de rejet

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la couche au-dessus de SPF et DKIM. Il dit aux serveurs de reception quoi faire quand un email echoue les verifications SPF ou DKIM.

text_dmarc    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@paltemps.fr"

Decodage :

v=DMARC1 : version
p=quarantine : en cas d'échec, mettre en spam (pas rejeter directement)
rua=mailto:dmarc@paltemps.fr : envoyer des rapports agreges a cette adresse

Tu peux commencer avec p=none pour observer sans bloquer, puis passer a p=quarantine une fois que tout fonctionne. p=reject est l'option la plus stricte mais attend d'etre sur que tout est bien en place.

Les rapports rua sont precieux. Tu recevras des fichiers XML des gros providers (Google, Microsoft, Yahoo) qui te disent exactement combien d'emails passent ou echouent les checks. Ca te permet de détecter des problèmes avant tes utilisateurs.

La config complète sur OVH

Voici a quoi ressemble la zone DNS sur le manager OVH pour paltemps.fr :

textmail        IN    A      203.0.113.42
@           IN    MX     10 mail.paltemps.fr.
@           IN    TXT    "v=spf1 mx a:mail.paltemps.fr -all"
mail._domainkey IN TXT   "v=DKIM1; h=sha256; k=rsa; p=MIIBIjAN..."
_dmarc      IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@paltemps.fr"

Cinq records. C'est tout. Mais chacun est indispensable.

Verifier que tout est en place

Apres avoir configure tes records, attend la propagation (quelques minutes a 24h selon le TTL) et vérifié :

bash# Verifier le record MX
dig MX paltemps.fr +short

# Verifier le SPF
dig TXT paltemps.fr +short

# Verifier le DKIM
dig TXT mail._domainkey.paltemps.fr +short

# Verifier le DMARC
dig TXT _dmarc.paltemps.fr +short

Si tout répond correctement, le DNS est bon. On passe a un record un peu special que beaucoup oublient.

Prochain article : Le reverse DNS (PTR).

Navigation : Precedent : 00 - Introduction | Suivant : 02 - Le reverse DNS

Sources

RFC 7208 - Sender Policy Framework (SPF) par IETF
RFC 6376 - DomainKeys Identified Mail (DKIM) par IETF
RFC 7489 - DMARC par IETF
MXToolbox - DNS Lookup par MXToolbox

Retrouve d'autres articles techniques sur paltemps.fr.