Configuración de SPF para identificar orígenes de correo electrónico válidos para el dominio de Microsoft 365

Sender Policy Framework (SPF) es un método de autenticación por correo electrónico que ayuda a validar el correo enviado desde su organización de Microsoft 365 para evitar remitentes suplantados que se usan en el riesgo de correo electrónico empresarial (BEC), ransomware y otros ataques de suplantación de identidad (phishing).

El propósito principal de SPF es validar los orígenes de correo electrónico para un dominio. En concreto, SPF usa un registro TXT en DNS para identificar orígenes de correo válidos para el dominio. Los sistemas de recepción de correo electrónico usan el registro TXT de SPF para comprobar que el correo electrónico de la dirección del remitente utilizada durante la transmisión SMTP del mensaje (conocido como dirección MAIL FROM, 5321.MailFrom dirección, remitente P1 o remitente de sobre) procede de un origen de correo conocido y designado para ese dominio.

Por ejemplo, si el dominio de correo electrónico de Microsoft 365 es contoso.com, crea un registro TXT de SPF en DNS para que el dominio contoso.com identifique Microsoft 365 como origen de correo autorizado de contoso.com. Los sistemas de correo electrónico de destino comprueban el registro TXT de SPF en contoso.com para determinar si el mensaje procede de un origen autorizado para contoso.com correo electrónico.

Antes de empezar, esto es lo que necesita saber sobre SPF en Microsoft 365 en función de su dominio de correo electrónico:

• Si usa solo el dominio de dirección de enrutamiento de Email (MOERA) de Microsoft Online para el correo electrónico (por ejemplo, contoso.onmicrosoft.com): no es necesario hacer nada. El registro TXT de SPF ya está configurado para usted. Microsoft posee el dominio onmicrosoft.com, por lo que somos responsables de crear y mantener los registros DNS en ese dominio y subdominios. Para obtener más información sobre los dominios *.onmicrosoft.com, consulte ¿Por qué tengo un dominio "onmicrosoft.com"?

• Si usa uno o varios dominios personalizados para el correo electrónico (por ejemplo, contoso.com): el proceso de inscripción de Microsoft 365 ya requiere que cree o modifique el registro TXT de SPF en DNS para su dominio personalizado para identificar Microsoft 365 como origen de correo autorizado. Sin embargo, todavía tiene más trabajo que hacer para lograr la máxima protección por correo electrónico:

  • Consideraciones sobre subdominios:

    • Para los servicios de correo electrónico que no están bajo su control directo (por ejemplo, servicios de correo electrónico masivos), se recomienda usar un subdominio (por ejemplo, marketing.contoso.com) en lugar de su dominio de correo electrónico principal (por ejemplo, contoso.com). No quiere que los problemas con el correo enviado desde esos servicios de correo electrónico afecten a la reputación del correo enviado por los empleados en el dominio de correo electrónico principal. Para obtener más información sobre cómo agregar subdominios, consulte ¿Puedo agregar subdominios personalizados o varios dominios a Microsoft 365?.

    • Cada subdominio que use para enviar correo electrónico desde Microsoft 365 requiere su propio registro TXT de SPF. Por ejemplo, el registro TXT de SPF para contoso.com no cubre marketing.contoso.com; marketing.contoso.com necesita su propio registro TXT de SPF.

      Sugerencia

      Email protección de autenticación para subdominios no definidos está cubierta por DMARC. Los subdominios (definidos o no) heredan la configuración de DMARC del dominio primario (que se puede invalidar por subdominio). Para obtener más información, consulte Configuración de DMARC para validar el dominio De dirección para remitentes en Microsoft 365.

  • Si posee dominios registrados pero no utilizados: si posee dominios registrados que no se usan para correo electrónico o nada (también conocidos como dominios estacionados), configure los registros TXT de SPF para indicar que ningún correo electrónico debe provenir de esos dominios, como se describe más adelante en este artículo.

• SPF por sí sola no es suficiente. Para obtener el mejor nivel de protección de correo electrónico para los dominios personalizados, también debe configurar DKIM y DMARC como parte de la estrategia general de autenticación por correo electrónico . Para obtener más información, consulte la sección Pasos siguientes al final de este artículo.

  Importante

  En organizaciones complejas en las que es difícil identificar todos los orígenes de correo válidos para el dominio, es importante configurar rápidamente la firma DKIM y DMARC (en modo "no realizar ninguna acción") para el dominio. Un servicio de informes DMARC es muy útil para identificar orígenes de correo electrónico y errores de SPF para el dominio.

En el resto de este artículo se describen los registros TXT de SPF que debe crear para dominios personalizados en Microsoft 365.

Sintaxis de registros TXT de SPF

Los registros TXT de SPF se describen exhaustivamente en RFC 7208.

La sintaxis básica del registro tx de SPF para un dominio personalizado en Microsoft 365 es:

v=spf1 <valid mail sources> <enforcement rule>

O bien:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Por ejemplo:

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

• v=spf1 identifica el registro TXT como un registro TXT de SPF.

• Orígenes de correo válidos: orígenes de correo válidos especificados para el dominio. Usa dominios, direcciones IP o ambos:

  • Dominios: include: los valores especifican otros servicios o dominios como orígenes de correo válidos del dominio original. En última instancia, estos valores conducen a una dirección IP mediante búsquedas DNS.

    La mayoría de las organizaciones de Microsoft 365 requieren include:spf.protection.outlook.com en el registro TXT de SPF para el dominio. Otros servicios de correo electrónico de terceros a menudo requieren un valor adicional include: para identificar el servicio como un origen válido de correo electrónico del dominio original.

  • Direcciones IP: un valor de dirección IP incluye los dos elementos siguientes:

    • Valor ip4: o ip6: para identificar el tipo de dirección IP.
    • La dirección IP que se puede resolver públicamente del sistema de correo electrónico de origen. Por ejemplo:
      • Una dirección IP individual (por ejemplo, 192.168.0.10).
      • Intervalo de direcciones IP con notación de enrutamiento de Inter-Domain sin clase (CIDR) (por ejemplo, 192.168.0.1/26). Asegúrese de que el rango no sea demasiado grande o demasiado pequeño.

    En Microsoft 365, normalmente se usan direcciones IP en el registro TXT de SPF solo si tiene servidores de correo electrónico locales que envían correo desde el dominio de Microsoft 365 (por ejemplo, Exchange Server implementaciones híbridas). Algunos servicios de correo electrónico de terceros también pueden usar un intervalo de direcciones IP en lugar de un include: valor en el registro TXT de SPF.

• Regla de cumplimiento: indica a los sistemas de correo electrónico de destino qué hacer con los mensajes de orígenes que no se especifican en el registro TXT de SPF para el dominio. Los valores admitidos son:

  • -all (error): los orígenes no especificados en el registro TXT de SPF no están autorizados para enviar correo para el dominio, por lo que los mensajes deben rechazarse. Lo que realmente sucede con el mensaje depende del sistema de correo electrónico de destino, pero los mensajes suelen descartarse.

    En el caso de los dominios de Microsoft 365, se recomienda -all (error) porque también se recomienda DKIM y DMARC para el dominio. La directiva DMARC especifica qué hacer con los mensajes que producen un error en SPF o DKIM, y los informes de DMARC le permiten validar los resultados.

    Sugerencia

    Como se indicó anteriormente, DMARC configurado con un servicio de informes de DMARC ayuda en gran medida a identificar orígenes de correo electrónico y errores de SPF para el dominio.

  • ~all (error temporal): es probable que los orígenes no especificados en el registro TXT de SPF no estén autorizados para enviar correo para el dominio, por lo que los mensajes se deben aceptar pero marcar. Lo que realmente sucede con el mensaje depende del sistema de correo electrónico de destino. Por ejemplo, es posible que el mensaje se ponga en cuarentena como correo no deseado, se entregue en la carpeta de Email no deseado o se entregue en la Bandeja de entrada con un identificador agregado al cuerpo del asunto o del mensaje.

    Dado que también recomendamos DKIM y DMARC para dominios de Microsoft 365, las diferencias entre -all (error grave) y ~all (error temporal) se eliminan eficazmente (DMARC trata cualquiera de los resultados como un error SPF). DMARC usa SPF para confirmar que los dominios en las direcciones MAIL FROM y From se alinean y el mensaje procede de un origen válido para el dominio From.

  Sugerencia

  ?all (neutral) también está disponible para sugerir ninguna acción específica en los mensajes de orígenes no identificados. Este valor se usa para las pruebas y no se recomienda este valor en entornos de producción.

Puntos importantes que hay que recordar:

• Cada dominio o subdominio definido en DNS requiere un registro TXT de SPF y solo se permite un registro SPF por dominio o subdominio. Email dmARC controla mejor la protección de autenticación para subdominios no definidos.
• No se puede modificar el registro TXT de SPF existente para el dominio *.onmicrosoft.com.
• Cuando el sistema de correo electrónico de destino comprueba los orígenes de correo electrónico válidos en el registro SPF, se produce un error en la validación de SPF si la comprobación requiere demasiadas búsquedas DNS. Para obtener más información, consulte la sección Solución de problemas de registros TXT de SPF más adelante en este artículo.

Registros TXT de SPF para dominios personalizados en Microsoft 365

• Escenario: usa contoso.com para el correo electrónico en Microsoft 365 y Microsoft 365 es el único origen de correo electrónico de contoso.com.

  Registro TXT de SPF para contoso.com en Microsoft 365 y Microsoft 365 Government Community Cloud (GCC):

  v=spf1 include:spf.protection.outlook.com -all
  

  Registro TXT de SPF para contoso.com en Microsoft 365 Government Community Cloud High (GCC High) y El Departamento de Defensa (DoD) de Microsoft 365:

  v=spf1 include:spf.protection.office365.us -all
  

  Registro TXT de SPF para contoso.com en Microsoft 365 operado por 21Vianet

  v=spf1 include:spf.protection.partner.outlook.cn -all
  

• Escenario: usa contoso.com para correo electrónico en Microsoft 365 y ya ha configurado el registro TXT de SPF en contoso.com con todos los orígenes de correo electrónico del dominio. También posee los dominios contoso.net y contoso.org, pero no los usa para el correo electrónico. Quiere especificar que nadie esté autorizado a enviar correo electrónico desde contoso.net o contoso.org.

  Registro TXT de SPF para contoso.net:

  v=spf1 -all
  

  Registro TXT de SPF para contoso.org:

  v=spf1 -all
  

• Escenario: se usa contoso.com para el correo electrónico en Microsoft 365. Tiene previsto enviar correo desde los siguientes orígenes:

  • Un servidor de correo electrónico local con la dirección de correo electrónico externa 192.168.0.10. Dado que tiene control directo sobre este origen de correo electrónico, consideramos correcto usar el servidor para los remitentes en el dominio contoso.com.
  • El servicio de correo masivo de Adatum. Dado que no tiene control directo sobre este origen de correo electrónico, se recomienda usar un subdominio para crear marketing.contoso.com con ese fin. Según la documentación del servicio Adatum, debe agregar include:servers.adatum.com al registro TXT de SPF para su dominio.

  Registro TXT de SPF para contoso.com:

  v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all
  

  Registro TXT de SPF para marketing.contoso.com:

  v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all
  

Solución de problemas de registros TXT de SPF

• Un registro SPF por dominio o subdominio: varios registros TXT de SPF para el mismo dominio o subdominio provocan un bucle de búsqueda DNS que produce un error en SPF, por lo que solo se usa un registro SPF por dominio o subdominio.

• Menos de 10 búsquedas DNS: cuando los sistemas de correo electrónico de destino consultan el registro TXT de SPF en busca de orígenes válidos para el dominio de dirección MAIL FROM, la consulta examina las direcciones IP y include: las instrucciones del registro hasta que el origen del mensaje (en última instancia, una dirección IP) coincide con uno de los orígenes especificados. Si el número de búsquedas DNS (que puede ser diferente del número de consultas DNS) es mayor que 10, el mensaje produce un error permanente (también conocido como permerror). El sistema de correo electrónico de destino rechaza el mensaje en un informe de no entrega (también conocido como NDR o mensaje de rebote) con uno de los errores siguientes:

  • El mensaje ha superado el recuento de saltos.
  • El mensaje ha necesitado demasiadas búsquedas.

  En el registro TXT de SPF, las direcciones IP individuales o los intervalos de direcciones IP no provocan búsquedas DNS. Cada include: instrucción requiere al menos una búsqueda DNS y es posible que se necesiten más búsquedas si el include: valor apunta a recursos anidados. En otras palabras, tener menos de 10 include: instrucciones no garantiza menos de 10 búsquedas DNS.

  Tenga en cuenta también: los sistemas de correo electrónico de destino evalúan los orígenes del registro TXT de SPF de izquierda a derecha. La evaluación se detiene cuando se valida el origen del mensaje y no se comprueban más orígenes. Por lo tanto, un registro TXT de SPF podría contener suficiente información para provocar más de 10 búsquedas DNS, pero la validación de algunos orígenes de correo por parte de algunos destinos no es lo suficientemente profunda en el registro como para dar lugar a un error.

  Además de conservar la reputación del dominio de correo electrónico principal, no superar el número de búsquedas DNS es otra razón para usar subdominios para otros servicios de correo electrónico que no controla.

Puede usar herramientas en línea gratuitas para ver el registro TXT de SPF y otros registros DNS de su dominio. Algunas herramientas incluso calculan el número de búsquedas de registros DNS que requiere el registro TXT de SPF.

Pasos siguientes

Como se describe en Cómo SPF, DKIM y DMARC funcionan juntos para autenticar a los remitentes de mensajes de correo electrónico, SPF por sí solo no es suficiente para evitar la suplantación de dominio de Microsoft 365. También debe configurar DKIM y DMARC para obtener la mejor protección posible. Para obtener instrucciones, consulte:

• Usar DKIM para validar el correo electrónico saliente enviado desde su dominio personalizado
• Usar DMARC para validar el correo electrónico

Para el correo que entra en Microsoft 365, es posible que también tenga que configurar selladores de ARC de confianza si usa servicios que modifican los mensajes en tránsito antes de la entrega a su organización. Para obtener más información, consulte Configuración de selladores arc de confianza.