Práctica recomendada para la autenticación de correo electrónico: formas óptimas de implementar SPF, DKIM y DMARC

Introducción

En esta guía se describen las tres tecnologías de autenticación de correo electrónico predominantes en uso actualmente: SPF, DKIM y DMARC, y se analizan diversos aspectos de su implementación. Se analizan varias situaciones de la arquitectura de correo electrónico real y se ofrecen directrices para implementarlas en el conjunto de productos de Cisco Email Security. Dado que se trata de una guía práctica de prácticas recomendadas, se omitirán algunos de los materiales más complejos. Cuando sea necesario, ciertos conceptos pueden simplificarse o condensarse para facilitar la comprensión de la materia presentada.

Requisitos de conocimiento del producto

Esta guía es un documento de nivel avanzado. Para continuar con el material presentado, el lector debe poseer conocimientos sobre el producto de Cisco Email Security Appliance hasta el nivel de certificación de ingeniero de campo de Cisco Email Security. Además, los lectores deben tener un fuerte dominio de DNS y SMTP y su funcionamiento. Conocer los conceptos básicos de SPF, DKIM y DMARC es una ventaja.

Autenticación de correo electrónico: breve descripción general

Marco de políticas de remitentes (SPF)

Sender Policy Framework se publicó por primera vez en 2006, como RFC4408. La versión actual se especifica en RFC7208 y se actualiza en RFC7372. Básicamente, proporciona una forma sencilla para que un propietario de dominio anuncie sus orígenes de correo electrónico legítimos a los receptores mediante DNS. Aunque SPF autentica principalmente la dirección de la ruta de acceso de retorno (MAIL FROM), la especificación recomienda (y proporciona un mecanismo) también autenticar el argumento HELO/EHLO SMTP (FQDN del gateway del remitente tal como se transmite durante la conversación SMTP).

SPF utiliza registros de recursos DNS de tipo TXT con una sintaxis bastante simple:

spirit.com text = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"

El registro anterior de Spirit Airlines permite que el correo electrónico de las direcciones @spirit.com provenga de una subred /24 determinada, dos máquinas identificadas por un FQDN y el entorno Office365 de Microsoft. El calificador "~all" al final indica a los receptores que consideren cualquier otra fuente como falla suave - uno de los dos modos de falla de SPF. Tenga en cuenta que los remitentes no especifican qué deben hacer los receptores con los mensajes que fallan, hasta qué punto fallarán.

Delta, por otro lado, emplea un esquema SPF diferente:

delta.com text = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

Para minimizar el número de consultas DNS requeridas, Delta creó un único registro "A" que enumera todas sus puertas de enlace SMTP. También proporcionan un registro SPF independiente para sus proveedores en "_spf.vendor.delta.com". También incluyen instrucciones para Fallar cualquier mensaje no autenticado por SPF (calificador "-all"). Podemos investigar más a fondo el registro SPF de los proveedores:

_spf.vendor.delta.com text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

Por lo tanto, los mensajes de correo electrónico de los remitentes @delta.com pueden proceder legítimamente, por ejemplo, de los gateways de correo electrónico de Air France.

United, por otro lado, utiliza un esquema SPF mucho más simple:

united.com text = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"

Aparte de sus propios gateways de correo electrónico corporativos, incluyen sus proveedores de email marketing ("usa.net" y "enviaremails.com.br"), gateways heredados de Continental Air Lines, así como todo lo que figura en sus registros MX ("mecanismo MX"). Tenga en cuenta que MX (una puerta de enlace de correo entrante para un dominio) puede no ser lo mismo que outgoing. Mientras que para las empresas más pequeñas normalmente serán las mismas, las organizaciones más grandes tendrán una infraestructura independiente que gestionará el correo entrante y la entrega saliente.

Además, vale la pena señalar que todos los ejemplos anteriores hacen un uso extensivo de referencias DNS adicionales ("incluir" mecanismos). Sin embargo, por motivos de rendimiento, la especificación SPF limita a diez el número total de búsquedas DNS necesarias para recuperar un registro final. Cualquier búsqueda de SPF con más de 10 niveles de recursión de DNS fallará.

Correo identificado por claves de dominio (DKIM)

DKIM, especificado en RFC 5585, 6376 y 5863 es una combinación de dos propuestas históricas: DomainKeys de Yahoo y Identity Internet Mail de Cisco. Proporciona una forma sencilla para que los remitentes firmen criptográficamente los mensajes salientes e incluyan las firmas (junto con otros metadatos de verificación) en un encabezado de correo electrónico ("firma DKIM"). Los remitentes publican su clave pública en el DNS, lo que facilita que los receptores recuperen la clave y comprueben las firmas. DKIM no autentica el origen de los mensajes físicos, pero se basa en el hecho de que si el origen está en posesión de la clave privada de la organización del remitente, está implícitamente autorizado a enviar un correo electrónico en su nombre.

Para implementar DKIM, la organización de envío generaría uno o más pares de claves públicas y publicaría las claves públicas en el DNS como registros TXT. Un "selector" haría referencia a cada par de claves para que los verificadores DKIM puedan diferenciar entre claves. Los mensajes salientes se firmarían y se insertaría el encabezado de firma DKIM:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt pBp acEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=

El formato de la firma es bastante sencillo. la etiqueta "a" especifica los algoritmos utilizados para la firma, "c" especifica los esquemas de canonización utilizados [1], "s" es el selector o la referencia de clave, "d" es el dominio de firma. El resto de este encabezado de firma DKIM es específico para cada mensaje: "h" muestra encabezados firmados, "i" muestra la identidad del usuario que firma y, por último, el encabezado termina con dos hash independientes: "bh" es un hash de encabezados firmados, mientras que "b" es el valor hash para el cuerpo del mensaje.

Al recibir un mensaje firmado por DKIM, el receptor buscará la clave pública creando la siguiente consulta DNS:

<selector>._domainkey.<dominio de firmas>

como se especifica en el encabezado DKIM-Signature. Para el ejemplo anterior, nuestra consulta sería "united._domainkey.news.united.com":

united._domainkey.news.united.com text = "g=*\; k=rsa\; n=" "Contacto" "postmaster@responsys.com" "con" "cualquier" "pregunta" "sobre" "esta" "firma" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35h4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz Kc3UB2IBwIDAQAB\;"

El registro DNS devuelto contiene la clave, así como otros parámetros opcionales. [2]

El principal problema con DKIM es que la especificación inicial no permitía la publicidad de que un remitente utiliza DKIM. Por lo tanto, si un mensaje llega sin una firma, no hay una manera fácil para que un receptor sepa que debería haber sido firmado y que, en ese caso, lo más probable es que no sea auténtico. Dado que una sola organización puede (y lo hará con más frecuencia) utilizar varios selectores, no es trivial "adivinar" si un dominio está habilitado para DKIM. Se desarrolló una norma separada, Prácticas de firma de dominio de autor, para cubrir esto, pero debido al bajo uso y otros problemas se quedó obsoleta en 2013 sin sucesor.

Autenticación de mensajes basada en dominio, informes y conformidad (DMARC)

DMARC es la más joven de las tres tecnologías de autenticación de correo electrónico incluidas y se desarrolló específicamente para abordar las deficiencias tanto de SPF como de DKIM. A diferencia de los otros dos, autentica el encabezado de un mensaje y enlaza con las comprobaciones realizadas anteriormente por los otros dos. DMARC se especifica en RFC7489.

El valor añadido de DMARC sobre SPF y DKIM incluye:

• Asegurarse de que todas las identidades disponibles (HELO, MAIL FROM y/o dominio de firmas DKIM) estén alineadas (coincidan exactamente o estén subordinadas) con el encabezado From
• Proporcionando un medio para que el propietario del dominio del remitente especifique una política para los receptores sobre cómo deben manejar los mensajes fallidos
• Proporcionar un servicio de comentarios para que los propietarios de dominios de remitentes estén informados de cualquier mensaje erróneo, lo que facilita la identificación de campañas de suplantación de identidad o errores en la asignación de políticas SPF/DKIM/DMARC.

DMARC también utiliza un sencillo mecanismo de distribución de políticas basado en DNS:

_dmarc.aa.com text = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 La única etiqueta obligatoria en la especificación de la política de DMARC es "p", que especifica la política que se debe utilizar en los mensajes con fallos. Puede ser una de las tres: ninguna, cuarentena, rechazar.

La mayoría de los parámetros opcionales utilizados tienen que ver con la generación de informes: "rua" especifica una URL (ya sea un mailto: o una URL http:// usando el método POST) para enviar informes agregados diarios sobre todos los mensajes que fallan y que supuestamente provienen de un dominio determinado. "ruf" especifica una URL para enviar informes de fallos detallados e inmediatos en cada mensaje de fallo.

Según la especificación, un receptor debe cumplir con la política anunciada. Si no lo hacen, deben notificar al propietario del dominio del remitente en el informe agregado.

El concepto central de DMARC es la denominada alineación de identificadores. La alineación de identificadores define cómo un mensaje puede pasar la verificación de DMARC. Los identificadores SPF y DKIM se alinean por separado, y un mensaje debe pasar cualquiera de ellos para pasar el DMARC en general. Sin embargo, existe una opción de política de DMARC en la que el remitente puede solicitar que se genere un informe de fallos incluso si se supera una alineación, pero la otra falla. Podemos ver esto en el ejemplo anterior con la etiqueta "fo" configurada en "1".

Hay dos formas de que los mensajes se adhieran a la alineación de identificadores DKIM o SPF: estricta y relajada. La adhesión estricta significa que el FQDN del encabezado de debe coincidir completamente con el ID de dominio de firmas ("etiqueta") de la firma DKIM o el FQDN del comando MAIL FROM SMTP para SPF. Relajado, por otro lado, permite Encabezado De FQDN para ser un subdominio de los dos antes mencionados.  Esto tiene importantes implicaciones a la hora de delegar el tráfico de correo electrónico a terceros, que se tratarán más adelante en el documento.

Consideraciones de implementación de SPF

SPF para receptores

La verificación SPF es trivial de configurar en los dispositivos virtuales Cisco Email Security Appliance o Cloud Email Security. En el resto de este documento, cualquier referencia al SEC incluirá también el CES.

La verificación SPF se configura en Políticas de flujo de correo: la forma más sencilla de ejecutarla globalmente es activarla en la sección Parámetros de política predeterminados del receptor o receptores adecuados. Si está utilizando el mismo receptor para la recopilación de correo entrante y saliente, asegúrese de que su política de flujo de correo "RELAYED" tenga la verificación SPF establecida en "Off".

Dado que SPF no permite especificar la acción de la política que se debe tomar, la verificación SPF (así como DKIM, como veremos más adelante) solo verifica el mensaje e inserta un conjunto de encabezados para cada verificación SPF realizada:

Received-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: dominio de

  united.5765@envfrm.rsys2.com designa 12.130.136.195 como

  allowed sender) identity=mailfrom;

  client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible; x-record-type="v=spf1"

Received-SPF: None (Recibido-SPF: Ninguno) (mx1.hc4-93.c3s2.smtpi.com: no sender

  información de autenticidad disponible en el dominio de

  postmaster@omp.news.united.com) identity=helo;

  client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-conformance=sidf_compatible

Tenga en cuenta que para este mensaje, SPF verificó dos "identidades": "mailfrom" según lo estipulado en la especificación, y "helo" según lo recomendado por la misma. El mensaje pasará formalmente SPF, ya que solo el primero es relevante para el cumplimiento de SPF, pero algunos receptores pueden sancionar a los remitentes que no incluyen registros SPF para sus identidades HELO también. Por lo tanto, se recomienda incluir los nombres de host de los gateways de correo saliente en los registros SPF.

Una vez que las políticas de flujo de correo verifican un mensaje, son los administradores locales los que deben configurar la acción que se debe llevar a cabo. Esto se realiza mediante la regla de filtro de mensajes SPF-status() [3], o mediante la creación de un filtro de contenido entrante utilizando el mismo y aplicándolo a las políticas de correo entrante apropiadas.

Imagen 1: Condición de filtro de contenido de verificación SPF

Las acciones de filtrado recomendadas son eliminar los mensajes que fallan ("-all" en el registro SPF) y poner en cuarentena los mensajes que fallan en modo suave ("~all" en el registro SPF) en una cuarentena de políticas; sin embargo, esto puede variar según sus requisitos de seguridad. Algunos receptores solo etiquetan los mensajes que fallan o no realizan ninguna acción visible, pero informan a los administradores.

Recientemente ha habido un aumento significativo en la popularidad de SPF, pero muchos dominios publican registros SPF incompletos o incorrectos. Para estar seguro, puede poner en cuarentena todos los mensajes SPF que no funcionen y supervisar la cuarentena durante un tiempo para asegurarse de que no haya "falsos positivos".

Si Proporciona Servicios De Correo Electrónico Para Otros Dominios O Terceros

Si proporciona servicios de envío o alojamiento de correo electrónico a terceros, estos tendrán que agregar los nombres de host y las direcciones IP que utilice para enviar sus mensajes a sus propios registros SPF. La forma más sencilla de hacerlo es que el proveedor cree un registro SPF "general" y haga que los clientes utilicen el mecanismo "incluir" en sus registros SPF.

suncountry.com text = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:10 7.20.247.57 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exacttarget.com ~all"

Como podemos ver, Sun Country tiene algunos de sus correos electrónicos bajo su propio control, pero su correo electrónico de marketing se subcontrata a un tercero. La ampliación del registro mencionado revela una lista de direcciones IP actuales utilizadas por su proveedor de servicios de correo de marketing:

cust-spf.exacttarget.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20:13.111.0.0/18 -todo"

Esta flexibilidad permite a los proveedores de servicios de correo electrónico ampliar sin tener que ponerse en contacto con cada cliente para modificar sus registros DNS.

Si utiliza servicios de correo electrónico de terceros

Al igual que en el párrafo anterior, si utiliza servicios de correo electrónico de terceros y desea establecer un flujo de correo totalmente verificado por SPF, debe incluir sus propios registros SPF en el suyo.

jetblue.com texto descriptivo "v=spf1 include:_spf.qualtrics.com ?all"

JetBlue utiliza el servicio de análisis Qualtrics y lo único que deben hacer es incluir un registro SPF correcto de Qualtrics. Del mismo modo, la mayoría de los otros ESP proporcionan registros SPF para que se incluyan en los registros de sus clientes.

Si su ESP o email marketer no proporciona registros SPF, tendrá que enumerar sus gateways de correo saliente directamente en el suyo. Sin embargo, es su responsabilidad mantener esos registros exactos, y si el proveedor agrega gateways adicionales o cambia direcciones IP o nombres de host, su flujo de correo puede estar en peligro.

El peligro adicional de terceros que no son conscientes de SPF proviene del uso compartido de recursos: si un ESP utiliza la misma dirección IP para entregar correo electrónico de varios clientes, es técnicamente posible que un cliente genere un mensaje SPF válido fingiendo ser otro cliente que entrega a través de la misma interfaz. Por este motivo, antes de establecer restricciones SPF, debe investigar las políticas de seguridad de su MSP y el conocimiento de la autenticación de correo electrónico. Si no tienen respuestas a sus preguntas, teniendo en cuenta que SPF es uno de los mecanismos básicos de confianza en Internet, se recomienda encarecidamente que reconsidere su elección de MSP. No se trata solo de seguridad: SPF, DKIM, DMARC y otras prácticas recomendadas de los remitentes [4] empleadas por los MSP son una garantía de entrega. Si su MSP no los sigue o los sigue incorrectamente, eso reducirá su confiabilidad con sistemas de recepción grandes y posiblemente retrase o incluso bloquee sus mensajes.

(Sub)Dominios sin tráfico de correo electrónico

La mayoría de las organizaciones actuales poseen varios dominios con fines de marketing, pero solo utilizan uno de forma activa para el tráfico de correo electrónico corporativo. Incluso si SPF se implementa correctamente en el dominio de producción, los atacantes pueden seguir utilizando otros dominios que no se utilizan activamente para un correo electrónico para falsificar la identidad de una organización. SPF puede evitar que esto ocurra a través de un registro SPF especial de "negar todo": para cualquiera de sus dominios (y subdominios) que no generen tráfico de correo electrónico, publique "v=spf1 -all" en el DNS. Un excelente ejemplo es openspf.org - el sitio web del Consejo del FPS.

Dado que la delegación SPF es válida solo para un único dominio, es fundamental publicar también los registros SPF "denegar todos" para cualquier subdominio que esté utilizando y que no genere un correo electrónico. Incluso si su dominio de producción tiene un registro SPF "regular", haga un esfuerzo adicional para agregar registros "deny all" a sus subdominios sin tráfico. Y, de nuevo, no olvide que recibir no equivale a enviar: es muy posible que un dominio esté recibiendo correo electrónico, pero nunca será una fuente. Esto es muy cierto en el caso de los dominios de marketing a corto plazo (por ejemplo, eventos, promociones por tiempo limitado, lanzamientos de productos, etc.), en los que los correos electrónicos entrantes de esos dominios se enviarían a su dominio de producción, y cualquier respuesta a esos correos electrónicos se enviaría desde el dominio de producción. Estos dominios a corto plazo tendrán un registro MX válido, pero también deben tener un registro SPF que los identifique como ningún origen de correo electrónico.

Consideraciones sobre la implementación de DKIM

DKIM para receptores

La configuración de la verificación DKIM en el ESA es similar a la verificación SPF. En Parámetros de política predeterminados de las políticas de flujo de correo, simplemente active la verificación DKIM. Una vez más, dado que DKIM no permite ninguna especificación de política, esto sólo verificará la firma e insertará un encabezado "Authentication-Results":

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (firma verificada) header.i=MileagePlus@news.united.com

Los filtros de contenido deben realizar todas las acciones basadas en los resultados de la verificación DKIM:

Imagen 2: condición de filtro de contenido de verificación DKIM

A diferencia de SPF, que es sencillo, DKIM manipula el texto real del mensaje, por lo que algunos parámetros pueden estar limitados. Opcionalmente, puede crear perfiles de verificación DKIM y asignar diferentes perfiles de verificación a diferentes políticas de flujo de correo. Permiten limitar los tamaños de clave de las firmas que se aceptarán, establecer acciones de error de recuperación de claves y configurar la profundidad de la verificación DKIM.

A medida que un mensaje pasa por varias puertas de enlace, se puede firmar varias veces y, por lo tanto, llevar varias firmas. Para que un mensaje pase la verificación DKIM, cualquier firma debe verificarse. De forma predeterminada, el ESA verificará hasta cinco firmas.

Debido a la apertura histórica de SMTP y correo electrónico y a la renuencia de Internet en general a adaptarse a los cambios (positivos), todavía hay varias situaciones en las que las firmas DKIM pueden fallar legítimamente, como cuando los administradores de listas de correo retransmiten directamente pero modifican mensajes, o cuando los mensajes se reenvían directamente en lugar de como adjuntos a mensajes nuevos. Esta es la razón por la que, en general, la práctica recomendada para los mensajes que no superan DKIM sería ponerlos en cuarentena o etiquetarlos, en lugar de descartarlos.

Preparación para firmar con DKIM

Antes de poder activar la firma DKIM en la política de flujo de correo RELAYED, debe generar/importar las claves, crear perfiles de firma DKIM y publicar las claves públicas en el DNS.

Si está firmando para un único dominio, el proceso es sencillo. Genere el par de claves, cree su perfil de firma único en la sección Claves de dominio de Políticas de correo y haga clic en la opción "Generar" en "Registro de texto DNS" una vez que su perfil esté listo. Publique la clave tal y como se genera en el DNS. Por último, active la firma DKIM en la política de flujo de correo.

Se complica aún más si firma para varios dominios distintos. En ese caso, tiene dos opciones:

1. Utilice un único perfil de firma para firmar todos los dominios. Almacenará la clave pública (única) en la zona DNS del dominio "principal" y las firmas DKIM harán referencia a dicha clave. Esta técnica la utilizaban a menudo los ESP en el pasado: les permitía firmar a gran escala, sin tener que interactuar con el espacio DNS de los clientes individuales [5].
2. Cree un perfil de firma independiente para cada dominio que firme. Esto hace que la configuración inicial sea más compleja, pero proporciona mucha más flexibilidad en el futuro. Cree un par de claves para cada dominio, cree un perfil que especifique sólo un dominio (y sus subdominios) en la sección "Profile Users" (Usuarios del perfil) y publique la clave pública pertinente en la zona DNS de ese dominio concreto.

Aunque la opción #1 es más fácil de utilizar, recuerde que, en última instancia, supondrá una interrupción de DMARC. Dado que DMARC requiere que la ID de dominio de firma se alinee con el encabezado De, la alineación de su identificador con DKIM fallará. Puede salirse con la suya si configura su SPF correctamente y confía en la alineación del identificador SPF para pasar la verificación de DMARC.

Sin embargo, al implementar la opción #2 desde el principio, no tendrá que preocuparse por DMARC y es bastante fácil revocar o reconfigurar el servicio de firmas para un solo dominio.  Además, si proporciona algunos servicios de correo electrónico para un dominio de terceros, lo más probable es que necesite obtener la clave para utilizarla de ellos (e importarla a su ESA). Esa clave será específica del dominio, por lo que tendrá que crear un perfil independiente.

Si utiliza servicios de correo electrónico de terceros

En general, si utiliza la firma DKIM y descarga parte del procesamiento de correo electrónico (por ejemplo, mensajes de correo electrónico de marketing) a un tercero, no desea que utilice las mismas claves que utiliza en producción. Esta es una de las principales razones de la existencia de selectores en DKIM. En su lugar, debe generar un nuevo par de claves, publicar la parte pública en la zona DNS y entregar la clave secreta a la otra parte. Esto también le permitirá revocar rápidamente esa clave en particular en caso de problemas mientras mantiene su infraestructura DKIM de producción intacta.

Aunque no es necesario para DKIM (los mensajes para el mismo dominio se pueden firmar con varias claves diferentes), es una buena práctica proporcionar un subdominio independiente para cualquier correo electrónico que sea manejado por un tercero. Facilitará el seguimiento de los mensajes y permitirá una implementación mucho más limpia de DMARC más adelante. Como ejemplo, considere estos cinco encabezados DKIM-Signature de varios mensajes de Lufthansa:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;  

Vemos que Lufthansa utiliza cinco claves diferentes (selectores) divididas en cinco subdominios separados de dos dominios de producción primarios (lufthansa.com y milesandmore.com). Esto significa que cada uno de ellos se puede controlar de forma independiente y se puede externalizar a un proveedor de servicios de mensajería diferente.

Consideraciones sobre la implementación de DMARC

DMARC para receptores

La verificación de DMARC en el ESA se basa en perfiles, pero a diferencia de DKIM, el perfil predeterminado se debe editar para cumplir con la especificación. El comportamiento predeterminado del ESA es no descartar nunca ningún mensaje a menos que el cliente lo indique explícitamente, por lo que el perfil de verificación de DMARC predeterminado establecerá todas las acciones en "Sin acción". Además, para habilitar la generación correcta de informes, tendrá que editar "Configuración global" de la sección DMARC de "Políticas de correo".

Una vez que se ha configurado un perfil, la verificación de DMARC, al igual que las otras dos, se establece en la sección Configuración de política predeterminada de Políticas de flujo de correo. Asegúrese de marcar la casilla para enviar informes de comentarios agregados. Esta es posiblemente la función más importante de DMARC para el remitente. En el momento de redactar el presente documento, el ESA no admite la generación de informes de fallos por mensaje (etiqueta "ruf" de la política de DMARC).

Dado que el remitente aconseja las acciones de la política de DMARC, a diferencia de SPF o DKIM, no hay acciones específicas configurables fuera de la configuración del perfil. No es necesario crear ningún filtro de contenido.

La verificación de DMARC agregará campos adicionales al encabezado Authentication-Results:

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (firma verificada) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

En el ejemplo anterior, vemos que DMARC se verificó en función de la alineación del identificador DKIM y que el remitente solicitó la política de "ninguno". Esto indica que se encuentran actualmente en la fase de supervisión de la implementación de DMARC.

Si Proporciona Servicios De Correo Electrónico Para Otros Dominios O Terceros

La principal preocupación de los ESP con respecto al cumplimiento de DMARC es lograr una alineación de identificadores adecuada. Cuando planifique DMARC, asegúrese de que su SPF esté configurado correctamente, de que todos los demás dominios relevantes tengan sus gateways salientes en sus registros SPF y de que no envíen mensajes que no superen la alineación, principalmente mediante el uso de diferentes dominios para la identidad MAIL FROM y Header From. Este error lo suelen cometer las aplicaciones que envían notificaciones o advertencias por correo electrónico, ya que los autores de las aplicaciones desconocen las consecuencias de la incoherencia de sus identidades de correo electrónico.

Como se ha descrito anteriormente, asegúrese de que utiliza un perfil de firma DKIM independiente para cada dominio y de que el perfil de firma hace referencia correctamente al dominio para el que está firmando como se utiliza en Encabezado desde. Si utiliza sus propios subdominios, puede firmar con una sola clave, pero asegúrese de que ha establecido la conformidad con DKIM de forma relajada en la política de DMARC ("adkim="r").

En general, si proporciona servicios de correo electrónico a un mayor número de terceros sobre los que no tiene control directo, es una buena práctica escribir un documento de directrices sobre cómo enviar un correo electrónico que es más probable que se envíe. Dado que el correo electrónico de usuario a usuario suele comportarse correctamente, en la mayoría de los casos servirá como documento de políticas para los autores de aplicaciones en los ejemplos mencionados anteriormente.

Si utiliza servicios de correo electrónico de terceros

Si utiliza terceros para distribuir parte del tráfico de correo electrónico, la forma óptima es delegar un subdominio independiente (o un dominio completamente diferente) en el proveedor de terceros. De esta manera, pueden administrar los registros SPF según sea necesario, tener una infraestructura de firmas DKIM independiente y no interferir con el tráfico de producción. Por lo tanto, la política de DMARC para el correo electrónico subcontratado puede ser diferente a la de la organización interna. Como ya se ha mencionado, al considerar el correo electrónico entregado por terceros, asegúrese siempre de que sus identificadores se alinean y de que su adhesión a DKIM y SPF se establece de forma adecuada en su política de DMARC.

(Sub)Dominios sin tráfico de correo electrónico

Otra mejora de DMARC con respecto a las tecnologías de autenticación de correo electrónico anteriores es la forma en que gestiona los subdominios. De forma predeterminada, la política DMARC de un dominio concreto se aplica a todos sus subdominios. Al recuperar los registros de políticas de DMARC, si no se encuentra ningún registro en el nivel de encabezado de FQDN, los receptores están obligados a determinar el dominio organizativo [6] del remitente y buscar un registro de políticas en él.

Sin embargo, la política de DMARC para un dominio de organización también puede especificar una política de subdominio independiente (etiqueta "sp" de un registro de DMARC) que se aplicará a todos los subdominios que no tengan publicada una política de DMARC explícita.

En la situación descrita anteriormente en el capítulo SPF, debería:

1. Publique un registro de DMARC explícito para cualquier subdominio que sea fuente legítima de correo electrónico.
2. Publique una política de subdominio de "rechazo" en su registro de política de dominio organizativo para rechazar automáticamente cualquier correo electrónico que falsifique dominios que no envían

Este tipo de estructuración de su autenticación de correo electrónico proporciona la mejor protección posible de su infraestructura y marca.

Problemas específicos de DMARC

Existen varios problemas potenciales con DMARC, todos ellos derivados de la naturaleza y las deficiencias de otras tecnologías de autenticación de las que depende. El problema es que DMARC sacó a la luz estos problemas al aplicar de forma activa una política de rechazo del correo electrónico y correlacionar todos los diferentes identificadores de remitentes de un mensaje.

La mayoría de los problemas ocurren con las listas de correo y el software de administración de listas de correo. Cuando un correo electrónico se envía a una lista de correo, se redistribuye a todos sus destinatarios. Sin embargo, el correo electrónico resultante, con una dirección de remitente del remitente original, será entregado por la infraestructura de alojamiento del administrador de la lista de correo, fallando así las comprobaciones SPF para el encabezado de (la mayoría de los administradores de la lista de correo utilizan la dirección de la lista como remitente del sobre (MAIL FROM) y la dirección del remitente original como remitente del encabezado de).

Dado que DMARC fallará para SPF, es posible que confiemos en DKIM; sin embargo, la mayoría de los administradores de listas de correo también añaden pies de página a los mensajes o etiquetan los asuntos con el nombre de la lista, lo que interrumpe la verificación de la firma DKIM.

Los autores de DKIM sugieren varias soluciones al problema, todas las cuales se reducen a que los administradores de listas de correo tienen que usar la dirección de la lista en todas las direcciones de origen, e indicar la dirección del remitente original por otro medio.

Problemas similares surgen de los mensajes que se reenvían simplemente copiando el mensaje original a través de SMTP al nuevo destinatario. Sin embargo, la mayoría de los agentes de usuario de correo que se utilizan hoy formarán correctamente un nuevo mensaje e incluirán el mensaje reenviado en línea o como datos adjuntos al nuevo. Los mensajes reenviados de esta forma pasarán el DMARC si el usuario que los reenvía pasa (por supuesto, no se puede establecer la autenticidad del mensaje original).

Ejemplo De Plan De Acción Para Implementar La Autenticación De Correo Electrónico

Aunque las tecnologías en sí son sencillas, el camino para implementar una infraestructura de autenticación de correo electrónico completa puede ser largo y sinuoso. Para las organizaciones más pequeñas y aquellas con flujos de correo controlados, será bastante sencillo, mientras que para los entornos más grandes puede resultar un reto excepcional. No es raro que las grandes empresas contraten servicios de consultoría para gestionar el proyecto de implementación.,

Paso 1: DKIM

DKIM es relativamente poco intrusivo, ya que los mensajes sin firmar no se rechazarán. Antes de la implementación real, tenga en cuenta todos los puntos mencionados anteriormente. Póngase en contacto con cualquier tercero al que pueda delegar la firma, asegúrese de que sus terceros admitan la firma DKIM y considere su estrategia de gestión de selectores. Algunas organizaciones mantendrían claves (selectores) separadas para las distintas unidades organizativas. Puede considerar la rotación periódica de claves para mayor seguridad, pero asegúrese de que no elimina las claves antiguas hasta que se entreguen todos los mensajes en tránsito.

Debe prestarse especial atención a los tamaños clave. Aunque en general "más es mejor", debe tener en cuenta que la creación de dos firmas digitales por mensaje (incluida la canonización, etc.) es una tarea muy costosa para la CPU y puede influir en el rendimiento de los gateways de correo saliente. Debido a la sobrecarga informática, 2048 bits es el tamaño de clave práctica más grande que se puede utilizar, pero para la mayoría de las implementaciones, las claves de 1024 bits suponen un buen riesgo entre rendimiento y seguridad.

Para el éxito de la implementación posterior de DMARC, debe:

1. identifique todos los dominios que envíe como, incluidos los subdominios
2. generar claves DKIM y crear perfiles de firma para cada dominio
3. proporcionar claves privadas relevantes a terceros
4. publicar todas las claves públicas en las zonas DNS relevantes
5. verificar que los terceros estén listos para comenzar la firma
6. active la firma DKIM en la política de flujo de correo TRANSMITIDO en todos los ESA
7. notificar a terceros para que comiencen a firmar

Paso 2: SPF

La implementación correcta de SPF probablemente sea la parte más engorrosa y lenta de cualquier implementación de infraestructura de autenticación de correo electrónico. Como el correo electrónico era muy fácil de usar y gestionar, y estaba completamente abierto desde el punto de vista de la seguridad y el acceso, las organizaciones no aplicaban tradicionalmente políticas estrictas sobre quién y cómo podía utilizarlo. Esto ha dado lugar a que la mayoría de las organizaciones actuales no tengan una visión completa de las diferentes fuentes de correo electrónico, tanto internas como externas. El mayor problema de la implementación de SPF es descubrir quién está enviando correos electrónicos legítimamente en su nombre.

Aspectos a buscar:

1. objetivos obvios: servidores Exchange u otros groupware o gateways de correo saliente
2. cualquier solución de DLP u otro sistema de procesamiento de correo electrónico que pueda generar notificaciones externas
3. Sistemas CRM que envían información interactuando con los clientes
4. varias aplicaciones de terceros que pueden enviar correo electrónico
5. laboratorio, servidores de prueba u otros servidores que puedan enviar correo electrónico
6. ordenadores personales y dispositivos configurados para enviar un correo electrónico externo directamente

La lista anterior no está completa, ya que las organizaciones tienen entornos diferentes, pero debe considerarse como una directriz general sobre lo que hay que buscar. Una vez que se hayan identificado (la mayoría) los orígenes de correo electrónico, puede que desee dar un paso atrás y, en lugar de autorizar todos los orígenes existentes, limpiar la lista. Idealmente, todos sus correos electrónicos salientes deberían entregarse a través de sus gateways de correo saliente con algunas excepciones justificadas. Si dispone de su propia solución de correo electrónico de marketing o la utiliza de terceros, debe utilizar una infraestructura distinta a los gateways de correo electrónico de producción. Si su red de entrega de correo es excepcionalmente complicada, puede continuar documentando el estado actual en su SPF, pero tome tiempo para limpiar la situación en el futuro.

Si sirve a varios dominios en la misma infraestructura, es posible que desee crear un único registro SPF universal y hacer referencia a él en dominios individuales mediante el mecanismo de "inclusión". Asegúrese de que sus registros SPF no sean demasiado amplios; por ejemplo, si sólo cinco máquinas en una red /24 envían SMTP, agregue esas cinco direcciones IP individuales a su SPF, en lugar de a toda la red. Intente que sus registros sean lo más específicos posible para minimizar las posibilidades de que un correo electrónico malintencionado ponga en peligro su identidad.

Comience con una opción softfail para remitentes que no coincidan ("~all"). Solo tiene que cambiarlo a hardfail (-all) una vez que esté 100% seguro de que ha identificado todas las fuentes de correo electrónico, de lo contrario se arriesga a perder el correo electrónico de producción. Más adelante, tras implementar DMARC y ejecutarlo en modo de supervisión durante un tiempo, podrá identificar los sistemas que haya perdido y actualizar los registros SPF para que estén completos. Solo entonces será seguro establecer su SPF a hardfail.

Paso 3: DMARC

Una vez que haya configurado el DKIM y el SPF lo más completo posible, es el momento de crear las políticas de DMARC. Tenga en cuenta todas las situaciones mencionadas en los capítulos anteriores y prepárese para implementar más de un registro de DMARC si dispone de una infraestructura de correo electrónico compleja.

Cree alias de correo electrónico que recibirán informes o una aplicación Web que pueda invertirlos. No hay direcciones de correo electrónico definidas estrictamente para este fin, pero ayuda si son descriptivas, por ejemplo: rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com, etc. Asegúrese de que dispone de un proceso para que un operador supervise estas direcciones y modifique la configuración de SPF, DKIM y DMARC de forma adecuada, o avise al equipo de seguridad en caso de que se produzca una campaña de suplantación. Inicialmente, la carga de trabajo será considerable a medida que se ajusten los registros para cubrir cualquier cosa que se haya perdido durante la configuración SPF y DKIM. Después de un tiempo, los informes probablemente indicarán solo intentos de simulación.

Inicialmente, establezca la política de DMARC en "ninguno" y la opción de diagnóstico para enviar informes de cualquier comprobación que falle ("fo=1"); esto detectará rápidamente cualquier error en su SPF y DKIM sin influir en el tráfico. Una vez que esté satisfecho con el contenido de los informes enviados, cambie la directiva a "cuarentena" o "rechazar", en función de su directiva de seguridad y sus preferencias. De nuevo, asegúrese de que los operadores analizan continuamente los informes de DMARC recibidos para detectar posibles falsos positivos.

Implementar DMARC de forma completa y correcta no es una tarea pequeña ni corta. Si bien se pueden obtener algunos resultados (y la "implementación" formal de DMARC) mediante la publicación de un conjunto incompleto de registros y una política de "ninguno", es en el mejor interés de la organización remitente y de Internet en su conjunto que todos lo implementen en la medida de sus capacidades.

Con respecto a los plazos, aquí hay un esquema muy general de los pasos individuales para un proyecto típico. Una vez más, dado que cada organización es diferente, estos aspectos distan mucho de ser exactos:

1. Planificación y preparación de DKIM	2-4 semanas
2. Ejecuciones de prueba DKIM	2 semanas
3. SPF - identificación de remitente legítimo	2-4 semanas
4. Preparación de la política DMARC	2 semanas
5. Prueba de registros SPF y DMARC	4-8 semanas
6. Prueba SPF ejecutada con hardfail	2 semanas
7. Ejecución de pruebas de DMARC con cuarentena/rechazo	4 semanas
8. Supervisión de los informes de DMARC y adaptación de SPF/DKIM en consecuencia	continuo

Es probable que las organizaciones más pequeñas experimenten una duración más corta de la mayoría de los pasos, especialmente los pasos 3 y 4. Independientemente de lo sencilla que pueda ser su infraestructura de correo electrónico, asigne siempre un tiempo suficiente durante las ejecuciones de prueba y supervise de cerca los informes de comentarios en busca de cualquier cosa que pueda haber pasado por alto.

Las organizaciones más grandes podrían experimentar una duración aún mayor de los mismos pasos, con requisitos de prueba más estrictos. No es raro que las empresas con una infraestructura de correo electrónico compleja contraten ayuda externa, no solo para el aspecto técnico de la implementación de la autenticación de correo electrónico, sino también para gestionar todo el proyecto y coordinar a través de equipos y departamentos.

Referencias adicionales

• El sitio de referencia de SPF: http://www.openspf.org
• El Consejo DKIM: http://www.dkim.org
• Sitio web principal de DMARC, gestionado por The Trusted Domain Project: http://www.dmarc.org
• dmarcian: sitio de ayuda y recursos dirigido por Tim Draegen, uno de los autores de DMARC. No olvide visitar la sección "Herramientas": http://www.dmarcian.com
• Herramienta de validación de registros de Online Trust Alliance: https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant: otra herramienta útil para crear registros de DMARC: http://www.kitterman.com/dmarc/assistant.html
• Herramientas de prueba de registro SPF: http://www.kitterman.com/spf/validate.html
• "Don’t Be A Phish: Deep Dive Into Email Authentication Techniques", una presentación de Cisco Live 2014 BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] La canonización está fuera del alcance de este documento. Consulte el material de la sección "Referencias adicionales" para obtener más información sobre la canonización DKIM.

[2] Los parámetros de registro DNS DKIM también están fuera del alcance de este documento.

[3] La creación de filtros de mensajes está fuera del alcance de este documento. Consulte las guías del usuario de AsyncOS para correos electrónicos para obtener ayuda.

[4] M3AAWG definió un excelente conjunto de mejores prácticas aplicadas y honradas por la mayor parte de la industria. Su documento de Mejores Prácticas Comunes para Remitentes está disponible en https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] Este comportamiento aprovecha el hecho de que, originalmente, DKIM no verifica el origen del mensaje como se indica en MAIL FROM o Header From en absoluto. Solo verifica que el parámetro Signing Domain ID ("d" de DKIM Signature, y el parámetro "Domain Name" de su Signing Profile) esté realmente alojando la clave pública del par utilizado para firmar el mensaje. La autenticidad del remitente está implícita al tener el encabezado "De" firmado. Solo asegúrese de que enumera todos y cada uno de los dominios (y subdominios) que firma en la sección "Perfil de usuarios".

[6] Normalmente, un dominio un nivel por debajo del TLD o del prefijo ccTLD relevante (.ac.uk, .com.sg, etc...)