Por qué DMARC p=none ya no es suficiente en 2026
SPF y DKIM autentican el envío: prueban que un servidor estaba autorizado y que el mensaje no fue alterado. Pero no dan ninguna instrucción al servidor destinatario. DMARC decide: ¿qué hace el servidor receptor con un correo que falla SPF o DKIM? En p=none, la respuesta es «nada» — el correo se entrega normalmente y el propietario del dominio recibe informes. Este modo de observación tenía sentido en la fase de despliegue inicial. En 2026, Google y Microsoft cambiaron las reglas: leen activamente la política DMARC de los remitentes de más de 100 mensajes por día. Un dominio que sigue en p=none se trata como un dominio sin política. El resultado: tasas de entrega degradadas, clasificación preferencial como spam, y en cuanto la tasa de quejas supera el 0,3%, throttling inmediato. El umbral recomendado por Google Postmaster Tools para mantenerse por debajo del radar es inferior al 0,1%.
Qué arriesga al quedarse en p=none después de 2026
- Throttling silencioso — Google y Microsoft limitan el caudal de aceptación de sus mensajes a partir del 0,3% de quejas, sin ningún bounce explícito.
- Clasificación sistemática como spam — sin una política activa, las heurísticas de los grandes buzones tratan sus envíos como no verificados.
- Suplantación del dominio sin protección — un tercero puede enviar en su nombre; sin DMARC activo, los destinatarios no pueden distinguir un envío legítimo de uno falso.
- Informes rua sin aprovechar — en p=none los informes llegan pero nada se bloquea: usted observa el abuso sin detenerlo.
- Pérdida de reputación de remitente — una reputación degradada tarda semanas en recuperarse, incluso después de corregir la política.
- Bloqueo de campañas de correo — los ESP (Mailchimp, Brevo, SendGrid) se niegan a enviar para dominios con reputación marcada.
- Riesgo de escalada forzada a p=reject — Google puede aplicar unilateralmente una política más restrictiva si el dominio está asociado al phishing.
Las tres políticas de DMARC: p=none, p=quarantine, p=reject
Desplace la tabla
| Política | Efecto sobre los correos fallidos | Caso de uso |
|---|---|---|
| p=none | Entregado normalmente — ninguna acción sobre el mensaje. Se envían informes rua. | Fase de observación inicial (2-4 semanas como máximo). Ya no es adecuada para remitentes activos en 2026. |
| p=quarantine | Dirigido a la carpeta de spam/cuarentena del destinatario. Se envían informes rua. | Paso intermedio recomendado: protección activa, pero los falsos positivos siguen siendo accesibles en la carpeta de spam. |
| p=reject | Rechazado definitivamente con SMTP 554 por el servidor destinatario. Se envían informes rua. | Objetivo final: máxima protección. Alcanzarlo tras 2-4 semanas en cuarentena sin falsos positivos. |
Lista de verificación SPF + DKIM + DMARC + List-Unsubscribe: 8 pasos
Verificar el registro SPF
Asegúrese de que exista un registro TXT en la raíz de yourdomain.com que enumere todas sus fuentes de envío activas. Ejemplo:
v=spf1 include:_spf.su-proveedor.com include:sendgrid.net ~all. Un solo registro SPF por dominio — dos registros simultáneos invalidan ambos. Compruebe condig TXT yourdomain.como MXToolbox.Verificar la firma DKIM
Cada fuente de envío (servidor principal, ESP, herramienta de marketing) debe firmar los mensajes con una clave DKIM publicada en DNS. Ejemplo de registro:
mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0…". Envíe un mensaje de prueba y compruebe las cabeceras: busquedkim=passenAuthentication-Results.Publicar un registro DMARC con dirección rua
Cree un registro TXT en
_dmarc.yourdomain.com. Si sigue en p=none, el valor inicial es:v=DMARC1; p=none; rua=mailto:[email protected]; pct=100. Si está listo para p=quarantine:v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100. El camporuaes la dirección que recibirá los informes agregados diarios.Leer un informe DMARC agregado (formato rua)
Los informes llegan como archivos XML comprimidos. Campos clave:
source_ip(servidor emisor),count(número de mensajes),disposition(none / quarantine / reject),dkimyspf(pass o fail para cada comprobación). Un informe que muestrasource_ipdesconocidas condkim=failyspf=failseñala una suplantación activa de su dominio.Pasar a p=quarantine tras 2 a 4 semanas de observación
No pase directamente a p=reject. El período de 2-4 semanas sirve para identificar fuentes legítimas olvidadas: una lista de correo externa, una herramienta CRM, un boletín de un subdominio. Actualice el DNS:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100.Añadir la cabecera List-Unsubscribe one-click (RFC 8058)
Desde 2026, Gmail y Outlook exigen a los remitentes de más de 100 correos/día incluir la cabecera HTTP
List-Unsubscribe-Post: List-Unsubscribe=One-Clicken sus mensajes de tipo lista. La cabecera completa tiene dos partes:List-Unsubscribe: <https://yourdomain.com/unsubscribe?id=abc123>yList-Unsubscribe-Post: List-Unsubscribe=One-Click. La mayoría de los ESP lo gestionan automáticamente; verifique que su configuración lo habilita.Supervisar la tasa de quejas en Google Postmaster Tools
Google Postmaster Tools (postmaster.google.com) da acceso a la tasa de spam del dominio, la reputación de remitente y la entrega. Cree una cuenta, verifique su dominio mediante un registro DNS TXT y revise diariamente el panel «Spam rate». Objetivo: mantenerse por debajo del 0,1%. Entre el 0,1% y el 0,3%, riesgo de throttling. Por encima del 0,3%, throttling inmediato según las directrices Google 2026.
Pasar a p=reject una vez estabilizada la cuarentena
Después de 2 a 4 semanas en p=quarantine sin falsos positivos en la carpeta de spam y sin fuentes legítimas desconocidas en los informes rua, pase a p=reject:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100. Continúe supervisando los informes rua mensualmente.
Leer y analizar un informe DMARC agregado
Un informe DMARC agregado es un archivo XML enviado a diario a la dirección rua= de su registro. Cada informe cubre 24 horas de envíos desde su dominio, tal como lo ve el servidor destinatario (Gmail, Outlook, etc.).
Estructura de un registro de informe:
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>1247</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>Lea los informes buscando tres casos:
- dkim=pass + spf=pass en sus IPs conocidas: sus envíos legítimos pasan correctamente.
- dkim=fail + spf=fail en IPs desconocidas: suplantación activa — sus informes documentan que alguien envía en su nombre sin autorización.
- dkim=fail en una IP conocida: esta fuente envía en su nombre pero no está cubierta por una clave DKIM — corríjalo antes de pasar a p=quarantine.
Herramientas como dmarcian.com o MXToolbox DMARC Analyzer leen y agregan automáticamente estos archivos XML.
Pruebe antes de cambiar la política
mail-tester.com envía un correo de prueba y devuelve una puntuación sobre 10 con un informe detallado: SPF, DKIM, DMARC, listas negras, puntuación del contenido. Úselo antes y después de cada cambio de política. MXToolbox DMARC Check verifica el registro DNS directamente sin envío.
Resolución de problemas: cuatro casos frecuentes
DMARC falla pero SPF y DKIM pasan individualmente. La alineación DMARC exige que el dominio de la cabecera From coincida con el dominio verificado por SPF o DKIM. Si envía desde [email protected] pero su ESP firma DKIM con otrodominio.com, SPF y DKIM pasan por separado — pero DMARC falla por no-alineación. Corrija configurando su ESP para firmar DKIM con su dominio (yourdomain.com) o añadiendo la IP del ESP al SPF del dominio remitente.
Informe rua vacío después de 48 horas. Compruebe que la dirección rua pertenece al mismo dominio que el registro DMARC. Gmail y Outlook solo envían informes si su dominio envía suficiente tráfico hacia ellos.
Tasa de quejas en aumento pese a DMARC activo. DMARC protege la autenticación, no el contenido. Si los destinatarios hacen clic en «Spam», la política DMARC no puede intervenir. Compruebe la frecuencia de envío, la relevancia del contenido y el estado de la cabecera List-Unsubscribe one-click.
List-Unsubscribe one-click no reconocido por Gmail. Gmail exige la forma HTTP POST (RFC 8058): la cabecera List-Unsubscribe-Post: List-Unsubscribe=One-Click debe acompañar a la URL. Un enlace de baja solo en mailto: o en HTTPS sin List-Unsubscribe-Post no se reconoce como one-click. Consulte la documentación de su ESP para activar esta opción.
De p=quarantine a p=reject: el camino
Pasar de p=quarantine a p=reject es el último paso — y el más sencillo si los anteriores se han ejecutado bien. En este punto, todos sus envíos legítimos pasan SPF y DKIM, sus informes rua no muestran fuentes desconocidas y su tasa de quejas es inferior al 0,1%.
El cambio es una simple sustitución de valor en el registro DNS: p=quarantine pasa a p=reject. El TTL estándar de los registros DNS TXT es de 3600 segundos (1 hora): prevea una propagación de 1 a 4 horas según los resolvedores.
¿Por qué no pasar directamente a p=reject sin pasar por p=quarantine? En p=quarantine, los falsos positivos llegan a la carpeta de spam del destinatario — son accesibles y recuperables. En p=reject, son rechazados definitivamente en SMTP: ni el remitente ni el destinatario pueden recuperarlos. La fase intermedia actúa como red de seguridad para identificar las últimas fuentes legítimas mal configuradas.
Tras pasar a p=reject, continúe consultando Google Postmaster Tools una vez por semana durante el primer mes y luego mensualmente.
