Has configurado SPF. Has configurado DKIM. Tus emails están autenticados y te sientes bien con tu postura de seguridad. Luego descubres que alguien ha estado enviando miles de correos de phishing desde tu dominio durante meses, y nada de tu autenticación importó porque nunca le dijiste a nadie qué hacer ante los fallos.
Este es el vacío que DMARC llena. SPF y DKIM son mecanismos de verificación: pueden indicar a un servidor receptor si un email es legítimo. Pero no especifican qué debe ocurrir cuando la verificación falla. ¿Debería entregarse el email de todas formas? ¿Ponerlo en cuarentena? ¿Rechazarlo directamente? Sin instrucciones explícitas, la mayoría de los servidores optan por entregar el email, quizá con un aviso que los usuarios ignoran.
DMARC—Domain-based Message Authentication, Reporting, and Conformance—es la capa de políticas. Le dice al mundo: 'Esto es lo que quiero que hagas con los correos que fallen la autenticación. Y, por cierto, envíame informes sobre lo que ves.'
The three DMARC policies
Las políticas de DMARC se especifican con la etiqueta 'p=' en tu registro DMARC. Hay tres opciones, y elegir la correcta depende de en qué punto te encuentras en tu recorrido de autenticación de email.
'p=none' es el modo de monitoreo. Les dice a los servidores receptores: 'No hagas nada especial con los fallos, pero envíame informes sobre lo que ves.' Aquí es donde todos deberían empezar. Obtienes visibilidad de tu ecosistema de email sin arriesgar que se bloqueen correos legítimos.
'p=quarantine' es el punto intermedio. Les dice a los servidores: 'Si la autenticación falla, trata el email como sospechoso.' En la práctica, normalmente significa que el email va a las carpetas de spam o correo no deseado. Los usuarios aún pueden encontrarlo si buscan, pero no está en su bandeja de entrada.
'p=reject' es la aplicación total. Les dice a los servidores: 'Si la autenticación falla, no entregues el email en absoluto.' Este es el objetivo: protección completa contra la suplantación de dominio. Pero también es lo más peligroso si tu autenticación no está correctamente configurada, porque se bloquearán correos legítimos.
El recorrido de 'none' a 'reject' suele llevar semanas o meses. Empiezas con monitoreo, analizas los informes para encontrar todas las fuentes legítimas de correo, te aseguras de que estén correctamente autenticadas y luego aumentas la aplicación gradualmente. Correr hacia 'reject' antes de estar listo es una gran manera de romper tu email.
Understanding DMARC alignment
Aquí es donde DMARC se vuelve sutil y donde mucha gente se confunde. DMARC no solo comprueba si SPF y DKIM pasan: comprueba si 'alinean' con la dirección From visible.
Considera este escenario: Un atacante envía un email con una dirección From de [email protected]. Lo envía a través de su propio servidor, que tiene SPF válido para attackerdomain.com. El email pasa SPF, pero para el dominio equivocado. Sin comprobación de alineación, este ataque tendría éxito.
La alineación de DMARC requiere que el dominio autenticado por SPF o DKIM coincida con el dominio en la cabecera From. 'Coincidir' puede significar una coincidencia exacta (alineación estricta) o una coincidencia a nivel del dominio organizativo (alineación relajada).
Con alineación relajada (la predeterminada), mail.yourcompany.com alinea con yourcompany.com. Con alineación estricta, no lo hacen: solo cuentan las coincidencias exactas. La mayoría de las organizaciones usan alineación relajada porque es más práctica, especialmente si usas subdominios para diferentes flujos de correo.
Para que DMARC pase, o bien SPF debe pasar Y alinear, o DKIM debe pasar Y alinear (o ambos). Por eso es importante tener tanto SPF como DKIM configurados; si uno falla (por ejemplo, SPF falla debido a un reenvío), el otro aún puede proporcionar un resultado satisfactorio.
DMARC reports: Your window into email abuse
La función de informes de DMARC es posiblemente tan valiosa como la aplicación de políticas. Cuando publicas un registro DMARC con una etiqueta 'rua=', los servidores receptores te envían informes agregados sobre los emails que han visto que afirman ser de tu dominio.
Estos informes son archivos XML que llegan diariamente (por lo general). Contienen datos sobre volumen de correo, resultados de autenticación y fuentes de envío. Para cada IP de origen, verás cuántos correos se enviaron, si SPF y DKIM pasaron y qué política se aplicó.
La primera vez que mires los informes de DMARC, probablemente te sorprendas. Verás email proveniente de fuentes que habías olvidado: aquella vieja herramienta de marketing que dejaste de usar pero nunca desmantelaste, el sistema de facturación que envía recibos, el servicio de monitoreo que envía alertas. También verás fuentes no autorizadas: spammers, phishers o simplemente sistemas mal configurados que de alguna manera terminaron enviando como tu dominio.
Los informes de DMARC en bruto son difíciles de leer. La mayoría de las organizaciones utilizan un servicio de análisis de DMARC (hay opciones gratuitas y de pago) que agrega informes, visualiza los datos y te alerta sobre problemas. Esto es muy recomendable: intentar analizar informes XML manualmente no escala.
También existe 'ruf=' para informes forenses, que envían información detallada sobre emails individuales que fallan. Son más sensibles en términos de privacidad (pueden incluir contenido del email) y muchos receptores no los envían, pero pueden ser útiles para investigar incidentes específicos.
The path to enforcement
Pasar de p=none a p=reject es un proceso, no un evento. Así es como suele funcionar en la práctica.
Empiezas publicando un registro DMARC con p=none y una dirección rua para los informes. No necesitas SPF y DKIM perfectos en este punto: solo estás recopilando datos. Espera al menos dos semanas, preferiblemente un mes, para recolectar suficientes informes y ver el panorama completo.
Analiza los informes. Identifica cada fuente legítima de correo de tu dominio. Para cada una, verifica que SPF y DKIM estén correctamente configurados. Aquí es donde a menudo descubres servicios olvidados o configuraciones erróneas. Arréglalos.
Una vez que tus fuentes legítimas estén pasando la autenticación de forma consistente, pasa a p=quarantine. Pero no lo apliques al 100% de inmediato: usa la etiqueta 'pct=' para aplicar la política solo a un porcentaje de los emails que fallen. Comienza con pct=10, lo que significa que el 10% de los fallos se ponen en cuarentena mientras que el 90% aún se entrega normalmente.
Monitorea los informes. Si ves correo legítimo siendo puesto en cuarentena, investiga y corrige. Si todo se ve bien, aumenta gradualmente el porcentaje: 25%, 50%, 75%, 100%.
Una vez que estés en p=quarantine con pct=100 y todo sea estable, repite el proceso para p=reject. De nuevo, empieza con un porcentaje bajo y ve incrementando gradualmente. Cuando llegues a p=reject con pct=100 (o sin etiqueta pct, que por defecto es 100%), tendrás aplicación completa de DMARC.
Este proceso suele tardar entre 2 y 6 meses, dependiendo de la complejidad de tu ecosistema de email. Acelerar en exceso implica el riesgo de bloquear correo legítimo. Ser demasiado lento te deja vulnerable a la suplantación. Encuentra el ritmo adecuado para tu organización.
Common DMARC mistakes
El error más común es saltar directamente a p=reject sin monitorear primero. Romperás algo. Tal vez sea el sistema de RR. HH. que envía cartas de oferta, o la herramienta de finanzas que envía facturas, o la aplicación heredada que nadie recuerda que existe. Empieza con p=none, siempre.
Otro error frecuente es configurar DMARC pero nunca mirar los informes. Los informes son todo el propósito de la fase de monitoreo. Si no los estás analizando, estás volando a ciegas. Configura una herramienta de análisis de DMARC y revisa realmente los datos.
Olvidarse de los subdominios atrapa a muchas organizaciones. De forma predeterminada, la política de DMARC se aplica solo al dominio exacto, no a los subdominios. Si quieres proteger marketing.yourcompany.com, necesitas o bien un registro DMARC separado para ese subdominio o una etiqueta 'sp=' en tu registro principal que especifique la política para subdominios.
La mala configuración de servicios de terceros es muy común. Cuando agregas un nuevo servicio de email, debes actualizar tanto SPF (para autorizar sus servidores) como asegurarte de que estén firmando con DKIM en tu dominio (no en su dominio predeterminado). Muchos servicios requieren una configuración explícita para usar el DKIM de tu dominio.
Finalmente, tratar DMARC como 'configurar y olvidar' lleva a problemas. Tu ecosistema de email cambia con el tiempo. Se agregan nuevos servicios, se eliminan los antiguos, las configuraciones se desvían. Revisa tus informes de DMARC con regularidad, incluso después de alcanzar la aplicación total.
Frequently asked questions
¿Puedo usar DMARC sin SPF o DKIM?
Técnicamente sí, pero no tiene sentido. La política de DMARC se basa en los resultados de SPF y DKIM. Sin al menos uno de ellos configurado, todos los correos fallarán DMARC. Necesitas SPF, DKIM o ambos para que DMARC sea significativo.
¿Cuál es la diferencia entre los informes rua y ruf?
Los informes rua (agregados) son resúmenes diarios de resultados de autenticación: volúmenes y tasas de aprobación/fallo por fuente. Los informes ruf (forenses) son información detallada sobre correos individuales que fallan. La mayoría de las organizaciones solo usan rua; los informes ruf se envían con menos frecuencia y plantean preocupaciones de privacidad.
¿Cuánto tiempo debería quedarme en p=none antes de pasar a quarantine?
Al menos 2-4 semanas, más si tienes un ecosistema de email complejo. Necesitas suficientes datos para identificar todas las fuentes legítimas de correo y verificar que estén correctamente autenticadas. Acelerar esta fase es la causa más común de problemas de email relacionados con DMARC.
¿DMARC detendrá todo el phishing?
No. DMARC evita la suplantación exacta del dominio (alguien que envía como @yourcompany.com), pero no detiene dominios parecidos (yourcompany-secure.com) ni la suplantación del nombre visible ('Tu Empresa `<[email protected]>`'). Es una capa importante, pero no una solución completa anti-phishing.