SPF, DKIM y DMARC explicados para responsables de empresa

SPF, DKIM y DMARC son 3 registros DNS que indican al resto de internet qué servidores pueden enviar correo en nombre de su dominio y qué hacer con el correo que no supera esas comprobaciones. SPF enumera los remitentes permitidos, DKIM añade una firma criptográfica a cada mensaje y DMARC vincula ambos a la dirección que la gente ve realmente en el campo From y fija una política para los fallos.

Sin ellos, cualquiera puede enviar un mensaje que diga From: billing@yourcompany.com, y muchos proveedores de correo tienen pocos motivos para dudarlo. Con ellos bien configurados, un mensaje falsificado no supera la autenticación y puede rechazarse o enviarse a spam antes de que su cliente lo lea.

La buena noticia: los 3 son registros DNS que cualquiera puede consultar, así que puede revisar los suyos en pocos minutos con los comandos que verá más abajo.

SPF: quién puede enviar en nombre de su dominio

SPF (Sender Policy Framework, RFC 7208) es un registro TXT de su dominio que enumera los servidores y servicios autorizados a enviar correo en su nombre. Un registro típico tiene este aspecto:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Lo más importante es el final:

• -all (fail): todo lo que no aparece en la lista no está autorizado.
• ~all (softfail): todo lo que no aparece en la lista es sospechoso.
• ?all (neutral): el registro no expresa ninguna opinión, lo que apenas da información a los receptores.
• +all: cualquier servidor de internet puede enviar en su nombre. Esto nunca es correcto.

SPF tiene además un límite estricto: un receptor que evalúa su registro puede realizar como máximo 10 consultas DNS para mecanismos como include, a, mx y redirect (RFC 7208, sección 4.6.4). Cada nueva herramienta de marketing añade un include y, cuando la cuenta supera 10, SPF devuelve un error en lugar de un resultado correcto.

DKIM: una firma en cada mensaje

Con DKIM (DomainKeys Identified Mail, RFC 6376), el servidor de envío firma cada mensaje con una clave privada. La clave pública correspondiente está en DNS bajo un nombre de selector, de modo que los receptores pueden confirmar que el mensaje no se ha alterado y que lo firmó alguien que posee su clave.

Cada servicio que envía en su nombre (su proveedor de correo, su CRM, su herramienta de facturación) debería firmar con su propio selector. El registro DNS tiene este aspecto:

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

DKIM falla en silencio. El correo sigue saliendo sin firmar y nadie se da cuenta hasta que los mensajes empiezan a llegar a spam o un proveedor endurece sus reglas.

DMARC: la política que lo une todo

DMARC se define ahora en el RFC 9989, publicado en mayo de 2026, que sustituyó al antiguo RFC 7489. Comprueba si SPF o DKIM se superaron para un dominio que coincide (está alineado) con la dirección From visible, e indica a los receptores qué hacer cuando ninguno lo consigue:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

• p=none: solo supervisión. El correo que falla se entrega con normalidad; usted solo recibe informes.
• p=quarantine: el correo que falla debe tratarse como sospechoso, normalmente enviándolo a spam.
• p=reject: el correo que falla debe rechazarse.

La dirección rua recibe informes agregados de los grandes proveedores de correo. Esos informes muestran todas las fuentes que envían correo en su nombre, incluidas las que había olvidado y las que no son suyas.

Cómo revisar su propio dominio

Ejecute estos comandos desde cualquier terminal (sustituya example.com por su dominio):

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

Para DKIM necesita el nombre del selector. Abra cualquier correo que haya enviado su empresa, vea el código fuente original del mensaje y busque DKIM-Signature: y su valor s=. Las mismas cabeceras muestran también Authentication-Results: con spf=pass, dkim=pass y dmarc=pass, o los fallos.

Qué debe buscar:

1. Exactamente un registro SPF (2 registros v=spf1 invalidan SPF por completo).
2. Un final de SPF ~all o -all, no ?all ni +all.
3. Una firma DKIM en el correo de cada servicio que envía en su nombre.
4. Un registro DMARC que exista y tenga una dirección rua que alguien lea de verdad.
5. Un plan para pasar de p=none a p=quarantine o p=reject.

Errores habituales y cómo corregirlos

2 registros SPF. Suelen quedarse tras un cambio de proveedor. Únalos en un solo registro.

Demasiadas consultas. Elimine los servicios que ya no usa y sustituya los includes por los rangos concretos cuando su proveedor lo permita.

Remitentes olvidados. Una herramienta de newsletters o de atención al cliente que envía sin DKIM fallará en DMARC en cuanto lo aplique. Lea primero sus informes DMARC durante unas semanas y después active DKIM para cada fuente legítima.

Quedarse en p=none para siempre. La supervisión es el primer paso correcto, pero p=none pide a los receptores que entreguen igualmente el correo falsificado. Cuando los informes muestren que todo el correo real pasa, avance a p=quarantine y después a p=reject.

Dominios aparcados y sin uso. Un dominio que nunca envía correo también puede falsificarse. Publique en él v=spf1 -all y un registro DMARC con p=reject.

Estos registros también influyen en la entrega. Gmail, Yahoo y Outlook los exigen ya a los remitentes de gran volumen, tema que tratamos en los requisitos de Gmail y Yahoo para remitentes. Y son una capa de defensa frente a las estafas de facturas falsas que describimos en cómo funciona el compromiso del correo empresarial.

Lista de comprobación breve

• Un solo registro SPF, terminado en ~all o -all, con menos de 10 consultas.
• Firma DKIM activada en cada servicio que envía en su nombre.
• DMARC publicado, con informes dirigidos a un buzón que alguien revisa.
• Política que avanza hacia p=reject cuando los informes están limpios.
• Dominios aparcados protegidos con -all y p=reject.

Cómo le ayuda Datahorses

La autenticación del correo es una de las áreas que vigilamos desde fuera todos los días, junto con sus dominios, certificados y sitio web. Cuando cambia un registro SPF, desaparece un selector DKIM o se debilita DMARC, una persona lo revisa y usted recibe los registros exactos que hay que corregir. Puede ver la lista completa en lo que vigilamos, y por qué no necesitamos ningún acceso a sus sistemas. Para una visión más amplia, lea qué es la vigilancia de la superficie de ataque externa.