SPF, DKIM y DMARC leídos en registros

SPF (RFC 7208) es un registro TXT donde el dominio lista qué direcciones pueden enviar correo en su nombre. El receptor compara la dirección IP que se conectó con esa lista, usando el dominio del sobre del mensaje (el MAIL FROM, a donde irían los rebotes) o, si no hay, el del saludo HELO. Cada mecanismo puede llevar un calificador: + pasa, - falla, ~ falla suave (softfail) y ? neutral.

SPF no mira el dominio que la persona ve en la cabecera From. Por eso un mensaje puede pasar SPF y aun así mostrar un remitente que no es el del sobre.

DKIM (RFC 6376) funciona con una firma: el servidor emisor firma ciertas cabeceras y el cuerpo, y añade la firma en una cabecera DKIM-Signature que nombra un dominio (d=) y un selector (s=). El receptor busca la clave pública en el DNS, en el nombre selector._domainkey.dominio, y comprueba la firma. Si el contenido cambió, la firma deja de coincidir.

El selector permite tener varias claves a la vez (por servicio, o para rotarlas). Leerlo en el DNS dice qué claves existen hoy; una firma cuyo selector no tiene clave publicada no se puede verificar.

Consulta registros_txt y busca el nombre que contiene _domainkey.

Para evaluar un SPF, el receptor hace consultas DNS adicionales, y la norma limita a 10 el total de términos que las provocan. Cuentan include, a, mx, ptr y exists, y el modificador redirect. No cuentan ip4, ip6 ni all. Superar el límite hace que el resultado sea un error permanente y el SPF deje de valer, por eso los registros que van sumando servicios (un include por cada proveedor) se vuelven frágiles.

Cuenta solo los términos del registro de la empresa, sin entrar en lo que cada include contenga por dentro.

DMARC exige algo que SPF y DKIM por separado no exigen: la alineación. Para pasar, el mensaje necesita que SPF o DKIM pasen y que el dominio que validaron coincida con el dominio de la cabecera From. Con adkim=r y aspf=r (modo relajado) basta con que pertenezcan al mismo dominio de organización.

Es la forma típica en que un servicio externo, que envía con su propio dominio de sobre y su propia firma, falla DMARC aunque sus dos comprobaciones salgan en pass. Mira mensajes y compara from_cabecera con mail_from y con dkim_d.

El registro _dmarc publica la política: con p=none el dominio pide al receptor que no haga nada especial con lo que falla (solo informar); quarantine pide tratarlo como sospechoso y reject pide rechazarlo. La etiqueta rua dice a qué dirección enviar los informes agregados. Un dominio con p=none está observando, no protegiéndose: nadie le bloquea la suplantación.

La especificación de DMARC se actualizó en 2026 (RFC 9989, que sustituye al RFC 7489, con los informes en el RFC 9990); la idea de política, alineación e informes se mantiene.