SPF, DKIM y DMARC: qué comprueba cada registro y cómo se configura

SPF, DKIM y DMARC son tres registros TXT en el DNS de su dominio que permiten a un servidor receptor decidir si un mensaje que dice venir de usted vino realmente de usted. Son mecanismos distintos, responden preguntas distintas, fallan de maneras distintas — y el orden en que los añade importa más de lo que admiten casi todas las guías.

¿Qué demuestran realmente SPF, DKIM y DMARC?

Tres afirmaciones diferentes, comprobadas por separado.

SPF es la lista de servidores autorizados a enviar correo en nombre de su dominio. El receptor toma la dirección IP del servidor emisor y pregunta si su dominio la autorizó.

DKIM es una firma criptográfica sobre el mensaje. El servidor emisor firma un conjunto de encabezados y el cuerpo con una clave privada; el receptor obtiene la clave pública correspondiente de su DNS y verifica que nada de lo firmado haya cambiado por el camino.

DMARC es la política que va encima. Indica a los receptores qué hacer cuando las dos primeras fallan, y añade un requisito que ninguna de ellas impone por su cuenta: el dominio que autenticaron SPF o DKIM tiene que coincidir con el dominio que una persona ve en el encabezado From:. Esa es toda la cuestión. Sin eso, cualquiera puede pasar SPF con un dominio propio y poner su dirección en la línea From:.

¿Qué se pone en un registro SPF?

Un único registro TXT en la raíz del dominio, que empieza por v=spf1 y termina en un mecanismo all:

example.com.  IN  TXT  "v=spf1 include:_spf.provider.net -all"

En la práctica, SPF se rompe por cuatro motivos.

Dos registros. Un dominio puede publicar exactamente un registro v=spf1. Con dos, la evaluación devuelve permerror, que cuenta como fallo. Dos proveedores significan un registro con dos términos include:.

El límite de diez consultas. Cada término include:, a, mx, ptr y exists cuesta una consulta DNS, y los includes anidados también cuentan. Pasadas las diez, el resultado es permerror. Las cadenas largas de includes de proveedores rebasan ese límite sin hacer ruido.

El all equivocado. -all pide a los receptores que rechacen todo lo que venga de un servidor no listado. ~all es un softfail, que la mayoría de receptores acepta y marca. Empiece con ~all y apriete cuando los informes estén limpios.

El reenvío. SPF autentica el remitente del sobre, en el Return-Path, no el encabezado From:. Un mensaje reenviado llega desde el servidor de quien lo reenvía, que su registro no lista, así que SPF falla sin que el registro tenga nada malo.

¿Cómo funciona la firma DKIM?

El servidor emisor genera un par de claves. La mitad privada se queda en el servidor; la pública va al DNS bajo un selector que usted elige:

sel1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Al salir, el servidor calcula el hash del cuerpo y de un conjunto elegido de encabezados, lo firma y adjunta un encabezado DKIM-Signature que nombra el dominio en d= y el selector en s=. El receptor lee esos dos campos, obtiene <selector>._domainkey.<domain> y verifica.

El selector existe para que pueda mantener más de una clave a la vez, y eso es lo que hace posible la rotación: publicar la clave nueva, cambiar la firma a ella y retirar el registro antiguo cuando ya no se firme nada con él.

DKIM sobrevive al reenvío, cosa que SPF no hace, porque la firma viaja con el mensaje. Se rompe cuando algo reescribe por el camino las partes firmadas — las listas de correo que añaden un pie o cambian el asunto son el caso habitual.

¿Qué decide una política DMARC?

Un registro TXT en el subdominio _dmarc:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

p es la instrucción para los receptores: none para no hacer nada más que informar, quarantine para tratar los fallos como sospechosos, reject para rechazarlos sin más. rua es la dirección a la que llegan los informes agregados, y es la razón para publicar el registro mucho antes de aplicar nada.

DMARC pasa cuando SPF pasa y su dominio se alinea con el del From:, o cuando DKIM pasa y su d= se alinea. Con uno basta. La alineación es relajada por defecto: tienen que coincidir los dominios organizativos, de modo que mail.example.com se alinea con example.com. La alineación estricta exige que sean idénticos.

¿En qué orden hay que añadirlos?

Primero MX, luego SPF y DKIM, luego DMARC en p=none, y por último la aplicación — y el intervalo entre los dos últimos se mide en semanas, no en minutos.

1. MX. El correo tiene que llegar antes de que autenticarlo signifique algo.
2. SPF y DKIM juntos. Ambos solo suman y ninguno rechaza correo por su cuenta.
3. DMARC en p=none con una dirección rua. Nada cambia para los destinatarios; empiezan a llegar los informes.
4. Leer los informes. Nombrarán remitentes que usted había olvidado: el sistema de facturación, el CRM, las alertas de monitorización, aquello en lo que se dio de alta el equipo de marketing. Cada uno de ellos entra en SPF, empieza a firmar con DKIM, o deja de usar su dominio.
5. p=quarantine, después p=reject. Cambie cuando los informes solo muestren fallos que reconozca como falsificaciones.

Publicar p=reject antes de leer los informes es la forma clásica de hacer desaparecer correo legítimo. Los fallos son silenciosos para usted e invisibles para quien envía.

¿Cómo se comprueba que los registros están bien?

Consúltelos igual que lo hace un receptor:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT sel1._domainkey.example.com
dig +short TXT _dmarc.example.com

Después envíe un mensaje real a una cuenta de otro proveedor y lea el encabezado Authentication-Results con el que llega. Ese encabezado es el veredicto del receptor sobre las tres comprobaciones, alineación incluida, que es lo que no le dirá ninguna lectura de su propio DNS:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Fíjese sobre todo en header.d y header.from. Cuando esos dos no coinciden, DMARC falla por muy verdes que se vean las demás líneas.

¿Qué no hacen estos registros?

Autentican un dominio. No dicen nada del contenido de un mensaje ni del cifrado.

Un mensaje puede pasar las tres comprobaciones y seguir siendo un fraude, siempre que sea un fraude honesto sobre qué dominio lo envió — los atacantes registran dominios parecidos y publican para ellos registros impecables. Estos registros tampoco cifran nada: la seguridad del transporte es TLS entre saltos, y si el mensaje está cifrado allí donde queda guardado es otra pregunta con otra respuesta.

Lo que sí corrigen es el tipo de falsificación que pone su dominio exacto en la línea From:. Antes salía gratis, y después de p=reject ya no.