La autenticación de remitente tiene un modo de fallo poco habitual: los registros son correctos, los verificadores en línea coinciden en que son correctos, y el mensaje se sigue tratando como no autenticado. Ocurre porque los verificadores comprueban lo que publicaste y el receptor comprueba la relación entre eso que publicaste y el mensaje. Son preguntas distintas. Abajo hay cuatro maneras en que hemos visto responder que no a la segunda mientras se respondía que sí a la primera, sacadas de configurar esto en dominios que no son nuestros.
01Lo que se comprueba es la alineación, no el registro
Un registro SPF publicado demuestra que algún servidor puede enviar por algún dominio. Una firma DKIM válida demuestra que alguna clave firmó el mensaje. Ninguno de los dos dice que ese dominio sea el que el destinatario ve en la cabecera From, y eso es lo único que evalúa DMARC.
Así que hay dos dominios en cada mensaje y la mayoría de las herramientas solo te enseña uno. El dominio From visible es lo que lee el destinatario. El dominio del Return-Path, contra el que realmente se comprueba SPF, lo fija quien envía, y por defecto es tu proveedor. Un mensaje puede pasar SPF de forma impecable contra un nombre de host del proveedor mientras DMARC registra un fallo, porque SPF pasó para un dominio que no es el tuyo.
DMARC solo necesita una de las dos alineaciones, y esa es la parte que conviene interiorizar. Alineación SPF mediante un Return-Path propio, o alineación DKIM mediante una firma que lleve tu dominio: cualquiera de las dos basta. Por eso un dominio puede mostrar SPF en verde y fallar igualmente, y por eso arreglar DKIM resuelve a menudo un problema que parecía de SPF.
02El CNAME con proxy que responde la dirección equivocada
Este es el que más tiempo nos ha costado y produce el falso éxito más convincente de los cuatro. Los registros de autenticación suelen ser CNAME hacia la zona de un proveedor. En un DNS con proxy, un CNAME puede marcarse para que el tráfico pase por el proxy, y un registro con proxy no responde el objetivo. Responde las direcciones del borde, porque ese es exactamente su propósito.
Para un sitio web ese es el comportamiento correcto y la razón por la que se usa. Para un selector DKIM es fatal de una forma muy concreta: la consulta tiene éxito. El nombre resuelve, algo responde, nada informa de un error. Lo que vuelve es un registro de dirección donde se esperaba una clave, así que el verificador no encuentra clave alguna y trata el mensaje como no firmado. Nada en esa secuencia parece un error de configuración desde fuera.
Sigue pasando porque el valor por defecto está pensado para el caso común. Casi todos los registros que se añaden a una zona son para un sitio, y la interfaz ofrece el proxy porque suele ser lo que se quiere. Los registros de autenticación son la excepción, y los añade alguien siguiendo instrucciones que no dicen nada de una opción que inventó su proveedor de DNS.
03El selector que te dieron ya está en uso
Un selector DKIM es una etiqueta que permite a un mismo dominio tener varias claves a la vez. Los proveedores eligen uno por defecto y lo reutilizan en todas las cuentas que han abierto jamás, lo cual no da problemas hasta que un dominio tiene dos relaciones con el mismo proveedor.
Uno de los dominios que autenticamos es un ejemplo vivo. Su proveedor asigna s1 y s2 por defecto, y los dos ya están publicados ahí por una cuenta anterior a la nuestra. Si hubiéramos aceptado el valor por defecto, nuestros registros habrían chocado con registros en funcionamiento de un dominio que no controlamos, y el fallo habría llegado en forma de correo roto para otra persona. Usamos un selector distinto exactamente por eso.
Hay una segunda trampa dentro de la primera y solo aparece cuando se emite la segunda clave. Es habitual que los proveedores deriven el segundo selector añadiendo un dígito al primero. Elige un selector que ya termine en dígito y la pareja que obtienes no es la que esperabas. Escogimos un nombre sin dígito final después de confirmar ese comportamiento contra la API real y no contra la documentación.
- Consulta los selectores por defecto del proveedor sobre el dominio antes de añadir nada. Unos registros existentes indican una relación existente de la que nadie te habló.
- No des por hecho que un dominio tiene un solo proveedor de correo. Marketing, transaccional, soporte y un contrato heredado son cuatro relaciones y a menudo cuatro proveedores.
- Elige un selector que identifique al remitente, no al año ni al número de orden. Queda legible en el DNS para cualquiera que audite esa zona más adelante.
04Apuntar al host del proveedor lo convierte en su registro, no en el tuyo
Este no es un fallo del mismo día, es un fallo dieciocho meses después, y es la razón por la que nuestros registros no se parecen a los que reparte la mayoría de los servicios.
Un proveedor te da CNAME hacia su propia zona y lo evidente es pasárselos al cliente tal cual. Funciona de inmediato. También coloca un nombre de host del proveedor dentro de una zona que no controlas, una vez por cliente. Cambiar de proveedor significa entonces pedir a cada cliente que edite su DNS, lo que en la práctica significa que una parte no lo hará nunca y dejará de autenticar sin avisar.
Por eso apuntamos los registros del cliente a nombres de host nuestros, y esos apuntan al proveedor. El salto extra cuesta una consulta y convierte una migración en tres registros de una zona que sí es nuestra, en lugar de un correo masivo. Una cadena real se lee como el selector del cliente, luego nuestro alias, luego el destino del proveedor, que es lo mismo que hace cualquier CNAME de proveedor con una indirección añadida en el único punto donde ayuda.
El precio de ese diseño es una forma nueva de equivocarse, y conviene nombrarla en vez de esconderla. Los destinos del proveedor contienen identificadores asignados, no garantizados, entre ellos un identificador de grupo que puede cambiar. Si cambia, nuestros alias apuntan a algo inútil y todos los clientes dejan de autenticar a la vez, en silencio, porque los registros siguen resolviendo. Vigilamos esa deriva de forma periódica por la misma razón que vigilamos todo lo demás: el fallo es invisible desde dentro.
05El clic único es una decisión del proveedor, no un estándar
Pedirle a un cliente que añada tres registros es donde se atasca la incorporación, y la respuesta estándar es Domain Connect: se envía al cliente a su propio proveedor de DNS, ese proveedor lo autentica, le enseña los registros y los escribe si acepta. Nadie le entrega credenciales a nadie.
Lo fácil de malinterpretar es qué consigues al publicar una plantilla. Que se integre en el repositorio público de plantillas es necesario y no suficiente, porque los proveedores adoptan las plantillas una por una. Una plantilla puede ser pública y correcta durante años sin que un proveedor de DNS concreto la haya servido nunca.
La plantilla de un proveedor de envío muy conocido está integrada desde 2022. Consultarla hoy en un proveedor de DNS grande devuelve un 404, lo que significa que todos los clientes de ese proveedor siguen añadiendo esos registros a mano. Lo comprobamos antes de suponerlo, porque suponerlo habría sido enseñar a los clientes un botón que no lleva a ninguna parte.
Esa es la forma general de todo lo anterior. Pregunta al proveedor si sirve la plantilla antes de ofrecer el botón. Resuelve el registro y lee su tipo antes de creerte la interfaz. Consulta el selector sobre el dominio antes de aceptar un valor por defecto. En todos los casos la comprobación es una consulta, y saltársela produce un sistema que informa de éxito sin entregar nada.
El resumen es que la autenticación es una relación entre un mensaje y un dominio, y todos los fallos de arriba son una ruptura de esa relación y no un error en un registro. Por eso los registros parecen correctos. Lo son. Simplemente no están conectados con aquello que se comprueba, y la única manera fiable de descubrirlo es resolver lo que publicaste y leer lo que vuelve de verdad.