Autenticación de dominios · 21 de septiembre de 2026
DMARC p=none, quarantine o reject: guía para operadores
Elegir la política DMARC adecuada es un equilibrio entre seguridad y entregabilidad. Conozca la ruta de despliegue segura de p=none a p=reject para evitar la suplantación sin bloquear el correo legítimo.
La disyuntiva fundamental
Elegir una política DMARC es elegir entre visibilidad y cumplimiento. p=none ofrece monitoreo sin afectar a la entrega. p=quarantine envía el correo sospechoso a la carpeta de spam. p=reject bloquea por completo el correo no autenticado. La ruta más segura es un despliegue por fases: empiece con none para identificar a todos los remitentes legítimos, pase a quarantine para probar el impacto y, por último, llegue a reject para proteger completamente su dominio contra la suplantación.
Por qué la política importa para la cola de incidentes
Como ingeniero responsable de la entregabilidad, su objetivo principal es garantizar que el correo transaccional legítimo llegue al destinatario e impedir al mismo tiempo que los atacantes usen su dominio. Si salta directamente a p=reject sin una fase de monitoreo, probablemente provocará un incidente de alta prioridad cuando un sistema heredado olvidado o una herramienta de marketing de terceros deje de entregar correo de repente.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) se basa en la alineación de SPF y DKIM. Si un mensaje falla ambos, la etiqueta p= le indica al servidor de correo receptor exactamente qué hacer con ese mensaje.
Los tres niveles de política
1. p=none (modo de monitoreo)
En este modo, el receptor no hace nada con el mensaje, sean cuales sean los resultados de la autenticación. Sirve únicamente para recopilar datos.
Cuándo usarlo:
- En la configuración inicial de DMARC.
- Cuando no está seguro de conocer todos los servicios que envían correo en su nombre.
- Durante una migración a una nueva API de correo electrónico.
El payload:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
La contrapartida: no tiene ninguna protección contra la suplantación. Los atacantes pueden seguir enviando correo en nombre de su dominio, pero usted lo verá en sus informes RUA (agregados).
2. p=quarantine (cumplimiento moderado)
Los mensajes que fallan DMARC se tratan como sospechosos. La mayoría de los receptores los moverá a la carpeta de spam o de correo no deseado.
Cuándo usarlo:
- Después de analizar los informes de
p=noney verificar que todos los flujos legítimos están alineados. - Como margen de seguridad antes de pasar al rechazo total.
El payload:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;
La contrapartida: reduce la visibilidad del correo suplantado, pero no lo elimina. Parte del correo legítimo podría seguir llegando a spam si sus claves DKIM rotan de forma incorrecta o si los registros SPF alcanzan el límite de 10 consultas DNS.
3. p=reject (cumplimiento total)
Es el estándar de referencia en seguridad de dominios. El servidor receptor se negará rotundamente a aceptar el mensaje si falla DMARC.
Cuándo usarlo:
- Cuando su monitoreo muestra un 99,9 % de alineación en todo el tráfico legítimo.
- Cuando el riesgo de suplantación del dominio supera el riesgo de un fallo de entrega ocasional.
El payload:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;
La contrapartida: no hay red de seguridad. Si un sistema crítico está mal configurado, el correo se pierde. Verá esos fallos en los informes RUA, pero el usuario nunca recibe el correo.
Lista de verificación de despliegue para operadores
No cambie de política por intuición. Hágalo según los datos de sus informes agregados. Use una herramienta como el Verificador de DNS de correo de SendHQ para comprobar que sus registros se propagan correctamente antes de cada cambio.
Fase 1: descubrimiento (p=none)
- Publique
p=nonecon una direcciónrua. - Espere de 7 a 14 días para capturar un ciclo de negocio completo de correos (incluidos los informes semanales).
- Analice los informes en busca de tráfico «no alineado».
- Identifique a los remitentes legítimos de terceros (p. ej., Zendesk, Salesforce, Shopify).
- Configure DKIM para cada remitente identificado. Es la forma más confiable de garantizar la alineación.
Fase 2: pruebas (p=quarantine)
- Actualice la política a
p=quarantine. - Vigile sus tickets de soporte en busca de «No me llegó el correo» o «El correo está en spam».
- Revise los informes RUA en busca de nuevos picos de fallos.
- Si se producen fallos, corrija la autenticación y permanezca en
quarantineotra semana.
Fase 3: refuerzo (p=reject)
- Actualice la política a
p=reject. - Verifique que sus flujos transaccionales más críticos (restablecimientos de contraseña, facturas) siguen entregándose.
- Mantenga el monitoreo. DMARC no es una configuración que se pueda «configurar y olvidar».
El correo como efecto secundario
Para los ingenieros de producto que construyen agentes de IA o flujos de trabajo automatizados, enviar un correo es un efecto secundario externo. Esto significa que puede fallar por motivos ajenos a la lógica de su aplicación (problemas de DNS, rechazo por DMARC, límites de frecuencia).
Idempotencia y aprobación
Cuando un agente de IA desencadena un correo, debe evitar envíos duplicados durante los reintentos. Use una clave de idempotencia en sus solicitudes a la API para garantizar que un timeout de red no haga que el cliente reciba el mismo correo cinco veces.
Además, los agentes no deberían tener permiso autónomo para enviar correos de alto impacto. Implemente una cola de aprobación para el contenido generado por agentes, de modo que la dirección «From» y el contenido estén alineados con su marca y sus políticas de autenticación.
El costo de la infraestructura de entrega
El proveedor de envío que elija influye en cómo gestiona DMARC. Algunos proveedores hacen que configurar DKIM sea trivial, mientras que otros exigen entradas DNS manuales para cada subdominio.
Al evaluar costos, fíjese en el costo total de propiedad. Por ejemplo, enviar 50.000 correos cuesta aproximadamente 5 USD con Amazon SES en modalidad de pago por uso (a 0.10 USD por cada 1.000 correos), mientras que los niveles de Postmark costarían unos 66 USD por el mismo volumen (15 USD por 10.000 más excedentes de entre 1.20 y 1.80 USD por cada 1.000).
Otras opciones son Resend, que ofrece un plan gratuito de 3.000 correos al mes (con un máximo de 100 al día), o Mailgun, desde 15 USD al mes por 10.000 correos. SendGrid ahora usa una prueba de 60 días como plan gratuito, y Essentials empieza en 19.95 USD al mes.
Sea cual sea el proveedor, la política DMARC sigue siendo el escudo principal de su dominio. Si usa un proveedor que solo admite SPF, corre un mayor riesgo de fallos de entrega al pasar a p=reject, porque SPF se rompe con el reenvío de correo. DKIM es la única forma de mantener la alineación a través de los reenvíos.
Modos de fallo habituales
La trampa del reenvío
El usuario A envía un correo al usuario B. El usuario B tiene un reenvío automático al usuario C. El servidor que reenvía suele cambiar el remitente del sobre a su propio dominio para no ser marcado como spam. Esto rompe la alineación de SPF. Si tiene p=reject y ninguna firma DKIM, el usuario C nunca verá el correo.
El límite de consultas DNS
Los registros SPF están limitados a 10 consultas DNS. Si agrega demasiados proveedores a su registro SPF, el receptor devolverá un permerror. Esto provoca un fallo de DMARC. Para resolverlo, use un proveedor que priorice la autenticación con DKIM o aplique el aplanamiento de SPF.
El problema de la «TI en la sombra»
Los equipos de marketing suelen darse de alta en herramientas nuevas (p. ej., un nuevo servicio de newsletters) sin avisar a ingeniería. Envían correo desde su dominio, falla DMARC y se rechaza. Por eso la fase p=none no es negociable.
Tabla resumen para operadores
Política | Acción | Riesgo | Visibilidad | Uso recomendado
p=none | Ninguna | Bajo | Alta | Descubrimiento y auditoría
p=quarantine | Carpeta de spam | Medio | Alta | Pruebas y transición
p=reject | Bloqueado | Alto | Media | Seguridad completa en producción
Para profundizar en la implementación técnica de estos registros, consulte nuestra guía sobre DKIM, SPF y DMARC.
Gestionar estos registros manualmente es tedioso. SendHQ lo simplifica con el envío transaccional desde dominios verificados y herramientas para que su infraestructura esté lista para agentes.
Más información en https://sendhq.cc.