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.

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:

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:

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í:

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:

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:

dig +short TXT your_domain @1.1.1.1

"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:

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:

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, [email protected]), ese otro dominio tiene que autorizarlo con un registro TXT adicional en su zona:

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.

Las etiquetas más habituales son:

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:

dig +short TXT _dmarc.your_domain @1.1.1.1

"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:

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>your_domain</header_from>
  </identifiers>
</record>

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:

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:

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:

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.