Una política DMARC reject solicita rechazar mensajes que no superan DMARC. Con p=none puedes solicitar informes sin medidas restrictivas, aunque su envío no está garantizado; quarantine ya supone una solicitud de aplicación. Pasar demasiado pronto a p=reject puede afectar a facturas, recuperación de contraseñas y soporte legítimos. Para revisar las bases, empieza por correo empresarial.
Observar sin revisar emisores deja problemas sin resolver; endurecer una política DMARC reject sin pruebas también añade riesgos. Esta guía reúne requisitos, una transición orientativa y patrones de fallo relevantes en 2025 y 2026.
| Requisito | Objetivo | Por qué revisarlo antes de reject |
|---|---|---|
| Observación del tráfico | 30 días como referencia inicial | Revisar ciclos mensuales y ampliar para flujos raros o trimestrales |
| Auditoría de alineación | 100% de emisores legítimos alineados como objetivo | SPF o DKIM válidos sin alineación no bastan para DMARC |
| Reputación | Tasa de spam inferior a 0.1% como referencia del destinatario | La reputación y los fallos DMARC pueden coexistir |
| Reenvíos | DKIM válido y alineado conservado | SPF puede fallar en rutas indirectas |
| Subdominios | Etiqueta sp revisada | La herencia puede afectar a subdominios antiguos o de desarrollo |
Qué hace realmente DMARC reject
Una política DMARC reject solicita que el destinatario rechace mensajes cuando ni SPF ni DKIM pasen con la alineación exigida para tu dominio. Puede reducir ciertos usos de suplantación cuando se aplica, pero no garantiza bloqueo ni llegada a la bandeja de entrada.
La alineación es esencial: al menos una autenticación válida debe alinearse con el dominio From visible, según el modo relajado o estricto. Un indicador SPF o DKIM positivo por sí solo no basta.
Según RFC 7489, los destinatarios pueden considerar pct y aplicar criterio local. Una política DMARC reject no corrige reputación, contenido ni configuración de envío.
Requisito 1: observar 30 días antes de reject
No bases una política DMARC reject solo en una semana favorable. Treinta días son un referente práctico, no una garantía: facturación mensual, informes trimestrales y automatizaciones raras requieren pruebas o una observación más larga.
Revisar siete días, publicar p=reject y descubrir después que las facturas rebotan es un riesgo evitable con inventario y pruebas de cada ciclo.
Ejemplo: tu herramienta de facturación solo envía al principio del mes. Autentica con el dominio del proveedor, pero no se alinea con el tuyo. Con
p=noneel fallo puede pasar desapercibido; conp=rejectlas facturas podrían rechazarse.
Busca emisores poco frecuentes pero importantes: facturación, recursos humanos, avisos de escáneres, formularios y soporte. La política DMARC reject debe evaluarse después de identificarlos, no utilizarse como sustituto del inventario.
Revisa DNS antes de interpretar resultados. La guía de registros DNS necesarios de TrekMail explica los registros esperados para la modalidad de servicio, incluidos SPF, DKIM, MX y DMARC.
Requisito 2: auditar alineación y autenticación
Antes de una política DMARC reject, verifica SPF o DKIM válidos y alineados en cada emisor legítimo. Un servicio puede autenticar correctamente para su dominio y aun así no aportar alineación con tu From.
Un ejemplo habitual en SaaS:
From visible:
support@yourcompany.com
Return-Path:bounce.vendor-mail.com, donde SPF pasa
DKIM:d=vendor-mail.com, donde DKIM pasa
Resultado: DMARC falla parayourcompany.com
El panel del proveedor puede indicar autenticación válida sin que tu dominio esté alineado. Una política DMARC reject puede afectar a esos mensajes.
Las correcciones habituales son:
- Publicar los registros DKIM del proveedor y configurar la firma con tu dominio.
- Configurar un dominio propio de rebote o return-path para la alineación SPF.
- Probar mensajes reales y leer cabeceras.
Revisa SPF: el límite es de diez mecanismos o modificadores evaluados que provocan consultas DNS, no de todas las consultas de red. Varios TXT SPF producen un error permanente. La guía de configuración de dominios explica cómo evitar registros SPF duplicados.
Requisito 3: revisar reputación antes de reject
Una política DMARC reject puede limitar parte de la suplantación, pero no mejora por sí sola la reputación. Los mensajes auténticos también pueden recibir quejas, filtrado o rechazo por otras causas.
Las directrices citadas de Google recomiendan a remitentes masivos mantener spam por debajo de 0.1% y evitar 0.3% o más, que puede afectar a las medidas de mitigación. Las de Yahoo también señalan 0.3% como límite. Comprueba los requisitos vigentes y cómo define cada destinatario esas métricas.
Si Postmaster muestra 0.18%, investiga calidad de listas y relevancia. No descarta un problema DMARC simultáneo; revisa ambos antes de modificar la política.
Antes de una política DMARC reject, comprueba:
- La tasa de spam en Google Postmaster Tools para el dominio de envío.
- Picos de quejas ligados a campañas, listas o herramientas.
- Rebotes que sugieren datos antiguos o direcciones funcionales.
- Si mensajes transaccionales y marketing comparten reputación.
Referencias: preguntas frecuentes sobre requisitos de Google y buenas prácticas para remitentes de Yahoo.
Requisito 4: probar reenvíos con reject
Antes de una política DMARC reject, prueba las rutas de reenvío. SPF puede fallar porque el servidor intermediario no está autorizado por el dominio original. DKIM válido y alineado puede permitir DMARC si se conservan los datos firmados.
Un fallo SPF en agregados no demuestra suplantación. Si DKIM pasa alineado, DMARC pasa, pero listas y pasarelas pueden modificar cuerpo o cabeceras firmadas e invalidarlo.
Comprueba la canonicalización y la firma en cada flujo importante antes de la política DMARC reject. SRS puede ayudar a SPF con el nuevo sobre sin restablecer necesariamente la alineación original; ARC depende del criterio del destinatario.
La documentación TrekMail explica SPF fallido con DKIM válido en reenvíos y el envío gestionado disponible según el plan. Verifica la firma de tu dominio en mensajes reales. Consulta reenvío de correo para revisar las modificaciones de ruta.
También consulta Mis mensajes llegan al spam y configuración IMAP y SMTP. La autenticación alineada no garantiza entrega, y el SMTP saliente depende del plan.
Requisito 5: revisar subdominios antes del reject principal
Una política DMARC reject del dominio organizativo puede heredarse en subdominios como dev.example.com o alerts.example.com si no tienen política específica. Revisa sp y los registros propios antes de solicitar restricciones.
Inventaría también desarrollo, impresoras, escáneres y herramientas antiguas. Una configuración correcta en producción no demuestra que esos flujos estén preparados.
Este ejemplo utiliza sp para diferenciar la política heredada:
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.comSolicita reject para el dominio principal y none para subdominios que heredan este registro, no para los que tienen una política propia. Evalúa después si conviene endurecerlos.
Los informes pueden revelar servicios no inventariados, como CRM o relays antiguos, pero su cobertura es parcial y una fuente desconocida no demuestra abuso. La política DMARC reject debe apoyarse en un inventario independiente.
Aplicar reject por etapas
Valora una política DMARC reject después de pruebas y observación. Quarantine ya solicita una medida restrictiva; pct expresa aplicación parcial según el destinatario, no una transición garantizada.
Un ejemplo orientativo es:
- Solicitar quarantine al 10% durante una semana, con respuesta a incidencias preparada.
- Valorar quarantine al 100% durante otra semana o dos y ampliar según tus ciclos.
- Valorar reject tras probar soporte, facturación, autenticación y reenvíos.
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.comv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comLos registros anteriores son alternativas sucesivas: publica solo uno. Quarantine no garantiza que un mensaje sea recuperable; reject puede provocar rebotes y, según el fallo, reintentos. Con una política DMARC reject, un mensaje legítimo podría rechazarse antes de llegar al buzón.
Gestionar reject en varios dominios
Una política DMARC reject requiere más coordinación al pasar de un dominio a diez, cincuenta o quinientos. Cada proveedor tiene su configuración DKIM y cada dominio necesita un inventario actualizado.
Enfoque disperso: revisar XML manualmente, investigar IP, corregir dominios por separado y depender de avisos informales de nuevos emisores.
Enfoque coordinado: centralizar dominios, documentar DNS y mantener pruebas de autenticación reproducibles.
TrekMail anuncia planes de pago desde $3.50 al mes con SMTP gestionado según sus condiciones, y un panel para dominios, buzones IMAP, reenvíos y DNS. Nano se ofrece gratuito para hasta 10 dominios con SMTP propio. Consulta el modelo de alojamiento multidominio y comprueba las funciones vigentes.
La coordinación puede reducir tareas repetidas para equipos pequeños, agencias y MSP, pero no garantiza ahorro ni menos incidencias. Mantén procedimientos para actualizar emisores antes de una política DMARC reject.
Consulta los registros DNS necesarios y trekmail.net/pricing. Los planes de pago pueden incluir una prueba de 14 días con tarjeta requerida; Nano se ofrece sin tarjeta según las condiciones vigentes.
Conclusión: cuándo publicar reject
Para valorar una política DMARC reject, observa al menos 30 días como referencia y amplía para ciclos raros, verifica autenticación alineada, revisa quejas, prueba reenvíos y decide la herencia de subdominios. Ninguno de esos indicadores por separado demuestra preparación completa.
Inventaría emisores, lee cabeceras y corrige DNS y rutas antes de publicar la política DMARC reject. Después sigue supervisando: la solicitud puede ayudar frente a suplantación, pero no protege contra todos los engaños.
Para coordinar la infraestructura, consulta TrekMail o compara los planes en trekmail.net/pricing.
