SPF, DKIM y DMARC explicados: por qué importa la alineación

SPF dice qué servidores pueden enviar en nombre de tu dominio. DKIM firma criptográficamente el mensaje para que el destino compruebe que nadie lo ha tocado. DMARC no comprueba ninguna de las dos cosas: comprueba que al menos una de ellas pase y además esté alineada con el dominio que el usuario ve en el remitente. Esa última palabra, alineada, es la que explica por qué un dominio puede tener SPF y DKIM en verde en cualquier comprobador y fallar DMARC en el cien por cien de sus envíos.

Los tres son registros TXT en el DNS de tu dominio. Son públicos: cualquiera puede leerlos, incluido tú, con un comando en un terminal. Esta guía explica qué hace cada uno, dónde se rompen en la práctica y cómo se comprueba la alineación mirando un correo real.

SPF: quién puede enviar por ti

Un registro SPF es una lista de servidores autorizados. El destino mira de qué IP le llega el mensaje y comprueba si está en la lista. Un SPF sano se parece a esto:

; correo corporativo (Google Workspace)
empresa.es.            TXT "v=spf1 include:_spf.google.com -all"

; transaccional (Amazon SES)
mail.empresa.es.       TXT "v=spf1 include:amazonses.com -all"

; campañas (SMTP2GO)
news.empresa.es.       TXT "v=spf1 include:spf.smtp2go.com -all"

SPF tiene dos límites que hunden más dominios que ninguna otra cosa. El primero es el de diez consultas DNS: el RFC 7208 obliga a limitar a diez los términos que resuelven nombres durante la evaluación. Cuentan include, a, mx, ptr, exists y el modificador redirect. No cuentan ip4, ip6, all ni exp. Cada herramienta de marketing que añades suele traer su include, y el día que se pasa de diez el resultado es permerror, que la mayoría de receptores trata como fallo de SPF. Es la causa número uno de "de repente dejó de llegar".

El segundo es el de las consultas vacías. El mismo RFC dice que las implementaciones deberían limitar a dos las void lookups, es decir, las consultas que no devuelven nada o dan NXDOMAIN. Dos include apuntando a servicios que ya no existen bastan para tumbar el SPF entero. Por eso una auditoría empieza podando: en un dominio con cinco años de vida es normal encontrar tres o cuatro include fósiles. Además, el registro debería caber en 512 octetos, con cada cadena TXT por debajo de 255 bytes.

Sobre el final del registro: ~all (softfail) es lo correcto mientras despliegas y mientras haya reenvíos sin ARC. El objetivo es -all (hardfail), pero solo aporta seguridad real si DMARC está en enforcement, porque con DMARC en reject es DMARC quien decide. Recomendación de producto: -all en los subdominios de envío controlado, ~all en el dominio corporativo donde la gente reenvía correo a su Gmail.

DKIM: la firma que viaja con el mensaje

DKIM firma unas cabeceras concretas y el cuerpo con una clave privada que solo tiene tu servidor de salida. La clave pública se publica en el DNS bajo un selector, y el destino la busca ahí para verificar. A diferencia de SPF, la firma sobrevive a los reenvíos mientras nadie modifique el mensaje.

sel2026a._domainkey.empresa.es. IN TXT ( "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                          "...IDAQAB" )

Longitud de clave

El RFC 8301 obliga a un mínimo de 1024 bits y recomienda 2048. Google exige el mínimo y recomienda lo mismo; Yahoo también fija 1024 como mínimo. La decisión sensata hoy es 2048 siempre.

Algoritmo

El RFC 8301 es taxativo: hay que firmar con rsa-sha256, y rsa-sha1 no debe usarse ni para firmar ni para verificar. Un selector con sha1 activo es un hallazgo, no un detalle.

Nombre del selector

M3AAWG recomienda que el selector diga a qué flujo pertenece, cuándo entra en servicio y de cuántos bits es, y desaconseja con fuerza reutilizar nombres. Una convención que funciona: camp-202608-2048, txn-202608-2048.

Qué cabeceras firmar (el tag h=)

Como mínimo From, To, Subject, Date, Message-ID, MIME-Version, Content-Type y Reply-To. Y obligatoriamente List-Unsubscribe y List-Unsubscribe-Post si envías comercial: lo exige el RFC 8058, y si no están cubiertas por la firma, Gmail no muestra el botón nativo de baja.

Canonicalización

relaxed/relaxed. La opción simple/simple se rompe en cuanto algo por el camino reescribe una cabecera, que es lo normal.

La rotación de claves tiene una referencia clara: el documento de buenas prácticas de M3AAWG, que en su actualización de 2019 pasó la recomendación de trimestral a semestral y propone abril y octubre como meses razonables. El procedimiento importa tanto como el calendario: se tienen siempre dos pares publicados, uno firmando y otro esperando; para rotar se publica el siguiente, se espera a la propagación y solo entonces se cambia el servidor de firma. La clave anterior se mantiene en el DNS entre siete y treinta días y después se retira dejando el campo p vacío, sin borrar la entrada del selector.

DMARC: lo que de verdad comprueba

Aquí está el malentendido que sostiene medio sector. DMARC no comprueba SPF y DKIM. DMARC comprueba que al menos uno de los dos pase y esté alineado con el dominio de la cabecera From, que es la única que ve el destinatario. Si los dos pasan pero ninguno alinea, DMARC falla.

Alineación SPF

Se compara el dominio del Return-Path (el remitente del sobre, MAIL FROM) con el dominio del From. Son dos cosas distintas y casi nadie mira la primera.

Alineación DKIM

Se compara el dominio del tag d= de la firma con el dominio del From. Una firma perfectamente válida con d= del proveedor no alinea con tu dominio.

Relajada frente a estricta

Por defecto la alineación es relajada (aspf=r, adkim=r) y basta con compartir dominio organizacional: news.empresa.es alinea con empresa.es. En modo estricto (s) la coincidencia debe ser exacta.

Yahoo lo dice con las mismas palabras y Microsoft exige DMARC válido más alineación por SPF o por DKIM para no rechazar con 550 5.7.515. Los tres piden lo mismo, y por eso la alineación no es un detalle de purista: es el requisito.

El fallo clásico: verde, verde, y DMARC al cero

El patrón se repite en casi todas las auditorías de una PYME española. La empresa contrata una herramienta de campañas. La herramienta pone su propio Return-Path (algo como bounces.proveedor.com) para gestionar los rebotes, así que SPF pasa, pero pasa para el dominio del proveedor: no alinea. Y si además la firma DKIM la pone el proveedor con d=proveedor.com en vez de con el dominio del cliente, tampoco alinea por ahí. Resultado: SPF verde, DKIM verde, DMARC fallando en el cien por cien de los mensajes.

Cómo se lee un informe DMARC de verdad

Cuando publicas un rua, los receptores te mandan a diario un XML comprimido que resume, por IP de origen, cuántos mensajes vieron y qué pasó con ellos. No contienen contenido ni destinatarios. Este es el fragmento que hay que saber leer:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>1420</count>
    <policy_evaluated>
      <disposition>none</disposition>   <!-- qué se hizo con el mensaje -->
      <dkim>fail</dkim>                 <!-- ALINEACIÓN, no validez -->
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>empresa.es</header_from></identifiers>
  <auth_results>
    <dkim><domain>proveedor.com</domain><result>pass</result></dkim>  <!-- firma válida... -->
    <spf><domain>empresa.es</domain><result>pass</result></spf>
  </auth_results>
</record>

Con los informes en la mano, cada IP que envía en tu nombre se clasifica en uno de cuatro cubos: legítima y alineada (nada que hacer), legítima y no alineada (hay que arreglarla), reenvíos (volumen bajo, muchas IP distintas, SPF fail con DKIM pass: es normal y lo mitiga ARC) y suplantación (sin autenticación de ningún tipo, que es la razón por la que se acaba subiendo a reject). La regla de oro: no se sube de escalón mientras el segundo cubo tenga volumen material.

Compruébalo tú mismo en tres minutos

dig +short TXT empresa.es | grep spf1
dig +short TXT _dmarc.empresa.es
dig +short TXT sel2026a._domainkey.empresa.es
dig +short MX empresa.es

La alineación no se ve en el DNS, se ve en un mensaje. Abre en Gmail un correo enviado por ti, usa "Mostrar original" y busca la cabecera Authentication-Results. Ahí está el veredicto de los tres, y el que manda es el último:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@proveedor.com header.s=sel1;
       spf=pass (google.com: domain of bounces.proveedor.com designates 203.0.113.10) smtp.mailfrom=bounces.proveedor.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=empresa.es

El orden correcto de trabajo

1. Inventario de emisores: quién envía hoy en nombre del dominio. Suele haber tres o cuatro más de los que la empresa recuerda.
2. Un SPF por flujo, corto, sin fósiles y por debajo de las diez consultas. Si no cabe, se segmenta por subdominio, no se aplana a mano.
3. DKIM de 2048 bits firmando con el dominio del cliente en cada proveedor, con el h= cubriendo las cabeceras de baja.
4. DMARC en p=none con rua a un buzón que alguien lea de verdad. Publicar un rua que nadie procesa es no tener DMARC.
5. Leer informes durante semanas, cerrar el cubo de los legítimos no alineados y solo entonces empezar a subir la política.

Ese último paso es una guía entera, porque desde mayo de 2026 se hace de otra manera: la revisión de DMARC eliminó el tag pct y con él el runbook clásico de subir por porcentajes. Cómo se llega hoy a p=reject sin perder correo legítimo está en la guía de DMARC sin romper nada.