Retour au blog
guidetechniqueHR Tech

SPF, DKIM, DMARC : protéger vos emails de paie contre l'usurpation

Publié le 2026-06-127 min de lectureCleanIssue

Pourquoi votre domaine est une cible

Votre SaaS RH envoie des emails que les salariés ouvrent sans réfléchir : « votre bulletin de paie est disponible », « validez vos congés », « complétez votre dossier d'embauche ». C'est exactement ce dont rêve un attaquant. S'il peut envoyer un email qui semble venir de notifications.votre-saas.fr, il obtient des taux de clic qu'aucune campagne de phishing classique n'atteint.

Et si votre domaine n'est pas correctement protégé, il n'a même pas besoin de compromettre quoi que ce soit : il usurpe l'adresse d'expéditeur, tout simplement.

Les trois mécanismes, en clair

SPF : qui a le droit d'envoyer

Un enregistrement DNS qui liste les serveurs autorisés à envoyer des emails pour votre domaine. Si vous passez par un service d'envoi (Brevo, SendGrid, Postmark, Resend), ses serveurs doivent y figurer — et rien d'autre.

Erreur classique : le +all ou ?all en fin d'enregistrement, qui autorise en pratique n'importe qui. Terminez par ~all (softfail) ou -all (rejet strict).

DKIM : le message n'a pas été modifié

Une signature cryptographique ajoutée à chaque email sortant. Le destinataire vérifie la signature via une clé publique publiée dans votre DNS. Sans DKIM, même un SPF correct ne protège pas le contenu du message.

Erreur classique : des clés de 1024 bits générées en 2019 et jamais tournées. Passez en 2048 bits et prévoyez une rotation annuelle.

DMARC : que faire en cas d'échec

DMARC dit aux serveurs destinataires quoi faire quand SPF ou DKIM échouent : ne rien faire (p=none), mettre en quarantaine (p=quarantine) ou rejeter (p=reject).

Erreur classique — et de loin la plus fréquente que nous constatons en audit : un DMARC en p=none depuis des années. p=none ne protège rien. C'est un mode d'observation, pas une politique.

Le chemin de migration réaliste

  • Publiez DMARC en p=none avec une adresse rua pour recevoir les rapports agrégés
  • Analysez 2 à 4 semaines de rapports : identifiez tous les émetteurs légitimes (marketing, transactionnel, CRM, outil de facturation…)
  • Alignez SPF et DKIM pour chacun d'eux
  • Passez en p=quarantine avec pct=25, puis montez progressivement
  • Objectif final : p=reject
  • Comptez 4 à 8 semaines pour un éditeur SaaS avec plusieurs flux d'envoi. C'est long, mais chaque étape est réversible.

    Checklist express

  • [ ] SPF présent, se termine par ~all ou -all, moins de 10 lookups DNS
  • [ ] DKIM 2048 bits sur tous les flux d'envoi (transactionnel ET marketing)
  • [ ] DMARC en p=quarantine minimum, avec rapports rua analysés
  • [ ] Sous-domaines d'envoi séparés (ex. mail.votre-saas.fr pour le transactionnel)
  • [ ] BIMI envisagé une fois DMARC en p=reject (logo vérifié dans les boîtes mail)
  • Un Premier diagnostic CleanIssue inclut la vérification de votre posture email : configuration DNS, alignement des flux, et exposition réelle à l'usurpation. Verdict en 48h.

    Pour aller plus loin

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    Sources

    Rédigé par CleanIssue
    Revu le 2026-06-12

    Services associés

    Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit