Votre SaaS envoie factures, réinitialisations de mot de passe et alertes d'exploitation depuis trois fournisseurs : SMTP maison, SendGrid, Helpdesk. Tout « fonctionne » jusqu'au jour où Microsoft 365 classe 40 % des mails en junk. Le SPF du domaine principal autorise trop de monde, DKIM tourne sur le helpdesk seulement, et personne n'a lu le premier rapport DMARC aggregate.
SPF, DKIM et DMARC ne sont pas trois buzzwords à cocher chez l'hébergeur mail. Ce sont trois mécanismes complémentaires avec une condition souvent oubliée : l'alignment.
SPF : qui peut envoyer depuis votre domaine
SPF liste les serveurs autorisés via un TXT _spf.example.com. Erreurs classiques : +all, trop d'inclusions (include: en cascade), oubli du ESP transactionnel, limite de 10 lookups DNS.
SPF vérifie l'enveloppe SMTP (MAIL FROM), pas forcément le From visible. Un attaquant peut afficher you@example.com en From tout en passant SPF sur son propre domaine.
DKIM : signature cryptographique
DKIM signe des parties du message avec une clé publiée en DNS. Survit souvent au forwarding modeste. Configurez des sélecteurs distincts par service (s1._domainkey, helpdesk._domainkey).
Rotation de clés : planifiez avant expiration ; certains registrars imposent des TXT longs — vérifiez la fragmentation.
DMARC : politique et rapports
DMARC indique quoi faire si SPF ou DKIM échoue et que l'alignment avec le From est mauvaise. Commencez par p=none; rua=mailto:dmarc@example.com.
| Phase | Politique | Objectif |
|---|---|---|
| 1 | p=none | Inventorier les envoyeurs légitimes |
| 2 | p=quarantine | Réduire l'usurpation |
| 3 | p=reject | Bloquer le spoofing |
Lisez les rapports XML aggregate — automatisez l'analyse si volume élevé.
Alignment : le détail qui tue
Relaxed : mail.example.com aligne avec example.com. Strict : égalité exacte du domaine.
Scénario fréquent : From hello@example.com, DKIM signé d=esp.net → SPF/DKIM OK, DMARC fail. Corrigez le Return-Path, le signeur DKIM, ou utilisez un sous-domaine dédié (bounce.example.com).
Checklist multi-fournisseurs
- Inventaire des IP/domaines envoyeurs.
- SPF unique consolidé ou sous-domaines par canal.
- DKIM par ESP + test avec mail-tester.com.
- DMARC p=none 30 jours minimum.
- BIMI optionnel seulement après reject stable.
Impact sur le choix d'hébergement mail
Envoyer depuis le SMTP du VPS mutualisé partage souvent IP et PTR avec des voisins spammeurs. Même avec SPF/DKIM/DMARC parfaits, la réputation IP plafonne. Les ESP transactionnels isolent cette couche — mais exigent DKIM/Return-Path alignés sur votre domaine, pas le leur seul.
Si vous restez en auto-hébergement, vérifiez que l'hébergeur autorise le port 25 sortant, le PTR personnalisé, et les enregistrements TXT longs pour DKIM 2048 bits. Certains panels tronquent les TXT : signe courant d'un « DKIM intermittent ».
Gardez un tableau vivant : service → selector DKIM → include SPF → politique DMARC. À chaque nouvel outil (CRM, newsletter, support), une ligne — sinon le prochain rapport aggregate révélera un expéditeur oublié.
Programmez une revue trimestrielle des rapports aggregate avec le marketing : ils ajoutent des outils sans ticket DNS, vous héritez des échecs DMARC.
Plan d'action sur sept jours
Jour 1 — Exportez tous les enregistrements TXT et MX existants. Listez chaque service qui envoie du mail (application, CRM, newsletter, monitoring, support).
Jour 2 — Publiez ou consolidez SPF avec -all final après includes. Vérifiez le compteur DNS lookups (inférieur à dix).
Jour 3 — Activez DKIM sur le premier ESP ; envoyez test vers Gmail et Microsoft ; inspectez les en-têtes Authentication-Results.
Jour 4 — Publiez DMARC p=none avec adresse rua fonctionnelle. Configurez boîte ou analyseur aggregate.
Jour 5 — Analysez premiers rapports : sources légitimes inconnues, échecs alignment, forwarding tiers.
Jour 6 — Corrigez Return-Path et selectors manquants. Re-testez envoi transactionnel critique (facture, réinitialisation mot de passe).
Jour 7 — Documentez runbook « ajout nouvel expéditeur » : SPF include, DKIM, test DMARC, validation marketing.
Cette semaine évite le piège classique : tout activer en reject le jour J et découvrir un outil interne oublié via les bounces clients.
Le sommet : un SPF vert ne suffit pas
Décider et avancer sans angle mort
Commencez par un inventaire honnête : quels services envoient du mail en production, qui les administre, et quelle fenêtre de maintenance est acceptable. Documentez l'état DNS actuel avant toute modification. Déployez SPF et DKIM, puis DMARC en mode observation pendant au moins trente jours. Analysez les rapports aggregate avant de durcir la politique vers quarantine ou reject. Pour l'infrastructure mail, parcourez notre annuaire d'hébergeurs, le comparateur et nos guides.
Questions fréquentes
SPF seul suffit-il ?
Non. SPF ne survit pas au forwarding et ne couvre pas les en-têtes From usurpés. DKIM et DMARC comblent ces angles morts — les trois protocoles forment un ensemble, pas des options interchangeables.
Qu'est-ce que l'alignment DMARC ?
Le domaine de l'en-tête From doit correspondre (strict) ou être parent (relaxed) du domaine SPF ou DKIM validé. Sans alignment, DMARC échoue même si SPF et DKIM passent isolément — c'est la cause la plus fréquente de rejet chez Gmail et Microsoft.
Par où commencer le déploiement ?
Publiez SPF et DKIM, puis DMARC en p=none avec rapports rua/ruf, analysez un mois, durcissez vers quarantine puis reject. Ne passez jamais directement en reject sans période d'observation préalable.
Les sous-domaines héritent-ils du DMARC parent ?
Non automatiquement. Ajoutez sp= ou des politiques DMARC explicites par sous-domaine envoyeur — chaque canal (newsletter, support, transactionnel) doit être cartographié.
Ouvrez votre dernier rapport DMARC aggregate avant d'ajouter un nouvel ESP — sinon vous découvrirez le conflit via les clients, pas via DNS.