Délivrabilité B2B et passerelles de messagerie d’entreprise

Quand vous écrivez à des adresses professionnelles (@company.com), vos messages ne sont généralement pas filtrés par un fournisseur de messagerie grand public comme Gmail ou Yahoo. Ils passent d’abord par une passerelle de messagerie sécurisée (SEG, secure email gateway) que l’administrateur informatique de l’organisation destinataire choisit et configure : Proofpoint, Mimecast, Barracuda, Cisco IronPort ou Exchange Online Protection de Microsoft 365. Les passerelles obéissent à l’administrateur, pas au destinataire, et se comportent très différemment des fournisseurs grand public.

Vous trouverez ci-dessous le modèle des passerelles et les trois grandes passerelles tierces. Pour le filtrage dans les environnements M365, voir Exigences de Microsoft envers les expéditeurs.

Note sur les sources : les pages de Proofpoint Essentials sur le flux de messagerie et sur URL Defense exigent une connexion sur help.proofpoint.com. Leur contenu provient donc d’instantanés de la Wayback Machine (mai 2025 et mars 2025 respectivement). L’article d’assistance de Mimecast sur les définitions URL Protect est derrière une vérification Cloudflare, et son contenu provient d’un instantané Wayback de juillet 2025.

En quoi le filtrage des passerelles diffère de celui des fournisseurs grand public

Ce que cela implique pour un expéditeur :

• La réputation fonctionne presque en tout ou rien. Soit vous êtes sur une liste de blocage ou dans une catégorie de faible réputation, soit vous ne l’êtes pas. Aucune personnalisation propre à chaque utilisateur ne peut vous sauver en partie.
• La quarantaine est invisible. De nombreuses passerelles acceptent le message (250 OK), puis le retiennent dans une quarantaine que le destinataire ne voit que dans un récapitulatif quotidien. Vos journaux indiquent « livré », et le destinataire affirme ne l’avoir jamais reçu.
• La décision d’un seul administrateur couvre des milliers de boîtes aux lettres. Un blocage sur le domaine d’une grande entreprise retire tout le domaine d’un coup. De la même manière, une seule entrée en liste blanche règle le problème d’un coup.
• Identifiez la passerelle à partir de l’enregistrement MX avant de diagnostiquer : *.pphosted.com ou *.ppe-hosted.com désigne Proofpoint, *.mimecast.com désigne Mimecast, *.barracudanetworks.com ou une appliance Barracuda sur site désigne Barracuda, et *.mail.protection.outlook.com désigne Microsoft 365 (EOP).

Proofpoint

Ordre du flux de messagerie et du filtrage (Essentials)

Proofpoint Essentials traite les messages entrants dans cet ordre :

1. Vérifications de réputation DNS et de l’adresse IP : PDR (Proofpoint Dynamic Reputation) et CSI (Cloudmark Sender Intelligence).
2. Vérifications de validité DNS (contrôle DNS de l’expéditeur entrant).
3. Attachment Defense (si la licence le prévoit).
4. Analyse antivirus. Ni le client ni Proofpoint ne peuvent jamais libérer un message bloqué comme virus.
5. Analyse anti-usurpation : DMARC, DKIM et SPF.
6. Filtres : filtres personnalisés définis par l’administrateur, et listes d’expéditeurs autorisés et bloqués. Les exécutables (.exe, .dll, .bat, .js et autres) sont bloqués avant l’exécution des filtres personnalisés. Tout filtre qui déclenche Quarantine ou Allow saute l’étape antispam.
7. Moteur de contenu antispam.
8. Analyse et réécriture URL Defense (si la licence le prévoit). Les filtres personnalisés ne contournent pas cette étape : même un message exempté par un filtre d’autorisation voit ses liens réécrits.

En pratique, les rejets PDR et CSI au moment de la connexion ont lieu avant tout examen du contenu, et la correction porte donc sur la réputation de l’adresse IP. Les mises en quarantaine relèvent de la politique ou du contenu, et la correction porte donc sur le contenu ou sur une entrée en liste blanche ajoutée par l’administrateur. Une entrée « Allow » de l’administrateur contourne le score de spam, mais pas la réécriture des URL ni les contrôles antivirus.

PDR et ipcheck.proofpoint.com

PDR (Proofpoint Dynamic Reputation) est un système de réputation des adresses IP fondé sur la classification du contenu par apprentissage automatique. Il cherche à identifier les adresses IP compromises et celles qui appartiennent à des botnets. Une fois identifiée, une adresse IP est retardée (reportée) ou bloquée d’un coup chez tous les destinataires que protège Proofpoint. Une vague soudaine de reports ou de rejets simultanés sur de nombreux domaines professionnels sans rapport entre eux est le symptôme classique d’une inscription PDR.

• Vérifier et demander le retrait : https://ipcheck.proofpoint.com/ (qui redirige vers proofpoint.com/us/ipcheck). Saisissez l’adresse IP pour savoir si elle est sur liste de blocage ou retardée, et soumettez des informations ou une demande de retrait depuis le même outil.
• Relance : écrivez à delist-request@proofpoint.com si l’outil ne règle pas le problème. Le traitement des demandes peut prendre 72 heures. Il n’existe aucune assistance téléphonique pour les retraits de liste.
• Les clients de Proofpoint bénéficient d’un traitement plus rapide via le portail d’assistance. Les autres ne peuvent utiliser que l’outil et l’adresse email.
• Si une organisation précise que protège Proofpoint vous bloque (une décision de politique, et non la réputation globale), Proofpoint ne donnera pas suite à votre demande. C’est l’organisation destinataire qui doit ouvrir le ticket, car seuls ses contacts d’assistance autorisés peuvent joindre le support de Proofpoint.

URL Defense (réécriture des liens)

URL Defense réécrit chaque URL des messages livrés pour la faire passer par urldefense.proofpoint.com (ou urldefense.com), et analyse la destination au moment du clic. Le format réécrit (v2) ressemble à ceci :

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.google.com&d=DwMBaQ&c=...&r=...&m=...&s=...&e=

Les comportements qui comptent pour les expéditeurs :

• Interaction avec DKIM : par défaut, URL Defense réécrit les URL des messages signés avec DKIM, ce qui casse la signature DKIM après la livraison. Cela compte lorsque le message est ensuite transféré (voir ARC). Les administrateurs peuvent désactiver la réécriture des messages signés avec DKIM.
• Des exemptions définies par l’administrateur existent pour un domaine ou une adresse IP, pour une adresse d’expéditeur, pour les URL en texte brut et pour les adresses IP nues. C’est ce que vous demandez à l’administrateur d’un destinataire de configurer si la réécriture abîme vos liens.
• Si le texte d’un lien affiche une URL différente du véritable href, l’URL du texte visible est réécrite et devient le lien. C’est pourquoi une « jolie » URL affichée par-dessus un lien de suivi peut finir par pointer vers un endroit inattendu dans les messages protégés.
• Lorsqu’un lien est jugé malveillant, l’utilisateur voit une page de blocage et l’URL du navigateur change. Pour signaler un faux positif à Proofpoint, il vous faut le lien réécrit d’origine tiré de l’email, et non l’URL de la page de blocage.
• Proofpoint ne propose aucun décodeur public officiel des liens URL Defense pour Essentials. Des décodeurs tiers existent, car le paramètre u= se décode mécaniquement.
• Comme les liens sont analysés au moment du clic, l’infrastructure de Proofpoint visite vos liens. Voir Pourquoi les indicateurs de clics mentent plus bas.

Canaux d’assistance de Proofpoint (synthèse)

Mimecast

URL Protect (réécriture des liens)

Mimecast réécrit tous les liens des emails entrants et analyse la destination en temps réel au moment du clic (il vérifie le domaine et valide l’URL avant de laisser passer l’utilisateur). Les liens réécrits pointent vers un domaine Mimecast régional (par exemple protect-eu.mimecast.com/s/... ; l’hôte exact dépend de la grille ou de la région qui héberge le compte). Chaque définition URL Protect fixe la configuration, et une stratégie l’applique. Voici les principaux réglages auxquels un expéditeur peut se heurter :

• Mode de réécriture : Relaxed ne réécrit que les URL valides dotées d’un domaine de premier niveau. Moderate ajoute les adresses IP. Aggressive réécrit tout ce qui ressemble à une URL, et c’est le seul mode qui réécrit les URL contenant des caractères interdits.
• L’analyse par catégorie d’URL bloque les liens selon leur catégorie. Compromised, Phishing & Fraud, Malware et Botnets sont bloqués à tous les niveaux. Spam Sites et Suspicious sont bloqués en Moderate et en Aggressive. Private IPs, ainsi que le modèle d’apprentissage automatique zero-day supplémentaire, ne s’appliquent qu’en Aggressive. Un domaine de suivi ou de destination classé « Spam Sites » ou « Suspicious » est donc bloqué chez la plupart des clients.
• Action sur une URL dangereuse : Allow (journalisé), Warn (une page intermédiaire ; l’utilisateur peut continuer) ou Block (une page de blocage). Pour une URL contenue dans une pièce jointe, c’est la pièce jointe qui est supprimée. Browser Isolation (une session de navigation sécurisée à distance) peut remplacer l’accès direct pour les sites suspects.
• Tous les clics sont journalisés, et chaque clic est analysé à nouveau. C’est une autre source de trafic de robots dans les statistiques de l’expéditeur.
• Les liens sont réécrits en HTTPS par défaut. Les URL de la ligne d’objet peuvent être supprimées ou réécrites (un lien réécrit peut atteindre 200 caractères, ce qui modifie visiblement l’objet). Un message en texte brut peut être converti en HTML précisément pour que ses liens puissent être réécrits (« Create Missing HTML Body »).
• L’option Ignore Signed Messages évite la réécriture des messages signés numériquement, pour préserver les signatures.
• Display URL Destination Domain ajoute le vrai domaine de destination au lien réécrit, par exemple protect-eu.mimecast.com/s/1dBvZWHZ?url.uk.m.mimecastprotect.com.
• Les contrôles de similarité avancés signalent les liens qui ressemblent aux domaines internes ou surveillés du client. Des domaines d’envoi sosies peuvent déclencher ce contrôle même lorsqu’ils sont légitimes.
• L’analyse des URL dans les pièces jointes couvre les fichiers HTML, TXT et PDF, les archives, et les formats Office et OpenOffice jusqu’à 50 Mo (les fichiers chiffrés de plus de 40 Mo sont traités comme malveillants). Les codes QR contenus dans les images sont analysés, et un verdict malveillant sur un code QR peut entraîner le rejet (Reject) ou la mise en attente (Hold) du message entier (une défense contre le « quishing »).
• Les pages User Awareness peuvent soumettre un pourcentage des clics à une page intermédiaire avant de laisser passer l’utilisateur. Un clic peut donc être journalisé alors que la personne n’atteint jamais votre page.
• Mimecast ne réécrit jamais ses propres domaines login*.mimecast.com.

Retrait de liste : Mimecast bloque les expéditeurs à la fois par ses propres contrôles de réputation globale et par les stratégies de chaque client. Son texte de rejet SMTP indique la catégorie de motif (la réputation, ou une stratégie nommée). Vous savez ainsi s’il faut passer par les canaux de Mimecast destinés aux expéditeurs ou contacter l’administrateur du destinataire. Un rejet qui cite la stratégie d’un client précis nécessite l’administrateur de ce client, exactement comme chez Proofpoint. (L’article de Mimecast sur le dépannage des messages rejetés et reportés ne faisait pas partie des sources utilisées ici. Les indications code par code de cette page ne sont donc pas encore couvertes.)

Barracuda

Barracuda Reputation Block List (BRBL) et retrait

Barracuda exploite sa propre DNSBL publique (zone de requête b.barracudacentral.org). Les appliances Barracuda comme des tiers la consultent (voir Listes de blocage DNS et zones Spamhaus). Pour demander un retrait, utilisez https://www.barracudacentral.org/rbl/removal-request :

• Champs obligatoires : l’adresse IP du serveur de messagerie, une adresse email de contact et un numéro de téléphone. Facultatifs : le nom ou l’adresse email du client Barracuda, et le motif du retrait.
• Les demandes accompagnées d’une justification valable sont généralement examinées et traitées en moins de 12 heures.
• Les demandes sans informations valables sont ignorées, et les soumissions en double ne sont pas prises en compte. Soumettez une seule fois, avec une vraie explication de la cause et de la correction.
• Le formulaire ne fait que recueillir les demandes. Barracuda ne publie ni ses critères d’inscription ni de procédure de recours.

Fonctionnement des listes d’autorisation et de blocage (Email Security Gateway)

Les listes de l’administrateur se trouvent dans les pages BLOCK et ACCEPT de l’appliance. Elles couvrent les adresses IP, les domaines et sous-domaines, et les adresses email d’expéditeurs ou de destinataires :

• Les messages en liste blanche échappent au score de spam, mais sont toujours analysés par l’antivirus. Les contrôles d’adresse IP et de pièces jointes interdites s’appliquent toujours. L’ajout à la liste blanche n’est pas un contournement complet.
• Dans le journal des messages, « Allowed » signifie que le message a passé tous les filtres, et « Allow Listed » qu’il correspond à une entrée d’autorisation explicite. La distinction est utile quand l’administrateur d’un destinataire vous lit ses journaux.
• La protection contre l’usurpation de l’expéditeur rejette les messages externes qui utilisent le propre domaine du client dans l’en-tête From. Elle se règle globalement ou pour chaque domaine, et le réglage global l’emporte sur les entrées de liste blanche propres à chaque utilisateur. C’est une raison fréquente pour laquelle les messages rebondissent encore alors qu’« ils nous ont mis en liste blanche » : vous avez mis le propre domaine du destinataire dans l’en-tête From.
• Les filtres d’expéditeur personnalisés portent sur Envelope From, Header From et Reply-To. Les trois identités comptent, pas seulement l’adresse From visible.
• La vérification SPF est désactivée par défaut en raison de la charge DNS. Une fois activée, elle peut marquer ou bloquer les échecs, et la quarantaine est recommandée pour les résultats none. Les adresses IP des services de transfert connus échappent aux contrôles SPF, de débit et de réputation IP. La vérification DKIM consomme beaucoup de processeur et est désactivée par défaut. Barracuda prévient que les lignes HTML de plus de 990 caractères peuvent casser la validation DKIM. L’application de DMARC est disponible via la Cloud Protection Layer.
• La suppression des rebonds invalides marque les messages sortants avec un jeton chiffré et rejette les rebonds qui ne le portent pas. C’est une des raisons pour lesquelles les notifications d’état de livraison (DSN) envoyées à des expéditeurs protégés par Barracuda rebondissent parfois.
• Les appliances Barracuda évaluent le contenu, et l’administrateur de chaque client fixe les seuils de score de spam. Un même message peut donc être marqué sur un site Barracuda et passer sans problème sur un autre.

Les rejets de Barracuda comportent généralement une URL sur barracudanetworks.com/reputation avec l’adresse IP inscrite. Cette URL mène directement au formulaire de retrait de la BRBL décrit plus haut.

Recommandations pratiques pour les expéditeurs

Chauffer vers des listes B2B

• La logique habituelle de la chauffe d’IP s’applique, mais le retour d’information est différent. Les passerelles ne vous donnent ni tableau de bord postmaster ni FBL : surveillez donc le texte des rebonds et les taux de reports de remise pour chaque domaine de réception, et non l’engagement.
• Les passerelles s’appuient fortement sur la réputation statique au moment de la connexion (PDR, CSI, BRBL, Spamhaus). Une adresse IP toute neuve et sans historique déclenche des reports et des limitations de débit semblables à la liste grise ; une adresse IP au passé chargé déclenche un rejet pur et simple. Vérifiez l’adresse IP sur ipcheck.proofpoint.com, sur b.barracudacentral.org et sur les grandes listes de blocage publiques avant le premier envoi.
• Les listes B2B concentrent le risque : un seul domaine d’entreprise peut représenter 5 à 10 % de la liste. Chauffez séparément pour chaque domaine de réception et, quand un domaine renvoie une avalanche de reports 4xx, ralentissez pour ce seul domaine plutôt que de tout mettre en pause.
• Les listes d’entreprise se dégradent plus vite que les listes grand public (l’attrition due aux changements d’emploi est couramment estimée à 20 à 30 % par an). Les listes B2B périmées atteignent des taux élevés de destinataires inconnus, que les passerelles et leurs flux de réputation considèrent comme un fort signal de spam. Vérifiez soigneusement les adresses avant de chauffer.
• Chauffer en fonction de l’engagement (« envoyer d’abord aux ouvreurs récents ») n’aide guère ici, car les passerelles ne surveillent pas les ouvertures. Ce qui aide, c’est une authentification propre, avec SPF, DKIM et DMARC tous réussis et alignés, puisque les passerelles exécutent tôt dans leur chaîne des étapes explicites d’anti-usurpation. Un rDNS et un HELO valides aident aussi.

Interpréter les rebonds des passerelles

Recueillez toujours le texte intégral de la réponse SMTP. Les rejets des passerelles nomment généralement l’éditeur et la catégorie de motif, et donnent souvent l’URL exacte de correction.

Pourquoi les indicateurs de clics mentent (scanners de sécurité)

Toutes les grandes passerelles réécrivent les liens et les visitent depuis l’infrastructure de l’éditeur. Elles le font au moment de la livraison (sandboxing ou pré-analyse), au moment du clic (URL Defense, URL Protect, Microsoft Safe Links), et parfois à plusieurs reprises. Chaque visite atteint votre redirection de suivi des clics et est enregistrée comme un « clic ». Les effets, et comment les détecter :

• Les taux de clics B2B sont gonflés et ne sont pas fiables comme signaux d’engagement. Un schéma du type « tous les liens cliqués moins de 1 seconde après la livraison » est le fait d’un scanner, pas d’une personne.
• Heuristiques pour filtrer les clics de robots dans les données d’événements : clics quelques secondes après la livraison ; tous les liens d’un message cliqués (y compris le lien de désabonnement et les liens du pied de page) ; clics depuis des plages d’adresses IP de centres de données ou depuis le numéro de système autonome (ASN) de l’éditeur de la passerelle ; requêtes HEAD ou user-agents qui ne sont pas des navigateurs ; plusieurs destinataires d’un même domaine qui « cliquent » de façon identique.
• Ne considérez jamais un clic sur un lien de désabonnement ou de confirmation comme une intention d’un destinataire B2B, car les scanners suivent aussi ces liens. Utilisez le comportement POST du désabonnement en un clic via List-Unsubscribe, et exigez une action de confirmation explicite avant toute modification destructrice qu’une requête GET déclencherait.
• Avec les pages intermédiaires Warn et User Awareness de Mimecast, la passerelle peut journaliser un vrai clic qui n’atteint jamais votre page. À l’inverse, l’infrastructure de Browser Isolation peut télécharger votre page à la place de l’appareil de l’utilisateur.
• C’est le pendant, côté entreprise, des ouvertures par proxy dues à Apple MPP. Pour le fonctionnement des pixels de suivi, le comportement des ouvertures par proxy de MPP et la conception de politiques de mise en sommeil sur des données faussées, voir Distorsions du suivi et de la mesure dans operations/.
• La réécriture affecte aussi la délivrabilité des messages transférés. URL Defense casse DKIM sur les messages signés qu’il réécrit, si bien que tout filtre qui vérifie plus loin des messages d’entreprise transférés voit des signatures cassées.

Demander aux destinataires un ajout à la liste blanche

Si une part significative de votre liste est B2B, publiez une demande d’ajout à la liste blanche sur laquelle l’équipe informatique du destinataire peut agir. Demandez-lui d’autoriser les éléments suivants, par ordre de préférence :

1. Vos plages d’adresses IP d’envoi. Une autorisation au niveau de la connexion l’emporte sur le filtrage du contenu et, chez Barracuda, une autorisation pour un service de transfert connu ou une adresse IP contourne aussi SPF et le contrôle du débit.
2. Votre domaine d’enveloppe (Return-Path) et votre domaine DKIM, pas seulement l’adresse From affichée. Les filtres d’expéditeur des passerelles vérifient séparément Envelope From, Header From et Reply-To.
3. Une exemption de réécriture des liens pour votre domaine de suivi (chez Proofpoint, « Exclude URLs that contain specified domains » ; chez Mimecast, des exceptions dans la définition), si la réécriture casse vos liens ou si vos statistiques comptent.

Cadrez les attentes de vos clients. Sur la plupart des passerelles, l’ajout à la liste blanche laisse actifs l’analyse antivirus, le blocage des pièces jointes et les contrôles d’adresse IP. Il ne vaut que pour un client, et doit donc être demandé auprès de chaque organisation destinataire importante. Enfin, il ne survit pas à un changement d’éditeur de passerelle chez le destinataire.

Ce qui ne fonctionne PAS

• Agir sur l’engagement (« campagnes de reconquête pour améliorer la réputation »), car les passerelles ne mesurent pas l’engagement.
• Attendre la fin d’une inscription. Les inscriptions BRBL et PDR persistent jusqu’à ce que vous demandiez le retrait, ou jusqu’à ce que le comportement en cause ne soit plus observé. Utilisez les portails.
• Contacter l’éditeur de la passerelle au sujet d’un blocage imposé par la politique d’un client. Les éditeurs n’agissent que sur leurs propres inscriptions de réputation globale ; le client est maître de ses blocages.
• Changer d’adresse IP pour échapper à une inscription. Les inscriptions fondées sur le contenu (PDR classe selon le contenu ; Barracuda évalue le contenu) suivent le flux d’emails vers la nouvelle adresse IP, et les adresses IP neuves ramènent le problème de limitation de débit. Voir Surveillance et rétablissement de la réputation pour la procédure générale de retrait de liste.