Rafael Pfister

Consulting

SPF, DKIM et DMARC : une authentification des e-mails qui tient

Les grands fournisseurs de messagerie exigent des e-mails authentifiés, mais votre propre DMARC est à p=none depuis des années et personne ne sait quels systèmes envoient sous le domaine de l’entreprise. J’amène les domaines à une politique applicable de manière maîtrisée : d’abord l’inventaire complet, puis le durcissement par étapes, sans perdre de messages légitimes.

Le conseil est assuré en allemand ou en anglais.

  • SPF
  • DKIM
  • DMARC
  • p=reject
  • Rapports DMARC
  • Protection contre l’usurpation
  • Délivrabilité

Pourquoi c’est plus que trois enregistrements DNS

Publier les enregistrements est la partie rapide. Le vrai travail réside dans la question de savoir qui envoie légitimement sous le domaine : l’ERP, le service de newsletter, le système de tickets, les appareils multifonctions, le prestataire externe de paie. Chaque source oubliée signifie des messages perdus après l’application de la politique. C’est pourquoi chacun de mes projets DMARC commence par un inventaire des sources d’envoi réelles à partir des rapports DMARC et des journaux de messagerie, et non par la modification de la zone DNS.

Prestations

  • Inventaire des sources d’envoiIdentifier chaque système qui envoie sous vos domaines, y compris les oubliés ; à partir des rapports, des journaux et des analyses du tenant.
  • Conception des enregistrementsSPF dans la limite de requêtes, signature DKIM par source d’envoi, DMARC avec une stratégie d’alignement judicieuse, sous-domaines et domaines parqués compris.
  • Plan par étapes vers p=rejectDurcissement via none, quarantine et des paliers pct, avec analyse des rapports avant chaque étape et des critères d’arrêt définis.
  • Les cas difficilesTransferts, listes de diffusion, passerelles en amont de Microsoft 365, scellement ARC : les cas sur lesquels les projets DMARC échouent généralement.

Exemples tirés de la pratique