SPF, DKIM y DMARC explicados: quién puede enviar correo en su nombre

Un cliente recibe un correo desde la dirección de su empresa. El logotipo es el correcto, la firma también, y lleva una factura adjunta. Lo único distinto es el número de cuenta bancaria. El cliente paga, y usted se entera dos semanas después, cuando le pregunta por qué le ha enviado un recordatorio de pago por algo que ya abonó.

Poner la dirección de otra persona en el campo «De» es técnicamente trivial. El correo electrónico se diseñó en una época en la que nadie esperaba que la gente se hiciera pasar por otros. Las protecciones con los nombres cortos SPF, DKIM y DMARC se añadieron después, para que los servidores de correo pudieran comprobar si un mensaje venía realmente de usted. Pero solo funcionan cuando alguien las configura en su dominio.

Las tres protecciones en palabras sencillas

Las tres son registros en el DNS de su dominio, el mismo lugar donde alguien indica a qué servidor apunta su sitio web. No se instala nada en el ordenador de nadie.

SPF es una lista de invitados. Dice: el correo de mi dominio pueden enviarlo estos servidores y ningún otro. La lista debe incluir su correo de empresa, su programa de facturación, su herramienta de boletines y cualquier otra cosa que envíe correo con su dirección. Un registro tiene más o menos este aspecto: v=spf1 include:_spf.google.com ~all.

DKIM es un sello. Su servidor de correo firma cada mensaje que sale, y la clave para comprobar esa firma está en el DNS. Así el destinatario puede confirmar que el mensaje vino de usted y que nadie lo modificó por el camino.

DMARC es una instrucción para el destinatario. Indica qué hacer con un mensaje que dice venir de usted pero no supera las comprobaciones. También comprueba algo que SPF por sí solo no comprueba: si el dominio confirmado por SPF o DKIM coincide con la dirección que el cliente ve realmente en el campo «De». Sin eso, un estafador puede superar SPF con su propio dominio y seguir mostrando el suyo en pantalla. DMARC también puede pedir a los servidores receptores que le envíen informes, para que sepa quién envía correo en su nombre. El registro va en _dmarc.sudominio.com.

Hay un segundo motivo para ocuparse de esto. Desde 2024 Gmail y Yahoo, y desde 2025 Microsoft para los buzones de Outlook.com, exigen a los remitentes masivos SPF y DKIM que funcionen y al menos un registro DMARC básico. Así que la falta de registros perjudica también a su correo legítimo.

Cómo comprobar si su dominio los tiene

Hay dos formas sencillas, y ninguna necesita acceso a la configuración de su dominio.

La primera es una herramienta gratuita de consulta DNS, como nuestra comprobación de SPF, DKIM y DMARC (en inglés). Introduzca su dominio, sin www y sin https://. En DMARC verá una de tres cosas:

• ningún registro, lo que significa ninguna protección,
• un registro con p=none, que observa pero no bloquea nada,
• un registro con p=quarantine o p=reject, con el que los mensajes falsificados van a spam o se rechazan.

En SPF, lo principal es comprobar que hay exactamente un registro. Dos registros SPF distintos en el mismo dominio son un error que puede hacer que los servidores receptores consideren su SPF no válido.

La segunda forma es Gmail. Envíe un correo desde la dirección de su empresa a cualquier cuenta de Gmail, ábralo, haga clic en los tres puntos junto al botón de responder y elija Mostrar original. Arriba verá líneas separadas para SPF, DKIM y DMARC, cada una con PASS o FAIL. Tres PASS son buena señal. Repita la prueba con una factura de su programa de contabilidad y con un mensaje del formulario de contacto de su sitio, porque cada uno sale por un camino distinto.

De p=none a quarantine sin perder su propio correo

El error más habitual es saltar directamente a p=reject. Entonces resulta que las facturas del programa de contabilidad, las notificaciones de la tienda o el boletín nunca tuvieron bien configurados SPF o DKIM. A partir de ese momento acaban en spam o no llegan, y se tarda mucho en averiguar por qué.

Un orden más seguro es este:

1. Configure DMARC con p=none y una dirección para los informes, por ejemplo v=DMARC1; p=none; rua=mailto:dmarc@sudominio.com.
2. Reúna informes durante unas semanas. Llegan como archivos XML, así que lo más fácil es cargarlos en uno de los lectores gratuitos de informes DMARC, que los convierte en una tabla legible.
3. Haga una lista de todos los servicios que, según los informes, envían correo como su dominio. Para cada uno que sea realmente suyo, configure bien SPF y DKIM.
4. Cuando los informes solo muestren orígenes que no reconoce, pase a p=quarantine. Los mensajes falsificados empezarán a ir a spam.
5. Tras unas cuantas semanas más sin incidencias, puede pasar a p=reject, con el que los servidores receptores rechazan directamente las falsificaciones.

Si tiene dominios que nunca envían correo, como un nombre antiguo de la empresa o un dominio comprado por si acaso, asígneles v=spf1 -all y un registro DMARC con p=reject desde el primer momento. No pierde nada, y un estafador no podrá usarlos en lugar del principal.

Lo que estos registros no hacen

DMARC protege su dominio exacto. No detiene a quien registra uno parecido, como su-dominio.com o sudominio.co, y configura sus propios registros perfectamente válidos. Tampoco ayuda si alguien se hace con el buzón real de un empleado, porque entonces los correos falsos salen de su propio servidor y superan todas las comprobaciones.

Por eso, además de los registros DNS, ayudan dos cosas sencillas. Primero, el inicio de sesión en dos pasos en todos los buzones de la empresa. Segundo, una regla que sus clientes conozcan: los datos bancarios nunca cambian por correo electrónico, y cualquier aviso de una cuenta nueva se confirma por otro canal. Puede decirlo claramente en sus facturas o en la firma de su correo.

Qué preguntar a quien gestiona su dominio

Su dominio suele gestionarlo su empresa de alojamiento, la empresa donde lo compró o su desarrollador. Envíeles estas preguntas:

1. ¿Qué servicios envían correo desde nuestro dominio y están todos en el registro SPF?
2. ¿Tenemos exactamente un registro SPF y se mantiene dentro del límite de diez consultas DNS?
3. ¿Está activado DKIM para nuestro correo de empresa, nuestro programa de facturación y nuestra herramienta de boletines? En Microsoft 365 y Google Workspace normalmente hay que activarlo a mano.
4. ¿Tenemos DMARC, con qué nivel y quién lee los informes?
5. ¿Cuándo podemos pasar con seguridad a p=quarantine?

Una buena respuesta no tiene por qué ser larga. Lo importante es que nombre a una persona que revise los informes de vez en cuando y una fecha para pasar al siguiente nivel de protección.