Serie de emails Misfit: mi email no es lo suficientemente auténtico

En mi último artículo, hablé sobre los conceptos básicos y el contexto de los distintos protocolos de autenticación disponibles para que los remitentes demuestren a los destinatarios que sus emails son auténticos para sus marcas.  Hace poco me hicieron una pregunta: “¿Y si mi email no es lo suficientemente auténtico?”. Hoy repasaré los posibles problemas y soluciones de una autenticación de emails incorrecta, así que busca una silla y acomódate.

Los protocolos de autenticación de emails son cuestiones técnicas.  Al igual que con todo lo técnico, si no se implementan adecuadamente, puede haber y habrá consecuencias.  Algunas serán un inconveniente menor, pero otras pueden resultar bastante catastróficas. En este blog, me gustaría destacar algunos de los casos más notables en los que nuestros clientes no configuran bien la autenticación de emails y qué hacer al respecto.

Dado que Mailgun a menudo puede actuar como fuente secundaria de emails salientes de un dominio, vemos que a nuestros clientes les cuesta implementar correctamente los registros SPF para todas sus plataformas de envío.  Un problema común que observamos es que un cliente añade un registro TXT secundario para su SPF de Mailgun, mientras que el SPF principal permanece intacto. Un ejemplo ayudará a ilustrarlo. A partir de ahora usaré nuestro dominio falso favorito, meowgun.com.  Tomaremos como referencia:

dig txt meowgun.com

; <> DiG 9.10.6 <> txt meowgun.com

;; ANSWER SECTION:

meowgun.com.   869    IN TXT    "v=spf1 include:mailgun.org ~all"

meowgun.com.   869    IN TXT    "v=spf1 ipv4:127.0.0.1 ~all

Aquí vemos que se devuelven ambos registros SPF. El problema que esto presenta para los servidores del destinatario es que, dependiendo del registro que se devuelva primero, el destinatario podría aplicar el registro IPv4 o el registro include:mailgun.org. Si no quieres probar suerte, hay una forma mejor.

La solución aquí es bastante sencilla: combina los registros en una sola entrada TXT de SPF ordenada que utilice la sintaxis correcta. La sintaxis del SPF es bastante flexible y permite incluir muchas fuentes de emails en un registro TXT pequeño, siempre y cuando hayas hecho los deberes.  Así es como recomendamos integrar los registros en el caso anterior:

"v=spf1 ipv4:127.0.0.1 include:mailgun.org ~all"

Ahora tenemos un único registro SPF ordenado que cubre todas nuestras fuentes de emails.

Las especificaciones del SPF limitan la cantidad de búsquedas DNS que se pueden realizar en nombre de un registro SPF a 10.  Estos son todos los mecanismos de SPF que actuarán como disparador de una búsqueda DNS:

• Un
• Exists
• Include
• MX
• PTR

Para algunos remitentes con una fuente abundante de flujos de emails para su dominio, sus registros SPF no tardan mucho en volverse inmanejables y acabar implementando un registro por encima del límite permitido.

En lo que respecta a este problema, no existe una solución única para todo el mundo, sino que dependerá realmente de las fuentes de emails de un remitente.  Dicho esto, hay algunas recomendaciones generales que podemos darte para servirte de guía:

• Averigua cuántas búsquedas se utilizan en tu mecanismo include. Los include se pueden anidar y provocar más de 1 búsqueda.  El registro SPF de Mailgun pertenece a esta categoría y requiere 3 búsquedas en total debido a los include anidados.
• No utilices mecanismos PTR.  
• Como los mecanismos IPv4 e IPv6 hacen referencia a las IP directamente, no requieren ninguna búsqueda DNS y puedes usarlos a tu antojo.
• La mayoría de los servidores web y pocos servidores MX entrantes están configurados correctamente para enviar emails, así que ten cuidado al usar los mecanismos A o MX si no son absolutamente necesarios.
• Para algunas empresas, las fuentes de emails cambian a menudo, así que asegúrate de revisar todo el registro SPF de vez en cuando y eliminar las entradas innecesarias.  El sistema DNS mundial te lo agradecerá.
• NO. PTR. MECANISMOS.

Hablando en serio por un momento, el mecanismo PTR puede descontrolarse bastante rápido debido a su implementación y no encontrarás muchos proveedores de confianza que lo recomienden.

A veces, al hacer pruebas u obtener comentarios de un destinatario de emails, nuestros clientes notan que algunos mensajes enviados a través de la plataforma Mailgun tienen algo más que la firma DKIM en los encabezados del mensaje.  A menudo se ponen en contacto con nuestro equipo de asistencia para preguntar por qué ocurre esto y si sus mensajes están mal configurados de algún modo.

No hay de qué preocuparse: tus mensajes no están mal configurados y no pasa nada malo con los mensajes que tienen varias firmas DKIM. Mailgun aplica una doble firma DKIM a los mensajes cuando se envían a proveedores que requieren una firma DKIM de ESP como parte de sus sistemas de bucle de comentarios.

Gmail y Verizon Media Group (Yahoo/AOL/Verizon) son los nombres más importantes que tienen implantado este tipo de bucle de comentarios. Por tanto, nuestros equipos de reputación e ingeniería decidieron aplicar la doble firma DKIM a los mensajes dirigidos a esos sistemas para garantizar que podamos recibir sus comentarios para nuestros clientes. Los mensajes con doble autenticación y los comentarios de los ESP son una situación en la que todo el mundo gana.

Como equipo teórico de administración de Meowgun.com, una marca bien consolidada de los mejores memes de gatos en internet que aspira a la dominación mundial de los memes, queremos ampliar nuestros dominios de envío para cubrir un par de áreas nuevas: los envíos transaccionales y las campañas de marketing. Por tanto, se eligen transgressions.meowgun.com y meowketing.meowgun.com para gestionar esos dos nuevos flujos de emails.  Estos dominios se unirán a meowgun.com en nuestra cuenta de Mailgun y, de forma predeterminada, heredarán automáticamente la autoridad DKIM de meowgun.com. 

 Pero, ¿deberían hacerlo?

Una vez más, aquí no hay una respuesta universal, sino que los aspectos clave a tener en cuenta son el grado de comodidad que supone el solapamiento de la reputación del dominio, el grado de comodidad con un procedimiento de calentamiento de dominio y la vida útil del flujo de emails.

Por separado

• Si no quieres que se solape la reputación entre los distintos flujos de emails, mantenerlos por separado es la solución.  Cada versión del dominio tendrá poca o ninguna influencia en la reputación de los demás.
• Mantenerlos por separado significará que los dominios nuevos no tendrán ninguna reputación entre los proveedores, así que valora utilizar una estrategia de calentamiento adecuada.
• Lo mejor es mantener por separado los flujos de emails que vayan a tener una vida útil considerable.

Heredar el dominio raíz

• Si el solapamiento de la reputación no supone un gran problema, opta por heredar.  En este caso, ten cuidado con los flujos de marketing, porque la interacción del marketing suele ser menor que la interacción de los mensajes transaccionales o entre personas, y podría tener un efecto negativo en la reputación del dominio principal.
• Si necesitas evitar el calentamiento de un dominio nuevo, valora la posibilidad de heredar. El deterioro de la reputación que mencionamos antes también se aplica aquí.
• Si necesitas un flujo de emails a corto plazo (de unas semanas a un mes) a un volumen más pequeño con una audiencia de gran interacción, valora la posibilidad de heredar.

Lo último que hay que tener en cuenta sobre la autoridad DKIM es que tu elección no es inamovible. Los ajustes siempre se pueden cambiar a través de nuestra API de dominios o contactando con nuestro equipo de asistencia, pero se seguirán aplicando las mismas consideraciones sobre la reputación a la hora de hacer el cambio.

A medida que las implementaciones de DMARC por parte de los sistemas destinatarios siguen ganando popularidad en el sector y aumentan las tasas de adopción, implementar una política DMARC inteligente puede aportar ventajas reales a la reputación como remitente. Tenemos muchos clientes concienciados con la seguridad que quieren aplicar de inmediato la política p=reject más estricta.  Siempre parece una buena idea hasta que reciben informes de que se han bloqueado emails válidos debido a la política, y sus propios clientes se molestan y se preguntan a dónde han ido a parar sus emails.

Aquí la paciencia da sus frutos. Incontables interacciones con los clientes nos han enseñado que es mejor implementar una política p=none durante un largo periodo de tiempo antes de probar con una política más estricta. Esto da tiempo al equipo de administración de políticas para recibir informes sobre todos los emails que incumplen la política y ajustar adecuadamente el registro DMARC o el flujo de emails. Calcula un periodo de entre unas semanas y un mes para intentar llevar la cuenta de todos los flujos de emails y sus respectivas frecuencias. Una vez que todos los flujos válidos cumplan la política, empieza a decantarte por una política p=quarantine o p=reject más estricta para empezar a recoger los frutos en cuanto a la reputación del dominio.

Con suerte, algunos de estos supuestos resultarán útiles a nuestros clientes en la implementación de los distintos protocolos de autenticación de emails. Sin embargo, hay mucho más que explorar con cada protocolo de autenticación, pero que no cunda el pánico. Si aún tienes dudas o preguntas sobre tus protocolos de autenticación de emails, no dudes en ponerte en contacto con nuestro equipo de asistencia, que te ayudará con mucho gusto a lo largo de tu proceso de envío de emails.

Autor: Levi Trejo Technical Account Manager at Sinch Mailgun