Le Chef d’Orchestre#

Publié en 2015 (RFC 7489).

Jusqu’ici, nous avons vu que :

SPF valide l’IP mais vérifie le Return-Path, pas le From.
DKIM valide le contenu et vérifie le domaine de la signature (d=). Il ne vérifie pas le From.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ne propose pas une nouvelle méthode d’authentification technique, mais une couche de politique qui s’appuie sur SPF et DKIM pour résoudre le problème de l’alignement.

DMARC utilise les résultats de SPF et DKIM et ajoute une règle simple : Pour que l’e-mail soit valide, le domaine visible par l’utilisateur (le From) doit être “aligné” (identique) avec au moins l’un des deux protocoles authentifiés (soit le domaine du SPF, soit le domaine du DKIM).

Les 3 piliers de DMARC#

L’Alignement (Identifier Alignment) : DMARC vérifie si le domaine du From correspond soit au domaine validé par SPF (celui du Return-Path), soit au domaine de la signature DKIM (le tag d= du champ d’en-tête DKIM-Signature). On appelle “alignement” cette correspondance. C’est ce qui empêche un spammeur d’utiliser par exemple l’infrastructure de Mailjet (SPF valide pour Mailjet) pour envoyer un e-mail avec From: president@whitehouse.gov. DMARC échoue car whitehouse.gov n’est pas aligné avec mailjet.com. C’est ce mécanisme qui empêche enfin le spoofing d’adresse visible.
La Politique (Policy) : DMARC permet au propriétaire du domaine de dire au récepteur quoi faire si la validation échoue. C’est défini par la balise p= dans le DNS :

p=none : Observation uniquement. “Dis-moi juste qui échoue, mais laisse passer l’e-mail.” (Idéal pour commencer et auditer).
p=quarantine : Mise en doute. “Mets les e-mails qui échouent dans le dossier Spam du destinataire.”
p=reject : Protection maximale. “Rejette purement et simplement les e-mails qui échouent. Ils n’arriveront jamais.”

Le Reporting (RUA/RUF) : C’est la boucle de rétroaction. Les serveurs de réception (Gmail, Yahoo, etc.) envoient des rapports XML quotidiens à l’adresse définie dans le record DMARC. Cela permet à l’administrateur de savoir exactement qui envoie des e-mails en son nom (légitimement ou non) et de corriger sa configuration avant de passer en mode reject.

graph TD
    %% --- Styles ---
    classDef input fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#000
    classDef check fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000
    classDef pass fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px,color:#000
    classDef fail fill:#ffcdd2,stroke:#c62828,stroke-width:2px,color:#000
    classDef policy fill:#e1bee7,stroke:#8e24aa,stroke-width:2px,color:#000

    %% --- ETAPE 1 : LES PREUVES ---
    subgraph INPUTS ["1 - LES PREUVES DISPONIBLES"]
        HeaderFrom["👤 Header FROM<br/>(Ce que voit l'utilisateur)"]:::input
        
        SPF_Res["🚚 Résultat SPF<br/>(Domaine Return-Path)"]:::input
        DKIM_Res["🛡️ Résultat DKIM<br/>(Domaine de signature d=)"]:::input
    end

    %% --- ETAPE 2 : LE TEST D'ALIGNEMENT ---
    subgraph ALIGNMENT ["2 - VERIFICATION D'ALIGNEMENT"]
        %% Liens invisibles pour forcer la structure
        HeaderFrom --> CompareSPF
        HeaderFrom --> CompareDKIM
        
        CompareSPF{"Le FROM matche<br/>le SPF ?"}:::check
        CompareDKIM{"Le FROM matche<br/>le DKIM ?"}:::check
        
        SPF_Res --> CompareSPF
        DKIM_Res --> CompareDKIM
    end

    %% --- ETAPE 3 : LE VERDICT DMARC ---
    subgraph VERDICT ["3 - VERDICT GLOBAL"]
        FinalDecision{"Au moins UN<br/>match ?"}:::check
        
        CompareSPF --> FinalDecision
        CompareDKIM --> FinalDecision
        
        FinalDecision -- OUI --> DMARC_OK["✅ DMARC PASS<br/>(Inbox)"]:::pass
        FinalDecision -- NON --> DMARC_FAIL["❌ DMARC FAIL<br/>(Non aligné)"]:::fail
    end

    %% --- ETAPE 4 : APPLICATION POLITIQUE ---
    subgraph ENFORCEMENT ["4 - POLITIQUE"]
        PolicyCheck["👮 Lecture de p=..."]:::policy
        
        DMARC_FAIL --> PolicyCheck
        
        PolicyCheck -- "p=none" --> ActNone["Laissez passer<br/>(Monitoring)"]:::policy
        PolicyCheck -- "p=quarantine" --> ActSpam["Dossier Spam"]:::policy
        PolicyCheck -- "p=reject" --> ActReject["🚫 Rejet Total"]:::fail
    end

Pour aller plus loin#

Note sur le transfert et les Mailing Lists (SRS & ARC)#

Vous avez peut-être constaté que certains transferts d’e-mails fonctionnent malgré les limitations de SPF. C’est grâce à deux mécanismes gérés par les serveurs intermédiaires (sur lesquels vous n’avez pas la main) :

SRS (Sender Rewriting Scheme) : Le serveur de relais réécrit l’enveloppe (Return-Path) pour que le SPF passe avec sa propre IP. Cela corrige le SPF mais casse l’alignement DMARC.
ARC (Authenticated Received Chain) : Le serveur de relais signe l’état de l’authentification (SPF/DKIM) avant de modifier le message. Cela permet au destinataire final (comme Gmail) de valider l’e-mail via une chaîne de confiance, même si SPF et DKIM échouent techniquement à l’arrivée.