Política DMARC: elegir none, quarantine o reject

Una política DMARC solicita al destinatario cómo tratar los mensajes que utilizan tu dominio y no superan DMARC. Puede ayudar frente a la suplantación, pero el destinatario conserva su criterio local. Una aplicación prematura también puede afectar a facturas, soporte o reenvíos legítimos. Para conocer la configuración completa, empieza por correo empresarial.

El problema suele estar en saltarse el inventario de emisores: publicar p=none indefinidamente sin revisar los informes, o pasar a p=reject antes de comprobar la autenticación y alineación de cada servicio. Eso puede poner en riesgo correo válido.

Una ruta habitual consiste en utilizar p=none para observar emisores, valorar p=quarantine después de corregir la autenticación alineada y plantear p=reject tras investigar los fallos restantes. No todos los fallos son suplantación, ni hay un calendario universalmente seguro.

Qué es una política DMARC

La política solicita una acción cuando un mensaje que usa tu dominio no supera DMARC. Las opciones son none, quarantine y reject. La elección depende especialmente de si tus emisores legítimos autentican y se alinean correctamente.

El destinatario comprueba SPF y DKIM, y la alineación de sus dominios con el From visible. Para aprobar DMARC basta que al menos uno pase su autenticación y esté alineado.

Si SPF pasa y se alinea, DMARC pasa.

Si DKIM pasa y se alinea, DMARC pasa.

Si ninguno aporta autenticación válida y alineada, se evalúa la política solicitada.

Qué política DMARC elegir primero

Empieza por p=none si no has comprobado la autenticación alineada de todos los emisores. Observar tráfico real permite valorar los riesgos antes de solicitar medidas más restrictivas.

Un registro inicial de supervisión es:

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

Este modo no solicita bloqueo frente a la suplantación ni garantiza la entrega. Puede aportar visibilidad si los destinatarios participantes envían informes; estos no cubren necesariamente todo el tráfico.

Emisores que suelen pasarse por alto:

1. Programas de contabilidad que envían facturas.
2. Herramientas de recursos humanos y selección.
3. Plataformas CRM y de marketing.
4. Sistemas de soporte que responden con el dominio principal.
5. Reglas personales de reenvío que afectan a SPF en el siguiente salto.

Sin observar esos flujos, una política restrictiva puede afectar a procesos reales. No conviene dar por identificados todos los emisores solo porque existe un TXT.

Para remitentes masivos, publicar DMARC forma parte de los requisitos de determinados destinatarios, como Google. Revisa los requisitos aplicables de autenticación y alineación. El estándar se describe en RFC 7489.

Cuánto tiempo mantener DMARC en none

Mantener none durante dos a cuatro semanas puede servir de orientación inicial, pero no garantiza observar flujos mensuales, trimestrales o excepcionales. Adapta la supervisión a tus ciclos reales de envío.

Tres días suelen aportar poca información: pueden quedar fuera facturas mensuales, comunicaciones trimestrales o aplicaciones antiguas que solo envían cuando se solicita recuperar una contraseña.

La observación debería cubrir:

1. Correo empresarial habitual.
2. Campañas de marketing.
3. Ciclos de facturación.
4. Escalaciones de soporte.
5. Correo reenviado.
6. Automatizaciones de terceros.

Revisa los informes agregados y contrástalos con tu inventario: distingue sistemas legítimos que requieren cambios, suplantación probable y fallos aún sin explicar. Los informes por sí solos no siempre revelan la causa.

Ejemplo: un boletín firma con el dominio de la plataforma y SPF también pasa para un dominio no alineado. DMARC falla aunque haya autenticación válida. Antes de solicitar rechazo, configura la alineación del emisor legítimo.

En TrekMail, el flujo DNS puede ayudarte a revisar los registros indicados y su verificación, según la modalidad de envío. Consulta añadir un dominio y registros DNS necesarios. Estas comprobaciones no sustituyen el inventario de servicios externos.

Por qué los reenvíos complican la política DMARC

El reenvío puede hacer fallar SPF al cambiar el servidor emisor. DKIM válido y alineado suele permitir que DMARC siga pasando si los datos firmados se conservan. Por eso conviene revisar DKIM, sin suponer que todos los reenvíos lo preservan.

La diferencia entre identidades de remitente es importante.

El usuario ve From; el servidor usa un remitente de sobre para los rebotes. SPF comprueba el dominio de esa identidad y la IP de envío. DMARC comprueba si un resultado SPF válido se alinea con el From visible.

Al reenviar, cambia la IP y puede dejar de estar autorizada por el SPF original. DKIM puede conservarse si no se modifican los datos firmados más allá de lo que tolera su canonicalización.

Así pueden darse estos resultados:

1. SPF falla después del reenvío.
2. DMARC pasa porque DKIM pasa y está alineado.

Antes de solicitar medidas restrictivas, prueba los reenvíos que importan a tu actividad y la firma alineada de tus emisores. Consulta reenviar correo de dominio a Gmail y, para resolver problemas de rutas, reenvío de correo.

ARC transmite contexto de autenticación entre intermediarios y listas, pero no sustituye la alineación propia ni garantiza que el destinatario acepte el mensaje. Está documentado en RFC 8617.

Cuándo pasar a quarantine

Valora quarantine después de comprobar que los emisores legítimos pasan SPF o DKIM con alineación. Solicita tratar los fallos como sospechosos; el destinatario puede aplicar excepciones u otras medidas.

El registro es:

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

Un emisor olvidado podría acabar en spam y revelar un problema, pero no puedes contar con que todos los mensajes se conserven allí o que los usuarios lo adviertan.

Para responder a una incidencia:

1. Recibe y verifica el aviso de correo ausente.
2. Inspecciona el emisor y la alineación.
3. Corrige SPF, DKIM o ambos según la causa.
4. Repite las pruebas antes de plantear reject.

Algunos equipos utilizan pct=25 o pct=50 para solicitar aplicación parcial. No todos los destinatarios respetan ese porcentaje del mismo modo. Incluso 100% expresa una solicitud, no una garantía de cobertura. Elige el avance según los riesgos y la evidencia, no solo el porcentaje.

En los planes TrekMail que incluyen SMTP gestionado, comprueba que la firma salga válida y alineada para tu dominio. En reenvíos puede fallar SPF y pasar DKIM; revisa la guía mis mensajes llegan al spam para el diagnóstico.

Cuándo pasar a reject

Valora reject después de resolver los fallos legítimos y analizar las causas desconocidas. Esta política solicita rechazar los mensajes que no superan DMARC, pero los destinatarios pueden aplicar sus excepciones locales.

El registro es sencillo:

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

Es un objetivo habitual para dominios cuyo tráfico legítimo ya se ha verificado.

Puede resultar útil porque:

1. Dificulta ciertos usos directos del dominio para suplantación cuando el destinatario aplica la política.
2. Puede reducir parte del riesgo de phishing y fraude empresarial.
3. Comunica a los destinatarios el tratamiento solicitado para los fallos.
4. Forma parte de una estrategia de protección de marca, sin cubrir todos los engaños.

Google describe límites y rechazos relacionados con autenticación y alineación, incluidos códigos como 4.7.31 y 4.7.32. Algunos rebotes mencionan 5.7.26 y la política del dominio. Consulta las preguntas frecuentes sobre requisitos para remitentes de Google para interpretar el contexto vigente.

Precaución: si contabilidad sigue enviando desde un servicio sin autenticación alineada, sus facturas podrían ser rechazadas. Confirma ese flujo antes de endurecer la política.

Qué registro DMARC publicar en DNS

Publica un único TXT de política en _dmarc.yourdomain.com. Aunque el valor sea breve, su configuración afecta al tratamiento solicitado para el correo del dominio.

Estos son ejemplos alternativos; no publiques los tres simultáneamente:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

En TrekMail, revisa conjuntamente MX, SPF, DKIM y DMARC según tu configuración real. El patrón siguiente es ilustrativo: la política quarantine no es una recomendación de activarla antes de inventariar los emisores.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

No publiques varios SPF ni inventes claves DKIM. Revisa los MX existentes antes de cambiarlos. Con un proveedor saliente propio, SPF y DKIM deben corresponder a ese servicio, no necesariamente al ejemplo. Consulta SMTP propio (BYO) y comprueba la alineación.

Errores habituales de política DMARC

Entre los problemas habituales están mantener p=none sin analizar el tráfico, aplicar restricciones antes de tiempo, depender solo de SPF y olvidar los subdominios. Pueden dejar una protección incompleta o afectar a correo legítimo.

Revisa estos puntos:

1. Dejar none durante meses sin un plan de revisión: no solicita bloqueo y los informes dependen de los participantes.
2. Ignorar la alineación DKIM porque SPF pasa: los reenvíos pueden exponer esa dependencia.
3. Olvidar la herencia de subdominios; utiliza sp= cuando necesites otra política.
4. Superar el límite SPF de 10 términos evaluados que provocan consultas DNS puede producir PermError; no es un simple recuento de consultas de red.
5. Confiar en un servicio que usa tu dominio sin verificar cómo autentica y firma.

Un ejemplo para subdominios es:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Solicita reject para el dominio principal y none para los subdominios que heredan esta política. No se limita a un subdominio concreto; los registros específicos pueden cambiar el comportamiento.

Cómo ayuda TrekMail a configurar DMARC

TrekMail puede coordinar dominios, almacenamiento y comprobaciones DNS según el plan. Esa coordinación reduce trabajo entre herramientas, pero la política exige conocer también todos los emisores externos y sus resultados reales.

Como referencia, Starter se anuncia desde $3.50 al mes con SMTP gestionado según sus condiciones. Nano se ofrece gratuito con SMTP propio. TrekMail utiliza IMAP y ofrece dominios propios, catch-all, reenvío, migración y API según el plan y la configuración; comprueba las condiciones vigentes.

Lo importante para DMARC no es solo publicar el TXT, sino controlar y verificar los sistemas que envían con tu dominio.

Según la configuración disponible, puedes:

1. Gestionar varios dominios desde un panel.
2. Verificar los registros DNS antes de activar el servicio.
3. Usar SMTP gestionado en los planes que lo incluyen o configurar SES/SendGrid con Nano.
4. Separar el alojamiento de buzones de la elección del proveedor saliente.
5. Importar correo antiguo mediante la migración IMAP compatible.

Para el flujo completo, consulta configurar correo en mi dominio. Para varias marcas o clientes, alojamiento de correo multidominio explica el modelo operativo.

Conclusión: avanzar con datos de none a reject

Una ruta habitual empieza por none, corrige autenticación y alineación, evalúa quarantine y después reject. Cada paso debe apoyarse en pruebas y observación, no en una casilla marcada.

En resumen:

1. Usa p=none durante 2 a 4 semanas como orientación inicial, ampliando el periodo para cubrir tus ciclos.
2. Configura SPF o DKIM válidos y alineados para cada emisor legítimo; revisa DKIM especialmente para reenvíos.
3. Valora p=quarantine como solicitud de tratamiento intermedio.
4. Valora p=reject tras resolver fallos legítimos e investigar los restantes.

Este proceso puede reducir la suplantación sin perder de vista el correo válido, pero no garantiza entrega ni protección total. Si quieres coordinar buzones, reenvíos y migraciones según tus necesidades, consulta la documentación o compara los planes de TrekMail en https://trekmail.net/pricing.