En antiguas entradas de blog hemos podido hablar sobre SPF o DKIM, los cuales ayudan a verificar y autenticar los emails y evitar los fraudes, spam, phising, etc...
En esta nueva entrada, vamos a hablar sobre un nuevo mecanismo, que aún reciente, debería implementarse de aquí a poco en cada dominio (es un registro DNS añadido TXT al estilo de dkim o spf), pero... ¿qué hace realmente DMARC?
DMARC, Domain-based Message Authentication, Reporting & Conformance, es un mecanismo para compartir información entre sistemas origen y destino de correo y de este modo, aumentar la precisión a la hora de detectar correo fraudulento.
El diseño de DMARC se orienta pues, a conseguir minimizar los falsos positivos proporcionando información robusta sobre la autenticación y afirmar la política del emisor en los receptores, para reducir el éxito del phishing, entre otras vulnerabilidades.
Funcionamiento de DMARC
DMARC funciona a nivel de dominio utilizando SPF y DKIM y utilizando registros DNS para la publicación de sus políticas de verificación de correo y proceso de feedback.
La implementación DMARC incluye:
- Especificación para los emisores de correo para desplegar las tecnologías SPF y DKIM de modo que los receptores puedan verificar la autenticidad a nivel del dominio.
- mecanismo basado en DNS a través del cual los emisores puedan publicar sus prácticas dmarc , solicitar información a los receptores e informar a los mismos las políticas a aplicar para el manejo de correo no autenticado.
- Un modelo de feedback que permite a los receptores de correo informar a los emisores de cómo el correo recibido es tratado, permitiendo a estos una mejora contínua en la precisión del manejo del correo.
DMARC utiliza registros TXT DNS para especificar sus políticas. Este registro se identificará con la etiqueta
_dmarc precediendo el dominio. Por ejemplo _dmarc.gmail.com o _dmarc.yahoo.es:
Parámetros de configuración de DMARC
Esta etiqueta debe estar presente con ese valor, sí o sí.
- p= Aqui deberás elegir una de las tres opciones. Esto será el modo que tendrá DMARC de comportarse con los emails.
none -> No muestra ningún aviso.
quarantine -> Avisa a la cuenta de correo que pongamos que el email es sospechoso de SPAM o similar.
reject -> Rechza el correo que ha fallado la comprobación DKIM y/o SPF.
- sp= Mismos valores que para p= (reject, quarantine, none).
Opcional. Si no está puesta la opción p= policy se asume que eso es global para todo el dominio y subdominios. Si sp= está configurada, indica que la política de seguridad se aplicará al subdominio el cual DMARC está configurado, pero no al dominio global. El dominio se configura con p=
$ORIGIN example.com.
...
_dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine"
Esto hará que sea rechazado para el dominio y rechazado para un subdominio.
- adkim= r (relaxed - default) or s (strict) mode
Opcional (si se omite, por defecto es "r"). En el modo estricto el que envía el dominio debe exactamente ser el mismo que el DKIM.
En relaxed, cualquier subdominio del dominio principal será aceptado también
- aspf= r (relaxed) or s (strict) mode
Opcional (si se omite, por defecto es "r". En el modo estricto el dominio en el MAIL FROM (casos de SMTP) y el from (header) debe coincidir exactamente. En el modo relaxed será valido cualquier subdominio del dominio principal.
Opcional. Define el porcentaje de emails a los cuales DMARC aplicará su política. Si se omite, por defecto es el 100%.
Todos los emails serán procesados. Este parámetro permitirá a los remitentes experimentar con un pequeño porcentaje de emails que estarán bajo el control de DMARC.
- fo= Puedes poner más de una opción de las siguientes (opcional, por defecto es 0)
0 -> Genera un reporte si todos las comprobaciones fallan. Por tanto, si solo DKIM es usado para asegurar los emails y DKIM falla, enviará un reporte. Si solo SPF es usado y SPF falla, enviará un reporte. Sin embargo, si ambos (SPF y DKIM) están siendo usados y SPF falla pero DKIM no, no se enviará reporte.
1 -> Genera un reporte si alguna comprobación falla. Por tanto, si se usa DKIM y falla, enviará un reporte, si solo falla SPF se enviará un reporte. Sin embargo, si ambos (SPF y DKIM) están siendo usados y SPF falla pero DKIM no, no se enviará reporte.
d -> Genera un reporte si DKIM falla.
s -> Genera un reporte si SPF falla.
Define la politica de reportes de errores al enviar el correo. Podemos usar varias opciones separándolo por dos puntos (:), ejemplo: fo=0:s
Opcional (por defecto "afrf"). Define el tipo de formato que recibirás el reporte. afrf usa el formato 5965. iodef usa el formato 5070. Podemos usar varias.
Opcional (si se omite, por defecto es ri=86400 - 24 horas). Define el reporte en intervalos de segundos en recibir los envíos.
Una coma delimitará a las personas que se les enviará el reporte. Opcional. Si no está presente esta opción, el
reporte global no será enviado. El formato debe ser:
mailto:user@example.com
Por tanto, si la cuenta que envía el correo es "
example.net" y el DMARC TXT RR contiene
rua=mailto:dmarc-admin@example.net no se requiere ninguna información adicional. Sin embargo, si es "
example.net" y el DMARC TXT RR es example.net deberás validar el reporte para example.net teniendo el siguiente DMARC TXT RR:
# example.com zone file fragment
$ORIGIN example.com.
...
# authorises the receiving of DMARC reports for example.net
example.net._report._dmarc TXT "v=DMARC1"
Una coma delimitará a las personas que se les enviará el reporte. Opcional. Si no está presente esta opción, el
reporte de fallos no será enviado. El formato debe ser:
mailto:user@example.com
Por tanto, si la cuenta que envía el correo es "
example.net" y el DMARC TXT RR contiene
rua=mailto:dmarc-admin@example.net no se requiere ninguna información adicional. Sin embargo, si es "
example.net" y el DMARC TXT RR es example.net deberás validar el reporte para example.net teniendo el siguiente DMARC TXT RR:
# example.com zone file fragment
$ORIGIN example.com.
...
# authorises the receiving of DMARC reports for example.net
example.net._report._dmarc TXT "v=DMARC1"
Ejemplo 1. Agresivo. Usando DKIM y SPF
# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"
"adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.com")
# NOTE: since the required email address is out-of-zone the
# following change to the zone file for example.com must be made
# example.com zone file fragment
$ORIGIN example.com.
...
example.net._report._dmarc TXT "v=DMARC1"
# functionally identical
example.net._report._dmarc.example.net. TXT "v=DMARC1"
...
Ejemplo 2. Tímido. Usando DKIM y SPF
# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc TXT ( "v=DMARC1;p=none;sp=reject;pct=10;"
"adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.net")
Ejemplo 3. Agresivo. Usando solo SPF
# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"
"aspf=r;fo=0;ri=86400;rua=mailto:dmarc-admin@example.net")
Ejemplos de verificación
Verificación fallida
Ejemplo de correo no legítimo donde se aplica SPF y dmarc, y donde falla la verificación SPF al ser enviado desde un servidor no autorizado. Dado que la política es permisiva, el correo entra en la bandeja de entrada, pero se muestra un mensaje de advertencia en el cliente de correo:
Verificación correcta.
En la siguiente ilustración se muestra un ejemplo de correo legítimo desde una cuenta de yahoo y que pasa filtros de verificación SPF, DKIM y DMARC:
Con esto ya teneis la información necesaria para configurar vuestro DMARC a nivel de DNS.
Etiquetas:
correo
Volver