SPF y DMARC cuando el servidor de correo es tuyo

Esta página no explica qué es SPF. Si tu MX apunta a máquinas vuestras —un Exchange, un Postfix, un appliance— eso ya lo sabes. Lo que falla en organizaciones como la tuya no suele ser la sintaxis: es que el registro deje de cubrir lo que hoy envía. Una aplicación de citas. Un boletín que contrató otro departamento. Una sede que manda por su cuenta. Eso no se ve desde fuera —el DNS no dice quién ni cuándo—, pero es lo que aparece en cuanto se leen los informes.

1. Cómo está hoy tu grupo

De los 1.072 dominios españoles de energía y sanidad que medimos, 251 no pudieron atribuirse a ninguna plataforma de nuestra lista por sus registros MX y SPF públicos. Ese grupo incluye servidores operados por la propia organización y también proveedores que no reconocemos: desde fuera no se distinguen. Así está, medido el 2026-08-14:

«Servidor propio» aquí quiere decir no atribuible con nuestra lista, no «mal configurado» — y no es una etiqueta que hayamos verificado uno a uno. Lo que sí se ve en la tabla es lo que publica cada dominio.

2. El inventario de emisores: el trabajo que la documentación se salta

La sintaxis de SPF es trivial. Saber qué meter dentro, no. Antes de tocar el registro, la lista:

• Los logs del MTA de salida: quién ha enviado en los últimos noventa días.
• Los informes RUA de DMARC, que es la mejor herramienta de descubrimiento —y por eso se publica DMARC antes de tocar nada—, pero parcial: solo reportan los receptores que participan, llegan agregados y con retraso, y un envío estacional (nóminas, certificados, una campaña anual) puede tardar semanas en aparecer. No autorices una IP solo porque sale, ni retires una fuente solo porque no sale.
• Las aplicaciones internas que mandan correo: monitorización, RRHH, gestión de citas, helpdesk, encuestas.
• Los contratos de otros departamentos: boletines, marketing, mensajería transaccional.

Sin esta lista, cualquier cambio en el SPF es a ciegas.

3. SPF con muchos emisores: los límites que os tocan a vosotros

4. Subdominios, sedes y delegaciones

SPF no se hereda, y se evalúa sobre el dominio que se usa como identidad —el MAIL FROM, o el HELO en algunos casos—, no sobre cualquier subdominio que aparezca en el From:. Cada identidad que envíe necesita el suyo; y a un nombre que existe y no debe enviar se le puede poner v=spf1 -all.

En DMARC manda el registro propio del subdominio si lo tiene. Si no, sp cubre los subdominios que existen y np los que no existen; a falta de ambos se aplica p. Es la parte que más se olvida en organizaciones con decenas de organismos colgando del mismo dominio, cada uno con su equipo.

5. El proveedor que contrató otro departamento

El patrón es: un subdominio visible dedicado por proveedor, con su d= de DKIM y su MAIL FROM alineados con ese subdominio, su propia clave y selector, y su propio DMARC. Así un proveedor que se va no obliga a tocar el dominio principal.

Pero conviene saber qué no hace por sí solo: con el alineamiento relajado que viene por defecto, quien controle el SPF o una clave DKIM de un subdominio puede autenticar un From: del dominio principal. Si necesitas una frontera de verdad, el alineamiento estricto —tras comprobar todos los flujos— o un dominio aparte.

Y con las claves: una distinta por sistema, publicar el selector nuevo antes de firmar con él, conservar el viejo un tiempo razonable y después retirarlo. Compartir la misma clave entre varios selectores se lleva por delante buena parte del aislamiento.

Lo que de verdad lo sostiene no es técnico: que no se pueda contratar envío de correo sin que pase por quien mantiene el DNS. El inventario es descubrir; esto es gobernar lo descubierto.

6. De p=none a reject sin perder correo legítimo

1. Si aún no tienes DMARC, publícalo en p=none con dirección de informes y léelos. No pide al receptor que cambie su disposición, aunque tampoco garantiza la entrega: cada receptor aplica además sus propias reglas. Si ya estás en quarantine o reject y funciona, no lo bajes.
2. Corrige el alineamiento, que es lo que decide DMARC. En un mensaje recibido fuera de la organización mira tres cosas: el dominio del From:, el del Return-Path que pasa SPF y el d= de la firma DKIM que pasa. DMARC pasa solo si al menos uno de los dos autenticados está alineado con el From:. Una firma válida de un proveedor no vale si su d= no es tu dominio.
3. Sube a p=quarantine cuando estés preparado para aplicarlo al conjunto. El pct parcial que se recomendaba antes se retiró del estándar porque los receptores lo aplicaban de forma inconsistente: no cuentes con una transición por porcentaje.
4. Y decide si el rechazo te toca. El RFC vigente desaconseja p=reject en dominios cuyos usuarios participan en listas de correo, porque el reenvío rompe la autenticación. Si lo adoptas, que todos los flujos lleven DKIM alineado: no dependas solo de SPF.

Cuánto tiempo en cada fase depende de tu volumen y de tus emisores. Como orientación, al menos un mes en cada una, y más si tienes envíos estacionales. Y el aviso honesto: un p=none que nadie lee no es una fase, es donde se quedan los despliegues que empezaron sin inventario.

7. El transporte, que aquí sí os toca

Quien opera sus propios MX puede además cerrar el cifrado en tránsito, y el orden importa: comprobar primero STARTTLS, los nombres de todos los MX y que los certificados sean válidos; publicar MTA-STS en testing junto con TLS-RPT; corregir lo que lleguen a reportar; y solo entonces pasar a enforce. En enforce, un emisor compatible no entregará por un MX sin TLS o con el certificado o el nombre mal. TLS-RPT por su cuenta da visibilidad, no impone nada.

8. Lo que exige la norma, sin humo

El ENS aplica a las administraciones públicas y a quien les presta servicios, y sus medidas de protección del correo electrónico están desarrolladas en las guías del CCN. Sobre la NIS2: a día de hoy no está transpuesta en España; lo exigible hoy es lo que ya obligaba. Lo ponemos al final a propósito: quien llega aquí viene a resolver, no a que le agiten la norma.

Preguntas frecuentes