La autenticación del correo son tres registros DNS, publicados en tu propio dominio, que permiten a un servidor receptor decidir si un mensaje viene de verdad de ti. SPF nombra los servidores autorizados a enviar. DKIM firma cada mensaje para que se note si lo manipulan. DMARC dice qué hacer cuando los dos primeros no concuerdan con la dirección de la cabecera From, y pide informes al respecto.
Publicar los tres era antes una buena práctica. Desde febrero de 2024 es una condición de entrega en los mayores proveedores de correo, y la mayoría de los dominios aún no ha terminado. En los dominios que probamos para el Unspam 2026 Email Deliverability Benchmark, el 93% publica un registro SPF válido y el 90% firma con una clave DKIM que funciona, pero solo el 48% publica una política DMARC. El hueco entre el 90 y el 48 es este artículo entero.
Puedes ver dónde está tu propio dominio en unos treinta segundos con un chequeo de salud del correo gratuito, que lee los tres registros a la vez y te dice sobre cuáles actuaría de verdad un receptor.
Los tres registros responden a tres preguntas distintas
Un servidor receptor no hace una sola pregunta sobre tu correo. Hace tres, y cada registro responde exactamente a una de ellas.
| Registro | La pregunta que responde | Qué es |
|---|---|---|
| SPF | ¿Estaba este servidor autorizado a enviar por este dominio? | Un registro TXT que lista los remitentes permitidos |
| DKIM | ¿Se ha alterado este mensaje, y quién lo firmó? | Una clave pública en el DNS, más una firma en la cabecera |
| DMARC | ¿Qué hago cuando las respuestas no coinciden con la dirección From? | Un registro TXT con una política y una dirección de informes |
El orden importa porque DMARC no es independiente. Es una capa de decisión que se apoya sobre los otros dos, y no tiene nada sobre lo que actuar hasta que al menos uno de ellos pasa. Un dominio con DMARC pero sin SPF ni DKIM funcionando ha publicado una instrucción que nunca se podrá cumplir.
SPF publica qué servidores pueden enviar por tu dominio
SPF es una lista de los servidores que has autorizado, publicada como un registro TXT de DNS en tu propio dominio. Cuando un servidor se conecta para entregar correo diciendo que viene de ti, el receptor consulta esa lista y comprueba si la dirección IP que conecta está en ella.
Un registro tiene este aspecto: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Cada include delega en la lista de otra organización, que es como autorizas a Google Workspace y a tu plataforma de marketing a la vez sin llevar tú el control de sus direcciones IP.
Hay dos límites que pillan a la gente. El primero es que SPF permite un máximo de diez consultas DNS por comprobación, y cada include gasta al menos una. Si te pasas, el resultado es un error permanente, que la mayoría de receptores tratan como un fallo y no como un registro ausente. El segundo es que SPF se rompe con el reenvío: cuando una lista de correo o una dirección de reenvío retransmite tu mensaje, el servidor que conecta es el suyo y no el tuyo, y SPF falla sin que tú hayas hecho nada mal. Ese segundo límite es justamente la razón de ser de DKIM. Nuestra guía sobre registros SPF cubre la sintaxis y el presupuesto de consultas al completo. Que SPF se rompa con el reenvío es además el problema para el que se construyó ARC, y nuestra guía sobre ARC cubre por qué se está retirando ese experimento.
DKIM firma el mensaje en sí, así que el reenvío no lo rompe
DKIM adjunta una firma criptográfica a cada mensaje saliente, generada con una clave privada que guarda tu plataforma de envío. Tú publicas la clave pública correspondiente en el DNS, y el receptor la usa para verificar la firma.
Como la firma cubre las cabeceras y el cuerpo y no la conexión, DKIM sobrevive al reenvío. También demuestra que el mensaje no se alteró en tránsito, algo que SPF no puede hacer en absoluto. Esa combinación lo convierte en la señal más fuerte de las dos y en aquella sobre la que probablemente se apoya DMARC cuando tu correo pasa.
Toda plataforma de envío seria rota las claves con cierta periodicidad, y el selector de la cabecera es lo que permite a un dominio llevar varias claves a la vez: s1._domainkey.example.com y s2._domainkey.example.com pueden estar activos los dos, que es como se hace una rotación sin dejar un hueco. Un receptor lee el selector de la firma y consulta solo esa clave. Usa claves de 2048 bits en vez de 1024; la longitud corta todavía valida, pero ya no se considera suficiente. El formato completo del registro está en nuestra guía sobre firmas DKIM. Qué longitud debe tener una clave, y cómo una actualización la acorta en silencio, está en nuestra guía sobre la longitud de clave DKIM.
DMARC solo funciona cuando SPF o DKIM se alinea con tu dominio From
La alineación es la parte que casi todas las introducciones se saltan, y es donde fallan los registros que funcionan. DMARC no pregunta si SPF o DKIM pasaron. Pregunta si alguno de los dos pasó para el mismo dominio que tu lector ve en la cabecera From.
Tu plataforma de marketing puede firmar cada mensaje a la perfección con su propio dominio y pasar SPF en su propio dominio de envío, y DMARC fallará igualmente, porque ninguno de los dos identificadores coincide con el tuyo. La solución es configurar esa plataforma para que firme como tu dominio, algo que toda plataforma de envío seria admite y que muchos clientes nunca llegan a activar. La dirección que autentica SPF es el remitente del sobre y no la que ve tu lector, algo que cubre al completo nuestra guía sobre el Return-Path.
Una vez que el receptor tiene un resultado de alineación, tu política le dice qué hacer:
p=nonesignifica no hagas nada y mándame informes. Es la posición de partida, no el destino.p=quarantinesignifica manda el correo que falle a la carpeta de spam.p=rejectsignifica recházalo en la puerta.
Dos cosas de DMARC cambiaron en mayo de 2026 y casi ninguna documentación se ha puesto al día. El RFC 9989 sustituyó al RFC 7489, convirtiendo DMARC en una especificación de vía estándar en vez de informativa, y retiró las etiquetas pct, ri y rf. Si tu registro lleva pct por debajo de 100 junto a quarantine o reject, tu aplicación es ahora más estricta de lo que configuraste, sin haber tocado el DNS. Nuestra guía sobre registros DMARC repasa cada etiqueta.
Los proveedores de correo dejaron de tratar DMARC como opcional en 2024
Cualquier guía que te diga que DMARC es recomendable pero no obligatorio está describiendo el mundo anterior a febrero de 2024. Ese mes, Google y Yahoo empezaron los dos a exigir una política DMARC a los remitentes masivos hacia sus propios buzones. Apple siguió en febrero de 2025 y Outlook.com en mayo de 2025.
Vale la pena precisar cuatro detalles, porque se cuentan mal a menudo:
- El umbral de Google son 5.000 mensajes al día a direcciones personales de Gmail. Outlook.com usa la misma cifra para sus buzones de consumo. Yahoo se ha negado públicamente a publicar ninguno, así que desconfía de cualquier cifra que se le atribuya.
p=nonecumple el requisito. Los proveedores exigen una política publicada, no aplicación. Empezar en none cumple, y además es la forma correcta de empezar.- La regla de Microsoft cubre el correo de consumo de Outlook.com, no los tenants de Microsoft 365. Si vendes a empresas, ese requisito no describe a tus destinatarios.
- Las tasas de quejas por spam llevan su propio umbral, el 0,3% en Google y Yahoo, y una tasa por debajo del 0,1% es lo que Google recomienda, no lo que exige.
La autenticación es necesaria pero no suficiente. Un mensaje autenticado a la perfección acaba igualmente en spam si el contenido activa un filtro, algo que se puntúa aparte y es el tema de nuestra guía sobre puntuaciones de SpamAssassin.
Cinco formas en que estos registros fallan pareciendo correctos
Cada fallo de los de abajo produce un registro que a una persona le parece bien y que en un receptor no hace nada. Son aquellos alrededor de los cuales se construyó nuestro propio analizador, más o menos por orden de frecuencia con la que los vemos.
Dos registros SPF en un dominio. Publicar un segundo registro TXT en vez de editar el primero no los fusiona. El resultado es un error permanente, y la mayoría de receptores tratan un error permanente como un fallo y no como la ausencia de registro. Un dominio, un registro SPF, siempre.
Más de diez consultas DNS en la cadena de SPF. Cada include cuesta al menos una consulta, y el proveedor que hay detrás puede gastar varias más dentro de su propio registro. Con cuatro o cinco proveedores ya te sales del presupuesto. El registro sigue pareciendo corto y legible; simplemente deja de evaluarse a mitad de camino.
Una errata en la etiqueta sp o np de DMARC. Esta es la más cruel. Una política de subdominio inválida descarta el registro entero, incluido un p=reject impecable. v=DMARC1; p=reject; sp=quarintine no protege absolutamente nada, y un comprobador que informe del p que ha conseguido leer te dirá que el dominio está blindado.
Nada alineado con el dominio From. SPF pasa en el dominio de la plataforma, DKIM firma con el dominio de la plataforma, las dos comprobaciones informan de un pase, y DMARC falla igualmente. Todos los resultados de tus registros se ven en verde. Esta es la razón más común, con diferencia, por la que un dominio cuidadosamente configurado se pasa un año en p=none.
Confundir una política p=none con protección. None es una instrucción para no hacer nada. Es el sitio correcto para empezar y el sitio equivocado para quedarse, y un dominio que lleva dos años ahí está publicando una petición de informes que nadie lee.
Publícalos en orden, porque DMARC depende de los otros dos
La secuencia de abajo no es una preferencia. Invertirla publica una política que no tiene nada debajo.
- Publica SPF y confirma que pasa. Un registro por dominio, por debajo de diez consultas, terminado en
~allo-all. Dos registros SPF en un dominio son un error permanente, no una fusión. - Activa la firma DKIM en cada plataforma que envíe como tú. Tu ESP, tu CRM, tu servicio de soporte, tu herramienta de facturación. Cada una publica su propio selector.
- Comprueba que al menos uno de ellos se alinea con tu dominio From. Este es el paso que se salta la gente, y saltárselo vuelve decorativo todo lo que viene después.
- Publica DMARC en
p=nonecon una dirección de informes. Estás recogiendo pruebas, todavía no estás aplicando nada. - Lee los informes entre dos y cuatro semanas. Buscas remitentes legítimos que se te habían olvidado, porque eso es lo que bloquearía una política de aplicación.
- Pasa a
p=quarantiney después ap=reject. Solo cuando cada fuente legítima pase y esté alineada.
El paso cinco es donde importan las herramientas, porque los informes DMARC en bruto llegan en XML y son casi ilegibles a mano. Comparamos las opciones en nuestro repaso de herramientas de monitorización DMARC, incluidas las gratuitas. Si solo quieres confirmar que tu registro está publicado y se analiza bien, basta con un comprobador DMARC gratuito.
BIMI enseña tu logo en la bandeja, y casi nadie cumple todavía
BIMI muestra el logo de tu marca junto a tus mensajes en las bandejas compatibles, y es el único de estos estándares que tus destinatarios pueden ver. También es el único que exige los demás primero: un dominio ya tiene que estar en p=quarantine o p=reject para que un receptor muestre el logo.
La adopción es realmente escasa. El 99% de los dominios que probamos no publica ningún registro BIMI, lo que lo convierte en una de las pocas formas que quedan de verse distinto en una bandeja saturada. Gmail exige además un Verified Mark Certificate, una acreditación de pago de que la marca del logo es tuya, que es la razón principal de que la cifra siga donde está.
Trata BIMI como la recompensa por terminar DMARC y no como un proyecto aparte. Si no estás en aplicación, todavía no hay nada que configurar.
Qué comprobar después de publicar
Los registros se desvían. Se añade una plataforma sin actualizar el SPF, se rota mal una clave, alguien edita un registro a mano y se deja un punto y coma. El fallo es silencioso, porque nada en tu propio flujo de correo te avisa de que un receptor ha empezado a rechazar.
Vale la pena hacer cuatro comprobaciones de forma periódica:
- Que los tres registros se analicen y digan lo que crees que dicen. Una etiqueta
sponpinválida descarta por completo un registro DMARC que por lo demás es perfecto, y un comprobador que informe delpque puede leer te dará un sello verde sobre un dominio abierto. - Que cada plataforma de envío siga alineada. Se compran herramientas nuevas, y no se autentican solas.
- Que tus informes DMARC sigan llegando. Si tu dirección de informes se cae del registro, los informes paran y nada lo anuncia.
- Que el mensaje en sí siga pasando. Solo el 89% de los mensajes que probamos supera una comprobación completa de entregabilidad, con un 9% que recibe un aviso y un 2% que falla del todo, y la autenticación es solo una parte de esa puntuación.
Dejar bien los tres registros es el trabajo con más palanca que hay en entregabilidad, porque es la única parte que un receptor comprueba antes de leer una sola palabra de lo que escribiste. Si los registros van más allá de lo que quieres llevar en casa, un consultor de entregabilidad puede encargarse del despliegue. Si no, haz una prueba de spam gratis sobre un mensaje real y lee los resultados de autenticación junto a los de contenido, que es la forma más rápida de ver lo que ve un receptor.
