Cómo EOP valida la dirección Desde para evitar la suplantación de identidad (phishing)

Sugerencia

¿Sabía que puede probar las características de Microsoft Defender XDR para Office 365 Plan 2 de forma gratuita? Use la prueba de Defender para Office 365 de 90 días en el centro de pruebas del portal de Microsoft Defender. Obtenga información sobre quién puede registrarse y los términos de prueba aquí.

Los ataques de phishing son una amenaza constante para cualquier organización de correo electrónico. Además de usar direcciones de correo electrónico del remitente suplantadas (falsificadas), los atacantes suelen usar valores en la dirección From que infringen los estándares de Internet. Para evitar este tipo de phishing, Exchange Online Protection (EOP) y Outlook.com requieren que los mensajes entrantes incluyan una dirección From compatible con RFC, como se describe en este artículo.

  • Si recibe periódicamente correo electrónico de organizaciones que tienen un formato incorrecto de las direcciones De, como se describe en este artículo, anime a estas organizaciones a actualizar sus servidores de correo electrónico para que cumplan con los estándares de seguridad modernos.

  • El campo Remitente relacionado (usado por Enviar en nombre y listas de correo) no se ve afectado por estos requisitos. Para obtener más información, consulte la siguiente entrada de blog: ¿Qué queremos decir cuando nos referimos al 'remitente' de un correo electrónico?.

Introducción a los estándares de mensajes de correo electrónico

Un mensaje de correo electrónico SMTP estándar está compuesto por el sobre del mensaje y el contenido del mensaje. El sobre del mensaje contiene información necesaria para transmitir y entregar el mensaje entre servidores SMTP. El contenido del mensaje contiene el cuerpo del mensaje y campos de encabezado de mensaje, que se denominan de forma colectiva encabezado del mensaje. El sobre del mensaje se describe en RFC 5321 y el encabezado del mensaje se describe en RFC 5322. Los destinatarios nunca ven el sobre del mensaje real porque lo genera el proceso de transmisión de mensajes y en realidad no forma parte del mensaje.

  • La dirección MAIL FROM (también conocida como dirección 5321.MailFrom , remitente P1 o remitente de sobre) es la dirección de correo electrónico que se usa en la transmisión SMTP del mensaje. Esta dirección de correo electrónico se registra normalmente en el campo de encabezado Return-Path del encabezado del mensaje (aunque es posible que el remitente designe una dirección de correo electrónico return-path diferente).

  • La dirección de origen (también conocida como dirección 5322.From o remitente P2) es la dirección de correo electrónico en el campo De encabezado y es la dirección de correo electrónico del remitente que se muestra en los clientes de correo electrónico. La dirección Desde es el foco de los requisitos de este artículo.

La dirección From se define en detalle en varias RFC (por ejemplo, las secciones RFC 5322 3.2.3, 3.4 y 3.4.1 y RFC 3696). Hay muchas variaciones en el direccionamiento y lo que se considera válido o no válido. Para simplificarlo, se recomienda el siguiente formato y definiciones:

From: "Display Name" <EmailAddress>

  • Nombre para mostrar: una frase opcional que describe el propietario de la dirección de correo electrónico.

    • Se recomienda incluir siempre el nombre para mostrar entre comillas dobles (") como se muestra. Si el nombre para mostrar contiene una coma, debe incluir la cadena entre comillas dobles por RFC 5322.
    • Si la dirección From incluye un nombre para mostrar, el valor emailAddress debe ir entre corchetes angulares (<>) como se muestra.
    • Microsoft recomienda encarecidamente insertar un espacio entre el nombre para mostrar y la dirección de correo electrónico.

  • EmailAddress: una dirección de correo electrónico usa el formato local-part@domain:

    • elemento local: cadena que identifica el buzón asociado a la dirección. Este valor es único dentro del dominio. A menudo, se usa el nombre de usuario o GUID del propietario del buzón.
    • domain: nombre de dominio completo (FQDN) del servidor de correo electrónico que hospeda el buzón identificado por la parte local de la dirección de correo electrónico.

    Además:

    • Solo una dirección de correo electrónico.
    • Se recomienda no separar los corchetes angulares con espacios.
    • No incluya texto después de la dirección de correo electrónico.

Ejemplos de direcciones buenas y malas a partir de

La tabla siguiente contiene ejemplos de direcciones From válidas:

Dirección Comentarios
From: sender@contoso.com Aceptar
From: <sender@contoso.com> Aceptar
From: < sender@contoso.com > Está bien, pero no se recomienda porque hay espacios entre los corchetes angulares y la dirección de correo electrónico.
From: "Sender, Example" <sender.example@contoso.com> Aceptar
From: "Microsoft 365" <sender@contoso.com> Aceptar
From: Microsoft 365 <sender@contoso.com> Aceptar, pero no se recomienda porque el nombre para mostrar no está entre comillas dobles.

La tabla siguiente contiene ejemplos de direcciones From que no son válidas:

Dirección Comentarios
Sin dirección de origen Cuando un mensaje llega a Microsoft 365 o Outlook.com sin una dirección From, intentamos asignar la dirección MAIL FROM a la dirección From para asegurarse de que el mensaje se puede entregar. Actualmente, el servicio acepta estos mensajes, incluso si la dirección From original es From: <>.
From: <firstname lastname@contoso.com> La dirección de correo electrónico contiene un espacio.
From: Microsoft 365 sender@contoso.com El nombre para mostrar está presente, pero la dirección de correo electrónico no está entre corchetes angulares.
From: "Microsoft 365" <sender@contoso.com> (Sent by a process) Texto después de la dirección de correo electrónico.
From: Sender, Example <sender.example@contoso.com> El nombre para mostrar contiene una coma, pero no está entre comillas dobles.
From: "Microsoft 365 <sender@contoso.com>" El valor completo se incluye incorrectamente entre comillas dobles.
From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com El nombre para mostrar está presente, pero la dirección de correo electrónico no está entre corchetes angulares.
From: Microsoft 365<sender@contoso.com> No hay espacio entre el nombre para mostrar y el corchete angular izquierdo.
From: "Microsoft 365"<sender@contoso.com> No hay espacio entre las comillas dobles de cierre y el corchete angular izquierdo.

Supresión de las respuestas automáticas a dominios personalizados

No se puede usar el valor From: <> para suprimir las respuestas automáticas. En su lugar, debe configurar un registro MX nulo para el dominio personalizado. Después de configurar el registro MX nulo, todas las respuestas se suprimen de forma natural porque no hay ninguna dirección publicada a la que el servidor que responde envíe mensajes.

Para el registro MX nulo, elija un dominio de correo electrónico que no pueda recibir correo electrónico. Por ejemplo, si el dominio principal está contoso.com, puede elegir noreply.contoso.com. El registro MX nulo de este dominio consta de un único período. Por ejemplo:

noreply.contoso.com IN MX .

Para obtener más información sobre cómo configurar registros MX, consulte Create registros DNS en cualquier proveedor de hospedaje DNS para Microsoft 365.

Para obtener más información sobre cómo publicar un MX nulo, vea RFC 7505.

Invalidación de la aplicación de direcciones

Para omitir los requisitos de direcciones de origen para el correo electrónico entrante, puede usar las reglas lista de direcciones IP permitidas (filtrado de conexiones) o flujo de correo (también conocidas como reglas de transporte), tal como se describe en Create listas de remitentes seguros en Microsoft 365. Outlook.com no permite invalidaciones de ningún tipo, incluso a través de solicitudes de soporte técnico.

No puede invalidar los requisitos de direcciones From para el correo electrónico saliente que envíe desde Microsoft 365 o Outlook.com.

Otras formas de prevenir y proteger contra los delitos cibernéticos en Microsoft 365

Para obtener más información sobre cómo reforzar su organización frente a phishing, spam, infracciones de datos y otras amenazas, consulte Procedimientos recomendados para proteger Microsoft 365 para planes empresariales.