¿Qué problema resuelven SPF, DKIM y DMARC?
El correo se diseñó sin comprobar quién envía: cualquiera puede poner tu dirección como remitente. SPF, DKIM y DMARC son la forma de decir a Gmail, a Outlook y al resto qué correos con tu dominio son tuyos de verdad y qué hacer con los demás. Sin ellos, cada receptor decide por su cuenta.
INCIBE lo explica desde el protocolo: el correo se creó como un método sencillo de comunicación, «sin tener en cuenta aspectos como la seguridad, el correo no deseado, las suplantaciones», y con ese funcionamiento «cualquiera con una dirección de correo puede enviar un e-mail a cualquier dirección de destino». Para quien usa un dominio propio de empresa, añade, son las tecnologías que ponen barreras a quien intente usarlo de forma fraudulenta.
El caso que importa a una pyme: alguien envía a tus clientes una factura desde «administracion@tuempresa.es» sin haber entrado en ningún sitio. Con los tres registros bien puestos, el buzón de tu cliente puede comprobar que ese correo no salió de tus servidores. Es una de las formas de montar el fraude del cambio de cuenta bancaria, la que no necesita ni un dominio parecido ni un buzón robado.
¿Qué hace cada registro: SPF, DKIM y DMARC?
SPF es la lista de servidores autorizados a enviar correo con tu dominio. DKIM añade a cada correo una firma digital que demuestra que salió de tu dominio y no se alteró. DMARC exige que al menos uno de los dos cuadre con el remitente visible y dice qué hacer si no.
| Registro | Qué hace | En una frase | Dónde se publica |
|---|---|---|---|
| SPF | Lista los servidores autorizados a enviar correo con tu dominio | Quién puede enviar | Un registro TXT en tu dominio que empieza por v=spf1 |
| DKIM | Firma cada correo que envías con una clave cuya parte pública se publica en el dominio | Que no se ha alterado | Un registro TXT en selector._domainkey.tudominio |
| DMARC | Pide que SPF o DKIM cuadren con el remitente visible y dice qué hacer si fallan | Qué hacer con los falsos | Un registro TXT en _dmarc.tudominio que empieza por v=DMARC1 |
La pieza que más se olvida es la alineación. DMARC no se conforma con que SPF o DKIM pasen: el dominio que comprueban tiene que coincidir con el del remitente que ve el destinatario, el del campo «De:». La ayuda de Google para remitentes lo dice así: «el dominio del encabezado "From:" del remitente debe coincidir con el dominio de SPF o con el de DKIM». Un servicio de facturación que envía en tu nombre con su propio dominio pasa SPF, pero no cuadra con el tuyo y falla DMARC.
¿Qué significan las políticas none, quarantine y reject de DMARC?
None, quarantine y reject son las tres respuestas que puedes pedir para un correo que falla DMARC. Con none solo observas: recibes informes y no se bloquea nada. Con quarantine pides que vaya a correo no deseado. Con reject pides que se rechace antes de llegar. El objetivo es reject, pero se llega por fases.
| Situación | Qué pides | Qué pasa con el correo falso | Qué ganas |
|---|---|---|---|
| Sin registro DMARC | Nada | Cada receptor decide por su cuenta | Nada, y no recibes informes |
| p=none | Solo observar | El receptor aplica sus filtros de siempre | Los informes: quién envía con tu nombre |
| p=quarantine | Tratarlo como sospechoso | Va a correo no deseado o a revisión, según el receptor | Protección parcial |
| p=reject | Rechazarlo | El receptor que aplica DMARC lo rechaza | Que tu dominio exacto no sirva para suplantarte |
El RFC 9989, la norma de DMARC desde mayo de 2026, define las tres así: con none, el dueño del dominio no expresa ninguna preferencia; con quarantine, considera sospechoso el correo que falla; con reject, considera el fallo una señal clara de que el uso de su dominio no es válido. Es una petición a quien recibe, que es quien decide.
¿Qué es un informe DMARC y para qué sirve?
Un informe DMARC es el resumen, en formato XML, que los receptores envían a la dirección que pones en la etiqueta rua de tu registro, a diario o con más frecuencia. Dice qué servidores han enviado correo con tu dominio y si pasaron SPF y DKIM. Sin rua, no te envían ninguno.
El RFC 9990, publicado con el 9989 en mayo de 2026, regula estos informes agregados: un documento XML por dominio con qué direcciones IP han enviado en tu nombre, el resultado de SPF y de DKIM, si cuadraron con tu dominio y cuántos mensajes hubo. Están pensados para leerlos con una herramienta, no a mano: el RFC 9989 recomienda procesarlos de forma automática.
- Servicios tuyos que envían con tu dominio y no estaban en SPF: el boletín, la facturación, la web.
- Servicios que pasan SPF con su propio dominio pero no cuadran con el tuyo.
- Correo que tu empresa no ha enviado: el de quien se hace pasar por ti.
Google recomienda configurarlos porque «te ayudan a identificar a los remitentes que puedan estar suplantando la identidad de tu dominio». El diagnóstico gratuito de tu dominio comprueba si tu registro DMARC pide informes y, si no los pide, lo señala.
¿En qué orden se configuran SPF, DKIM y DMARC?
El orden que evita perder correo legítimo: inventario de todo lo que envía correo con tu dominio, SPF y DKIM para cada servicio, DMARC en none con una dirección de informes y, con los informes limpios, quarantine y reject. El RFC 9989 avisa de que asegurarte de que autenticas todo puede llevar meses.
Haz inventario: tu correo, la web, la facturación, el boletín y cualquier servicio que envíe en tu nombre.
Publica SPF con todos ellos y activa DKIM en cada uno, con tu dominio.
Publica DMARC en p=none con rua: una dirección donde recibir los informes.
¿Los informes muestran correo legítimo que falla DMARC?
- Sí
- Corrige ese servicio y sigue en none.
- No
- Sigue al paso 5.
Sube a p=quarantine y sigue leyendo los informes.
¿Siguen limpios los informes?
- Sí
- Sube a p=reject.
- No
- Vuelve al paso 4.
Es el orden que describe el apartado 5.1 del RFC 9989: SPF y DKIM alineados, un buzón para los informes, DMARC en none, lo que el estándar llama modo de observación, y solo cuando el dueño del dominio está seguro de que autentica todo su correo, una política que se aplique. Según el ritmo de envíos, añade, eso puede llevar muchos meses. Si usas Microsoft 365 o Google Workspace, empieza por sus guías: seguridad en Microsoft 365 y seguridad en Google Workspace.
Inventario
- Tienes la lista de todo lo que envía correo con tu dominio
- Cada servicio está en SPF y firma con DKIM con tu dominio
Registros
- Hay un solo registro SPF y no pasa de 10 consultas
- La clave DKIM tiene al menos 1.024 bits; mejor 2.048
- El registro DMARC no lleva pct
- DMARC pide informes con rua y alguien los lee
Informes
- Llevas semanas, o meses, con informes en none
- Ningún servicio legítimo falla DMARC
- Has pasado por quarantine antes que por reject
Después
- Cada herramienta nueva que envíe en tu nombre entra en SPF y DKIM antes del primer envío
- Revisas los informes después de cada cambio
¿Qué piden Gmail y Outlook a quien les envía correo?
Gmail pide desde febrero de 2024 SPF o DKIM a todo el que le envía correo y, a quien manda más de 5.000 al día, los tres registros, con DMARC al menos en none. Outlook.com pide lo mismo a los grandes remitentes desde mayo de 2025. Por debajo, DMARC es buena práctica.
| Quién envía | Gmail (desde el 1 de febrero de 2024) | Outlook.com, Hotmail y Live (desde el 5 de mayo de 2025) |
|---|---|---|
| Cualquier remitente | SPF o DKIM; tasa de spam por debajo del 0,30 %; no suplantar el campo «From:» | Los requisitos son para quien envía mucho; al resto se le recomiendan |
| Más de 5.000 correos al día | SPF, DKIM y DMARC, que puede estar en p=none; el «From:» alineado con SPF o DKIM; baja con un clic en el correo de marketing | SPF y DKIM que pasen; DMARC al menos en p=none, alineado con SPF o DKIM |
| Si no cumples | El correo puede ir a spam o rechazarse con el error 5.7.26 | Rechazo con el error 550 5.7.515 |
Las dos reglas son para el correo que llega a cuentas personales (@gmail.com, @outlook.com, @hotmail.com, @live.com), no a buzones de empresa. Pero marcan el listón: Google recomienda «que siempre configures SPF, DKIM y DMARC en tus dominios», y Microsoft responde a quien envía menos de 5.000 al día que a todos les conviene. Si tu boletín o tu tienda en línea mandan miles de correos, el límite sí te afecta. El detalle de Outlook está en su página de soporte.
Marzo de 2015
RFC 7489
DMARC se publica como documento informativo, fuera de la vía de estándares.
1 de febrero de 2024
Gmail
SPF o DKIM para todos; los tres registros para quien envía más de 5.000 al día.
5 de mayo de 2025
Outlook.com
Los tres registros para quien envía más de 5.000 al día a Outlook.com, Hotmail y Live.
Mayo de 2026
RFC 9989 y RFC 9990
DMARC pasa a ser estándar de internet y sustituye al RFC 7489.
¿Qué cambió en DMARC en mayo de 2026?
Desde mayo de 2026, DMARC es estándar de internet. El RFC 9989 sustituye al RFC 7489, retira la etiqueta pct, añade np para los subdominios que no existen y t para el modo de prueba, y busca la política recorriendo el DNS en vez de usar una lista de sufijos. Tu registro sigue valiendo.
| Etiqueta o pieza | Antes (RFC 7489, 2015) | Ahora (RFC 9989, 2026) | Qué haces |
|---|---|---|---|
| Estado del documento | Informativo, fuera de la vía de estándares | Estándar de internet | Nada |
| pct | Aplicar la política solo a un porcentaje del correo | Retirada | Quítala; para probar, usa t=y |
| t | No existía | Modo de prueba: con t=y se aplica un nivel menos (reject como quarantine, quarantine como none) | Úsala solo mientras pruebas |
| np | Experimental (RFC 9091) | Política para los subdominios que no existen | Valora np=reject: nadie debería enviar desde ellos |
| psd | No existía | Marca los dominios de sufijo público, como .es | Nada: es para registros de dominios, no para empresas |
| rf y ri | Formato de los informes de fallo e intervalo entre informes | Retiradas | Quítalas si las tienes |
| Cómo se encuentra la política | Con una lista de sufijos públicos | Recorriendo el árbol DNS | Publica un registro DMARC en cada dominio desde el que envíes |
La versión del registro sigue siendo v=DMARC1, y el estándar obliga a ignorar las etiquetas desconocidas, así que un registro correcto de antes sigue funcionando. El cambio del árbol DNS puede dar resultados distintos entre receptores que aplican una norma u otra; el RFC 9989 dice que se evita con alineación estricta y publicando un registro DMARC en cada dominio desde el que se envía.
¿Protegen SPF, DKIM y DMARC tu bandeja de entrada?
SPF, DKIM y DMARC no protegen tu bandeja: protegen tu dominio ante los demás. Lo que te llega lo protege tu filtro de correo. Y no frenan un dominio parecido al tuyo ni un correo enviado desde un buzón robado: el RFC 9989 dice que DMARC solo combate la suplantación del dominio exacto.
El RFC 9989 lo deja escrito: DMARC solo puede combatir directamente la suplantación del dominio exacto, y no aborda el uso de dominios visualmente parecidos ni el nombre que se muestra en el campo «De:». Si alguien registra «tuernpresa.es» en lugar de «tuempresa.es» (un ejemplo inventado), ese dominio tiene sus propios registros y pasa todas las comprobaciones. Qué hacer entonces, en la guía del typosquatting.
INCIBE ya lo advertía en 2018 al explicar DMARC a las empresas: se pueden usar «dominios con similitudes al original esperando que el cliente pique, a través de técnicas como el typosquatting». Y si lo que roban es el buzón, el correo sale de tus servidores y pasa las tres comprobaciones: ahí lo que frena es el doble factor.
El diagnóstico gratuito lee tus registros SPF y DMARC, busca la firma DKIM entre los nombres de selector más habituales de Microsoft 365, Google Workspace y los proveedores españoles, y te dice qué falta y por dónde empezar. Si tu proveedor usa otro selector, puede no encontrarla aunque exista. En Talvit, el filtro de correos trampa de Microsoft 365 va en todos los planes. Más fraudes que llegan por correo, en correo y fraude.
Lo que esta guía no cubre
- Cómo se configura cada registro en cada proveedor: los valores exactos te los da el tuyo.
- Los dominios parecidos al tuyo, que tienen su propia guía.
- MTA-STS y TLS-RPT, que obligan a cifrar el correo que te llega y no autentican el que envías.
Preguntas frecuentes
¿Cómo sé si mi dominio tiene SPF, DKIM y DMARC?
Con el diagnóstico gratuito de tu dominio: lee los tres registros y te dice qué hay, qué falta y por dónde empezar.
¿Puedo romper algo al configurar DMARC?
Si pasas a reject sin revisar los informes, algún servicio legítimo puede dejar de entregar, como el boletín o la facturación. Por eso se hace por fases, empezando en none.
¿Tengo que cumplir los requisitos de Gmail si envío pocos correos?
Los tres registros los exige a quien envía más de 5.000 correos al día a cuentas personales de Gmail. A todos les pide al menos SPF o DKIM. Y Google recomienda configurar siempre los tres.
¿Quién configura estos registros?
Se publican en el DNS de tu dominio, donde lo tengas gestionado. Los valores de SPF y DKIM te los da tu proveedor de correo; la política DMARC la decides tú.
Fuentes
- IETF, RFC 9989, «Domain-Based Message Authentication, Reporting, and Conformance (DMARC)» (mayo de 2026), consultado el
- IETF, RFC 9990, «DMARC Aggregate Reporting» (mayo de 2026), consultado el
- RFC 7489, «Domain-based Message Authentication, Reporting, and Conformance (DMARC)», documento informativo (marzo de 2015), consultado el
- Ayuda de Google Workspace, «Directrices para remitentes de correo», consultado el
- Microsoft, «Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders» (2 de abril de 2025, actualizado el 29 de abril), consultado el
- Soporte de Microsoft, «Fix NDR error 550 5.7.515 in Outlook.com», consultado el
- INCIBE, «El correo electrónico: la primera barrera a proteger para evitar el fraude» (4 de octubre de 2018), consultado el
Registro de cambios
- : Publicación.
- : Reescrita entera: DMARC pasa a estándar con el RFC 9989 (mayo de 2026) y retira pct, los requisitos de Gmail y Outlook y los informes rua.
