SPF, DKIM et DMARC au Maroc : protéger le domaine e-mail de votre entreprise contre l’usurpation

La réponse courte : SPF, DKIM et DMARC sont trois enregistrements DNS qui permettent aux serveurs de messagerie du monde entier de vérifier qu’un e-mail portant votre nom de domaine vient bien de chez vous. SPF liste les serveurs autorisés à envoyer, DKIM signe chaque message avec une clé, et DMARC vérifie que l’adresse visible par le destinataire correspond à l’un des deux, puis indique quoi faire en cas d’échec : rien, mettre en indésirables, ou rejeter. Tant que DMARC n’est pas en mode rejet, n’importe qui peut encore envoyer un faux e-mail « de » votre direction financière à vos clients.

Ce guide explique le rôle de chacun, les valeurs à publier pour Microsoft 365 et Google Workspace, la méthode pour passer au rejet sans bloquer vos propres e-mails, et les erreurs que nous corrigeons le plus souvent chez les entreprises marocaines. Les éléments techniques proviennent de la documentation officielle de Microsoft et de Google, et des normes publiées par l’IETF.

Pourquoi c’est devenu indispensable

L’usurpation de domaine est la base des arnaques les plus coûteuses pour une PME : faux changement de RIB d’un fournisseur, fausse demande urgente du dirigeant, fausse facture. Nous détaillons ces scénarios dans les 8 arnaques par e-mail qui visent les PME marocaines. Sans DMARC en mode rejet, le serveur de votre client n’a aucune consigne claire pour écarter un message qui prétend venir de votre domaine.

Le second enjeu est la délivrabilité. Google, dans ses règles pour les expéditeurs, exige au minimum SPF ou DKIM de tous les expéditeurs vers Gmail, et les trois mécanismes pour ceux qui envoient plus de 5 000 messages par jour vers des comptes Gmail. Microsoft applique des exigences comparables aux domaines qui dépassent ce volume vers Outlook.com. Même en dessous de ces seuils, un domaine mal authentifié voit ses devis et ses factures finir plus souvent en indésirables.

SPF, DKIM et DMARC en un tableau

Mécanisme	Ce qu’il vérifie	Où il se publie	Limite à connaître
SPF	Le serveur expéditeur figure dans la liste autorisée du domaine de l’enveloppe (MAIL FROM)	Un enregistrement TXT sur le domaine	Ne protège pas l’adresse visible, échoue souvent au transfert, maximum 10 recherches DNS
DKIM	Le message porte une signature valide et n’a pas été modifié	Un TXT ou un CNAME sur selecteur._domainkey	Chaque service d’envoi doit signer avec votre domaine
DMARC	SPF ou DKIM réussit et correspond au domaine de l’adresse visible (From)	Un TXT sur _dmarc.votredomaine	Sans politique quarantine ou reject, il ne fait qu’observer

Le point clé est l’alignement. Un message peut réussir SPF pour le domaine technique d’un prestataire d’envoi, tout en affichant votre adresse dans le champ « De ». Seul DMARC fait le lien entre l’authentification et l’adresse que le destinataire voit. Un message réussit DMARC si au moins l’un des deux contrôles, SPF ou DKIM, réussit et est aligné.

SPF : déclarer qui a le droit d’envoyer

Un enregistrement SPF est une ligne TXT qui commence par v=spf1, liste les sources autorisées, et se termine par une règle pour tout le reste. Pour un domaine qui n’envoie qu’avec Microsoft 365, Microsoft recommande :

v=spf1 include:spf.protection.outlook.com -all

Pour Google Workspace, la source à inclure est include:_spf.google.com. Si un serveur interne envoie aussi, on ajoute son adresse IP publique avec ip4:.

Trois règles évitent la plupart des pannes :

• Un seul enregistrement SPF par domaine. Deux lignes v=spf1 produisent une erreur permanente, et SPF échoue pour tous vos e-mails.
• Pas plus de 10 recherches DNS. Chaque include:, a, mx, exists ou redirect en consomme au moins une, et les include: imbriqués en ajoutent. Au-delà, SPF échoue. Les adresses ip4: et ip6: ne comptent pas.
• Terminer par -all. Microsoft le recommande quand DKIM et DMARC sont en place, car DMARC traite alors correctement les messages non autorisés. ?all est à réserver aux tests.

DKIM : signer chaque message

DKIM ajoute à chaque e-mail une signature chiffrée, vérifiable grâce à une clé publique publiée dans votre DNS. Elle prouve que le message vient d’un service autorisé par votre domaine et qu’il n’a pas été modifié en route. Contrairement à SPF, elle survit en général au transfert d’un message.

Avec Microsoft 365, on active DKIM pour chaque domaine personnalisé depuis le portail Microsoft Defender, dans les paramètres d’authentification des e-mails. Microsoft fournit deux CNAME à publier, selector1._domainkey et selector2._domainkey, dont les valeurs sont propres à votre tenant : il faut les copier depuis le portail, jamais d’un exemple. Une fois les CNAME en place, on active la signature ; le second sélecteur sert aux rotations de clé.

Avec Google Workspace, on génère la clé dans la console d’administration (Applications, Google Workspace, Gmail, Authentifier les e-mails). Google recommande une clé de 2 048 bits si votre hébergeur DNS l’accepte, avec le préfixe google, ce qui donne l’hôte google._domainkey. On publie la valeur TXT, puis on clique sur « Démarrer l’authentification ». Google indique jusqu’à 48 heures avant que la signature soit effective.

Point souvent oublié : chaque outil qui envoie avec votre domaine (logiciel d’e-mailing, CRM, ERP comme Odoo, plateforme de facturation, site web) doit lui aussi signer en DKIM avec votre domaine. Sinon, ses messages réussiront peut-être SPF pour le domaine du prestataire, mais échoueront à DMARC.

DMARC : relier le tout et donner la consigne

DMARC se publie en TXT sur l’hôte _dmarc. Sa forme minimale de départ :

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.ma

Balise	Rôle	Valeurs
p	Politique pour le domaine	none (observer), quarantine (indésirables), reject (rejet)
rua	Adresse des rapports agrégés quotidiens	Une boîte dédiée, pas celle d’un salarié
pct	Part des messages en échec soumis à la politique	Par défaut, tous ; utile pour monter par paliers
sp	Politique pour les sous-domaines	Mêmes valeurs que p
adkim / aspf	Alignement souple ou strict	r (par défaut) ou s

Les rapports rua arrivent sous forme de fichiers XML envoyés par les grands fournisseurs de messagerie. Ils listent les adresses IP qui envoient au nom de votre domaine, et si elles réussissent ou non. Bruts, ils sont peu lisibles : un service d’analyse DMARC les transforme en tableau de bord. C’est en les lisant que l’on découvre l’imprimante multifonction, le logiciel de paie ou l’ancien hébergement web qui envoyaient encore « en votre nom ».

Un enregistrement DMARC sur le domaine principal couvre aussi tous les sous-domaines qui n’ont pas le leur, y compris ceux qui n’existent pas. En revanche, chaque sous-domaine qui envoie réellement a besoin de son propre SPF et de son DKIM.

La méthode pour passer au rejet sans rien casser

Microsoft recommande explicitement une approche progressive. Voici celle que nous appliquons :

1. Inventorier tous les expéditeurs : messagerie (Microsoft 365, Google Workspace, ancien cPanel), site web et formulaires, ERP et CRM, outil d’e-mailing, logiciel de paie, scanners et imprimantes, alertes de supervision.
2. Corriger SPF : un seul enregistrement, sous les 10 recherches, terminé par -all.
3. Activer DKIM sur la messagerie et sur chaque service tiers qui le permet, avec votre domaine.
4. Publier DMARC en p=none avec une adresse de rapports dédiée.
5. Lire les rapports pendant plusieurs semaines et corriger chaque source légitime en échec, ou la déplacer vers un sous-domaine dédié.
6. Passer en p=quarantine, éventuellement par paliers avec pct, puis observer.
7. Passer en p=reject une fois les rapports propres, et continuer à les surveiller.

Microsoft conseille aussi d’envoyer les e-mails marketing depuis un sous-domaine (par exemple news.votredomaine.ma), avec son propre SPF, DKIM et DMARC. Une campagne mal reçue n’entame alors pas la réputation du domaine utilisé par vos équipes au quotidien.

Et les domaines qui n’envoient rien ?

Beaucoup d’entreprises possèdent plusieurs domaines : la variante en .com d’un .ma, une ancienne marque, un domaine réservé pour un projet. S’ils n’envoient aucun e-mail, ils sont encore plus simples à usurper, car personne ne les surveille. La configuration recommandée par Microsoft est courte :

Enregistrement	Hôte	Valeur
SPF	domaine	v=spf1 -all
DMARC	_dmarc	v=DMARC1; p=reject;

Pas de DKIM sur ces domaines. Si vous êtes sur Microsoft 365 sans utiliser le domaine en onmicrosoft.com pour envoyer, Microsoft recommande d’y ajouter aussi un DMARC en rejet, depuis le centre d’administration.

Les erreurs que nous corrigeons le plus souvent

1. Deux enregistrements SPF après une migration, l’ancien hébergeur et le nouveau : SPF échoue pour tout le domaine.
2. Un SPF qui dépasse les 10 recherches à force d’ajouter des include: à chaque nouvel outil.
3. DKIM jamais activé après la bascule vers Microsoft 365 ou Google Workspace : la messagerie marche, mais rien n’est signé avec votre domaine. Nous en parlons dans notre guide de migration de messagerie cPanel vers Microsoft 365.
4. DMARC en p=none depuis des années, sans que personne ne lise les rapports : on observe l’usurpation sans la bloquer.
5. Des rapports envoyés dans la boîte du dirigeant ou d’un salarié parti, au lieu d’une boîte ou d’un groupe dédiés.
6. Un passage direct en reject qui fait disparaître les factures envoyées par l’ERP ou les e-mails du site.
7. Les domaines inutilisés oubliés, alors qu’ils servent justement aux fraudeurs.

Ce que SPF, DKIM et DMARC ne font pas

Ces trois mécanismes protègent votre domaine contre l’usurpation exacte. Ils n’empêchent pas un fraudeur d’acheter un domaine qui ressemble au vôtre, à une lettre près, ni de pirater une vraie boîte de votre entreprise ou de celle d’un fournisseur. Ils se complètent donc avec le MFA sur tous les comptes, voir notre guide de déploiement du MFA, avec un filtrage des e-mails entrants, et avec une procédure de vérification par téléphone de tout changement de coordonnées bancaires. Pour un tenant Microsoft 365, ces réglages font partie des 10 réglages pour sécuriser Microsoft 365.

Checklist SPF, DKIM et DMARC

• Liste complète des services qui envoient avec votre domaine.
• Un seul SPF, sous les 10 recherches DNS, terminé par -all.
• DKIM actif sur la messagerie et sur chaque service tiers.
• DMARC publié, avec une boîte dédiée aux rapports et un outil pour les lire.
• Calendrier de passage de none à quarantine puis reject.
• Sous-domaine dédié aux envois marketing.
• SPF et DMARC en rejet sur les domaines qui n’envoient rien.
• Contrôle après chaque nouvel outil ou changement de fournisseur.

Comment nous procédons

Nous commençons par un état des lieux de vos domaines : enregistrements actuels, expéditeurs détectés, en-têtes d’e-mails réels. Nous corrigeons SPF, activons DKIM sur la messagerie et sur vos outils, publions DMARC en observation, puis lisons les rapports avec vous jusqu’au passage en rejet. Le travail se fait dans votre zone DNS, quel que soit l’hébergeur de votre domaine, et s’intègre à notre offre de cybersécurité d’entreprise au Maroc. Pour la messagerie elle-même, nous intervenons en tant que partenaire Microsoft et partenaire Google Workspace, dans le cadre de notre cloud managé Microsoft 365. Nous intervenons depuis Casablanca, à distance ou sur site partout au Maroc.

Pour une messagerie sur Google, ces réglages font partie de notre guide Google Workspace au Maroc.

Vous voulez savoir si votre domaine peut être usurpé aujourd’hui ? Demandez votre audit initial offert : nous vérifions SPF, DKIM et DMARC sur vos domaines et vous répondons sous 24 h ouvrées avec les corrections à faire.