Shadow IT et email : les outils qui envoient sans que vous le sachiez

Vous avez configuré SPF, DKIM et DMARC. Votre infrastructure email est sous contrôle. Puis un jour, en analysant vos rapports DMARC, vous découvrez des dizaines d’IP inconnues qui envoient des emails au nom de votre domaine. Pas du phishing - des outils internes que personne en IT n’a validés.

Bienvenue dans le monde du shadow IT email.

Qu’est-ce que le shadow IT email

Le shadow IT désigne l’utilisation de services technologiques sans l’approbation explicite de l’équipe informatique. Appliqué à l’email, c’est un phénomène courant : des équipes métier configurent des outils SaaS pour envoyer des emails depuis votre domaine, sans passer par l’IT.

Ces outils ne sont pas malveillants. Ils sont parfaitement légitimes. Mais ils envoient des emails au nom de votredomaine.com sans que personne n’ait :

Ajouté leur IP au record SPF
Configuré une signature DKIM avec votre domaine
Vérifié l’alignement avec votre politique DMARC

Résultat : ces emails échouent aux contrôles d’authentification et finissent en spam - ou sont bloqués si vous êtes en p=reject.

Les coupables habituels

La liste est longue, et elle grandit avec chaque nouvel outil adopté par vos équipes :

Marketing et CRM

HubSpot - emails marketing, séquences de prospection, notifications CRM
Salesforce - alertes workflow, emails de campagne, notifications commerciales
ActiveCampaign, Klaviyo, Drip - automation marketing
Intercom, Drift - chatbots qui envoient des récapitulatifs par email
Mailchimp - la newsletter que le service com’ a lancée sans prévenir

Outils internes et productivité

Notion - partage de pages par email, commentaires
Calendly, Cal.com - confirmations et rappels de rendez-vous
Jira, Linear - notifications de tickets
DocuSign, Yousign - envoi de documents à signer
Typeform, Tally - confirmations de formulaires

Support et facturation

Zendesk, Freshdesk - tickets de support envoyés depuis votre domaine
Stripe - reçus et factures
QuickBooks, Pennylane - documents comptables
SendGrid, Postmark - utilisés par un développeur pour un projet ponctuel, puis oubliés

Anciens prestataires

Un freelance qui a configuré un outil il y a deux ans
Un ancien ESP dont l’include SPF est toujours actif mais qui n’est plus utilisé
Un service en période d’essai qui continue d’envoyer des notifications

Pourquoi c’est un problème

Échecs d’authentification silencieux

Si ces services ne sont pas couverts par votre SPF et n’ont pas de signature DKIM alignée, leurs emails échouent aux vérifications DMARC. Avec p=none, ils passent quand même - vous ne voyez rien. Avec p=quarantine ou p=reject, ils sont filtrés ou rejetés.

Dans les deux cas, quelqu’un dans votre entreprise s’étonne que “les emails n’arrivent pas” - sans savoir que c’est un problème DNS.

Blocage de la migration DMARC

C’est la raison numéro un pour laquelle les entreprises restent bloquées en p=none pendant des mois. Elles veulent passer à p=reject (comme le recommande le guide DMARC : de p=none à p=reject), mais elles ont peur de casser des flux qu’elles ne connaissent pas.

Inflation du record SPF

Chaque outil ajouté nécessite un include: ou une IP dans votre record SPF. Avec 5, 10, 15 services, vous dépassez la limite des 10 lookups DNS imposée par la RFC 7208. Un SPF cassé invalide tous vos envois, pas seulement ceux du service fautif.

Surface d’attaque élargie

Chaque include: dans votre SPF autorise les serveurs de ce fournisseur à envoyer au nom de votre domaine. Si un prestataire que vous n’utilisez plus est compromis, ses serveurs peuvent envoyer du spam ou du phishing avec votre identité.

Comment détecter le shadow IT email

Méthode 1 : les rapports DMARC RUA

C’est l’outil principal. Si vous avez un record DMARC avec un tag rua=, les fournisseurs de messagerie (Gmail, Microsoft, Yahoo) vous envoient quotidiennement un rapport agrégé de toutes les IP qui ont tenté d’envoyer des emails depuis votre domaine.

Dans ces rapports, cherchez les entrées avec :

source_ip: [IP inconnue]
spf: fail
dkim: fail
disposition: none (ou quarantine/reject)

Ou, plus subtil :

source_ip: [IP inconnue]
spf: pass          ← l'IP est dans votre SPF
dkim: fail         ← mais DKIM n'est pas configuré
disposition: none

Ce deuxième cas est typique du shadow IT : quelqu’un a ajouté l’include SPF mais n’a pas activé DKIM. L’email est “autorisé” par SPF mais pas signé cryptographiquement.

Pour interpréter les rapports en détail, consultez le guide Lire et comprendre les rapports DMARC.

Méthode 2 : le dashboard Sender Audit

Si vous avez ajouté votre domaine sur Sender Audit, les rapports DMARC sont parsés automatiquement. Le dashboard classe les sources en trois catégories :

Vérifiées : sources connues et correctement authentifiées
À examiner : sources avec une authentification partielle (SPF pass mais DKIM fail, ou inversement)
Non autorisées : sources inconnues en échec complet

Le monitoring continu détecte également les nouvelles sources qui apparaissent d’un rapport à l’autre - le signal le plus fiable pour attraper un nouvel outil SaaS configuré sans votre accord.

Méthode 3 : l’audit SPF inversé

Listing de tous les include: dans votre record SPF actuel, puis vérification un par un :

dig TXT votredomaine.com - listez tous les mécanismes include:
Pour chaque include:, identifiez le service (ex. include:spf.brevo.com → Brevo)
Demandez à chaque département : “Utilisez-vous encore ce service pour envoyer des emails ?”
Supprimez les include: orphelins

C’est fastidieux mais révélateur. Il n’est pas rare de trouver 2 ou 3 services obsolètes.

Le workflow de résolution

Une fois les sources shadow IT identifiées, voici le processus à suivre pour chacune :

Étape 1 : Identifier le service

À partir de l’IP source (visible dans le rapport DMARC), remontez au service :

rDNS : dig -x [IP] - souvent le nom du provider apparaît dans le PTR
Whois : whois [IP] - identifie l’organisation propriétaire du range IP
ASN : le numéro d’AS et l’organisation associée (Amazon, Google Cloud, OVH, etc.)
Sender Audit : le dashboard affiche automatiquement le rDNS et l’organisation pour chaque IP source

Étape 2 : Valider la légitimité

Contactez le département concerné :

“Utilisez-vous [service X] pour envoyer des emails depuis votredomaine.com ?”
“Qui l’a configuré et pour quel usage ?”
“Est-ce toujours actif et nécessaire ?”

Trois issues possibles :

Résultat	Action
Légitime et actif	Intégrer (étape 3)
Légitime mais obsolète	Désactiver le service et retirer l’autorisation SPF
Non reconnu	Investiguer et bloquer

Étape 3 : Intégrer proprement

Pour chaque service légitime validé :

SPF : vérifiez que l’include: est présent (et que vous ne dépassez pas 10 lookups)
DKIM : activez la signature DKIM personnalisée dans les paramètres du service. La plupart offrent cette option via un CNAME DNS
Vérifiez l’alignement : envoyez un test depuis le service et analysez-le avec Sender Audit pour confirmer que SPF et DKIM s’alignent avec le From:
Documentez : maintenez un registre des services autorisés à envoyer depuis votre domaine

Étape 4 : Bloquer les sources non légitimes

Retirez les include: SPF correspondants
Montez votre politique DMARC progressivement vers p=reject
Surveillez les rapports RUA pour confirmer que le trafic non autorisé est bloqué

Prévenir le shadow IT : gouvernance email

Le shadow IT email est un problème récurrent. Sans gouvernance, il revient dès qu’un nouveau service est adopté.

Politique d’envoi email

Documentez une politique simple et partagée :

Tout service qui envoie des emails depuis @votredomaine.com doit être validé par l’IT avant configuration. Contactez it@votredomaine.com avec le nom du service, l’usage prévu, et la documentation DNS du fournisseur.

Checklist d’onboarding d’un nouveau service

Pour chaque nouveau SaaS qui doit envoyer des emails :

Collecter les informations DNS du fournisseur (include SPF, CNAME DKIM)
Vérifier que l’ajout SPF ne dépasse pas 10 lookups
Configurer DKIM personnalisé
Tester l’envoi avec Sender Audit
Ajouter le service au registre
Optionnel : dédier un sous-domaine (support.votredomaine.com pour Zendesk)

Monitoring continu

Même avec une bonne gouvernance, des services passent entre les mailles. Le monitoring automatique est le filet de sécurité :

Les rapports DMARC signalent toute nouvelle source
Le monitoring Sender Audit alerte en cas de changement DNS (nouveau include: SPF, DKIM modifié, DMARC altéré)
La vérification toutes les 12 heures détecte les dérives avant qu’elles n’impactent vos envois

Cas pratique : une PME avec 8 services d’envoi

Voici un cas réel simplifié. Une PME de 50 personnes avec le domaine acme.fr :

Service	Département	Dans le SPF	DKIM custom	Découverte
Google Workspace	IT	✅	✅	Connu
Brevo	Marketing	✅	✅	Connu
HubSpot	Commercial	✅	❌	Rapport DMARC
Zendesk	Support	✅	❌	Rapport DMARC
Calendly	Commercial	❌	❌	Rapport DMARC
Stripe	Finance	❌	❌	Rapport DMARC
Ancien Mailjet	Marketing	✅	❌	Audit SPF
Freelance Postmark	Ancien projet	✅	❌	Audit SPF

Résultat de l’audit :

2 services connus et correctement configurés
2 services connus dans le SPF mais sans DKIM → DKIM activé
2 services non couverts → ajoutés au SPF + DKIM configuré
2 services obsolètes → include: retirés du SPF

Après correction : le record SPF passe de 9 à 7 lookups, tous les services légitimes passent DMARC, et la migration vers p=reject peut enfin commencer.

Pour aller plus loin

Lire et comprendre les rapports DMARC (RUA)
DMARC : migrer de p=none à p=reject
SPF : le guide complet
DKIM : signer vos emails
Email et DNS : tous les records à connaître
Dashboard Sender Audit pour visualiser vos sources d’envoi