--- title: "Cómo configurar SPF y DMARC para el correo de tu dominio" description: "Publica un registro SPF y una política DMARC para tu dominio, compruébalos con dig y con las cabeceras de Gmail y pasa de p=none a p=reject sin perder correo." category: "Servidor de Correo" language: es source: https://cubepath.com/es/docs/servidor-de-correo/configuracion-de-spf-y-dmarc updated: 2026-09-25 --- # Cómo configurar SPF y DMARC para el correo de tu dominio SPF y DMARC son dos registros TXT de DNS que indican a los servidores de correo del mundo qué servidores pueden enviar en nombre de tu dominio y qué hacer con los mensajes que no pasan la comprobación. Sin ellos, cualquiera puede suplantar tu dominio y tus propios correos tienen más probabilidades de acabar en spam; Gmail y Yahoo exigen además SPF o DKIM a todos los remitentes, y DMARC a quienes envían grandes volúmenes. En este tutorial harás inventario de las fuentes que envían correo con tu dominio, publicarás un registro SPF y una política DMARC, los verificarás y desplegarás DMARC de forma progresiva hasta `p=reject`. ## Requisitos previos Para seguir esta guía necesitas: - Un dominio propio y acceso a la zona DNS en tu proveedor de DNS (el sitio donde gestionas los registros A y MX, que puede ser distinto del registrador). - Un equipo con `dig` para las comprobaciones. En Ubuntu 24.04 está en el paquete `dnsutils` (`sudo apt install dnsutils`). - Una lista de los servicios que envían correo con tu dominio: tu servidor de correo (por ejemplo, un VPS de CubePath con Postfix), Google Workspace o Microsoft 365, la plataforma de newsletters, el CRM, la facturación, etc. - Recomendado: DKIM ya configurado en tu servidor de correo. DMARC funciona con SPF solo, pero DKIM es lo que sobrevive a los reenvíos, así que conviene tener ambos antes de endurecer la política. En los ejemplos se usa `your_domain` como dominio, `203.0.113.10` como IP del servidor de correo y `2001:db8::10` como su IPv6. Sustitúyelos por tus valores. ## Cómo funcionan SPF y DMARC Un mensaje tiene dos remitentes distintos, y es importante no confundirlos: - El **remitente del sobre** (`MAIL FROM`, que aparece como `Return-Path` en las cabeceras): la dirección a la que vuelven los rebotes. **SPF** comprueba este dominio: el servidor receptor consulta el registro SPF del dominio del sobre y mira si la IP que le está entregando el mensaje está autorizada. - El **remitente visible** (cabecera `From:`): lo que ve el destinatario en su cliente de correo. SPF no lo comprueba. **DMARC** cierra ese hueco. Un mensaje pasa DMARC si pasa SPF o DKIM **y** el dominio que ha pasado está alineado con el dominio de la cabecera `From:`. Si no lo pasa, el receptor aplica la política que publiques (`none`, `quarantine` o `reject`) y te envía informes diarios con lo que ha visto. | Resultado SPF | Significado | |---|---| | `pass` | La IP está autorizada. | | `fail` | La IP no está autorizada y el registro termina en `-all`. | | `softfail` | La IP no está autorizada y el registro termina en `~all`. | | `neutral` | El registro termina en `?all`, no afirma nada. | | `none` | El dominio no tiene registro SPF. | | `permerror` | El registro es inválido (sintaxis, más de un registro, demasiadas consultas DNS). | ## Paso 1: Hacer inventario de las fuentes de correo Antes de escribir nada, comprueba si ya existen registros. Un dominio solo puede tener **un** registro SPF; si publicas un segundo, ambos quedan invalidados: ```bash dig +short TXT your_domain dig +short TXT _dmarc.your_domain ``` Si el primer comando devuelve una línea que empieza por `"v=spf1`, tendrás que editar ese registro en lugar de crear otro. Después anota cada servicio que envía correo con `@your_domain` en el `From:` y cómo se autoriza en SPF. Los proveedores publican el valor exacto en su documentación; algunos habituales son: | Servicio | Mecanismo SPF | |---|---| | Tu propio servidor | `ip4:203.0.113.10 ip6:2001:db8::10` | | Google Workspace | `include:_spf.google.com` | | Microsoft 365 | `include:spf.protection.outlook.com` | | Otros (newsletters, CRM, etc.) | El `include:` que indique el proveedor | > Nota: muchas plataformas de envío masivo usan su propio dominio en el remitente del sobre, así que añadir su `include:` a tu SPF no sirve para DMARC. Para que esos mensajes pasen DMARC, configura en la plataforma la firma DKIM con tu dominio (o un dominio de rebote personalizado bajo tu dominio). ## Paso 2: Escribir el registro SPF Un registro SPF empieza por `v=spf1`, sigue con los mecanismos que autorizan remitentes y termina con `all`, que se aplica a todo lo que no haya coincidido antes. Los mecanismos más útiles son: - `ip4:` e `ip6:`: una IP o un rango, por ejemplo `ip4:203.0.113.10` o `ip4:203.0.113.0/28`. - `a` y `mx`: las IP a las que resuelven los registros A/AAAA o MX del dominio. - `include:`: incorpora el SPF de otro dominio, normalmente el de un proveedor. El calificador de `all` decide qué pasa con lo demás: `-all` (fallo) es lo que quieres cuando el inventario está completo; `~all` (fallo leve) es razonable mientras lo estás completando. Para un servidor propio que además usa Google Workspace, el registro quedaría así: ```text v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com -all ``` Ten en cuenta estas reglas al construirlo: - **Máximo 10 consultas DNS.** Cada `include`, `a`, `mx`, `exists` y `redirect` cuenta, igual que los `include` anidados dentro de los de tus proveedores. Si te pasas, el resultado es `permerror` para todo el correo. `ip4` e `ip6` no consumen consultas, así que son la mejor opción para tus propios servidores. - No uses `ptr` (está desaconsejado) ni `+all` (autoriza a todo Internet). - Si el servidor tiene IPv6 y envía por ella, incluye su `ip6:`. Si no, Postfix puede usar IPv6 hacia Gmail y el mensaje fallará SPF. ## Paso 3: Publicar el registro SPF En el panel de tu proveedor de DNS crea (o edita) un registro: | Tipo | Nombre | Valor | TTL | |---|---|---|---| | TXT | `@` (el propio dominio) | `v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com -all` | 3600 | La mayoría de paneles añade las comillas por ti. Si el valor supera 255 caracteres, divídelo en varias cadenas dentro del mismo registro; los receptores las concatenan sin espacios. Comprueba que se ha publicado, consultando directamente a un resolvedor público: ```bash dig +short TXT your_domain @1.1.1.1 ``` ```output "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com -all" ``` Si no aparece, espera a que caduque el TTL del registro anterior y repite la consulta. ## Paso 4: Comprobar que SPF pasa La prueba definitiva es enviar un correo real desde cada fuente a una cuenta de Gmail y revisar las cabeceras. En Gmail abre el mensaje, pulsa los tres puntos y elige **Mostrar original**. Arriba verás un resumen como este: ```text SPF: PASS con la IP 203.0.113.10 DKIM: 'PASS' con el dominio your_domain DMARC: 'PASS' ``` En las cabeceras completas, la línea `Authentication-Results` da el detalle, incluido el dominio que se ha comprobado en cada caso: ```text Authentication-Results: mx.google.com; dkim=pass header.i=@your_domain header.s=mail; spf=pass (google.com: domain of user@your_domain designates 203.0.113.10 as permitted sender) smtp.mailfrom=user@your_domain; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your_domain ``` Fíjate en `smtp.mailfrom`: es el dominio del sobre, el que evalúa SPF. Si ahí aparece el dominio de tu proveedor de newsletters en lugar del tuyo, SPF pasará para ese dominio, pero no contará para DMARC. Repite la prueba con cada servicio del inventario. ## Paso 5: Crear la dirección para los informes DMARC Los receptores envían a diario un informe agregado en XML comprimido por cada dominio y cada fuente que ha visto. Pueden ser bastantes mensajes, así que usa un buzón o alias dedicado, por ejemplo `dmarc@your_domain`, en lugar de tu buzón personal. Si quieres recibir los informes en un dominio distinto (por ejemplo, `reports@example.net`), ese otro dominio tiene que autorizarlo con un registro TXT adicional en su zona: | Tipo | Nombre | Valor | |---|---|---| | TXT | `your_domain._report._dmarc.example.net` | `v=DMARC1` | Sin ese registro, los receptores descartan la dirección de informes. ## Paso 6: Publicar la política DMARC en modo monitorización La política se publica como registro TXT en el subdominio `_dmarc`. Empieza siempre con `p=none`: no cambia la entrega de ningún mensaje, pero activa los informes, que te dirán si alguna fuente legítima se te ha escapado del inventario. | Tipo | Nombre | Valor | TTL | |---|---|---|---| | TXT | `_dmarc` | `v=DMARC1; p=none; rua=mailto:dmarc@your_domain; fo=1` | 3600 | Las etiquetas más habituales son: | Etiqueta | Uso | |---|---| | `v=DMARC1` | Obligatoria y siempre la primera. | | `p=` | Política para el dominio: `none`, `quarantine` o `reject`. | | `sp=` | Política para los subdominios. Si no la indicas, heredan `p`. | | `rua=` | Dirección `mailto:` para los informes agregados. | | `ruf=` | Dirección para informes de fallo individuales. Pocos proveedores los envían. | | `adkim=` / `aspf=` | Alineación `r` (relajada, por defecto) o `s` (estricta). | | `fo=1` | Pide informes de fallo cuando falla cualquiera de los dos mecanismos. | Con alineación relajada, `mail.your_domain` se considera alineado con `your_domain`, que es lo que necesitas casi siempre. Deja `adkim` y `aspf` sin definir salvo que tengas un motivo concreto. Comprueba la publicación: ```bash dig +short TXT _dmarc.your_domain @1.1.1.1 ``` ```output "v=DMARC1; p=none; rua=mailto:dmarc@your_domain; fo=1" ``` Envía de nuevo un correo a Gmail y confirma en **Mostrar original** que aparece `DMARC: 'PASS'`. ## Paso 7: Leer los informes agregados A partir del día siguiente empezarán a llegar a `dmarc@your_domain` mensajes con adjuntos `.xml.gz` o `.zip`. Cada registro del XML indica una IP de origen, cuántos mensajes envió y el resultado de SPF, DKIM y DMARC: ```xml 198.51.100.25 142 none fail fail your_domain ``` Para cada IP que falla, averigua de quién es (`dig -x 198.51.100.25 +short` suele dar una pista) y decide: - Si es un servicio legítimo tuyo, añádelo a SPF o configura DKIM con tu dominio en ese servicio. - Si no la reconoces y envía con tu dominio en el `From:`, es suplantación: exactamente lo que DMARC va a bloquear. - Si es un servidor de listas de correo o un reenvío, es normal que falle SPF; con DKIM intacto el mensaje pasará DMARC. Leer XML a mano funciona con pocos informes. Con más volumen, usa un analizador como la herramienta de código abierto parsedmarc o un servicio de informes DMARC. ## Paso 8: Endurecer la política progresivamente Cuando los informes de dos a cuatro semanas muestren que todas tus fuentes legítimas pasan DMARC, sube la política. Edita el registro `_dmarc` y cambia solo el valor de `p`: ```text v=DMARC1; p=quarantine; rua=mailto:dmarc@your_domain; fo=1 ``` Con `quarantine`, los mensajes que fallan van a la carpeta de spam. Sigue revisando los informes un par de semanas más y, si no aparecen fuentes legítimas fallando, pasa a la política final: ```text v=DMARC1; p=reject; rua=mailto:dmarc@your_domain; fo=1 ``` Con `reject`, los receptores rechazan los mensajes que suplantan tu dominio. Mantén `rua`: los informes siguen siendo la forma de detectar un servicio nuevo que alguien de tu organización haya dado de alta sin configurar. En este momento también puedes cambiar `~all` por `-all` en el SPF si aún no lo habías hecho. ### Subdominios y dominios que no envían correo Si tus subdominios no envían correo, protégelos de la suplantación añadiendo `sp=reject` al registro DMARC del dominio principal. Un subdominio que sí envía (por ejemplo, `news.your_domain`) puede tener su propio registro `_dmarc.news.your_domain` y su propio SPF. Para un dominio que nunca envía correo (dominios aparcados o de redirección web), publica esta combinación, que le dice al mundo que cualquier mensaje con ese dominio es falso: | Tipo | Nombre | Valor | |---|---|---| | TXT | `@` | `v=spf1 -all` | | TXT | `_dmarc` | `v=DMARC1; p=reject;` | | MX | `@` | `0 .` (MX nulo: el dominio no recibe correo) | ## Solución de problemas **`permerror` en SPF por demasiadas consultas DNS**: cuenta los `include` recursivamente, por ejemplo con `dig +short TXT _spf.google.com` para ver lo que incluye cada uno. Elimina los servicios que ya no usas, sustituye `a` y `mx` por `ip4:`/`ip6:` explícitas y, si aún te pasas, mueve algún servicio de envío a un subdominio con su propio SPF. **Dos registros SPF**: `dig +short TXT your_domain` muestra dos líneas `v=spf1`. Combínalas en una sola con todos los mecanismos y borra la otra. **SPF pasa pero DMARC falla**: el dominio de `smtp.mailfrom` no es el tuyo (lo usa tu proveedor de envío) y DKIM no está firmado con tu dominio. Configura DKIM con tu dominio en ese proveedor o un dominio de rebote personalizado. **Correos reenviados que fallan DMARC**: cuando un servidor intermedio reenvía un mensaje, la IP ya no es la tuya y SPF falla. Por eso es imprescindible DKIM, que viaja con el mensaje. Asegúrate de que todas tus fuentes firman con DKIM antes de pasar a `p=reject`. **No llegan informes**: comprueba que `rua` empieza por `mailto:`, que el buzón existe y recibe correo externo, y que, si está en otro dominio, publicaste el registro de autorización del paso 5. ## Conclusión Has hecho inventario de las fuentes que envían con tu dominio, has publicado un registro SPF dentro del límite de consultas, has activado DMARC en modo monitorización y has visto cómo endurecer la política hasta `p=reject` usando los informes agregados. Tu dominio queda protegido frente a la suplantación y los receptores tienen una base sólida para confiar en tu correo. Como siguientes pasos puedes: - Configurar DKIM en tu servidor de correo si todavía no lo has hecho, para que DMARC no dependa solo de SPF. - Comprobar que el DNS inverso (PTR) de la IP de tu servidor coincide con el nombre que anuncia en el saludo SMTP. - Registrar tu dominio en Google Postmaster Tools para seguir la reputación y la tasa de spam de tu correo en Gmail.