SPF, DKIM, DMARC : comprendre l'authentification email

Le problème : SMTP fait confiance

SMTP, le protocole derrière l'email, a été conçu en 1982 dans un monde où on faisait confiance aux machines connectées à Internet. Conséquence : n'importe qui peut envoyer un mail en prétendant venir de n'importe quelle adresse. Le champ From: n'est pas vérifié par le protocole lui-même.

SPF (2003), DKIM (2004) et DMARC (2012) ont été créés pour rajouter cette vérification, sans casser la rétro-compatibilité.

SPF : qui a le droit d'envoyer pour mon domaine

SPF (Sender Policy Framework) est un enregistrement DNS public. Il liste les serveurs autorisés à envoyer du mail au nom de votre domaine.

Exemple pour fiabli.io :

fiabli.io. IN TXT "v=spf1 include:spf.mailjet.com ~all"

Ça veut dire : « les serveurs Mailjet sont autorisés à envoyer en mon nom, tous les autres devraient être marqués suspect (~all) ou rejetés (-all) ».

Quand votre serveur reçoit un mail prétendant venir de noreply@fiabli.io, il vérifie : « le serveur émetteur (par son IP) est-il dans la liste SPF de fiabli.io ? ». Si non → SPF fail, le mail est suspect.

DKIM : la signature cryptographique

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque mail envoyé, dans un en-tête DKIM-Signature. Cette signature est faite avec une clé privée connue uniquement du serveur émetteur. La clé publique correspondante est dans le DNS, accessible à tous.

Le serveur récepteur prend la signature, la décode avec la clé publique, et vérifie qu'elle correspond bien au contenu du mail. Si oui → DKIM pass : le contenu n'a pas été modifié en route et l'expéditeur a bien la clé privée du domaine.

Avantage par rapport à SPF : DKIM survit aux relais (un mail forwardé garde sa signature DKIM), pas SPF.

DMARC : la politique du domaine

DMARC (Domain-based Message Authentication, Reporting and Conformance) coordonne SPF + DKIM et dit au serveur récepteur : « voici ce qu'il faut faire si SPF ou DKIM échouent ».

Exemple :

_dmarc.fiabli.io. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@fiabli.io"

3 politiques possibles :

• p=none : observe, ne fait rien (mode monitoring)
• p=quarantine : met les mails échoués en spam
• p=reject : rejette les mails échoués (recommandé)

Le rua= permet de recevoir des rapports quotidiens sur qui essaie d'envoyer en votre nom — précieux pour détecter une tentative d'usurpation.

Comment Fiabli utilise SPF/DKIM/DMARC

À chaque mail analysé, Fiabli extrait les en-têtes Authentication-Results (déjà calculés par le serveur de réception) ou les recalcule si besoin. Le verdict des 3 protocoles compte dans notre score de risque global :

• 3 pass : forte présomption d'authenticité (15 % de poids dans le score)
• 2 pass + 1 fail : suspect modéré (peut être un mail forwardé légitime — courant)
• SPF fail + DKIM fail : très suspect (40 % de poids)
• DMARC fail : red flag majeur (50 % de poids)

L'analyse est combinée avec l'analyse du contenu (Claude Haiku/Sonnet) et des URL (PhishTank + WHOIS) pour le verdict final.

Vérifier soi-même un mail

Sur Gmail : ouvrez le mail → 3 points → « Afficher l'original ». Vous verrez en haut :

SPF:    PASS
DKIM:   'pass' with domain fiabli.io
DMARC:  'PASS'

Si vous voyez du fail, méfiance maximale. Si vous gérez un domaine et que ces 3 lignes ne sont pas configurées, faites-le aujourd'hui : c'est gratuit, ça prend 30 minutes, et ça protège votre marque contre le phishing usurpateur.

Avec Fiabli, vous n'avez plus à faire ces vérifications manuellement — chaque mail entrant est analysé en moins de 2 secondes.