Configurar DMARC con p=reject de golpe puede bloquear correo legítimo

Para configurar DMARC sin bloquear correo legítimo, identifica primero todos los sistemas que envían con tu dominio y verifica que cada uno supere SPF o DKIM con un dominio alineado con el de De:. Publica después una política p=none para recibir informes, corrige los fallos de los emisores conocidos y avanza por etapas hacia p=quarantine y p=reject. La guía de Google recomienda activar SPF o DKIM antes de DMARC, esperar al menos 48 horas y empezar con p=none.

Un mensaje de facturación o una campaña enviada por un proveedor puede ser legítimo para tu empresa y, aun así, fallar DMARC. El resumen de DMARC.org explica que los entornos con remitentes externos pueden mezclar correo autorizado que se autentica correctamente con correo autorizado que no lo consigue. Si publicas p=reject antes de distinguir esos flujos, los receptores que apliquen la política pueden rechazar mensajes que esperabas entregar.

Haz un inventario de los envíos reales

Enumera el servidor de correo habitual, las aplicaciones que mandan avisos, las plataformas de campañas, los servicios de soporte y los proveedores que usan direcciones de tu dominio. Incluye los subdominios desde los que salen mensajes transaccionales o comerciales. Para cada flujo, registra la dirección visible en De:, el dominio de retorno usado en MAIL FROM, el dominio d= de la firma DKIM y la persona o el proveedor capaz de cambiar esos ajustes.

Contrasta el inventario con mensajes enviados de verdad: una integración antigua o un servicio contratado por otro equipo puede seguir activo aunque no figure en la configuración principal. Los encabezados de un mensaje recibido permiten observar los dominios empleados y el resultado de autenticación que registró ese receptor. Si un proveedor usa su propio dominio tanto para MAIL FROM como para DKIM, anótalo como un flujo pendiente de alineación antes de endurecer la política.

Comprueba qué dominio supera DMARC

DMARC exige que pase al menos una ruta completa: SPF con el dominio de MAIL FROM alineado con el de De:, o DKIM con una firma válida cuyo dominio d= esté alineado con el de De:. Un resultado «pass» de SPF o DKIM, por sí solo, no basta si corresponde únicamente al dominio del proveedor. En el modo relajado predeterminado pueden alinearse subdominios del mismo dominio organizativo; aspf=s y adkim=s exigen una coincidencia exacta.

Como ejemplo hipotético, un servicio envía con De: [email protected], MAIL FROM bajo proveedor.net y una firma DKIM válida con d=proveedor.net. SPF y DKIM podrían pasar para proveedor.net, pero ninguna de esas identidades se alinea con example.com. Puedes resolverlo si el servicio firma con d=example.com o si admite un MAIL FROM bajo tu dominio con SPF configurado para ese origen. Añadir servidores del proveedor al SPF de example.com no arregla por sí mismo el problema mientras el mensaje siga usando proveedor.net en MAIL FROM.

No actives la alineación estricta solo para endurecer la configuración: primero verifica los subdominios que usan tus emisores. El reenvío también puede romper SPF, y una lista de correo que modifica el mensaje puede invalidar DKIM. Esos fallos requieren examinar el trayecto del mensaje antes de clasificar su origen como una suplantación.

Publica una política de observación en DNS

Crea un registro TXT para _dmarc.example.com con este valor de ejemplo: v=DMARC1; p=none; rua=mailto:[email protected]. Sustituye el dominio y el buzón por los tuyos. v identifica la versión, p establece la política y rua indica dónde recibir los informes agregados; p=none solicita observación sin pedir cuarentena ni rechazo por DMARC, aunque el receptor puede aplicar otros filtros al mensaje.

Usa un buzón dedicado y comprueba que recibe correo. Según el panel DNS, quizá debas introducir _dmarc como nombre porque el proveedor añade automáticamente el dominio; consulta luego el TXT publicado en el nombre completo y verifica que no haya registros DMARC duplicados. Si envías los informes a una dirección de otro dominio, el operador de ese dominio debe publicar la autorización DNS correspondiente. No dependas de ruf para este despliegue: los informes individuales tienen una compatibilidad limitada, mientras que rua proporciona la vista agregada necesaria para detectar flujos.

Usa los informes para separar fallos y remitentes

Agrupa los registros agregados por IP de origen, dominio visible en De:, volumen y resultados de SPF y DKIM. Compara el resultado bruto de autenticación con el de alineación: SPF puede figurar como «pass» para el dominio de retorno y como fallo en la evaluación DMARC porque ese dominio difiere del visible. La misma distinción se aplica a una firma DKIM válida con d= del proveedor.

Relaciona las IP y los dominios con tu inventario antes de modificar SPF. Un origen conocido que falla necesita un cambio de configuración; una IP desconocida requiere investigación, no una autorización automática. Revisa los encabezados de algunos mensajes concretos cuando el informe no permita identificar qué ajuste falla. Los informes muestran patrones de los receptores que los envían, pero no todos los receptores generan informes, por lo que también conviene atender las incidencias de entrega.

Avanza hacia cuarentena y rechazo

Cuando los remitentes conocidos pasen DMARC y los fallos restantes estén investigados, cambia el registro de ejemplo a v=DMARC1; p=quarantine; rua=mailto:[email protected]. Observa los informes y los mensajes legítimos que terminen en spam o cuarentena antes de continuar. La secuencia de Microsoft propone monitorizar p=none, pasar a p=quarantine y finalmente a p=reject para evitar que fallos involuntarios provoquen el rechazo de correo válido.

La etiqueta pct permite aplicar la política a una parte de los mensajes que fallan; pct=10 sería un valor inicial de ejemplo durante una transición controlada. Ese porcentaje no identifica de antemano qué mensaje quedará afectado. Amplía el alcance solo después de comprobar el efecto de la etapa anterior. Publica p=reject cuando los flujos legítimos conocidos tengan una ruta SPF o DKIM alineada y las incidencias de entrega estén resueltas; conserva rua para detectar cambios posteriores en los proveedores.

Incluye los subdominios en la decisión

Un subdominio sin registro DMARC propio puede heredar la política del dominio principal. La etiqueta sp permite definir una política general distinta para los subdominios, mientras que un registro en _dmarc del subdominio establece su política específica. Antes de rechazar correo del dominio principal, identifica cuáles envían mensajes, cuáles dependen de proveedores externos y cuáles necesitan su propia etapa de observación.

Puede resultar más sencillo empezar por un subdominio con pocos emisores y repetir después el proceso en los más complejos. Cada flujo debe superar DMARC con el dominio que aparece en su propio campo De:. Así, una política estricta para el dominio principal no obliga a adelantar el rechazo en un subdominio cuyo proveedor todavía necesita corregir MAIL FROM o DKIM.

Lee también:

• El 98% despliega IA en atención, pero solo el 5% puede medir su impacto
• Bloquear una invitación en Calendar también corta al remitente en otros servicios
• Notion o ClickUp: configurar antes o ejecutar desde el primer día