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

Les messages envoyés à des domaines professionnels (@company.com) ne sont généralement pas filtrés par le fournisseur de messagerie que décrivent les articles de cette base centrés sur le grand public. Ils passent d’abord par une passerelle de messagerie sécurisée (SEG, secure email gateway) (Proofpoint, Mimecast, Barracuda, Cisco/IronPort ou Exchange Online Protection de Microsoft 365), choisie et configurée par l’administrateur informatique de l’organisation destinataire. Les passerelles obéissent à l’administrateur, pas au destinataire, et se comportent de façon fondamentalement différente de Gmail ou de Yahoo. Cet article présente ce modèle et les trois grandes passerelles tierces ; pour le filtrage des clients Microsoft 365, voir Exigences de Microsoft envers les expéditeurs.

Provenance : les pages de Proofpoint Essentials sur le flux de messagerie et sur URL Defense sont réservées aux utilisateurs connectés sur help.proofpoint.com ; le contenu ci-dessous provient d’instantanés de la Wayback Machine (mai 2025 et mars 2025 respectivement). L’article de Mimecast sur les définitions URL Protect est protégé par Cloudflare sur le site d’assistance ; le contenu provient d’un instantané Wayback de juillet 2025.

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

Conséquences pour un expéditeur :

• La réputation est plus binaire. Vous êtes sur une liste de blocage ou dans une catégorie de faible réputation, ou vous ne l’êtes pas ; aucune personnalisation par utilisateur ne vient 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 qu’à travers un récapitulatif quotidien : vos journaux indiquent « livré », le destinataire dit « jamais reçu ».
• Une décision d’administrateur couvre des milliers de boîtes. Un blocage sur le domaine d’une grande entreprise retire tout le domaine d’un coup ; inversement, 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 / *.ppe-hosted.com → Proofpoint ; *.mimecast.com → Mimecast ; *.barracudanetworks.com / appliance Barracuda sur site → Barracuda ; *.mail.protection.outlook.com → Microsoft 365/EOP.

Proofpoint

Flux de messagerie et ordre de filtrage (Essentials)

Les messages entrants sont traités dans cet ordre :

1. Vérifications de réputation DNS/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 : un message bloqué comme Virus ne peut jamais être libéré, ni par le client ni par Proofpoint.
5. Analyse anti-usurpation : DMARC, DKIM et SPF.
6. Filtres : filtres personnalisés de l’administrateur et listes d’expéditeurs autorisés ou bloqués. Les exécutables (.exe, .dll, .bat, .js, etc.) sont bloqués avant les 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) : non contournée par les filtres personnalisés ; même un message exempté par un filtre d’autorisation voit ses liens réécrits.

Lectures pratiques : les rejets PDR/CSI au niveau de la connexion ont lieu avant même que le contenu soit examiné (correction = réputation de l’IP), tandis que les mises en quarantaine relèvent de la politique ou du contenu (correction = contenu ou liste blanche de 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 d’IP fondé sur la classification du contenu par apprentissage automatique, conçu pour identifier les IP compromises ou appartenant à des botnets ; les IP identifiées sont retardées (reportées) ou bloquées d’un coup chez tous les destinataires protégés par 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/ (redirige vers proofpoint.com/us/ipcheck) : saisissez l’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’y a aucune assistance téléphonique pour les retraits de liste.
• Les clients de Proofpoint bénéficient d’un traitement accéléré via le portail d’assistance ; les autres n’ont que l’outil et l’adresse email.
• Si une organisation précise protégée par Proofpoint vous bloque (politique, et non réputation globale), Proofpoint ne donnera pas suite à votre demande : c’est l’organisation destinataire qui doit ouvrir le ticket ; 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 via urldefense.proofpoint.com (ou urldefense.com) et analyse la destination au moment du clic. Format réécrit (v2) :

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

Comportements utiles à connaître pour l’expéditeur :

• 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 (important 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 administrateur existent par domaine ou IP, par adresse d’expéditeur, pour les URL en texte brut et pour les 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 une raison pour laquelle de « jolies » URL affichées par-dessus des href de suivi peuvent finir par pointer vers un endroit inattendu dans les messages protégés.
• En cas de verdict malveillant, l’utilisateur voit une page de blocage et l’URL du navigateur change ; les signalements de faux positifs à Proofpoint exigent le lien réécrit d’origine tiré de l’email, pas l’URL de la page de blocage.
• Il n’existe pas de décodeur URL Defense public officiel pour Essentials ; des décodeurs tiers existent (le paramètre u= se décode mécaniquement).
• L’analyse au moment du clic signifie que 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 (vérifications du domaine + validation de 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). La configuration se fait par définition URL Protect, appliquée par stratégie ; les principaux réglages avec lesquels un expéditeur peut entrer en conflit :

• Mode de réécriture : Relaxed (seulement les URL valides avec un TLD), Moderate (ajoute les adresses IP), Aggressive (tout ce qui ressemble à une URL ; seul mode qui réécrit les URL contenant des caractères interdits).
• L’analyse par catégorie d’URL bloque selon la catégorie ; Compromised, Phishing & Fraud, Malware et Botnets sont bloqués à tous les niveaux ; Spam Sites et Suspicious sont bloqués en Moderate/Aggressive ; Private IPs et le modèle d’apprentissage automatique zero-day supplémentaire uniquement en Aggressive. Un domaine de suivi ou de destination classé « Spam Sites » ou « Suspicious » est bloqué chez la plupart des clients.
• Action sur une URL dangereuse : Allow (journalisé), Warn (page intermédiaire, l’utilisateur peut continuer), Block (page de blocage) ; pour les URL contenues dans des pièces jointes, c’est la suppression de la pièce jointe qui se déclenche. Browser Isolation (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 : 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 (liens réécrits jusqu’à 200 caractères, ce qui modifie visiblement l’objet) ; les messages en texte brut peuvent être convertis en HTML précisément pour que les liens deviennent réécrivables (« 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 visuellement proches des domaines internes ou surveillés du client : des domaines d’envoi sosies peuvent les déclencher même lorsqu’ils sont légitimes.
• L’analyse des URL dans les pièces jointes couvre les formats HTML/TXT/PDF, les archives et les formats Office/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 (défense contre le « quishing »).
• Les pages User Awareness peuvent soumettre un pourcentage des clics à une page intermédiaire avant de laisser passer : des clics peuvent être journalisés alors que l’humain 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 des stratégies propres à chaque client. Le texte de rejet SMTP indique la catégorie de motif (réputation ou stratégie nommée), ce qui vous dit s’il faut passer par les canaux de Mimecast destinés aux expéditeurs ou par l’administrateur du destinataire : les rejets qui citent une stratégie de client précise nécessitent l’administrateur de ce client, exactement comme chez Proofpoint. (L’article de Mimecast sur le dépannage des messages rejetés ou reportés ne faisait pas partie des sources de cette extraction ; les indications par code de cette page restent un travail à venir.)

Barracuda

Barracuda Reputation Block List (BRBL) et retrait

Barracuda exploite sa propre DNSBL publique (zone de requête b.barracudacentral.org), consultée à la fois par les appliances Barracuda et par des tiers (voir Listes de blocage DNS et zones Spamhaus). Le retrait se demande via https://www.barracudacentral.org/rbl/removal-request :

• Champs obligatoires : adresse IP du serveur de messagerie, adresse email de contact, numéro de téléphone. Facultatifs : nom et email du client Barracuda, motif de la demande de 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 ; 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 sert à recevoir les demandes, pas à documenter : les critères d’inscription et la procédure de recours ne sont pas publiés.

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

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

• Les messages en liste d’autorisation échappent au score de spam mais sont toujours analysés par l’antivirus ; les contrôles d’IP et de pièces jointes interdites s’appliquent toujours. L’ajout à la liste d’autorisation n’est pas un contournement complet.
• Signification dans le journal des messages : « Allowed » = a passé tous les filtres ; « Allow Listed » = correspond à une entrée d’autorisation explicite. (Utile quand l’administrateur d’un destinataire vous lit ses journaux.)
• La protection contre l’usurpation de l’expéditeur (rejeter les messages externes qui utilisent le propre domaine du client dans le From) se configure globalement ou par domaine, et le réglage global l’emporte sur les entrées de liste d’autorisation propres aux utilisateurs : une raison fréquente pour laquelle « ils nous ont pourtant mis en liste blanche » rebondit encore quand vous mettez 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 le From visible.
• La vérification SPF est désactivée par défaut (charge DNS) mais, une fois activée, peut marquer ou bloquer les échecs, avec une quarantaine recommandée pour les résultats none ; les IP de services de transfert connus échappent aux contrôles SPF, de débit et de réputation d’IP. La vérification DKIM est gourmande en processeur et 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 DSN destinées à des expéditeurs protégés par Barracuda rebondissent parfois.
• Les appliances Barracuda évaluent le contenu (les seuils de score de spam sont fixés par l’administrateur de chaque client), si bien qu’un même message peut être marqué sur un site Barracuda et passer sans problème sur un autre.

Les rejets Barracuda comportent généralement une URL pointant vers barracudanetworks.com/reputation avec l’IP inscrite : le renvoi direct vers le formulaire de retrait de la BRBL ci-dessus.

Recommandations pratiques pour les expéditeurs

Chauffer vers des listes B2B

• La logique standard de chauffe d’IP s’applique, mais le signal de retour est différent : les passerelles ne vous donnent ni tableau de bord postmaster ni FBL, donc surveillez le texte des rebonds et les taux de reports de remise par domaine de réception, pas l’engagement.
• Les passerelles s’appuient fortement sur la réputation statique au moment de la connexion (PDR, CSI, BRBL, Spamhaus). Une IP toute neuve et sans historique déclenche des reports de type liste grise et des limitations de débit ; une IP sale déclenche un rejet pur et simple. Vérifiez l’IP sur ipcheck.proofpoint.com, b.barracudacentral.org et 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. Segmentez la chauffe par domaine de réception et, face à des avalanches de 4xx, ralentissez domaine par 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 liée 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 énergiquement les adresses avant de chauffer.
• Chauffer en fonction de l’engagement (« envoyer d’abord aux ouvreurs récents ») n’aide guère ici : les passerelles ne surveillent pas les ouvertures. Ce qui aide, c’est une authentification propre (SPF/DKIM/DMARC tous réussis et alignés), puisque les passerelles exécutent tôt dans leur chaîne des étapes explicites d’anti-usurpation, ainsi qu’un rDNS et un HELO valides.

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, la catégorie de motif et 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 : au moment de la livraison (sandboxing, pré-analyse), au moment du clic (URL Defense, URL Protect, Microsoft SafeLinks), et parfois à plusieurs reprises. Chaque visite atteint votre redirection de suivi des clics et est enregistrée comme un « clic ». Effets et détection :

• Les taux de clics B2B sont gonflés et peu 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 désabonnement et les liens du pied de page) ; clics depuis des plages d’IP de centres de données ou l’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 pour des destinataires B2B : les scanners suivent aussi ces liens. Utilisez la sémantique POST du désabonnement en un clic via List-Unsubscribe et exigez une action de confirmation explicite pour toute opération destructrice déclenchée par un GET.
• Les pages intermédiaires Warn et User Awareness de Mimecast font qu’un vrai clic peut être journalisé par la passerelle sans jamais atteindre votre page ; inversement, votre page peut être téléchargée par l’infrastructure de Browser Isolation plutôt que par l’appareil de l’utilisateur.
• C’est le pendant, côté entreprise, des ouvertures par proxy d’Apple MPP : voir l’article sur le suivi et MPP dans operations/ pour le fonctionnement du pixel, les ouvertures via le proxy de MPP et la conception de politiques de mise en sommeil sur des données faussées (Distorsions du suivi et de la mesure).
• 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 le filtrage ultérieur des messages d’entreprise transférés voit des signatures cassées.

Demander aux destinataires un ajout à la liste blanche

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

1. Vos plages d’IP d’envoi (une autorisation au niveau de la connexion l’emporte sur le filtrage du contenu et, chez Barracuda, une autorisation d’IP ou de service de transfert connu contourne aussi SPF et le contrôle du débit).
2. Votre domaine d’enveloppe (Return-Path) et votre domaine DKIM, pas seulement le From affiché : 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 (« Exclude URLs that contain specified domains » chez Proofpoint ; exceptions de définition chez Mimecast) si la réécriture casse vos liens ou si vos statistiques comptent.

Réserves pour cadrer les attentes des 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’IP ; il est propre à chaque client et doit donc être demandé auprès de chaque organisation destinataire importante ; et il ne survit pas à un changement d’éditeur de passerelle par le destinataire.

Ce qui ne fonctionne PAS

• Les actions sur l’engagement (« campagnes de reconquête pour améliorer la réputation ») : les passerelles ne mesurent pas l’engagement.
• Attendre la fin d’une inscription : les inscriptions BRBL et PDR persistent jusqu’au 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 par la politique d’un client : les éditeurs n’agissent que sur leurs propres inscriptions de réputation globale ; les blocages d’un client relèvent de ce client.
• Changer d’IP pour échapper à une inscription : les inscriptions fondées sur le contenu (PDR classe selon le contenu ; Barracuda évalue le contenu) suivent le flux de messages vers la nouvelle IP, et les IP neuves relancent 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.