SPF, DKIM et DMARC en Belgique : sécuriser son domaine e-mail sans bloquer les messages légitimes

Pourquoi la sécurité du domaine e-mail devient prioritaire en Belgique

Un domaine connu est une identité numérique : s’il peut être usurpé, la confiance construite par l’organisation sert l’attaquant. Le faux message peut demander un changement de compte bancaire, diffuser une fausse facture, inviter à se connecter sur une page de phishing ou se faire passer pour la direction. Il ne faut pas que l’attaquant ait accès au tenant pour imiter l’adresse visible.

Safeonweb@work, le service destiné aux organisations du Centre pour la Cybersécurité Belgique, présente SPF, DKIM, DMARC et DNSSEC comme des mécanismes complémentaires contre le spoofing et le phishing. Sa recommandation du 2 septembre 2025 sur la sécurisation du DNS et de l’e-mail fournit des guides d’implémentation distincts pour SPF, DKIM et DMARC. Cette source belge évite de réduire le sujet à la seule délivrabilité marketing.

La page cybersécurité de GVISION replace cette protection dans un ensemble plus large : identités, postes, réseaux, données, sensibilisation et réponse. C’est important, car DMARC ne bloque ni un message envoyé depuis une boîte réellement compromise, ni un domaine ressemblant acheté par un fraudeur.

SPF, DKIM, DMARC, DNSSEC, MTA-STS et DANE : qui fait quoi ?

Les standards ne sont pas des alternatives : ils couvrent des questions différentes et se renforcent lorsqu’ils sont déployés ensemble. SPF demande si le serveur est autorisé à envoyer. DKIM demande si une signature valide protège le message. DMARC demande si l’un de ces résultats est aligné avec le domaine visible. MTA-STS et DANE protègent le trajet entre serveurs.

L’alignement est le point souvent oublié. Microsoft explique que SPF vérifie le domaine du MAIL FROM et que DKIM signe avec un domaine indiqué dans la signature ; sans DMARC, ces domaines peuvent être différents de celui affiché à l’utilisateur. La documentation Microsoft sur l’authentification e-mail montre comment DMARC relie ces résultats au champ « From » visible.

Commencer par l’inventaire des expéditeurs, pas par un enregistrement DNS

Le déploiement réussit lorsque chaque source légitime est connue, attribuée à un propriétaire et testée ; le DNS vient ensuite. Un inventaire incomplet produit deux résultats possibles : une politique trop faible qui laisse passer l’usurpation, ou une politique stricte qui bloque des factures, confirmations ou alertes utiles.

Créer une matrice par domaine et par flux

Listez le domaine principal, les domaines secondaires, les anciennes marques, les domaines défensifs et les sous-domaines. Pour chacun, documentez l’adresse visible, le domaine d’enveloppe, le domaine DKIM, le prestataire, le propriétaire métier, le volume approximatif, les destinataires habituels et la criticité. Les rapports DMARC confirmeront l’observation, mais ils ne remplacent pas les entretiens avec la finance, le marketing, les RH et les équipes opérationnelles.

Les sources à rechercher comprennent notamment :

• Exchange Online, serveurs SMTP, relais et connecteurs hybrides ;
• CRM, ERP, facturation électronique, plateformes de paiement et signatures ;
• newsletters, outils de recrutement, enquêtes, billetterie et événements ;
• applications web, formulaires de contact, monitoring et systèmes de tickets ;
• scanners, imprimantes multifonctions, NAS, alarmes et équipements techniques ;
• prestataires qui envoient réellement avec votre domaine, et pas seulement en leur nom.

Séparer les flux lorsque c’est utile

Les domaines qui n’envoient jamais doivent recevoir une politique explicite. Ils n’ont pas besoin d’autoriser des serveurs dans SPF ni de publier des clés DKIM. Une politique DMARC stricte réduit leur intérêt pour l’usurpation. Documentez néanmoins l’intention : un domaine « inutilisé » aujourd’hui pourrait être activé demain par un projet oublié.

Configurer SPF, DKIM et DMARC autour de Microsoft 365

Dans Microsoft 365, le bon ordre est SPF, DKIM sur chaque domaine personnalisé, puis DMARC progressif, avec un test externe des en-têtes. Microsoft précise que DKIM n’est pas automatiquement signé avec le domaine personnalisé tant que sa configuration n’est pas activée. L’envoi avec le domaine initial onmicrosoft.com suit une logique différente.

1. Consolider SPF

Il ne doit exister qu’un seul enregistrement SPF par domaine ou sous-domaine. Fusionnez les sources au lieu de publier plusieurs TXT commençant par v=spf1. Vérifiez les mécanismes include, retirez les anciens prestataires et surveillez la limite de dix recherches DNS fixée par SPF. La procédure Microsoft SPF insiste sur le fait que SPF seul ne suffit pas.

2. Activer DKIM sur les domaines personnalisés

Créez les deux CNAME demandés dans le portail Microsoft Defender, attendez leur résolution, puis activez la signature. Les valeurs sont propres au tenant et au domaine : ne recopiez pas un exemple trouvé dans un article. Envoyez ensuite un message vers une boîte externe et vérifiez dkim=pass ainsi que le domaine de signature. Prévoyez aussi DKIM chez chaque prestataire tiers capable de signer avec votre domaine.

3. Publier DMARC en observation

Une première politique peut utiliser p=none avec une adresse dédiée aux rapports agrégés. Elle n’applique pas encore de mise en quarantaine, mais révèle les domaines, IP et résultats observés par les destinataires participants. Les rapports XML bruts deviennent vite volumineux ; une plateforme de traitement ou un processus d’analyse interne doit transformer ces données en sources, tendances et exceptions actionnables.

Le service Microsoft 365 de GVISION peut intégrer ce chantier à la gouvernance du tenant, aux connecteurs, aux comptes techniques et au support des applications. L’objectif n’est pas seulement d’obtenir trois résultats « pass », mais de garder cette configuration cohérente lors de chaque changement.

Passer de p=none à quarantine puis reject sans incident

La progression DMARC doit être fondée sur des preuves : les flux légitimes passent avec alignement, les inconnus sont qualifiés et une procédure de retour existe. Microsoft recommande explicitement une approche graduelle vers p=reject afin d’éviter le rejet de bons messages provoqué par des échecs non intentionnels.

Définir des critères de passage

Le passage à quarantine permet aux destinataires compatibles de traiter les échecs plus sévèrement, souvent vers le courrier indésirable. Le paramètre pct peut limiter la proportion demandée, mais son interprétation dépend du destinataire et ne remplace pas les tests. Le passage à reject demande que les flux utiles soient maîtrisés. Utilisez aussi sp pour définir le comportement des sous-domaines lorsque la politique doit différer.

Garder une procédure de changement

Tout nouvel outil qui envoie des messages doit passer par une revue avant sa mise en production : sous-domaine, adresses, DKIM, SPF, alignement, destinataires de test et responsable. Sans cette porte d’entrée, la configuration se dégrade en quelques mois. Les rapports DMARC doivent rester surveillés après reject pour détecter un prestataire modifié, une clé expirée, une nouvelle source non autorisée ou une campagne d’usurpation.

MTA-STS ou DANE : sécuriser le transport SMTP après l’identité

SPF, DKIM et DMARC authentifient l’expéditeur ; MTA-STS et DANE cherchent à empêcher qu’un serveur émetteur livre le message vers une destination non authentifiée ou sans TLS fiable. Ils répondent donc à une autre couche du risque.

SMTP utilise souvent TLS de manière opportuniste : le chiffrement est utilisé lorsque les deux serveurs l’acceptent, mais un attaquant capable d’influencer le DNS ou la négociation peut tenter une redirection ou une dégradation. MTA-STS, défini par la RFC 8461, publie en HTTPS une politique indiquant les serveurs MX attendus et l’exigence TLS. TLS-RPT, défini par la RFC 8460, fournit des rapports sur les échecs de négociation ou de validation.

DANE pour SMTP utilise des enregistrements TLSA authentifiés par DNSSEC. Microsoft résume la différence ainsi : DANE exige DNSSEC, tandis que MTA-STS s’appuie sur le système d’autorités de certification. La documentation Exchange Online sur DANE et MTA-STS, mise à jour le 21 juillet 2026, explique également pourquoi TLS opportuniste ne suffit pas contre certaines attaques de résolution DNS.

Adapter la mise en œuvre au fonctionnement réel de l’organisation

La taille ne détermine pas la complexité : le nombre de domaines, de prestataires et de flux métiers est plus révélateur. Un cabinet de dix personnes avec facturation, portail client, newsletter et scanners peut avoir plus de sources d’envoi qu’une structure centralisée de cent personnes.

ASBL, école ou organisation publique

Les outils se multiplient souvent par projet, année scolaire ou subvention. Maintenez un registre avec propriétaire et date de fin. Désactivez l’autorisation SPF et les clés d’un fournisseur quitté. Protégez les domaines inactifs et les anciennes variantes. Pour les listes de diffusion qui modifient l’objet ou le corps, vérifiez l’impact sur DKIM et envisagez les mécanismes ARC lorsque la chaîne de transfert est légitime.

Groupe multi-sites ou grande entreprise

La gouvernance doit être fédérée sans perdre le contrôle central. Attribuez des sous-domaines par usage, automatisez l’inventaire DNS, imposez des exigences contractuelles aux fournisseurs et centralisez les rapports. Une équipe valide les standards ; chaque entité reste responsable de ses applications. Les acquisitions nécessitent un inventaire avant de modifier une politique héritée.

Site web et formulaires

Le serveur web ne devrait pas usurper arbitrairement l’adresse du visiteur dans le champ « From ». Utilisez une adresse de votre domaine correctement authentifiée et placez l’adresse du demandeur dans Reply-To. Cette distinction évite de casser DMARC tout en permettant la réponse. Pour les notifications hébergées chez un prestataire, privilégiez DKIM aligné et un sous-domaine dédié.

Les erreurs qui fragilisent ou interrompent la messagerie

La plupart des incidents viennent d’une vue incomplète des flux, d’un alignement mal compris ou d’une politique publiée sans observation. La syntaxe DNS est rarement le seul problème.

1. Publier plusieurs SPF : un domaine ne doit avoir qu’une politique SPF. Plusieurs enregistrements créent une erreur permanente.
2. Dépasser les recherches DNS : les include imbriqués peuvent dépasser la limite. Mesurez l’évaluation complète avant d’ajouter un fournisseur.
3. Confondre pass et alignement : SPF ou DKIM peut passer sur un domaine tiers tandis que DMARC échoue face au domaine visible.
4. Passer directement à reject : les imprimantes, CRM, formulaires ou factures oubliés deviennent des victimes collatérales.
5. Laisser p=none indéfiniment : l’organisation collecte des rapports mais ne demande jamais aux destinataires de bloquer les échecs.
6. Autoriser trop largement : l’inclusion d’une grande plateforme peut permettre à d’autres clients du fournisseur de passer SPF ; DKIM aligné réduit cette dépendance.
7. Ignorer les domaines dormants : ils restent attractifs pour l’usurpation alors qu’une politique stricte y est souvent simple.
8. Utiliser une allowlist comme correction permanente : Microsoft avertit que certaines listes d’autorisation peuvent contourner des contrôles d’authentification et de filtrage.
9. Oublier l’exploitation : une clé, un connecteur ou un fournisseur change ; sans supervision, la conformité d’aujourd’hui devient l’incident de demain.

Checklist de validation avant une politique DMARC stricte

Une politique stricte est prête lorsque l’organisation peut prouver qui envoie, comment chaque flux s’authentifie et qui réagit à un échec. Utilisez cette liste comme contrôle de changement, pas comme certification.

• Tous les domaines et sous-domaines sont inventoriés, y compris les domaines inactifs.
• Chaque source a un propriétaire métier et un responsable technique.
• Un seul enregistrement SPF valide existe et reste sous la limite de recherches DNS.
• DKIM est activé et vérifié pour Microsoft 365 et les plateformes tierces importantes.
• Le domaine SPF ou DKIM s’aligne avec le champ « From » pour chaque flux critique.
• Les rapports DMARC couvrent les cycles rares : paie, facturation, campagnes et notifications saisonnières.
• Les transferts, listes de diffusion et passerelles ont été testés.
• Les sous-domaines et domaines dormants ont une politique documentée.
• Un canal d’alerte, une procédure de retour et un propriétaire existent.
• Les changements futurs de CRM, ERP, site ou fournisseur passent par une revue e-mail.
• MTA-STS ou DANE est évalué séparément selon la maîtrise de DNSSEC et des connecteurs.
• La date, les preuves et la décision de passer à quarantine ou reject sont conservées.