DMARC es un protocolo que nos brinda la posibilidad de autenticar al emisor del correo electrónico, es decir, garantizar que el correo viene del dominio que indica, por ejemplo, seguridad@empresa.com.
La aparición de DMARC se remonta a 2015 ante la apremiante necesidad de autenticar el remitente, los principales proveedores a nivel mundial desarrollaron de forma conjunta este protocolo, de ahí nace el RFC7489 https://tools.ietf.org/html/rfc7489 documento que define el estandar DMARC.
¿Qué es DMARC?
«Domain-based Message Authentication, Reporting and Conformance» son las siglas en inglés de Autenticación de mensajes basada en dominio informes y conformidad.
Es un protocolo de autenticación de correo electrónico. Permite proteger un determinado dominio de usos no autorizados relacionados con la suplantación del correo electrónico de su organización. Así, gracias a DMARC podrá evitar que sus clientes reciban correos electrónicos de phishing, scam u otras ciberamenazas en su nombre.
DMARC tiene dos principales funciones:
- Verificar la autenticidad de un correo electrónico.
- Impedir que los correos falsos lleguen a su destino.
¿Cómo funciona DMARC?
DMARC se apoya en dos protocolos, SPF (Sender Policy Framework) y DKIM (Domain Keys Identified Mail).
SPF comprueba que el email es enviado desde una direccion IP válida.
En este parámetro debemos recopilar todas las IPs de proveedores, propias y de terceros que queramos permitir que envíen correos en nombre de la entidad, la mayoria de proveedores de correo facilitan esta labor.
Ejemplo de SPF: «v=spf1 include:gmail.com +ip4:10.10.10.1 -all«
| Etiqueta | Descripción y valores permitidos |
| v | Versión de SPF. Esta etiqueta es obligatoria y tiene que ser la primera del registro. Debe tener este valor:v=spf1 |
| ip4 | Autoriza a servidores de correo mediante una dirección o un intervalo de direcciones IPv4. El valor debe ser una dirección o un intervalo de direcciones IPv4 en formato estándar. Por ejemplo:ip4:192.168.0.1o ip4:192.0.2.0/24 |
| ip6 | Una lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”. Autoriza a servidores de correo mediante una dirección o un intervalo de direcciones IPv6. El valor debe ser una dirección o un intervalo de direcciones IPv6 en formato estándar. Por ejemplo:ip6:3FFE:0000:0000:0001:0200:F8FF:FE75:50DFo ip6:2001:db8:1234::/48 lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”. |
| a | Autoriza a servidores de correo por su nombre de dominio. Por ejemplo:a:tuproveedor.com |
| mx | Autoriza a uno o varios servidores de correo por el registro MX del dominio. Por ejemplo:mx:mail.solarmora.comSi no incluyes este mecanismo en tu registro SPF, el valor predeterminado son los registros MX del dominio en el que se usa el registro SPF. |
| include | Autoriza a remitentes de correo externos por su dominio. Por ejemplo:include:servers.mail.net |
| all | Indica que todos los mensajes entrantes coinciden. Te recomendamos que siempre incluyas este mecanismo en tu registro SPF. Tiene que ser el último mecanismo del registro SPF. Todos los mecanismos que haya después de all se ignorarán.¿Debo usar ~all o -all? Cuando un registro SPF incluye ~all (calificador de que se supera la autenticación con reservas), los servidores que reciben correo suelen aceptar los mensajes de remitentes que no figuran en el registro SPF, pero los marcan como sospechosos.Cuando un registro SPF incluye -all (calificador de fallo), puede que los servidores que reciben correo rechacen los mensajes de remitentes que no figuren en el registro SPF. Si tu registro SPF no está bien configurado y usas el calificador de fallo, puede que se marquen como spam más mensajes de tu dominio.Para evitar el spoofing de dominios que no envían correo, usa este registro SPF en el dominio: vspf1 ~all |
Ejemplo de configuración DMARC en el DNS:
DKIM verifica que el correo está firmado digitalmente por el dominio original.
Para este parametro debemos generar una clave DKIM, nuestro proveedor de correo nos facilitará esta información que debemos reflejar en el DNS.
ejemplo de DKIM: v=DKIM1;k=rsa;t=s;s=email;p=XXXXXXXXXXXXXXXXXX
Impacto
Tengamos en cuenta que en caso de que tu organización no implemente DMARC o no esté correctamente implementado un atacante podría enviar un email suplantando la identidad de un compañero de trabajo solicitando acceso a algún servicio interno por ejemplo. No se queda solo ahí, un atacante podría solicitar cobrar una factura desde un correo aparentemente legitimo de un proveedor a suplantar y conseguir no solo información confidencial sino incluso lograr que se realicen transferencias a la cuenta del atacante mientras la victima piensa que está pagando una factura legítima al proveedor.
Si nuestra entidad tiene correctamente alineado DMARC, automáticamente estos correos maliciosos serían bloqueados o llevados a spam.
Estos ataques son mucho más comunes de lo que parece dentro del sector empresarial e implementar DMARC correctamente evitaría la mayoria de ellos
Esto también puede suceder fuera de entorno laboral, suplantando el atacante a páginas de venta bancos, falsas promociones, y una larga lista de eventos conocidos.
¿Que parámetros tiene en cuenta la configuración de DMARC?
La configuración se define mediante etiquetas, estas son:
| Etiqueta | Descripción y valores permitidos |
| v | Versión del protocolo DMARC (actualmente DMARC1). |
| p | Política para aplicar al correo electrónico que falla la verificación de DMARC. Puede ser “none”, “quarantine” o “reject”. “none” se utiliza para recopilar los reportes de DMARC y obtener información sobre el alineamiento y configuración de proveedores de correo. |
| rua | Una lista de URI para enviar reportes XML. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc@receptor-del-reporte.com”. |
| ruf | Una lista de URI para enviar informes forenses. DMARC requiere una lista de URI y no solo un correo, quedando: “mailto: analizador-dmarc-forense@receptor-del-reporte.com”. |
| rf | El formato de reporte para informes forenses. Esto puede ser “afrf” (Authentication Failure Reporting Formats) o “iodef” (Incident Object Description Exchange Format ). |
| pct | La etiqueta de porcentaje indica que solo apliquen la política de DMARC a un porcentaje de los correo electrónico fallidos. “pct=50” indicará a los receptores apliquen solo la política al 50% de los correos electrónicos que no superen la verificación DMARC. La etiqueta pct se diseñó como una forma de aplicar gradualmente las políticas DMARC para acortar el período de implementación para las empresas en línea. |
| adkim | El modo de alineación adkim se refiere a la precisión con la que se comparan los registros del remitente con las firmas DKIM, con dos posibles valores: «r» (relajado) permite coincidencias parciales, como subdominios de un dominio dado. «s» (estricto) requiere una coincidencia exacta. |
| aspf | El modo de alineación aspf se refiere a la precisión con la que se comparan los registros del remitente con las firmas SPF, con dos posibles valores: «r» (relajado) permite coincidencias parciales, como subdominios de un dominio dado. «s» (estricto) requiere una coincidencia exacta. |
| sp | Esta política se debe aplicar a los correos electrónicos de un subdominio que no pasan la verificación de DMARC. Al usar esta etiqueta, los propietarios del dominio pueden publicar una política de comodín para todos los subdominios. |
| fo | Opciones forenses Valores permitidos: “0” para generar informes si tanto DKIM como SPF fallan, “1” para generar informes si DKIM o SPF fallan, por último “d” y «s» para generar un informe si DKIM(d) ha fallado o si SPF(s) falló. Este campo puede tener múltiples opciones combinadas. |
| ri | El intervalo de informe de la frecuencia con la que desea recibir informes XML agregados. Esta es una preferencia y los proveedores comúnmente enviar el informe en diferentes intervalos ignorando esta preferencia. |
Ejemplo de configuración DMARC en el DNS:
v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:analizador-dmarc@receptor-del-reporte.com,mailto:analizador-dmarc@otro-receptor-del-reporte-diferente.com; ruf=mailto:analizador-dmarc@receptor-del-reporte.com,mailto:analizador-dmarc@otro-receptor-del-reporte-diferente.com; pct=100; fo=1;
Esta configuración como hemos visto define:
- Versión: DMARC1
- Política: Cuarentena
- Alineamiento dkim: estricto
- Alineamiento spf: estricto
- Porcentaje: 100%
- Opciones forenses si DKIM o SPF fallan
Ejemplo de reporte
Los reportes vienen en formato XML. Saber léerlos es importante para comprender mejor el flujo de correo. Los informes ayudan a los administradores a tomar medidas rápidamente cuando detectan un proveedor de correo legitimo mal configurado, que ha añadido nuevas IPs y no están reflejadas en el SPF o que no tiene correctamente configurado dkim. Aquí hay un extracto de un informe inventado que muestra los resultados de los mensajes enviados desde un par de direcciones IP, uno enviado directamente y el otro reenviado. Ambos mensajes pasaron la validación.
<record>
<row>
<source_ip>192.168.1.101</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>tudominio.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>tudominio.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>tudominio.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>192.168.1.102</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identities>
<header_from>tudominio.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>tudominio.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>tudominio.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>Recomendaciones
Despliegue lento, no pasar de politica none a reject sin pasar el suficiente tiempo en quarantine, aplicar a un porcentaje de correos pequeños la validación e ir aumentando lentamente en funcion de los datos obtenidos en los reportes. Depende del número de proveedores y del volumen de correos las velocidades pueden ser muy diferente.
Tratándolo de la forma más genérica los pasos los podriamos resumir en:
Aplicamos Política Nada para analizar durante al menos dos meses el alineamiento, en función de los datos obtenidos, si son favorables, avanzamos a política Cuarentena al 5%, si los resultados son favorables avanzamos el porcentaje lentamente hasta el 100%, si queremos ir un paso más allá, aplicaremos la política Rechazar al 5% y vuelta a empezar con la subida del porcentaje paulatinamente.
Si los datos no son favorables, debemos analizar que IPs no están alineadas con el SPF y de que proveedor son, revisar que porcentajes de correos están pasando SPF, cuantos DKIM y cuantos DMARC.
Más información:
- RFC7489: https://tools.ietf.org/html/rfc7489
- DMARC Technical Specification: https://dmarc.org/resources/specification/
- Definir el registro SPF, configuración avanzada: https://support.google.com/a/answer/10683907?hl=es
Deja una respuesta