SPF en DKIM en DMARC en la práctica: identificar todos los remitentes

Módulo 4: Entregabilidad: SPF, DKIM y DMARC en la práctica · Tiempo de lectura: 12 minutos

Objetivo de aprendizaje: Después de esta lección podrá localizar todos los servicios que envían correo en nombre de su dominio, reunirlos en un único registro SPF, contar las consultas de forma recursiva hasta el límite de diez, y elegir conscientemente entre ~all y -all.

Conceptos clave: inventario de remitentes, remitente del sobre (Return-Path), un único registro SPF, include, redirect, límite de 10 consultas DNS (RFC 7208 apartado 4.6.4), consultas vacías (void lookups, máximo 2), conteo recursivo, permerror, flattening, SPF para subdominios, SPF en un dominio que no envía correo, ~all y -all

Un breve repaso

Un registro SPF es un registro TXT en su dominio que empieza por v=spf1 y enumera qué servidores pueden enviar correo en nombre de su dominio. La estructura, los caracteres + - ~ ? y los tres errores más conocidos (dos registros, +all, más de diez consultas) se explican en el curso de DNS, lección 4.3. Léala primero si SPF es nuevo para usted. Esta lección trata la parte más complicada: en la práctica, casi nadie sabe con exactitud quién envía correo en nombre de su dominio.

Paso 1: el inventario

SPF solo funciona si todos los remitentes están incluidos. Si olvida uno, ese correo acabará en la carpeta de spam o será rechazado en cuanto endurezca DMARC. Por eso conviene repasar esta lista. En una empresa pequeña media, enseguida encontrará cinco o seis:

Dos buenas formas de encontrarlos:

1. Leer las cabeceras. Envíese un correo desde cada sistema (una factura, una recuperación de contraseña, una newsletter de prueba) y revise en las cabeceras el Return-Path y Authentication-Results (lección 1.5). Ahí verá a través de qué dominio y qué servidor llegó.
2. Informes DMARC. Configure DMARC en p=none con una dirección de informes (lección 4.4). Al cabo de unas semanas verá en los informes (lección 4.5) todos los servidores que enviaron correo en nombre de su dominio, incluidos los que había olvidado. Es el inventario más fiable.

No todos los servicios pertenecen a su SPF

Aquí es donde suele haber errores. SPF se fija en el remitente del sobre (el Return-Path), no en la dirección De. Muchos servicios de newsletters y de envío utilizan un Return-Path en su propio dominio, por ejemplo bounce-123@mail.mailer.example. El destinatario comprueba entonces el registro SPF de mailer.example, no el suyo. Un include de ese servicio en su registro no sirve entonces de nada, salvo para gastar una consulta.

Lo que ese servicio sí necesita para superar DMARC es una firma DKIM con su dominio (lección 4.3), o un subdominio de Return-Path propio suyo (por ejemplo bounce.example.com como CNAME hacia el servicio). Consulte por tanto la documentación del servicio para saber qué pide. Si indica «ponga include: en su SPF», hágalo. Si solo dice «cree estos registros CNAME para DKIM y el dominio de bounce», entonces no hace falta nada en su registro principal. El módulo 7 profundiza en esto.

Paso 2: un solo registro, y contar bien

Todos los remitentes van en un único registro. Supongamos que su inventario arroja esto: el servidor de correo de su proveedor de hosting, Microsoft 365 para algunos empleados, su programa de contabilidad y un servicio de asistencia. Entonces el registro quedaría así, por ejemplo:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

¿Cuántas consultas son? Cuente cada a, mx, include, exists, ptr y redirect, y cuente después también todo lo que aparece en los registros detrás de cada include:

A partir de 11, el destinatario devuelve un permerror: todo el registro SPF deja de contar entonces, para ningún remitente. El correo de su propio servidor de correo se evalúa por tanto peor porque el servicio de asistencia cuesta tres consultas. Y lo traicionero es que su registro puede estar hoy en 9 y mañana en 11, sin que usted cambie nada, porque un servicio amplía su propio registro.

Además: máximo dos consultas vacías

El RFC 7208 también menciona las void lookups: consultas que no dan ningún resultado (el nombre no existe, o no tiene registro SPF ni de dirección). Más de dos de ellas también provocan un permerror. Esto ocurre sobre todo con includes antiguos de servicios que ya no utiliza y que han eliminado su registro, o con un a: hacia un servidor que ya no existe. Así que conviene hacer limpieza.

Paso 3: volver a bajar de diez

Si supera las diez consultas, hay cuatro soluciones, de la mejor a la menos recomendable:

1. Elimine lo que no sea necesario. Servicios que ya no utiliza. Servicios que envían con un Return-Path propio (vea más arriba) y que, por tanto, no deben estar en su SPF. a si su sitio web en sí no envía correo. mx si su MX apunta a un servicio que ya figura con un include en su registro.
2. Utilice un subdominio. Haga que un servicio envíe desde nieuws.example.com o factuur.example.com. Ese subdominio tendrá su propio registro SPF solo con ese servicio, y no contará para las diez consultas de su dominio principal. La alineación en DMARC (lección 4.4) también funciona por defecto para subdominios.
3. Utilice ip4: e ip6: para sus propios servidores fijos. Estos no cuestan ninguna consulta. Hágalo solo con direcciones que usted administre y que no cambien.
4. Flattening (sustituir todos los includes por las direcciones IP que hay actualmente detrás). Esto reduce el número a 0, pero el registro deja de ser correcto en cuanto un servicio cambie sus direcciones, y los grandes servicios lo hacen con regularidad. Hágalo solo con una herramienta que lo mantenga actualizado automáticamente, y preferiblemente no lo haga en absoluto.

¿redirect o include?

redirect= indica: utilice el registro SPF de ese otro dominio en lugar de este registro. Cuesta una consulta, igual que un include. Resulta útil si tiene muchos dominios que deben recibir exactamente la misma política: v=spf1 redirect=_spf.example.com en cada dominio, y el registro real en un único lugar. Un registro con redirect= no puede tener all, porque entonces se ignora el redirect. El propio Gmail lo utiliza: gmail.com tiene v=spf1 redirect=_spf.google.com.

Paso 4: ¿~all o -all?

La recomendación de este curso, igual que en el curso de DNS:

• Empiece con ~all (softfail). El correo de un servidor que no figure en su registro se considerará sospechoso, pero normalmente no se rechazará de inmediato. Si olvida un remitente, el daño será limitado.
• Pase a -all (fail) cuando esté seguro de que todos los remitentes están incluidos, por ejemplo después de haber revisado los informes DMARC durante varias semanas y comprobar que ya no aparecen fuentes desconocidas.

Con DMARC presente, la diferencia es menor de lo que a menudo se piensa. DMARC decide en función de «SPF o DKIM superado y alineado». Un softfail es, para DMARC, simplemente «no superado». La verdadera protección proviene por tanto de una política DMARC estricta, no de -all. Algunos destinatarios rechazan ya con -all antes incluso de la evaluación DMARC; eso es un motivo para elegir -all solo cuando su registro esté realmente completo.

Un dominio que nunca envía correo

¿Tiene dominios que nunca envían correo (un nombre de marca antiguo, un dominio de errata)? Protéjalos entonces frente a usos indebidos con:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Aquí -all es correcto desde el principio: nadie tiene permiso para enviar correo. La última línea es un null MX (RFC 7505): «este dominio no recibe correo». El propio example.com está configurado exactamente así.

En la práctica: así se ve en un panel

En un paquete de hosting de WebOké figura por defecto v=spf1 a mx include:webawere.nl ~all. Si añade un servicio, modifique ese registro (en DirectAdmin: Gestión DNS, el lápiz junto al registro SPF, campo Incluir Dominio; en Mi WebOké: el asistente de SPF en la pestaña DNS). Mantenga include:webawere.nl mientras su correo o su sitio web funcionen a través de esos servidores. En otros proveedores el include por defecto se llama de otra forma, pero el principio es el mismo: ampliar, no crear un segundo registro.

Resumen

• Haga primero un inventario de todos los remitentes; los informes DMARC y las cabeceras ayudan con ello.
• Un servicio con un Return-Path propio no pertenece a su SPF; necesita DKIM con su dominio.
• Cuente de forma recursiva: cada include, a, mx, exists, ptr y redirect, también dentro de los includes. Por encima de diez, o más de dos consultas vacías, se produce un permerror.
• Vuelva a bajar de diez haciendo limpieza y usando subdominios; el flattening solo con mantenimiento automático.
• Empiece con ~all, pase a -all cuando esté seguro. Dominios que nunca envían correo: -all, DMARC reject y null MX.

Cuestionario

Ejercicio

Ejercicio Z4.2: Contar el SPF de su dominio de forma recursiva. Introduzca su propio dominio (o sidn.nl si no tiene dominio propio). Cuente primero usted mismo cuántas consultas DNS cuesta el registro SPF, incluido todo lo que hay dentro de los includes, e introduzca el número, junto con el final del registro (~all, -all, ?all o +all). El programa lo comprueba en directo, incluidas las consultas vacías, y muestra el árbol.

Ejercicio O4.2: Su inventario de remitentes. Con la tabla de esta lección, elabore una lista de todos los sistemas que envían correo en nombre de su dominio. Anote para cada uno: a través de qué servidor o servicio, si debe figurar en su SPF (Return-Path propio o no), y si firma con DKIM usando su dominio. Envíese un correo de prueba desde al menos dos sistemas y anote, a partir de las cabeceras, el dominio del Return-Path y el dominio DKIM (d=).

Para saber más

Los pasos de estos artículos se refieren a los paneles de WebOké; en otros proveedores el funcionamiento es parecido.

• Curso gratuito de DNS 4.3: SPF: ¿quién puede enviar correo en nombre de su dominio?
• Manual de DirectAdmin 5.7: Configurar y ampliar el SPF
• ¿Cómo funciona el registro SPF en el DNS?
• Añadir o modificar un registro SPF en DirectAdmin
• Manual de WebOké 5.5: Asistentes DNS: MX, SPF, DMARC, CAA y SRV
• RFC 7208 (SPF), apartado 4.6.4 (límites) y 6.1 (redirect); RFC 7505 (null MX)