SeguridadLimita

Seguridad del correo: qué son SPF y DMARC y por qué tu dominio los necesita

Cualquiera puede enviar correos que aparenten venir de tu dominio si no lo has impedido. SPF y DMARC son los dos registros de DNS que lo impiden, y este hallazgo salta cuando faltan o cuando están puestos de una forma que no hace nada. Wakaris los comprueba junto al resto del análisis de tu web.

Por Juan Ignacio FrancoActualizado: 7 de septiembre de 20267 min de lectura

En resumen

Qué se comprueba

si tu dominio publica SPF y DMARC, y si lo que publican sirve de algo.

Qué protege

que alguien envíe correo suplantando tu dominio a tus clientes o a tu propio equipo.

Severidad en Wakaris

Importante. Aparece en el 80 % de los dominios analizados.

Trampa habitual

tener DMARC en modo de observación y creer que ya está resuelto.

Esquema de un correo que llega a un servidor destinatario y se comprueba contra los registros SPF y DMARC del dominio remitente
El servidor que recibe tu correo consulta el DNS de tu dominio. Si no encuentra nada, no tiene con qué decidir.

Qué es y qué comprueba este hallazgo

Tu dominio no solo sirve una web: también es el remite de tus correos. El protocolo con el que viaja el correo no restringe qué remitente puede poner cada servidor, tal como recoge el RFC 7208, así que la suplantación es el comportamiento por defecto de internet salvo que la desactives tú.

Eso se desactiva con dos registros de texto en el DNS del dominio. SPF declara qué servidores están autorizados a enviar correo con tu nombre. DMARC hace dos cosas más: dice qué quieres que haga el destinatario cuando un mensaje no supera la comprobación, y pide informes de quién está usando tu dominio.

Este hallazgo salta en tres situaciones: que no exista uno de los dos registros, que exista pero autorice a cualquiera, o que exista pidiendo que no se haga nada. Wakaris lo marca con severidad Importante.

Cómo se comprueba

Wakaris consulta el DNS del dominio de la URL que analizas y busca las dos entradas. La de SPF es un registro TXT en el propio dominio que empieza por v=spf1; el RFC 7208 obliga a publicarla exactamente así y no en otro tipo de registro. La de DMARC es otro TXT, pero en un subdominio con nombre fijo: _dmarc.tudominio.com.

Encontrar el registro no basta, y por eso el resultado tiene tres formas distintas. Un registro puede estar ausente. Puede estar y no servir: un SPF que termina en +all autoriza a todo el mundo, que es exactamente lo contrario de lo que se pretendía. Y un DMARC puede estar publicado con p=none, que el RFC 9989 llama modo de observación, pensado para auditar tus propios envíos antes de endurecer, no para quedarse ahí.

La comprobación es del dominio entero, no de una página. Es la única del análisis que mira fuera del HTML, y el resultado te dice qué falta y con qué forma exacta está publicado lo que hay.

Por qué importa

Un dominio sin protección es una marca que cualquiera puede usar para firmar. Las facturas falsas, el correo que pide un cambio de número de cuenta y el mensaje que aparenta venir de dirección se apoyan casi siempre en un dominio que no ha publicado nada, porque suplantarlo no cuesta ningún trabajo.

Hay un matiz que casi todo el mundo se salta. SPF valida el remitente del sobre, el que negocian los servidores, no la dirección que ve la persona en su pantalla. El propio RFC 7208 lo advierte: un correo autorizado por SPF puede contener otras identidades falsas. Por eso SPF a solas deja abierta justo la puerta que más daño hace, y hace falta DMARC, que es quien exige que el dominio visible cuadre con el que se ha autenticado.

El segundo frente es la entrega. Los grandes destinatarios usan estas señales para decidir a qué bandeja va tu correo. Un dominio sin autenticar reparte peor sus propios envíos legítimos, así que esto no es solo defensa: también es que tus mensajes lleguen.

Causas comunes

Rara vez es descuido puro. Suele ser una de estas cinco, y conviene distinguirlas porque el arreglo cambia.

La primera es no haberlo publicado nunca: el correo se contrató con un proveedor, el proveedor funciona y nadie tocó el DNS.

La segunda es un SPF que autoriza a cualquiera, normalmente por haber terminado el registro con +all o con ?all para que dejara de dar problemas.

La tercera es haberse pasado del límite técnico. El RFC 7208 obliga a que la evaluación de un SPF no supere diez consultas de DNS, y cada herramienta de facturación, boletines o soporte que se añade con un include gasta una. Al superarlo, el registro deja de evaluarse bien.

La cuarta es tener varios registros SPF sueltos en el mismo dominio, que es un error de configuración, no una suma.

La quinta es el DMARC eterno en modo de observación: se publicó p=none como primer paso, nadie leyó los informes y ahí sigue.

Cómo solucionarlo

El orden no es opcional: endurecer sin el inventario completo es la forma más rápida de tirar tu propio correo. Wakaris te dice qué falta y cómo está lo que hay.

Primero, haz la lista de quién envía en tu nombre: correo del equipo, tienda, facturación, boletines, formulario y soporte.

Segundo, publica un único registro SPF que incluya a todos ellos y termine en -all, o en ~all si prefieres red. Vigila el límite de diez consultas.

Tercero, firma tus envíos con DKIM en cada proveedor que lo permita. DMARC exige que el dominio visible esté alineado con el autenticado, y el reenvío rompe SPF porque las listas de correo reescriben el remite del sobre.

Cuarto, publica DMARC en _dmarc.tudominio.com con p=none y una dirección de informes agregados. Léelos unas semanas: enseñan quién usa tu dominio.

Quinto, avanza a quarantine y después a reject. El RFC 9989 ha eliminado la etiqueta de porcentaje, así que el avance ya no se hace aplicando la política a una parte del correo. Vuelve a pasar el dominio por Wakaris al terminar.

Imagen pendiente · {IMG_2}

Tabla con las tres políticas DMARC none, quarantine y reject y qué pide cada una al servidor destinatario

Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris.
Tema: Tabla con las tres políticas DMARC none, quarantine y reject y qué pide cada una al servidor destinatario.
Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía.
Formato: 16:9, 1440 píxeles de ancho.
Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen.
Sin logotipos reales ni marcas de terceros. Sin personas reconocibles.
Etiquetas: seguridad, correo, tabla, políticas, dmarc, none, quarantine, reject
Las tres políticas de DMARC. La primera solo observa; las otras dos son las que actúan.
Tabla con las tres políticas DMARC none, quarantine y reject y qué pide cada una al servidor destinatario
Las tres políticas de DMARC. La primera solo observa; las otras dos son las que actúan.

Pregúntale a tu IA

Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.

Prompt A

Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo

Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi dominio y decidir qué hacer con él, sin inventarte nada.

Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Seguridad del correo. Mi dominio no publica bien los dos registros de DNS que impiden que alguien envíe correo suplantándolo: SPF, que declara qué servidores pueden enviar en mi nombre, y DMARC, que dice qué hacer con los correos que no superan la comprobación. Referencia: se considera fallo que falten, que autoricen a cualquiera o que estén solo en modo de observación.

Pega aquí el resultado de Wakaris: qué te ha marcado en SPF, qué en DMARC y con qué forma exacta. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir.

Reglas que debes seguir en todo momento:

1. No asumas nada sobre mi dominio. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya comprobado. Si no lo sabes, pregúntamelo antes de afirmarlo.
2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde:
   a) ¿Con qué proveedor tienes el correo del equipo?
   b) ¿Qué otras cosas envían correo en tu nombre: la tienda, la facturación, los boletines, el formulario de la web, el soporte?
   c) ¿Sabes quién controla el DNS de tu dominio y puede añadir registros?
   d) ¿Has recibido avisos de clientes de correos raros que aparentaban venir de tu empresa?
   e) ¿Te consta que vuestros correos legítimos acaben con frecuencia en la carpeta de no deseado?
   f) Si hay que tocar el DNS, ¿lo harías tú, un técnico interno o una agencia?
3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso.
4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes comprobar, dilo: tú no ves mi dominio, razonas sobre lo que yo te cuento.
5. Avísame del riesgo antes de proponerme endurecer nada. Publicar una política estricta sin tener el inventario completo de quién envía en mi nombre puede hacer que se rechace correo legítimo mío: conviene ir por pasos y con informes.
6. Si necesitas un dato que solo se obtiene comprobando el dominio (qué hay publicado ahora mismo, o si el cambio ha surtido efecto), dímelo y recomiéndame volver a pasar la web por Wakaris: eso se comprueba, no se adivina.
7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí.
8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/seguridad-del-correo
Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Pégalo en la IA que uses.
Prompt B

Aún no lo he medido y quiero comprobar si mi web tiene este problema

Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi dominio tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho.

Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: la seguridad del correo de mi dominio. Consiste en que mi dominio no publique los registros SPF y DMARC, o los publique de una forma que no impide que alguien envíe correo suplantándome. Todavía NO sé si mi dominio lo tiene: quiero averiguarlo.

Reglas que debes seguir en todo momento:

1. Lo primero y más importante: esto se comprueba consultando los registros de DNS de mi dominio, y tú no puedes consultarlos desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente.
2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema:
   a) ¿Sabes si alguien configuró alguna vez SPF o DMARC en tu dominio?
   b) ¿Cuántas herramientas distintas envían correo en tu nombre: correo del equipo, tienda, facturación, boletines, formularios?
   c) ¿Has cambiado de proveedor de correo o has añadido herramientas nuevas sin revisar el DNS después?
   d) ¿Alguien te ha avisado alguna vez de correos sospechosos que aparentaban venir de tu empresa?
   e) ¿Quién lleva el dominio hoy: tú, un técnico interno, una agencia o nadie en concreto?
3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico.
4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá qué hay publicado realmente en SPF y en DMARC y de paso el estado de las otras áreas.
5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido y con información adicional que a mano no obtengo.
6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto.
7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/seguridad-del-correo
Para comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Pégalo en la IA que uses.

Preguntas frecuentes

¿Por qué un análisis de mi web me habla del correo? +

Porque SPF y DMARC viven en el DNS del mismo dominio que sirve la web. Quien suplanta tu correo daña la confianza en la misma marca, y el dato se obtiene en la misma consulta. Es la única comprobación del análisis que mira fuera del código de la página.

¿No basta con tener SPF? +

No. SPF valida el remitente del sobre que negocian los servidores, no la dirección que ve la persona. El RFC 7208 avisa de que un correo autorizado por SPF puede llevar otras identidades falsas. DMARC es el que exige que el dominio visible cuadre con el autenticado.

¿Qué significa tener DMARC con p=none? +

Que has pedido a los destinatarios que no hagan nada especial con los correos que fallan. El RFC 9989 lo describe como modo de observación: sirve para auditar tus envíos con los informes agregados antes de endurecer, pero por sí solo no bloquea ninguna suplantación.

¿Puede romperme el correo publicar una política estricta? +

Sí, si el inventario de quién envía en tu nombre está incompleto. Además, el reenvío complica las cosas: el RFC 7208 recoge que casi todas las listas de correo reescriben el remite del sobre, lo que hace fallar SPF en envíos legítimos. Por eso se avanza por pasos.

Fuentes citadas

  • rfc-editor.orgRFC 7208, Sender Policy Framework (SPF): la falsificación del remite es posible por defecto, publicación obligatoria como registro TXT, significado de +all, ~all, -all y ?all, límite de diez consultas de DNS y reescritura del remite por las listas de correo.
  • rfc-editor.orgRFC 9989, DMARC: obsoleta al RFC 7489, define las políticas none, quarantine y reject, describe el modo de observación y elimina la etiqueta de porcentaje.
  • rfc-editor.orgRFC 7489, DMARC (obsoleto): publicación del registro en el subdominio _dmarc y función de los informes agregados.
Retrato de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de datos · Bitanube

Juan Ignacio Franco es analista de datos en Bitanube. Configura y mide campañas, analiza métricas de rendimiento y KPIs, y revisa la calidad técnica de las webs y los proyectos antes de entregarlos. Los hallazgos de estas guías son los que aparecen en ese trabajo.

Actualizado: 7 de septiembre de 2026.

Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.

Compartir esta guía
Empieza ahora

Tu web tiene mucho que contarte
Y por fin vas a entenderla

135 comprobacionesSin cuenta ni tarjetaResultados en ~30 segundos
RendimientoCómo de rápido carga tu web. Si tarda, pierdes visitas y ventas antes de que te vean.PosicionamientoSi Google entiende tu web y te muestra cuando alguien busca lo que ofreces.SeguridadSi tu web está protegida. Un fallo aquí espanta a clientes y a Google por igual.PresenciaCómo apareces en Google, redes y mapas. Es la primera imagen que das antes de que te contacten.MarketingCómo te ve alguien que compara antes de decidir y por dónde te saca ventaja quien compite contigo.Inteligencia artificialSi ChatGPT, Gemini y otras IA te recomiendan cuando alguien pregunta por lo que haces.ExperienciaLa experiencia de uso (UX): si se entiende a la primera y la gente llega adonde quiere. Una web confusa se abandona aunque cargue rápido.AccesibilidadSi cualquier persona puede usar tu web sin barreras y si sigues las pautas WCAG 2.2. Más público que te entiende.LegalSi cumples con cookies y protección de datos. Evita sanciones y multas que duelen.

Suri

Asistente de Wakaris