DMARC: cómo pasar de p=none a p=reject sin perder correos

DMARC es el ajuste que de verdad protege tu dominio: le dice a quien recibe un correo «tuyo» qué hacer si no pasa las comprobaciones de SPF y DKIM, y te envía informes de quién está enviando con tu nombre. Muchas empresas lo tienen en p=none desde hace años, que no protege. Aquí explicamos cómo llegar a p=reject sin que se pierda ningún correo legítimo. Si quieres la visión general, la tienes en SPF, DKIM y DMARC: qué son y por qué tus correos acaban en spam.

DMARC se publica como un registro TXT en _dmarc.tudominio.es. Por ejemplo, para empezar:

v=DMARC1; p=none; rua=mailto:[email protected]

Desde mayo de 2026, DMARC es estándar oficial (RFC 9989), y estas son sus etiquetas:

• v=DMARC1: obligatoria y la primera.
• p: la política, none (ninguna preferencia), quarantine (sospechoso) o reject (rechazar).
• sp: la política para los subdominios; si no está, se aplica p.
• np: nueva en el estándar, la política para subdominios que no existen.
• adkim y aspf: la alineación de DKIM y de SPF, relajada (r, la de por defecto) o estricta (s).
• rua: dónde recibir los informes agregados.
• ruf y fo: los informes de fallo de mensajes concretos. Ni Gmail ni Microsoft 365 los envían.
• t: el modo de prueba (t=y).

Lo que desaparece: la etiqueta pct (el porcentaje de correos al que se aplica la política) se sustituye por t, y también desaparecen rf y ri. Pero ojo: a octubre de 2026, las guías de Microsoft y Google siguen usando pct y el estándar antiguo, y no consta que los servidores de correo ya interpreten t. En la práctica, hoy verás las dos.

Sobre la alineación: Google pone en su ejemplo adkim=s; aspf=s (estricta), pero Microsoft avisa de que la alineación estricta de SPF hace fallar los envíos desde subdominios. Para una pyme con herramientas que envían desde subdominios, lo prudente es dejar la relajada, que es la de por defecto.

Con rua, los servidores que reciben tu correo te envían cada día un informe agregado: un fichero XML (normalmente comprimido) con una fila por cada servidor que ha enviado correo con tu dominio, cuántos mensajes, y si han pasado SPF, DKIM y DMARC. Está definido en el RFC 9990, de mayo de 2026.

• Recíbelos en un buzón o un servicio dedicado, no en el de una persona: Google avisa de que pueden llegar muchos, y Microsoft recomienda un buzón específico o un grupo.
• No todos los servidores envían informes: según Microsoft, suelen cubrir entre el 70 % y el 90 % del correo.
• La pista clave al leerlos, según Microsoft: si SPF o DKIM aparecen como pass pero DMARC como fail, ese servicio está autorizado, pero no alineado con tu dominio. Hay que configurarlo para que firme o envíe con tu dominio.
• Si los informes van a una dirección de otro dominio (por ejemplo, un servicio externo), ese dominio tiene que publicar un registro que lo autorice (tudominio.es._report._dmarc.otrodominio); sin él, los servidores no envían los informes. Los servicios de informes suelen publicarlo ellos.

Microsoft lo plantea como objetivo: llegar a p=reject en todos tus dominios y subdominios. El camino, según su guía, la de Google y el propio estándar:

1. Antes de nada, SPF y DKIM funcionando en todo lo que envía con tu dominio. Google pide esperar 48 horas tras configurarlos.
2. p=none con rua, y leer los informes. Microsoft recomienda revisarlos cada semana al principio y cada mes cuando todo esté estable.
3. Corregir lo que salga: servicios que no estaban en SPF, que no firman con DKIM o que no están alineados.
4. p=quarantine, aplicándolo poco a poco: Microsoft propone empezar por un 10-25 % y subir al 50, 75 y 100 %.
5. p=reject. Microsoft aconseja empezar por los subdominios de menos volumen y dejar el dominio principal para el final, y el estándar avisa de que pueden hacer falta meses de informes antes de este paso.

Ojo con las herramientas que «configuran DMARC» por ti. Brevo, por ejemplo, ofrece autenticar el dominio automáticamente y, si ya tienes DMARC, te pregunta si quieres sustituirlo por el suyo, que en su ejemplo es v=DMARC1; p=none; rua=mailto:[email protected]. Si ya tenías quarantine o reject, aceptarlo bajaría tu protección a p=none; Brevo indica que, para conservar tu registro, hay que autenticar el dominio a mano. Solo puede haber un registro DMARC por dominio: si varias herramientas necesitan los informes, se añaden sus direcciones al mismo rua.

Si un subdominio no tiene su propio registro DMARC, hereda el del dominio principal (o el de sp, si lo has puesto). Pero cada subdominio que envía correo necesita su propio SPF y su propio DKIM.

Si tienes dominios que no usas para el correo (la variante con guiones, el .com además del .es, uno antiguo), cualquiera puede usarlos para suplantarte. La guía de la administración británica (gov.uk) recomienda publicar en ellos:

• SPF que no autoriza a nadie: v=spf1 -all.
• DMARC que lo rechaza todo: v=DMARC1; p=reject; sp=reject.
• Un registro MX nulo (prioridad 0 y valor .), para decir que no reciben correo.
• Una clave DKIM vacía.

Microsoft recomienda lo mismo en SPF y DMARC, pero en DKIM dice lo contrario: no publicar nada. Con SPF y DMARC así ya queda protegido.

En las cabeceras de un correo recibido, en Authentication-Results, verás dmarc=pass o dmarc=fail, y el dominio del remitente (header.from=) frente a los que han comprobado SPF y DKIM. O pasa tu dominio por nuestro analizador de correo, que revisa tu registro DMARC, su política y si tus correos tienen lo necesario para pasarlo.

Sí: pide al destinatario que trate como sospechoso (normalmente, a correo no deseado) lo que falla. p=reject va más allá y pide rechazarlo.

Solo si algún servicio legítimo no está bien configurado. Para eso están las fases y los informes: cuando los informes muestran que todo tu correo pasa, el cambio no se nota.

Microsoft recomienda cada semana durante el despliegue y cada mes cuando todo está estable, y siempre que se contrate una herramienta nueva que envíe con tu dominio.

En LN Digital configuramos SPF, DKIM y DMARC para que tus correos no acaben en spam y nadie pueda hacerse pasar por ti, dentro de nuestro mantenimiento de servidores. Escríbenos.

Consultadas el 20 de octubre de 2026.

• RFC 9989 (DMARC), secciones 4.7, 4.10, 5.1 y 7.1, y apéndice A.6; RFC 9990 (informes agregados); RFC 7489, al que sustituyen.
• Microsoft Learn: configurar DMARC.
• Google Workspace: configurar DMARC y despliegue recomendado.
• Gov.uk: proteger los dominios que no envían correo.
• Brevo: autenticar tu dominio (consultada el 21 de octubre de 2026).