Cómo configurar DMARC sin interrumpir el correo legítimo

Si buscas cómo configurar DMARC, la respuesta breve es esta: no pases directamente a p=reject. Empieza con una política de supervisión, comprueba que cada remitente autorizado supera SPF o DKIM con la alineación necesaria y aumenta las restricciones por etapas. Así puedes reducir la suplantación sin poner innecesariamente en riesgo las facturas, los restablecimientos de contraseñas o el correo de una herramienta SaaS que alguien olvidó mencionar.

Muchas guías presentan DMARC como algo más sencillo de lo que es. Un dominio envía desde Microsoft 365, la facturación usa una aplicación externa, marketing trabaja con otra plataforma y la fotocopiadora del almacén sigue enviando documentos escaneados. Si olvidas un remitente, una medida de seguridad puede convertirse en una interrupción. Si también estás configurando el correo del dominio, consulta cómo configurar el correo en tu dominio y la guía más amplia de correo empresarial.

Esta guía aborda la configuración de DMARC desde la operación diaria: observar, reunir pruebas, corregir la alineación y después aplicar restricciones. Con atención a los riesgos reales, sin presentar el proceso como un trámite automático.

Qué hace realmente DMARC

DMARC publica en DNS una política que indica a los servidores receptores cómo se solicita tratar los mensajes que usan tu dominio en el remitente visible pero no superan la autenticación con alineación. Se apoya en SPF y DKIM. DMARC pasa cuando al menos uno supera su verificación y queda alineado con el dominio visible de From.

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Permite publicar una política para los mensajes que no superan DMARC y solicitar informes sobre el uso de tu dominio como remitente. La especificación básica es RFC 7489; un resultado satisfactorio no garantiza que el contenido sea seguro.

Para entender cómo configurar DMARC, empieza por esta regla:

• SPF puede pasar sin que DMARC pase si el dominio autenticado no está alineado con From y DKIM tampoco aporta un resultado válido y alineado.
• DKIM puede pasar sin que DMARC pase por la misma razón, si SPF no aporta el resultado válido y alineado que falta.
• DMARC pasa si SPF o DKIM supera su verificación y está alineado con From. Basta con uno de los dos.

Las directrices de Google citadas exigen a los remitentes masivos SPF, DKIM y un registro DMARC cuya política mínima sea p=none. Para cumplir DMARC, SPF o DKIM debe pasar con alineación respecto a From. Revisa los requisitos vigentes y su ámbito en las preguntas frecuentes sobre las directrices de envío de Google.

Qué revisar antes de configurar DMARC

Antes de publicar una política DMARC, comprueba la configuración de envío. Un SPF incorrecto, la ausencia de DKIM o las firmas con otro dominio pueden producir fallos de DMARC. Detectarlos resulta útil; aplicar restricciones antes de resolverlos puede interrumpir el correo legítimo.

Hay tres comprobaciones iniciales.

1. SPF: publica un único registro SPF válido en cada dominio usado realmente como remitente del sobre. Respeta el límite de 10 mecanismos o modificadores que requieren consultas DNS, contando también las evaluaciones anidadas; no es un límite de consultas DNS totales.
2. DKIM: actívalo en las plataformas de envío que lo admitan. Usa claves de 2048 bits cuando el proveedor y su configuración lo permitan.
3. Inventario: enumera todos los servicios que envían con tu dominio: plataforma de correo, CRM, facturación, soporte, formularios, escáneres y herramientas de marketing.

En dominios de TrekMail, consulta los registros DNS necesarios y cómo añadir un dominio. Las comprobaciones disponibles pueden detectar registros publicados y errores habituales, como SPF duplicados, pero no sustituyen la verificación de mensajes reales ni de las respuestas DNS externas.

Ejemplo: la aplicación de facturación envía desde billing@yourdomain.com, pero firma con el dominio del proveedor y usa su return-path. SPF y DKIM pasan para esos dominios, pero ninguno está alineado con el tuyo. DMARC falla para tu dominio.

Ese desajuste de alineación explica muchas incidencias en las que el correo deja de funcionar tras activar restricciones DMARC.

Paso 1: publicar una política DMARC de supervisión

Para una implantación gradual suele ser útil empezar observando. Una política p=none solicita informes sin pedir cuarentena ni rechazo por DMARC. Los informes no están garantizados y los receptores pueden seguir aplicando sus filtros locales.

Crea un registro TXT en _dmarc.yourdomain.com con este valor:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

La misma entrada en formato de archivo de zona, no un registro adicional:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

El ejemplo sigue el formato de RFC 7489. Usa una dirección o un alias dedicado y supervisado para los informes, con controles de acceso y tratamiento adecuados. Los informes agregados son XML y pueden acumularse rápidamente. Un destino externo puede necesitar autorización DNS en el dominio que recibe los informes.

Después de publicar el registro, verifica las respuestas DNS y la autenticación de mensajes enviados por cada servicio. Las preguntas frecuentes sobre mensajes que llegan a spam también pueden ayudarte a investigar fallos, distinguiendo los efectos del reenvío de otros problemas.

Paso 2: leer los informes e identificar los remitentes

Este paso suele omitirse al configurar DMARC. Los informes aportan datos de los receptores participantes, no un inventario completo de todo el correo. Ayudan a investigar servicios autorizados, errores de configuración y posibles suplantaciones, pero no clasifican por sí solos el tráfico como legítimo o abusivo.

Los informes DMARC suelen mostrar:

• Las IP de origen que enviaron mensajes con tu dominio
• Los resultados de SPF
• Los resultados de DKIM
• La alineación de esos resultados con el dominio de From
• La disposición aplicada por el receptor

Conviene separar dos grupos para investigar.

Primero, los remitentes autorizados que fallan la alineación y necesitan ajustes. Segundo, las fuentes que todavía no reconoces. Una IP desconocida puede pertenecer a un reenvío o a una infraestructura compartida; no demuestra por sí sola una suplantación.

Estos casos son ilustrativos; los resultados dependen de la configuración y del mensaje:

Con muchos dominios, cada herramienta SaaS nueva requiere revisar el envío. Por eso algunas agencias estudian el alojamiento de correo para varios dominios y una gestión más ordenada de los buzones, sin asumir que cambiar de plataforma elimina estas tareas.

Paso 3: corregir la alineación, no solo la autenticación

Configurar bien DMARC exige un resultado satisfactorio y alineado. SPF o DKIM puede pasar con otro dominio y no servir para DMARC, pero basta con que el otro mecanismo pase y esté alineado. En modo relajado, el dominio autenticado debe compartir el dominio organizativo con el de From; no basta cualquier relación entre dominios padre e hijo.

RFC 7489 define la alineación relajada por el mismo dominio organizativo entre el dominio autenticado mediante SPF o firmante de DKIM y el dominio de RFC5322.From. Las preguntas frecuentes de Google indican que basta con un mecanismo válido y alineado para DMARC, aunque los remitentes masivos deben configurar ambos métodos.

Estas son las correcciones habituales:

• Plataformas de marketing: configura la firma DKIM con tu dominio.
• Gestión de rebotes: configura un return-path o dominio de rebotes propio si el proveedor lo permite, y comprueba la alineación.
• Microsoft 365: activa DKIM para el dominio personalizado antes de aplicar restricciones, si ese es el mecanismo de alineación elegido.
• Envío gestionado de TrekMail: publica exactamente los registros SPF y DKIM indicados para el servicio de salida que utilizas realmente.

La configuración debe corresponder al remitente de salida real. El alojamiento con facturación por usuario también puede ofrecer herramientas DNS; TrekMail propone separar los buzones del motor de envío, con SMTP gestionado en los planes de pago que lo incluyen o SMTP propio en Nano según las condiciones del plan. El proveedor SMTP elegido debe quedar configurado y verificado.

En la oferta descrita, Nano utiliza tu proveedor SMTP y los planes de pago incluyen SMTP gestionado. TrekMail presenta precios desde $3.50 al mes, una prueba de 14 días para planes de pago sujeta a sus condiciones y Nano sin coste ni tarjeta según la oferta aplicable. Comprueba los requisitos de la prueba y las prestaciones actuales en la página de precios de TrekMail.

Paso 4: evaluar una política de cuarentena

Cuando los remitentes autorizados pasan con alineación y has validado los flujos relevantes, puedes valorar la cuarentena. Ya es una política restrictiva: solicita tratar de forma especial los mensajes que fallan DMARC. El receptor decide su aplicación; no garantiza una carpeta de spam concreta, la recuperación del mensaje ni que sea el paso adecuado para todos los dominios.

Sustituye la política anterior por esta, sin publicar ambas:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

¿Por qué evaluar cuarentena antes del rechazo?

• Puede reducir la exposición a determinados intentos de suplantación.
• Puede permitir investigar errores con un tratamiento menos estricto, pero no garantiza la recuperación del correo.
• Permite probar una etapa restrictiva, siempre con evaluación del riesgo y seguimiento de los flujos críticos.

¿Cuánto tiempo conviene observar? Depende de tus flujos. Un par de semanas puede ser una referencia inicial en dominios pequeños; 30 días en dominios con muchos proveedores también es solo una referencia, no una prueba de preparación.

Comprueba además sistemas poco frecuentes: un complemento de WordPress, un entorno de pruebas del CRM, una fotocopiadora antigua o un proveedor que envía mensualmente. Los procesos trimestrales o excepcionales pueden exigir más tiempo y pruebas específicas; la cuarentena no es un margen de seguridad garantizado.

Paso 5: pasar al rechazo tras validar los flujos

La política p=reject solicita al receptor rechazar los mensajes que fallan DMARC, en vez de limitarse a tratarlos como sospechosos. Puede contribuir a reducir la suplantación directa del dominio, pero no bloquea todas las formas de fraude.

La política de esa etapa suele tener este aspecto:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Según RFC 7489, p=reject solicita el rechazo de los mensajes que fallan DMARC. Los receptores pueden aplicar excepciones y políticas locales; no garantiza el bloqueo universal ni la entrega del correo legítimo en la bandeja de entrada.

Antes de avanzar, comprueba lo siguiente:

• El proveedor principal supera SPF o DKIM con alineación
• Las herramientas de marketing y transaccionales también superan un mecanismo alineado
• Has revisado varias semanas de informes y probado los flujos críticos poco frecuentes
• Entiendes los fallos pendientes y sus consecuencias

Después, sigue observando los informes disponibles y probando cambios. La configuración de DMARC forma parte de la gestión continua del correo.

Errores habituales que interrumpen el correo

Además de conocer las políticas, necesitas conocer los remitentes. Un servicio olvidado, un SPF duplicado, DKIM sin activar o la autenticación predeterminada de un proveedor pueden causar fallos al imponer restricciones. La política de supervisión, por sí sola, no crea esos fallos.

• Aplicar restricciones antes de contar con SPF o DKIM válido y alineado
• Publicar varios registros SPF en vez de consolidar las autorizaciones en un único registro válido
• Suponer que SPF válido implica DMARC válido
• Olvidar proveedores de poco volumen cuyos mensajes pueden ser críticos
• Pasar directamente de no tener DMARC a p=reject
• Enviar informes a un buzón que nadie revisa

En alias y reenvíos, SPF puede fallar y DKIM aún permitir que DMARC pase, siempre que la firma siga siendo válida, alineada y con los datos firmados conservados tras la canonicalización. No ignores automáticamente esos fallos. Consulta el reenvío con alias de correo y el correo seguro para empresas para ampliar la revisión operativa.

Lista práctica para configurar DMARC

Esta lista resume una implantación gradual. Ayuda a organizar las comprobaciones, pero no garantiza una transición sin incidencias.

1. Revisa todos los sistemas que envían con tu dominio.
2. Publica un único SPF válido en cada dominio del sobre que corresponda.
3. Activa y verifica DKIM en cada plataforma de envío compatible.
4. Publica v=DMARC1; p=none; rua=mailto:....
5. Investiga los informes y contrástalos con tu inventario de remitentes.
6. Comprueba un mecanismo válido y alineado para cada remitente autorizado.
7. Valora pasar a p=quarantine tras probar los flujos.
8. Revisa de nuevo los informes y el funcionamiento real.
9. Pasa a p=reject cuando las pruebas y la evaluación del riesgo lo justifiquen.

Conclusión: configurar DMARC con una implantación controlada

Una secuencia habitual es empezar con p=none, investigar los informes junto con el inventario, corregir la autenticación y la alineación, evaluar p=quarantine y después p=reject. Puede reducir el riesgo al aplicar restricciones contra la suplantación, pero requiere pruebas y seguimiento.

Con un dominio, la coordinación puede ser manejable; con decenas o cientos, necesitas procesos más claros. Según el plan y la oferta vigente, TrekMail ofrece dominios personalizados, buzones IMAP, catch-all, reenvío, herramientas de migración y SMTP propio o incluido. La copia por IMAP no sustituye el cambio de MX ni migra automáticamente todas las aplicaciones. Revisa límites y precios: estas herramientas no eximen de configurar DMARC ni garantizan ahorro frente a la facturación por usuario.

Ese es el enfoque operativo de cómo configurar DMARC: observar primero, comprobar los remitentes y aplicar restricciones después. Basa las decisiones en los informes disponibles y en pruebas reales, no en suposiciones.