Los principales proveedores de buzones no «pasan por alto» una política DMARC establecida con p=reject: los servicios de consumo —Gmail y Outlook.com— rechazan por defecto los mensajes que fracasan las comprobaciones DMARC, y lo mismo ocurre en las versiones empresariales, Google Workspace y Microsoft 365.
Qué significa que rechacen p=reject
Una política DMARC con p=reject indica al receptor que debe no entregar el mensaje que no supera las comprobaciones de autenticación (SPF y/o DKIM) y alineamiento. Cuando un proveedor dice que «rechaza» ese correo, la práctica habitual es que el servidor de recepción lo rechace durante la sesión SMTP (respuesta 5xx) o lo bloquee antes de que llegue al buzón del destinatario.
Los matices: por qué puede parecer que no se rechaza
- Cambios históricos: Microsoft cambió en el pasado cómo maneja ciertas políticas DMARC, por lo que quien recuerde un comportamiento más permissivo no está equivocado. Sin embargo, las políticas actuales de Microsoft y Google muestran rechazo por defecto frente a p=reject.
- Controles administrativos en entornos empresariales: Los administradores de Microsoft 365 y, en menor medida, de Google Workspace, pueden aplicar reglas internas que alteren el tratamiento de correo dentro de su propio tenant. Es decir, aunque el proveedor tenga un comportamiento por defecto de rechazo, un administrador puede decidir retener, mover a cuarentena o aplicar otras acciones a los mensajes para sus usuarios.
- Casos de entrega alternativa: Rechazar en SMTP es la opción técnica más clara, pero algunos flujos empresariales pueden implementar cuarentenas o carpetas de spam internas antes de decidir la eliminación definitiva. Esto no equivale a «ignorar» p=reject: es un procesamiento posterior realizado por la administración del dominio receptor.
Qué debe hacer el administrador o dueño de la web
- Implementar DMARC correctamente: Antes de publicar p=reject conviene haber monitorizado el tráfico con una política de solo informe (p=none) o cuarentena (p=quarantine) para detectar fuentes legítimas que necesitan ajuste de SPF/DKIM.
- Corregir autenticación de envío: Asegúrese de que todos los envíos legítimos firmen DKIM y/o pasen SPF con alineamiento con el dominio visible en From. Esto incluye servicios de marketing, plataformas de facturación, remitentes externos y subdominios.
- Probar antes de aplicar p=reject: Use los informes DMARC (RUA/RUF) y pruebas puntuales para verificar que los mensajes legítimos no se vean bloqueados antes de pasar a p=reject.
- Coordinar con administradores receptores: Si sus destinatarios son organizaciones con políticas internas, puede ser útil coordinar cambios significativos en la política de envío (por ejemplo, un volumen alto de notificaciones) para evitar impactos inesperados.
Recursos y documentación
Los proveedores han publicado guías y notas sobre cómo manejan DMARC y las opciones disponibles para administradores de tenant en Google Workspace y Microsoft 365. Además, la especificación DMARC (RFC) recoge el comportamiento esperado para p=reject, aunque la operativa final puede incluir reglas internas del receptor.
En resumen: publicar p=reject no será ignorado por Gmail ni Outlook.com, ni por las versiones empresariales de Google y Microsoft; pero los administradores y operadores de correo pueden introducir reglas o procesos que modifiquen cómo se trata el correo fallido dentro de sus entornos. Por tanto, la preparación y la verificación previa siguen siendo pasos indispensables antes de aplicar un rechazo estricto.
Lee también:
