7 remitentes externos que suelen incumplir las normas DMARC (y cómo autenticar a cada uno de ellos)

La mayoría de las organizaciones envían correos electrónicos desde muchos más sistemas que su servidor de correo. Las plataformas de marketing, los sistemas CRM, los servicios de asistencia técnica, las herramientas de facturación y una lista cada vez mayor de asistentes de IA envían mensajes que incluyen tu dominio en la dirección del remitente. Cada uno de ellos es un remitente externo y cada uno es un punto en el que los protocolos SPF, DKIM y DMARC pueden fallar sin que nadie se dé cuenta.

Los errores tienen ahora más importancia. Gmail, Yahoo y Outlook.com exigen a los remitentes que envían más de 5.000 mensajes al día que se autentiquen mediante SPF, DKIM y DMARC y que los hagan coincidir con el dominio del remitente; de lo contrario, pueden rechazar directamente el correo masivo que no cumpla con estos requisitos. Por debajo de ese volumen, un mensaje que no supere la verificación DMARC tiene más probabilidades de acabar en la carpeta de spam, y no llegará en absoluto una vez que se adopte una política de rechazo.

Esta guía abarca siete categorías de remitentes externos, explica cómo suele incumplir cada uno de ellos la normativa DMARC y enumera los pasos para autenticarlos. Concluye con ejemplos de registros DNS, un método de verificación y un plan de implantación.

Por qué los remitentes externos incumplen las normas DMARC

DMARC se supera cuando al menos uno de los dos, SPF o DKIM, se supera y está alineado con el dominio que figura en la dirección «De» visible. La alineación es el aspecto que la gente suele pasar por alto.

• Alineación SPF compara el dominio de la ruta de retorno, también denominado remitente del sobre o dirección de rebote, con el dominio «De». Los proveedores suelen utilizar su propio dominio de rebote, por lo que la verificación SPF se supera en su caso, pero no coincide con el tuyo.
• Alineación DKIM compara el dominio de firma que figura en la firma DKIM (el valor «d=») con el dominio del campo «De». Los proveedores suelen firmar con su propio dominio de forma predeterminada, por lo que DKIM se supera, pero no se alinea.
• Errores de configuración afectan al resto. Los más habituales son: más de 10 consultas DNS en SPF, más de un registro SPF en un dominio, registros DKIM que faltan y registros que se han quedado sin eliminar de proveedores que ya no utilizas.

En la alineación flexible, que es la predeterminada, un subdominio se alinea con el dominio organizativo al que pertenece. La alineación estricta requiere una coincidencia exacta. Dado que las firmas DKIM suelen conservarse tras el reenvío y las SPF a menudo no, la mayoría de los equipos optan por la alineación DKIM para todos los remitentes externos.

Los Siete Remitentes de un vistazo

1. Asistentes de reuniones y tomadores de notas basados en IA

Los asistentes a las reuniones envían resúmenes, tareas pendientes, borradores de seguimiento y comparten enlaces, a menudo con participantes ajenos a tu empresa. Tanto si tu equipo utiliza Fathom como si está barajando alternativas a Fathom, pregunta al proveedor cómo se autentifican sus correos electrónicos antes de conectar un buzón o habilitar el envío desde tu dominio.

Muchas de estas herramientas envían desde su propio dominio y muestran tu nombre como nombre de remitente. Esto no afecta a tus resultados de DMARC, ya que el dominio que aparece en la dirección «De» es el del proveedor. El problema surge con aquellas funciones que incluyen tu dominio en la dirección «De» y envían desde los servidores del proveedor, como los correos de seguimiento que parecen proceder de ti. Esos mensajes llevan la ruta de retorno y la firma DKIM del proveedor, por lo que SPF y DKIM pueden pasar la comprobación aunque sigan sin coincidir con tu dominio. Un tercer caso es el de las herramientas que envían a través de tu propio buzón de Google o Microsoft. Ese correo lo firma y lo entrega tu proveedor de correo, por lo que coincide siempre que la firma DKIM esté habilitada para tu dominio en ese servicio.

Preguntas que hay que hacer al vendedor:

• ¿Qué dominio aparece en la dirección del remitente de los resúmenes, las invitaciones y los recordatorios?
• ¿Hay alguna función que envíe correos desde los servidores del proveedor utilizando mi dominio en el campo «De»?
• Si es así, ¿puedo autenticarme con un DKIM personalizado y una ruta de retorno personalizada en un subdominio?
• ¿Se pueden limitar o desactivar los correos electrónicos a participantes externos?
• Si la herramienta envía mensajes a mi buzón de correo, ¿qué permisos solicita?

Cómo verificarlo:

• Si el dominio del remitente pertenece al proveedor, no hay nada que configurar en tu DMARC. Céntrate en quién recibe los correos electrónicos.
• Si el proveedor realiza envíos desde tu dominio, añade los registros DKIM y de ruta de retorno que figuran en su documentación, a ser posible en un subdominio específico.
• Si la herramienta envía mensajes a través de tu buzón de correo, asegúrate de que la firma DKIM esté activada para tu dominio personalizado en Google Workspace o Microsoft 365.
• Envía un resumen real a un buzón externo y lee los encabezados de autenticación antes de la implementación.

2. Plataformas de marketing y de servicios de correo electrónico

Las plataformas de marketing envían el mayor volumen de correo de terceros, lo que las convierte en la fuente más habitual de problemas con DMARC. Por defecto, muchas de ellas firman con la clave DKIM del propio proveedor y utilizan el dominio de rebote de este como ruta de retorno. De este modo, SPF y DKIM se validan para el dominio del proveedor, pero ninguno de ellos coincide con el dominio de tu dirección de remitente, por lo que DMARC falla.

El volumen aumenta las exigencias. Gmail, Yahoo y Outlook.com exigen a los remitentes que envíen más de 5.000 mensajes al día que se autentiquen mediante SPF, DKIM y DMARC y que el dominio del remitente coincida con el de «De»; además, los correos de marketing deben incluir la opción de darse de baja con un solo clic y tener una baja tasa de denuncias por spam. Los correos masivos que no cumplan estos requisitos pueden ser rechazados directamente.

Cómo verificarlo:

• Envía los mensajes desde un subdominio específico, como news.example.com, para que la reputación de marketing y los registros DNS se mantengan separados del correo corporativo.
• Completa la autenticación del dominio en la plataforma. Esto suele implicar añadir registros DKIM —a menudo de tipo CNAME— para que los mensajes se firmen con tu dominio, además de un dominio de ruta de retorno personalizado, si se ofrece esta opción.
• Publica el SPF donde sea necesario. Si la ruta de retorno es un subdominio personalizado, el registro SPF se aloja en ese subdominio, lo que permite que tu registro raíz sea breve.
• Configura una política DMARC para el subdominio, ya sea con «sp=» en el registro principal o mediante un registro propio, y consulta los informes agregados.
• Añade encabezados para darse de baja con un solo clic y vigila las tasas de reclamaciones.

3. Plataformas de CRM y de interacción comercial

Las herramientas de ventas suelen enviar mensajes de dos formas diferentes. Los correos electrónicos individuales enviados a través de una cuenta de correo de Google o Microsoft conectada son autenticados por tu proveedor de correo. Las secuencias masivas y las opciones de «envío a través de la plataforma» utilizan los propios servidores de la plataforma, y estos requieren una configuración específica. Un error frecuente es que la plataforma envíe mensajes desde las direcciones personales de los usuarios en tu dominio sin haber configurado DKIM ni la ruta de retorno.

Estas herramientas también acumulan inclusiones SPF. Cada inclusión implica consultas al DNS, y el SPF solo permite 10 por evaluación (RFC 7208). Si se supera el límite, los destinatarios interpretan el SPF como un error permanente, lo que hace que la comprobación falle.

Cómo verificarlo:

• Utiliza el envío vinculado al buzón para la comunicación personalizada.
• En el caso de las secuencias enviadas desde la plataforma, autentifica un subdominio específico con DKIM y una ruta de retorno personalizados, y mantén las comunicaciones de divulgación en un dominio o subdominio distinto al del correo corporativo.
• Comprueba qué usuarios y qué plataformas tienen permiso para enviar mensajes en nombre de tu dominio.
• Realiza comprobaciones periódicas de SPF. Consolida o elimina las inclusiones de las herramientas que ya no utilices, y ten cuidado con la simplificación, ya que las listas de IP simplificadas quedan obsoletas cuando los proveedores cambian de dirección.

4. Herramientas de servicio de asistencia y atención al cliente

Los equipos de asistencia suelen querer que las respuestas se envíen desde [email protected]. Esto significa que los servidores del servicio de asistencia envían correos con tu dominio en el campo «De», lo que requiere que SPF o DKIM estén configurados correctamente para superar la verificación DMARC. Muchas configuraciones omiten este paso, ya que los tickets parecen funcionar en las pruebas: superan las comprobaciones del propio proveedor y se entregan correctamente en bandejas de entrada poco estrictas.

La gestión del correo entrante plantea una segunda serie de problemas. El reenvío automático de un buzón de asistencia al servicio de soporte técnico es sencillo, pero el reenvío suele provocar fallos en el SPF, ya que la dirección IP del reenviador no está autorizada por el remitente original. Las firmas DKIM pueden mantenerse tras el reenvío, lo cual es una de las razones por las que la alineación DKIM es más fiable que la alineación SPF.

Cómo verificarlo:

• Añade los registros DKIM del proveedor para que las respuestas se firmen con tu dominio, y añade los registros SPF o de ruta de retorno del proveedor si es necesario.
• Es preferible utilizar el enrutamiento MX o el método de reenvío compatible con el proveedor, en lugar de las reglas de reenvío automático de los buzones de correo.
• Prueba a enviar una respuesta a un ticket a un buzón externo y revisa los encabezados; a continuación, repite el proceso con los mensajes automáticos, como las encuestas de satisfacción, que a veces proceden de un sistema diferente.
• Elimina los registros correspondientes a las herramientas de asistencia técnica que ya no utilices.

5. Herramientas de calendario y planificación

Las herramientas de planificación envían invitaciones, confirmaciones y recordatorios, normalmente en nombre del organizador. La mayoría las envía desde el dominio del proveedor, indicando tu dirección en el campo «Responder a», lo que no afecta a tu DMARC. Los problemas surgen con las opciones personalizadas que envían mensajes desde tu dominio sin autenticación, y con los correos del calendario que se envían sin firmar.

Es fácil pasar por alto el caso de los mensajes sin firmar. Si la firma DKIM no está habilitada para tu dominio personalizado en Microsoft 365, el correo saliente se firma con el dominio predeterminado del inquilino, que no coincide con tu dominio de remitente. Del mismo modo, Google Workspace requiere que la firma DKIM esté activada para tu dominio.

Cómo verificarlo:

• Comprueba qué dominio utiliza la herramienta en la dirección del remitente para cada tipo de mensaje.
• Activa la firma DKIM para tu dominio personalizado en tu proveedor de correo electrónico, para que las invitaciones del calendario y los mensajes enviados desde tu buzón coincidan.
• Si utilizas una opción de envío con marca propia, autentícala con los registros DKIM y de ruta de retorno del proveedor.
• Comprueba los correos electrónicos de recordatorio y cancelación por separado de las invitaciones.

6. Plataformas de facturación y pago

Las facturas, los recibos y los recordatorios de pago se encuentran entre los tipos de correo electrónico más utilizados con fines fraudulentos. Los atacantes los imitan porque los destinatarios actúan con rapidez ante cualquier asunto relacionado con el dinero, y una factura falsificada puede desviar un pago. Estas plataformas suelen enviar los mensajes desde su propio dominio con el nombre de tu empresa, y ofrecen la opción de enviarlos desde [email protected]. Esa opción solo funciona para DMARC cuando los registros DNS están configurados correctamente.

Las empresas suelen utilizar varias herramientas relacionadas con la facturación al mismo tiempo, como un programa de contabilidad, un procesador de pagos y un gestor de suscripciones. Cada una de ellas es un remitente independiente con sus propios registros.

Cómo verificarlo:

• Utiliza la función de dominio de correo electrónico personalizado de cada plataforma y publica los registros DKIM, SPF y de ruta de retorno que te proporcione.
• Enumera todos los sistemas que envían correos de facturación y comprueba que cada uno de ellos se autentifique y se sincronice.
• Adopta una política de aplicación de medidas tan pronto como los informes indiquen que tus fuentes legítimas cumplen los requisitos. Eso es lo que impide que los atacantes envíen facturas que parezcan tuyas.
• Indica a los clientes desde qué direcciones se envían tus facturas.

7. Sistemas de recursos humanos, selección de personal y nóminas

Los sistemas de gestión de candidatos envían correos electrónicos a los candidatos desde direcciones del tipo careers@ o jobs@; las plataformas de incorporación envían mensajes de bienvenida y las herramientas de nóminas envían notificaciones a los empleados. A menudo, el departamento de RR. HH. se encarga de seleccionarlas y configurarlas sin la participación del departamento de TI, por lo que nadie comprueba la configuración del DNS. El resultado es que las ofertas acaban en la carpeta de spam y los candidatos no reciben las invitaciones a las entrevistas.

La suplantación de identidad también es habitual aquí. Los correos electrónicos con estafas laborales que imitan la imagen de marca de una empresa real son una táctica muy común, y una política DMARC aplicada con rigor dificulta su envío desde tu dominio real.

Cómo verificarlo:

• Incluye la revisión del DNS en el proceso de adquisición del software de recursos humanos.
• Autentifica un subdominio específico para los correos de selección de personal, utilizando los registros DKIM y de ruta de retorno del proveedor.
• Publica una breve lista de las direcciones oficiales relacionadas con la contratación y la nómina para que los candidatos y los empleados puedan identificarlas.
• Comprueba que las invitaciones a entrevistas y los correos electrónicos con ofertas lleguen a las bandejas de entrada reales, incluidos los proveedores de correo web gratuito.

Ejemplos de registros DNS

Los nombres y valores exactos se obtienen de la página de configuración de cada proveedor. Los ejemplos que aparecen a continuación muestran lo que cabe esperar. Los dominios son marcadores de posición.

SPF en el subdominio de envío (un registro por dominio)
mail.example.com. TXT «v=spf1 include:_spf.vendor.example ~all»

Registros de firma DKIM, que suelen proporcionarse como CNAME:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Dominio personalizado de ruta de retorno (rebote)
bounce.mail.example.com. CNAME return.vendor.example.

Registro DMARC, en modo de supervisión
_dmarc.example.com. TXT «v=DMARC1; p=none; rua=mailto:[email protected]» 

Cómo verificar a un remitente antes de poner en marcha el servicio

Envía un mensaje real desde el sistema a un buzón externo, abre el mensaje original y lee los resultados de la autenticación. Es importante que SPF o DKIM den positivo y que el dominio que aparece en ese resultado coincida con el dominio del campo «De».

Alineado: DMARC supera la comprobación
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Aprobado, pero sin alineación: DMARC falla
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

En el segundo ejemplo, ambas comprobaciones se superan, pero en lo que respecta al dominio del proveedor. Ninguno de ellos coincide con example.com, por lo que DMARC falla. Esa es la característica distintiva de un remitente externo no autenticado.

Un plan de implantación

1. Haz un inventario de tus remitentes. Pide información al departamento de finanzas sobre las suscripciones a servicios SaaS, revisa tu lista de aplicaciones de inicio de sesión único, lee tus inclusiones SPF y comprueba los registros de correo.
2. Publica DMARC con p=none y una dirección de notificación. Los informes agregados muestran todos los sistemas que envían mensajes en nombre de tu dominio, incluidos aquellos que nadie recordaba.
3. Autentifica a cada remitente legítimo. Utiliza DKIM y una ruta de retorno personalizadas, y da prioridad a los subdominios para los sistemas de gran volumen o de alto riesgo.
4. Avanza hacia la aplicación de las medidas. Una vez que los informes indiquen que el correo legítimo pasa sin problemas, pasa a la cuarentena y, a continuación, al rechazo, supervisando los informes en cada etapa.
5. Conviértelo en una rutina. Incorpora una comprobación de autenticación por correo electrónico al proceso de incorporación de proveedores y elimina los registros DNS cuando dejes de utilizar una herramienta.

PREGUNTAS FRECUENTES

¿Cuál es la diferencia entre que SPF o DKIM sean válidos y que DMARC sea válido?

SPF y DKIM pueden dar resultado positivo para cualquier dominio, incluido el del proveedor. DMARC añade el requisito de que el dominio que da resultado positivo coincida con el dominio que figura en la dirección del remitente.

¿Tengo que añadir a todos los proveedores a mi registro SPF?

No siempre. Si un proveedor utiliza una ruta de retorno personalizada en tu subdominio y firma con DKIM alineado, DMARC puede dar el visto bueno sin modificar tu registro SPF raíz. Además, un menor número de inclusiones te ayuda a mantenerte por debajo del límite de 10 consultas.

¿Debería utilizar subdominios para los remitentes externos?

A menudo, sí. Un subdominio separa los registros de reputación y los de DNS, y facilita el seguimiento y el control de cada fuente. Recuerda que los subdominios heredan tu política DMARC, a menos que establezcas «sp=» o publiques un registro independiente.

¿Cuánto tiempo se tarda en llegar a p=rechazado?

Depende del número de remitentes que tengas y de la rapidez con la que puedas solucionarlo. Muchas organizaciones tardan entre varias semanas y unos meses, basándose en informes agregados.

¿Qué pasa si un proveedor no puede registrarse con mi dominio?

En ese caso, DMARC tendría que pasar por la alineación con SPF utilizando una ruta de retorno personalizada. Si ninguna de las dos opciones es posible, el proveedor debería enviar los mensajes desde su propio dominio, no desde el tuyo.

¿Se aplica DMARC al correo electrónico enviado a través de Google Workspace o Microsoft 365?

Sí. Asegúrate de que la firma DKIM esté activada para tu dominio personalizado en esa configuración; de lo contrario, es posible que los correos se firmen con un dominio predeterminado que no coincida.