SPF, DKIM y DMARC: guía de autenticación de correo electrónico

Cualquiera puede poner tu dominio en la línea From de un correo. SMTP, el protocolo que transporta el correo, se diseñó en una época de confianza y nunca lo verifica. La autenticación de correo es el conjunto de registros DNS que permite a los servidores receptores verificarlo por ti: SPF indica qué servidores pueden enviar en nombre de tu dominio, DKIM añade una firma criptográfica a cada mensaje, y DMARC vincula ambos con la dirección que el destinatario realmente ve e indica a los receptores qué hacer cuando la verificación falla.

Sin estos registros, es más probable que tu correo legítimo termine en spam, y los estafadores pueden suplantar tu dominio con muy poco esfuerzo. Esta guía explica qué hace cada registro, cómo funcionan juntos y qué revisar primero.

SPF: quién puede enviar

SPF (Sender Policy Framework) es un único registro TXT en tu dominio que enumera los servidores autorizados para enviar correo en su nombre. Un registro típico se ve así:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

• v=spf1: marca el registro como SPF. Debe ir primero.
• ip4: / ip6:: direcciones individuales o rangos.
• include:: "confía también en quien indique este otro dominio". Así autorizas Google Workspace, Microsoft 365 o un servicio de newsletters.
• a y mx: los servidores a los que apuntan tus registros A o MX.
• ~all o -all: qué hacer con todos los demás: soft fail (aceptar, pero tratar como sospechoso) o fail.

Hay un detalle que se pasa por alto fácilmente: SPF verifica el remitente del sobre (la dirección Return-Path usada durante la entrega), no la dirección From que se muestra en el cliente de correo. Las plataformas de newsletters suelen usar su propio dominio en el Return-Path, por lo que SPF puede pasar sin demostrar nada sobre tu dominio From. Esa brecha es justo la que DMARC cierra.

Revisa lo que publica tu dominio con el verificador de SPF: muestra los mecanismos analizados, el calificador final y cuántas consultas DNS necesita el registro.

DKIM: una firma en cada mensaje

DKIM (DomainKeys Identified Mail) funciona como un sello. El servidor emisor firma con una clave privada ciertos encabezados y el cuerpo, y añade un encabezado DKIM-Signature. El receptor obtiene la clave pública correspondiente desde DNS y verifica que nada se haya modificado durante el tránsito. Dos etiquetas de la firma son las más importantes:

• d=: el dominio firmante;
• s=: el selector, el nombre bajo el cual se publica la clave pública: selector._domainkey.example.com.

Como la clave se localiza por selector, un dominio puede tener varias claves DKIM al mismo tiempo: una para tu proveedor de correo, otra para tu herramienta de newsletters y otra para tu CRM. Los selectores, la longitud de la clave y la rotación se explican en detalle en Qué es DKIM. Para ver si existe una clave y qué longitud tiene, usa el verificador de DKIM.

DMARC: alineación y política

DMARC (Domain-based Message Authentication, Reporting and Conformance) es un registro TXT en _dmarc.example.com:

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

Hace tres cosas:

1. Exige alineación. Un mensaje pasa DMARC solo si SPF o DKIM pasan y el dominio para el que pasaron coincide con el dominio de la dirección From visible. En SPF es el dominio del Return-Path; en DKIM, el dominio d=. De forma predeterminada la coincidencia es "relajada": mail.example.com se alinea con example.com porque comparten el dominio organizacional.
2. Establece una política para los mensajes que fallan: none (solo reportar), quarantine (carpeta de spam) o reject (rechazar la entrega).
3. Activa los reportes. Los receptores envían reportes agregados diarios a la dirección rua, así puedes ver todos los servidores que envían correo como tu dominio, incluidos los que habías olvidado.

Cada etiqueta, el despliegue de p=none a p=reject y cómo leer los reportes se explican en Registro DMARC: cómo configurar DMARC paso a paso.

Cómo funcionan juntos los tres

La conclusión práctica: DKIM es la mitad más robusta porque sobrevive al reenvío. Procura que cada flujo legítimo de correo pase con DKIM alineado y trata SPF como una segunda línea.

Qué exigen Gmail y Yahoo a los remitentes

Desde febrero de 2024, Google y Yahoo aplican requisitos publicados para remitentes, y otros grandes proveedores de correo han avanzado en la misma dirección. En resumen:

• Todos los que envían a direcciones personales de Gmail o Yahoo necesitan SPF o DKIM, DNS directo e inverso válidos para las IP de envío, TLS y una tasa baja de quejas de spam.
• Los remitentes masivos (Google indica un umbral de alrededor de 5,000 mensajes al día a sus usuarios) necesitan SPF y DKIM, un registro DMARC con al menos p=none, un dominio del From alineado con SPF o DKIM y cancelación de suscripción con un clic para el correo de marketing.

Lista de verificación de configuración

1. Haz una lista de todos los servicios que envían correo con tu dominio: proveedor de correo, formulario de contacto del sitio web, herramienta de newsletter, CRM, helpdesk, sistema de facturación. Los remitentes olvidados son la principal razón por la que los despliegues de DMARC rompen el correo.
2. Publica un solo registro SPF que cubra los servicios que usan tu dominio en el Return-Path. Mantenlo por debajo de 10 consultas DNS.
3. Activa DKIM en cada servicio con tu propio dominio, no con el predeterminado del proveedor. Cada servicio te da un registro TXT o CNAME para publicar.
4. Publica DMARC con p=none y una dirección rua que realmente leas o un servicio de procesamiento de informes.
5. Lee los informes durante 2–4 semanas y corrige cada fuente legítima que falle la alineación.
6. Endurece la política paso a paso: primero quarantine y luego reject.
7. Revisa lo básico alrededor: la consulta MX confirma dónde se recibe tu correo, y la verificación de listas negras de IP muestra si tu IP de envío figura en alguna. Para el resto del panorama DNS, consulta cómo revisar los registros DNS de un dominio.

Errores comunes

Dos registros SPF

Al añadir un servicio nuevo, es habitual acabar con un segundo registro v=spf1 junto al antiguo. El estándar SPF lo trata como un error permanente, y muchos receptores entonces ignoran SPF por completo. Debe haber exactamente un registro SPF; combina los mecanismos en él.

Más de 10 consultas DNS

Cada include, a, mx, ptr, exists y redirect cuenta como una consulta, y los include dentro de otros include también cuentan. Por encima de 10, el resultado es un error permanente. Elimina los servicios que ya no uses, reemplaza a/mx por IP explícitas cuando sean estables y evita ptr.

Remitentes de terceros sin DKIM

Google Workspace, Microsoft 365, Mailchimp y servicios similares pueden firmar con tu dominio, pero normalmente solo después de que publiques sus registros DKIM y actives la firma. Hasta entonces firman con su propio dominio o no firman, y el correo no pasa la alineación DMARC.

p=reject desde el primer día

Pasar directamente a reject sin leer los informes bloquea a todos los remitentes que olvidaste: el sistema de facturas, el formulario del sitio web, un socio que envía en tu nombre. Empieza con p=none, recopila datos y luego endurece.

Olvidar los dominios que nunca envían correo

Los dominios aparcados y secundarios son muy usados para la suplantación precisamente porque nadie los vigila. Para un dominio que no envía nada, publica v=spf1 -all y v=DMARC1; p=reject.

Un ejemplo real

Nuestro propio dominio publica v=DMARC1; p=none; rua=mailto:dmarc@promopilot.link y firma el correo con el selector DKIM mail usando una clave de 2048 bits (verificado en octubre de 2026). Es una etapa normal de monitoreo: se recopilan los reportes y la política se endurece una vez que se confirman todas las fuentes. Ejecuta el verificador de DMARC en tu propio dominio para ver cómo estás.