Comment EOP valide l’adresse De pour empêcher le hameçonnage

Conseil

Saviez-vous que vous pouvez essayer gratuitement les fonctionnalités de Microsoft Defender XDR pour Office 365 Plan 2 ? Utilisez la version d’évaluation Defender for Office 365 de 90 jours sur le hub d’essais du portail Microsoft Defender. Découvrez qui peut s’inscrire et les conditions d’essai ici.

Les attaques par hameçonnage constituent une menace constante pour tout organization de courrier électronique. En plus d’utiliser des adresses e-mail d’expéditeur usurpées (falsifiées), les attaquants utilisent souvent des valeurs dans l’adresse De qui violent les normes Internet. Pour empêcher ce type d’hameçonnage, Exchange Online Protection (EOP) et Outlook.com exiger que les messages entrants incluent une adresse From conforme À la norme RFC, comme décrit dans cet article.

  • Si vous recevez régulièrement des e-mails d’organisations dont les adresses à partir de données sont incorrectes, comme décrit dans cet article, encouragez ces organisations à mettre à jour leurs serveurs de messagerie pour qu’ils se conforment aux normes de sécurité modernes.

  • Le champ Expéditeur associé (utilisé par Envoyer de la part et les listes de diffusion) n’est pas affecté par ces exigences. Pour plus d’informations, consultez le billet de blog suivant : Qu’entendons-nous par « expéditeur » d’un e-mail ?.

Vue d’ensemble des normes relatives aux messages électroniques

Un message électronique SMTP standard est constitué d’une enveloppe de message et d’un contenu de message. L’enveloppe du message contient les informations requises pour transmettre et remettre le message entre les serveurs SMTP. Le contenu du message comporte les champs d’en-tête de message (collectivement appelés l’en-tête de message) et le corps du message. L’enveloppe du message est décrite dans RFC 5321, et l’en-tête de message est décrit dans RFC 5322. Les destinataires ne voient jamais l’enveloppe réelle du message, car elle est générée par le processus de transmission du message, et elle ne fait pas réellement partie du message.

  • L’adresse MAIL FROM (également appelée 5321.MailFrom adresse, expéditeur P1 ou expéditeur d’enveloppe) est l’adresse e-mail utilisée dans la transmission SMTP du message. Cette adresse e-mail est généralement enregistrée dans le champ Retour-Chemin d’accès dans l’en-tête du message (bien qu’il soit possible pour l’expéditeur de désigner une adresse e-mail de retour différente).

  • L’adresse de départ (également appelée 5322.From adresse ou expéditeur P2) est l’adresse e-mail dans le champ d’en-tête De et l’adresse e-mail de l’expéditeur affichée dans les clients de messagerie. L’adresse De est l’objet des exigences de cet article.

L’adresse De est définie en détail sur plusieurs RFC (par exemple, RFC 5322 sections 3.2.3, 3.4 et 3.4.1 et RFC 3696). Il existe de nombreuses variantes sur l’adressage et ce qui est considéré comme valide ou non valide. Pour simplifier les choses, nous vous recommandons d’utiliser le format et les définitions suivants :

From: "Display Name" <EmailAddress>

  • Nom d’affichage : expression facultative qui décrit le propriétaire de l’adresse e-mail.

    • Nous vous recommandons de toujours placer le nom d’affichage entre guillemets doubles (") comme indiqué. Si le nom d’affichage contient une virgule, vous devez placer la chaîne entre guillemets doubles conformément à la norme RFC 5322.
    • Si l’adresse De inclut un nom d’affichage, la valeur EmailAddress doit être placée entre crochets angulaires (<>) comme indiqué.
    • Microsoft vous recommande vivement d’insérer un espace entre le nom complet et l’adresse e-mail.

  • EmailAddress : une adresse e-mail utilise le format local-part@domain:

    • local-part : chaîne qui identifie la boîte aux lettres associée à l’adresse. Cette valeur est unique dans le domaine. Souvent, le nom d’utilisateur ou le GUID du propriétaire de la boîte aux lettres est utilisé.
    • domain : nom de domaine complet (FQDN) du serveur de messagerie qui héberge la boîte aux lettres identifiée par la partie locale de l’adresse e-mail.

    En outre :

    • Une seule adresse e-mail.
    • Nous vous recommandons de ne pas séparer les crochets par des espaces.
    • N’incluez pas de texte après l’adresse e-mail.

Exemples de bonnes et mauvaises adresses From

Le tableau suivant contient des exemples d’adresses From valides :

Address Comments
From: sender@contoso.com OK
From: <sender@contoso.com> OK
From: < sender@contoso.com > OK, mais non recommandé, car il y a des espaces entre les crochets et l’adresse e-mail.
From: "Sender, Example" <sender.example@contoso.com> OK
From: "Microsoft 365" <sender@contoso.com> OK
From: Microsoft 365 <sender@contoso.com> OK, mais non recommandé, car le nom d’affichage n’est pas placé entre guillemets doubles.

Le tableau suivant contient des exemples d’adresses From qui ne sont pas valides :

Address Comments
Aucune adresse de départ Lorsqu’un message arrive à Microsoft 365 ou Outlook.com sans adresse De, nous essayons d’affecter l’adresse MAIL FROM à l’adresse De pour nous assurer que le message est livrable. Actuellement, ces messages sont acceptés par le service, même si l’adresse De d’origine est From: <>.
From: <firstname lastname@contoso.com> L’adresse e-mail contient un espace.
From: Microsoft 365 sender@contoso.com Le nom d’affichage est présent, mais l’adresse e-mail n’est pas placée entre crochets.
From: "Microsoft 365" <sender@contoso.com> (Sent by a process) Texte après l’adresse e-mail.
From: Sender, Example <sender.example@contoso.com> Le nom d’affichage contient une virgule, mais n’est pas placé entre guillemets doubles.
From: "Microsoft 365 <sender@contoso.com>" La valeur entière est incorrectement placée entre guillemets doubles.
From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com Le nom d’affichage est présent, mais l’adresse e-mail n’est pas placée entre crochets.
From: Microsoft 365<sender@contoso.com> Aucun espace entre le nom d’affichage et le crochet gauche.
From: "Microsoft 365"<sender@contoso.com> Aucun espace entre le guillemet double fermant et le crochet gauche.

Supprimer les réponses automatiques aux domaines personnalisés

Vous ne pouvez pas utiliser la valeur From: <> pour supprimer les réponses automatiques. Au lieu de cela, vous devez configurer un enregistrement MX null pour le domaine personnalisé. Une fois que vous avez configuré l’enregistrement MX null, toutes les réponses sont naturellement supprimées, car il n’existe aucune adresse publiée pour le serveur qui répond à envoyer des messages.

Pour l’enregistrement MX null, choisissez un domaine de messagerie qui ne peut pas recevoir d’e-mail. Par exemple, si le domaine principal est contoso.com, vous pouvez choisir noreply.contoso.com. L’enregistrement MX null pour ce domaine se compose d’un point unique. Par exemple :

noreply.contoso.com IN MX .

Pour plus d’informations sur la configuration des enregistrements MX, consultez Create enregistrements DNS sur n’importe quel fournisseur d’hébergement DNS pour Microsoft 365.

Pour plus d’informations sur la publication d’un mx null, consultez RFC 7505.

Remplacement de l’application de l’adresse à partir de

Pour contourner les exigences d’adresse De pour les e-mails entrants, vous pouvez utiliser la liste d’adresses IP autorisées (filtrage des connexions) ou les règles de flux de courrier (également appelées règles de transport) comme décrit dans Create listes d’expéditeurs approuvés dans Microsoft 365. Outlook.com n’autorise pas les remplacements d’aucune sorte, même par le biais de demandes de support.

Vous ne pouvez pas remplacer les exigences d’adresse De pour les e-mails sortants que vous envoyez à partir de Microsoft 365 ou Outlook.com.

Autres moyens de prévenir et de protéger contre la cybercriminalité dans Microsoft 365

Pour plus d’informations sur la façon de renforcer votre organization contre le hameçonnage, le courrier indésirable, les violations de données et d’autres menaces, consultez Meilleures pratiques pour la sécurisation des plans Microsoft 365 pour les entreprises.