SPF, DKIM y DMARC explicados: los tres registros que prueban que tu email es tuyo
Son tres registros DNS que juntos prueban que un correo viene de verdad de tu dominio, y desde las reglas de Gmail y Yahoo de 2024 son prácticamente obligatorios para quien envía en volumen. SPF (Sender Policy Framework) publica qué servidores pueden enviar correo por tu dominio. DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje, para que un receptor confirme que no se manipuló. DMARC (Domain-based Message Authentication, Reporting and Conformance) une a los dos y agrega la pieza crucial: exige que al menos uno de SPF o DKIM pase Y se alinee con la dirección From visible, le dice al receptor qué hacer cuando eso falla, y te envía informes de quién envía en tu nombre. La sutileza que hace tropezar a casi todas las configuraciones es la alineación. SPF revisa el Return-Path oculto y DKIM revisa su propio dominio de firma —ambos invisibles para los destinatarios— así que un atacante puede pasar uno de ellos mientras suplanta la línea From que de verdad ves. El requisito de alineación de DMARC es lo que cierra ese hueco. Y lo único que nunca hay que hacer es saltar directo a la aplicación: despliega DMARC de p=none a quarantine a reject en unos 90 a 120 días, arreglando primero cada fallo legítimo que revelen los informes, o bloquearás tu propio correo.
¿Qué hace de verdad cada uno de los tres?
La forma más clara de entrar es una metáfora de un portero revisando invitados. SPF (Sender Policy Framework) es la lista de invitados: un registro DNS que publica qué servidores están autorizados a enviar correo por tu dominio, para que un receptor pueda rechazar correo de cualquier IP que no esté en la lista (EmailSneak, 2026). DKIM (DomainKeys Identified Mail) es un sello de cera: firma criptográficamente cada mensaje saliente con una clave privada, y la clave pública correspondiente en tu DNS le permite a un receptor confirmar que el mensaje no se alteró en tránsito y de verdad vino de ti (EmailSneak, 2026).
DMARC (Domain-based Message Authentication, Reporting and Conformance) es la política que el portero sigue cuando algo anda mal. Se construye sobre SPF y DKIM, le dice al receptor qué hacer cuando un mensaje falla —rechazar, poner en cuarentena, o solo monitorear— y te envía informes agregados que muestran quién envía en tu nombre (EmailSneak, 2026). Los tres son registros DNS de tipo TXT, y desde las reglas de Gmail y Yahoo de febrero de 2024 son la base para llegar a la bandeja en vez de un extra opcional — que es por qué nuestro pilar sobre si tu email llega a la bandeja de entrada llama a la autenticación el requisito básico.
SPF: qué servidores pueden enviar como tú
SPF es un solo registro DNS de tipo TXT que lista los servidores y direcciones IP autorizados a enviar por tu dominio, y unas pocas reglas deciden si funciona. Debe haber exactamente un registro SPF por dominio — dos registros v=spf1 en el mismo host causan un fallo automático, y la causa común es un administrador que añade un registro nuevo para un servicio como Google Workspace en vez de editar el existente (SPFmonitor, 2026). El registro también está limitado a 10 búsquedas DNS: cada include:, a:, mx: y redirect= cuenta como una, y exceder el límite causa un PermError que hace fallar SPF en cada mensaje (AI QA Monkey, 2026).
Dos propiedades importan más allá de la configuración. SPF termina en un calificador —~all (softfail) o -all (hardfail)— pero en la práctica la diferencia es pequeña, porque los grandes proveedores siguen la política DMARC en vez del calificador de SPF; el camino sensato es ~all durante la configuración, apretando a -all una vez que cada fuente legítima está en el registro (SPFmonitor, 2026). La limitación más grande es que SPF se rompe al reenviar: cuando alguien reenvía tu correo de forma automática, el servidor de reenvío no está en tu registro, así que SPF falla — que es justo por qué DKIM y DMARC existen para cubrir el hueco (getsliq, 2026).
DKIM: un sello criptográfico en cada mensaje
DKIM añade una firma que viaja con el mensaje. Tu servicio de envío genera un par de claves, publica la clave pública como un registro DNS en selector._domainkey.tudominio.com, y firma cada correo saliente con la clave privada; el receptor obtiene la clave pública y verifica que el mensaje no se alteró y se originó en tu dominio (getsliq, 2026). A diferencia de SPF, DKIM sobrevive intacto al reenvío, lo que lo vuelve el más firme de los dos chequeos de base (EmailSneak, 2026).
Tres prácticas mantienen sano a DKIM. Usa claves de 2048 bits, ahora el estándar recomendado, en vez de las viejas de 1024 (SPFmonitor, 2026). Usa un selector distinto para cada flujo de envío —transaccional, marketing, interno— para que las claves coexistan y una filtración quede contenida (Mailforge, 2026). Y rota las claves una o dos veces al año, revocando de inmediato si una se compromete, porque una clave privada filtrada le permite a un atacante forjar correo autenticado desde tu dominio hasta que rotes (PowerDMARC, 2026). Un fallo silencioso frecuente es publicar el registro DKIM pero nunca activar la firma en la consola de administración, así que el correo sale sin firmar a pesar de un registro DNS correcto.
DMARC: atarlo al nombre que la gente de verdad ve
Aquí está la pieza que hace que las otras dos cuenten. DMARC exige que al menos uno de SPF o DKIM pase y que el dominio que pasó se alinee con la dirección From visible (RedSift, 2026). No necesita que pasen ambos — un paso alineado basta (Mimecast, 2026).
La alineación es todo el juego, por un hueco que SPF y DKIM dejan abierto por su cuenta. SPF revisa el dominio del Return-Path oculto, y DKIM revisa el dominio de su propia cabecera d= — ambos que un atacante puede fijar a su propio dominio mientras pone tu dominio en la línea From visible que los destinatarios leen (RedSift, 2026). Así que un mensaje suplantado podría pasar SPF o DKIM contra el dominio del atacante y aun así hacerse pasar por ti. DMARC cierra esto al insistir en que el chequeo aprobado se alinee con la dirección From, sea en modo relajado (mismo dominio organizacional) o estricto (coincidencia exacta) (DMARCLY, 2026). La alineación es lo que convierte dos chequeos técnicos en anti-suplantación de verdad.
Por qué la autenticación puede “pasar” y aun así caer en spam
El fallo de entregabilidad más confuso es el correo que pasa SPF y DKIM y aun así se filtra, y la alineación suele explicarlo. Cuando envías una campaña por una plataforma de terceros que firma y enruta bajo sus propios dominios, tu dirección From puede verse correcta mientras la alineación de DMARC falla en silencio — y el mensaje va a spam a pesar de que ambos chequeos de base técnicamente pasan (EmailSneak, 2026).
El arreglo es autenticar cada servicio que envía como tú, en tu propio dominio. Eso significa añadir el include: de cada proveedor a tu registro SPF y configurar la firma DKIM con tu dominio en vez de aceptar el predeterminado de la plataforma, para que los destinatarios vean “firmado por tudominio.com” en vez de “firmado por sendgrid.net” (SPFmonitor, 2026). Cada herramienta de marketing, CRM, mesa de ayuda y sistema de facturación que envía en tu nombre es una fuente de envío que tiene que alinearse, y las que la gente olvida son justo las que rompen DMARC.
El despliegue de DMARC: none → quarantine → reject
La aplicación de DMARC es un despliegue por etapas, no un interruptor, y las etapas existen para proteger tu propio correo. La razón es que casi nunca conoces cada servicio que envía como tu dominio hasta que los informes te lo dicen, así que monitoreas primero, arreglas lo roto, y solo entonces aplicas (getsliq, 2026). Las etapas se ven así:
| Etapa | Política | Qué hace | Cuándo avanzar |
|---|---|---|---|
| 1. Monitorear | p=none | Recoge informes, sin impacto en la entrega | Tras unas semanas de informes, una vez que encontraste y arreglaste cada remitente legítimo |
| 2. Cuarentena | p=quarantine (sube pct 25→100) | El correo que falla va a spam | Una vez que los informes están limpios al 100% |
| 3. Aplicar | p=reject | El correo que falla se descarta de plano | La meta — protección total contra suplantación |
Dos advertencias enmarcan todo el proceso. Ir directo a p=reject es el error número uno, porque sin un periodo de monitoreo bloquearás correo legítimo de servicios que olvidaste autenticar (getsliq, 2026). En el otro extremo, dejar p=none de forma permanente es activamente peligroso: te da visibilidad con cero protección, así que el phishing contra tu dominio triunfa mientras te quedas en modo monitor (nicheadvertiser, 2026). Hecho con responsabilidad, el camino a p=reject toma cerca de 90 a 120 días.
¿Necesitas DMARC si no envías correo de marketing?
Sí, y esto sorprende a la gente. Cualquier dominio sin una política DMARC aplicada puede ser suplantado por atacantes que envían correo de phishing que parece venir de ti, dañando tu posición con destinatarios y proveedores sin importar si corres campañas (AI QA Monkey, 2026). Los atacantes apuntan deliberadamente a dominios sin aplicación de DMARC, porque el correo suplantado de un dominio sin proteger tiene más probabilidad de llegar a la bandeja, y el fraude de correo corporativo basado en suplantación de dominio es una categoría de miles de millones (AI QA Monkey, 2026).
La implicación práctica es que incluso un dominio que no envía correo debería publicar un registro DMARC en p=reject, declarando que nada legítimo se origina en él. La autenticación no es solo una herramienta de entregabilidad; es una forma de defender el nombre en la línea From, lo uses o no.
Cómo verificar que funciona, y mantenerlo funcionando
La verificación es rápida. Envía un correo de prueba e inspecciona su cabecera Authentication-Results, donde puedes confirmar que SPF, DKIM y DMARC pasaron cada uno, y los verificadores gratuitos de los distintos proveedores validan la sintaxis de tu registro, el conteo de búsquedas y la fuerza de la clave en segundos (PowerDMARC, 2026). El trabajo continuo es leer tus informes agregados de DMARC, que llegan como XML diario y son más fáciles de analizar por un panel de informes — revelan remitentes desconocidos o mal configurados antes de que se vuelvan un problema (RedSift, 2026).
Luego es mantenimiento. Actualiza tu registro SPF cada vez que añades o quitas un servicio de envío, ya que un registro desactualizado hace fallar el correo legítimo, y rota las claves DKIM en un calendario (PowerDMARC, 2026). Como el resto de la entregabilidad de email, la autenticación es un cimiento que fijas correcto una vez y luego cuidas, no un proyecto que terminas. Es el primero de los tres factores que describe nuestro pilar sobre si tu email llega a la bandeja de entrada, y condiciona a los otros dos: la reputación de remitente y el engagement solo empiezan a importar una vez que tu correo es lo bastante confiable como para ser juzgado por ellos.
Frequently asked
- ¿Cuál es la diferencia entre SPF, DKIM y DMARC?
- Son tres registros DNS que trabajan juntos para probar que un correo viene de verdad de tu dominio. SPF (Sender Policy Framework) publica una lista de servidores autorizados a enviar correo por tu dominio, para que un receptor pueda rechazar correo de IPs no autorizadas. DKIM (DomainKeys Identified Mail) firma criptográficamente cada mensaje para que un receptor confirme que no se alteró en tránsito. DMARC (Domain-based Message Authentication, Reporting and Conformance) los une: exige que al menos uno de SPF o DKIM pase Y se alinee con la dirección From visible, le dice al receptor qué hacer cuando eso falla, y te envía informes de quién está enviando en tu nombre.
- ¿Necesito los tres, o basta con SPF?
- Necesitas los tres, y SPF por sí solo no basta. SPF revisa el dominio oculto del Return-Path en vez de la dirección From que ven los destinatarios, y se rompe cada vez que un correo se reenvía, así que por su cuenta deja tu dominio visible suplantable. DKIM sobrevive al reenvío y prueba la integridad del mensaje pero no dice nada de política. DMARC es lo que cierra el hueco, al exigir alineación con la dirección From visible y decirle al receptor que rechace o ponga en cuarentena el correo que falla. Desde las reglas de Gmail y Yahoo de 2024, los remitentes masivos deben tener los tres.
- ¿Qué significa la alineación de DMARC?
- Alineación significa que el dominio que pasó SPF o DKIM tiene que coincidir con el dominio de la dirección From visible. Esto importa porque SPF revisa el Return-Path oculto y DKIM revisa su propio dominio d=, ambos controlables por un atacante de forma independiente al From — así que un correo puede técnicamente pasar SPF o DKIM y aun así suplantar tu marca. DMARC solo pasa si un chequeo aprobado se alinea con el dominio From, que es lo que de verdad frena la suplantación. También es por qué el correo enviado por una plataforma de terceros bajo sus propios dominios puede fallar DMARC aunque SPF y DKIM parezcan pasar.
- ¿Cómo despliego DMARC sin bloquear mi propio correo?
- Despliégalo por etapas y nunca saltes directo a la aplicación. Empieza con p=none, que monitorea y te envía informes sin afectar la entrega, y córrelo unas semanas para descubrir cada servicio legítimo que envía como tu dominio — casi siempre hay algunos que olvidaste. Arregla cada fallo legítimo añadiendo el include de SPF que falta o activando DKIM para ese servicio. Luego pasa a p=quarantine, subiendo opcionalmente el porcentaje pct de 25 a 100, y solo cuando los informes estén limpios avanza a p=reject. Hecho con responsabilidad el despliegue completo toma más o menos 90 a 120 días. Ir directo a p=reject es la forma más común de bloquear tu propio correo.
- ¿Necesito DMARC si no envío correos de marketing?
- Sí. Cualquier dominio que no esté protegido con una política DMARC aplicada puede ser suplantado por atacantes que envían correo de phishing que parece venir de ti, lo que daña tu reputación con destinatarios y proveedores sin importar qué envíes. El fraude de correo corporativo construido sobre suplantación de dominio es una categoría de miles de millones, y los atacantes apuntan específicamente a dominios sin aplicación de DMARC porque su correo suplantado tiene más probabilidad de llegar a la bandeja. Incluso un dominio que no envía correo debería publicar un registro DMARC en p=reject para declarar que nada legítimo viene de él.