Cómo Leer la Política DMARC de una Empresa en Diez Segundos (Y lo Que No Te Dice)

Una consulta DNS te dice qué le ha pedido una empresa a los servidores de correo del mundo que hagan con el correo falsificado enviado en su nombre. El registro es público, y el comando es una sola línea: dig +short TXT _dmarc.example.com. Lo que devuelve es una cadena corta de configuración, y dentro hay una instrucción —p=none, p=quarantine o p=reject— que expresa la preferencia del propietario del dominio cuando un mensaje que usa ese dominio no pasa la autenticación.

La especificación actual, RFC 9989, publicada en mayo de 2026 como documento IETF Standards Track, reemplazó el anterior RFC 7489. Define los tres valores casi de forma tajante:

• p=none — "El propietario del dominio no expresa preferencia alguna".
• p=quarantine — "El propietario del dominio considera que tal correo es sospechoso. Es posible que el correo sea válido, aunque el fallo genera una preocupación significativa".
• p=reject — "El propietario del dominio considera que todos tales fallos son una indicación clara de que el uso del nombre de dominio no es válido".

Lee de nuevo esas palabras, porque son más débiles de lo que la mayoría de explicaciones sobre DMARC reconocen. Una política es una preferencia, publicada por el remitente para que los receptores la consideren. No es una instrucción que un receptor esté obligado a ejecutar. RFC 9989 lo dice en una oración: "El tratamiento final de cualquier mensaje siempre es una cuestión de política local y se deja a discreción del Receptor de Correo". La misma sección añade ambas partes de la consecuencia — los receptores "PUEDEN optar por rechazar o poner en cuarentena un mensaje incluso si pasa la validación DMARC", y "NO DEBEN rechazar mensajes únicamente por una política publicada de 'reject'", precisamente para que el correo legítimo enviado de formas que DMARC no puede describir, y las listas de correo, no se destruyan en el proceso.

¿Qué confiesa realmente p=none? Menos de lo que usualmente se le acusa. En los términos de la especificación es Modo de Monitoreo: el propietario del dominio está recopilando informes agregados y "no expresa preferencia de tratamiento para mensajes que fallan la validación DMARC", mientras que un receptor que implementa DMARC "aún puede" validar el uso del dominio. Lo que no hace es desactivar nada en el extremo receptor. El filtrado de spam de tu proveedor, la puntuación de reputación, los controles de URL y el análisis de archivos adjuntos son maquinaria separada que funciona independientemente de lo que publicó el remitente. Un mensaje falsificado que llega a un dominio p=none no es promovido a tu bandeja de entrada por el registro; simplemente se entrega al receptor sin una preferencia expresada, y el receptor decide.

La otra mitad del malentendido va en la dirección opuesta. DMARC no lee la parte peligrosa de un correo de phishing. Su propia especificación enumera lo que está deliberadamente fuera del alcance, y "content analysis" (análisis de contenido) está en esa lista, en esas palabras. También establece que DMARC "no aborda el uso de nombres de dominio visualmente similares o el abuso del nombre visible legible por humanos RFC5322.From" — los dos trucos que llevan la mayoría del correo de suplantación de marca. Y sobre el valor de un paso: "un paso DMARC por sí solo no garantiza que la entrega a la bandeja de entrada del destinatario sería segura o deseable". Un mensaje correctamente autenticado de un dominio desechable pasa DMARC limpiamente. DMARC responde quién fue autorizado para usar el dominio en el encabezado From:. Nada más.

Aquí es donde las reglas de remitentes masivos de 2024 se reportan rutinariamente mal, incluso en la primera versión de este artículo. Las guías de remitentes de Google requieren que los remitentes de 5.000 o más mensajes al día a cuentas de Gmail "Configuren autenticación de correo DMARC para tu dominio de envío", y luego dicen, en el mismo aliento: "Tu política de aplicación DMARC puede estar configurada en none". El propio Sender Hub de Yahoo, que debe leerse por separado en lugar de asumir que copia Google, establece el requisito como "Publicar una política DMARC válida con al menos p=none - DMARC debe pasar", y no publica umbral de volumen numérico alguno. Ambos conjuntos de requisitos entraron en vigencia desde febrero de 2024. Ninguno obliga a nadie a abandonar p=none. Lo que ambos realmente obligan es a una autenticación que se alinee: Google requiere que "el dominio en el encabezado From: del remitente debe estar alineado con el dominio SPF o el dominio DKIM", y Yahoo dice que la alineación relajada es aceptable. Alineación, no severidad, es la puerta.

Lo que deja la razón real por la que los dominios se quedan en monitoreo, y es operacional en lugar de cobarde. Pasar a quarantine o reject significa primero encontrar cada servicio que envía correo en tu nombre — nómina, ticketing, marketing, un escritorio de soporte que nadie documentó — y autenticar cada uno para que se alinee. El propio estándar reconoce los peligros que hacen que esto sea lento: los remitentes de terceros no son introducidos ni excluidos por DMARC, el reenvío y las listas de correo pueden romper la alineación sin culpa del remitente, y la especificación señala a los receptores a RFC 7960 para exactamente esos modos de fallo. Una organización que publica p=none y lee sus informes está haciendo el trabajo en el orden que la especificación describe. Una que publica p=none e ignora los informes no lo está. Desde afuera, el registro solo no puede decirte cuál de los dos estás mirando.

No necesitas una terminal para mirar. Herramientas de búsqueda gratuitas — dmarcian's domain checker, MXToolbox's DMARC check — obtienen el registro e imprimen la política para ti. Hazlo para tu banco, tu proveedor de nómina, la aerolínea en la que vuelas. Solo lee la respuesta por lo que es: una declaración de intención del propietario del dominio, un input entre muchos en una decisión que tu proveedor de correo hace por su cuenta, sobre un tipo específico de falsificación. Eso es algo genuinamente útil que poder leer en diez segundos. No es un veredicto sobre si el próximo mensaje que afirma ser de esa marca es seguro.

Corrección, 20 de octubre de 2026. Una versión anterior de este artículo describía p=none como entregando falsificaciones a la bandeja de entrada y p=reject como el único parámetro que bloquea un mensaje suplantado, decía que las reglas de remitentes masivos de Google y Yahoo de 2024 obligaban a los remitentes a alejarse de p=none, y citaba una cifra de aproximadamente uno de cada tres dominios en aplicación. Las descripciones de políticas han sido corregidas contra RFC 9989; tanto Google como Yahoo de hecho aceptan p=none, citado arriba de su propia documentación; y la cifra de aplicación ha sido removida porque el informe subyacente no publica su muestra o denominador. El artículo ahora también establece lo que DMARC no examina.