término · comprobación de DMARC

¿Cómo se hace una comprobación de DMARC para el correo de una aplicación?

Una comprobación de DMARC debe verificar cuatro aspectos distintos: que se pueda descubrir una política válida en el DNS, que sus etiquetas obligatorias se analicen correctamente, que al menos un identificador SPF o DKIM autenticado esté alineado con el dominio From visible en un mensaje real y que todos los remitentes legítimos de la aplicación estén contemplados antes de pasar al modo de cumplimiento. Consulte el nombre _dmarc, inspeccione el registro y luego examine los resultados de autenticación de mensajes enviados de forma controlada. Un resultado DMARC pass valida el uso autorizado del dominio; no demuestra la entrega ni la llegada a la bandeja de entrada.

Trate una comprobación de DMARC como cuatro pruebas, no como una sola consulta

Una comprobación útil tiene cuatro capas. Primero, descubra la política que se aplica al dominio del autor del mensaje. Segundo, valide el registro TXT como política DMARC en lugar de aceptar cualquier texto que devuelva el DNS. Tercero, pruebe la alineación de identificadores en un mensaje real: el dominio MAIL FROM autenticado por SPF o un dominio de firma DKIM verificado debe estar alineado con el dominio del encabezado From visible. Cuarto, confirme la cobertura operativa enviando a través de cada aplicación, proveedor, región y clase de mensaje legítimos que usen el dominio. Una consulta DNS en verde solo cubre parte de las dos primeras capas. No puede mostrar que un proveedor firme con el dominio previsto, que un return path personalizado esté activo, que el reenvío haya cambiado el comportamiento de SPF ni que un sistema olvidado vaya a sobrevivir a una política en modo de cumplimiento.

Consulte el nombre DNS correcto y siga el descubrimiento de la política

Empiece por el dominio exacto del encabezado From de RFC5322, a menudo llamado dominio del autor. Consulte el TXT en _dmarc seguido de ese dominio. Para un mensaje de alerts@notify.example.test, empiece en _dmarc.notify.example.test y no en el host del sitio web, el host MX ni el dominio del return path. RFC 9989 define un descubrimiento de políticas que va más allá de una sola consulta: si el dominio del autor no tiene un registro válido, un receptor puede recorrer el árbol DNS para encontrar la política aplicable del dominio organizacional o del sufijo público. El tratamiento de los subdominios puede provenir de la etiqueta sp, np o p, según lo que exista y dónde se encuentre la política. Esto significa que un verificador debe informar tanto del nombre consultado como del dominio de política que realmente seleccionó. Un resultado que solo dice «registro encontrado» puede ocultar errores de herencia o una política de subdominio explícita que cambie el tratamiento esperado.

Valide la estructura del registro antes de interpretar la política

Un registro de política DMARC usa sintaxis de etiqueta-valor. Según RFC 9989, v=DMARC1 es obligatorio, distingue entre mayúsculas y minúsculas y debe aparecer primero; una etiqueta p válida proporciona la política de evaluación solicitada. Los valores de política comunes son none, quarantine y reject. Las etiquetas opcionales describen destinos de informes, comportamiento de subdominios y alineación SPF y DKIM estricta o relajada. No corrija silenciosamente etiquetas con errores ortográficos, un valor p faltante, registros duplicados o en conflicto, separadores no válidos ni un valor copiado con artefactos de comillas del proveedor DNS. Trate un error de evaluación permanente como un resultado que necesita corrección, no como un resultado DMARC pass o fail. Distinga también un error transitorio de consulta DNS de un registro malformado. Reintente un fallo transitorio del resolvedor mediante una ruta controlada, pero no afirme que el dominio no tiene política hasta que se pueda consultar DNS autoritativo de forma confiable.

Compruebe la alineación de SPF y DKIM en un mensaje real

DMARC se evalúa en función de la autenticación del mensaje, no de la configuración DNS por sí sola. Para SPF, compare el dominio MAIL FROM autenticado con el dominio From visible. Para DKIM, compare el dominio d= de cada firma verificada correctamente con el dominio From visible. La alineación relajada acepta dominios con el mismo dominio organizacional; la alineación estricta exige dominios idénticos. Un mensaje obtiene un resultado pass cuando al menos un identificador autenticado supera su mecanismo subyacente y está alineado. Por ejemplo, el return path de un proveedor puede hacer que SPF dé pass para el dominio del proveedor pero quede sin alinear con billing.example.test. Si DKIM verifica con d=example.test con alineación relajada, el mensaje aún puede dar pass en DMARC. Capture el encabezado Authentication-Results sin procesar desde cuentas de destinatario controladas, pero interprételo en contexto, ya que informa del resultado del receptor que evalúa y puede contener varios saltos o firmas.

Interprete con precisión los resultados pass, fail, none y error

Un resultado DMARC pass significa que se aplica un registro de política y un identificador SPF o DKIM autenticado se alinea con el dominio del autor. Un fail significa que se aplica una política, pero no existe ningún identificador autenticado alineado. None significa que no se descubrió ninguna política aplicable. Permerror y temperror indican errores durante la evaluación de DMARC; un mensaje con un error de DNS no puede considerarse aprobado ni rechazado por DMARC. Estos resultados no indican dónde colocó el proveedor de buzón el mensaje. RFC 9989 limita explícitamente un pass a la validación de que el uso del propietario del dominio estaba autorizado; no afirma que el mensaje sea seguro, deseado, confiable ni apto para la bandeja de entrada. Mantenga la aceptación del proveedor, la aceptación del servidor receptor, el resultado DMARC, las señales de quejas y la ubicación observada como campos separados en los diagnósticos y paneles.

Identifique todos los remitentes legítimos antes de aplicar el cumplimiento

Haga un inventario de todos los sistemas que colocan el dominio en From: aplicaciones de producción, correos de autenticación, avisos de facturación, herramientas de soporte, plataformas de marketing, alertas de monitoreo, flujos de CRM, cuentas regionales y sistemas de emergencia. Para cada flujo, registre el dominio From visible, el dominio MAIL FROM, el dominio d= y el selector de DKIM, la cuenta del proveedor, el responsable, la clase de mensaje y el volumen esperado. Envíe mensajes controlados por la ruta normal de producción y verifique tanto la autenticación como la alineación. Los informes agregados de DMARC pueden revelar fuentes que usan el dominio, pero requieren interpretación y pueden incluir reenvíos o tráfico no autorizado. Empiece con el monitoreo mientras el inventario esté incompleto y luego corrija los flujos legítimos no alineados antes de solicitar un tratamiento más estricto al receptor. No cambie una política organizacional compartida solo para que una aplicación aparezca en verde, y no pase al modo de cumplimiento basándose en un único mensaje de prueba.

Diagnostique los fallos habituales del correo de aplicaciones

Si no se encuentra ninguna política, verifique la zona DNS y el nombre del registro antes de editar el valor. Si el registro tiene un error permanente, redúzcalo a una única política válida y compruebe el orden y la sintaxis de las etiquetas. Si DKIM falla, compruebe si existe el selector esperado, si el proveedor realmente firmó el mensaje de prueba, si el cuerpo o los encabezados firmados cambiaron en tránsito y si el dominio d= verificado está alineado. Si SPF da pass pero DMARC falla, compare el dominio MAIL FROM con el dominio From visible en lugar de considerar suficiente cualquier resultado SPF pass. Si solo falla el correo reenviado, recuerde que el reenvío suele cambiar la ruta del sobre y puede romper SPF, mientras que una firma DKIM válida y alineada puede sobrevivir. Si un despliegue provoca rechazos, conserve los encabezados que fallan y la respuesta del receptor, detenga cualquier endurecimiento adicional de la política y corrija el flujo responsable en lugar de debilitar controles de autenticación no relacionados.

Aplique deliberadamente las reglas de alineación de cada proveedor

Los remitentes externos necesitan una configuración que vincule sus identificadores autenticados a un dominio que controle la organización. Amazon SES documenta dos vías: un dominio MAIL FROM personalizado y alineado para SPF, y un dominio de firma DKIM alineado. Su return path predeterminado, propiedad del proveedor, puede autenticarse con SPF sin estar alineado con el dominio From visible, por lo que DKIM suele ser el mecanismo alineado práctico a menos que se configure un dominio MAIL FROM personalizado. Otros proveedores usan nombres distintos para los return paths, los dominios de rebote, la autenticación de dominios y las identidades de firma. Verifique el mensaje de salida exacto en lugar de suponer que la insignia de verificado de un panel garantiza DMARC. Las directrices actuales de Gmail para remitentes también exigen autenticación y alineación para el tráfico aplicable y recomiendan los informes DMARC. Los requisitos de los receptores y las funciones de los proveedores pueden cambiar, así que vuelva a consultar su documentación oficial en el lanzamiento y durante la revisión de incidentes.

Use evidencia del proveedor sin tratarla como un veredicto DMARC

SendHQ admite envío desde dominios verificados, eventos de entrega, supresiones y un panel web. Use su información de dominio de envío y entrega para investigar un flujo de mensajes; después, verifique DMARC a partir del encabezado Authentication-Results del receptor y separe la evidencia de SPF, DKIM y alineación. La aceptación del proveedor y los eventos de entrega no demuestran la llegada a la bandeja de entrada.

Registre un resultado de comprobación de DMARC auditable

Un resultado duradero debe contener el dominio del autor, la hora de la consulta, el resolvedor, el nombre _dmarc consultado, el dominio de política seleccionado, el registro normalizado exacto, los modos de política y de alineación, el estado del DNS y si el análisis produjo una sintaxis válida, permerror o temperror. Agregue una fila por cada mensaje controlado con un identificador de mensaje no sensible, el sistema de envío, el dominio From visible, el dominio y el resultado de SPF autenticado, los dominios y selectores DKIM verificados, las decisiones de alineación, el resultado DMARC final y el receptor. Guarde los encabezados sin procesar en un almacenamiento restringido, ya que pueden exponer direcciones, detalles de enrutamiento e identificadores internos. Vincule cada hallazgo a un responsable y a una fecha de corrección. Vuelva a comprobar cuando expiren los TTL de DNS, cambie la configuración del proveedor, se roten las claves, aparezcan nuevos flujos de mensajes o se endurezca la política. Esta evidencia hace que la comprobación sea reproducible y evita que una captura de pantalla o la insignia de una herramienta se conviertan en una prueba permanente después de que cambie la configuración subyacente.

Preguntas frecuentes

¿Dónde se debe comprobar un registro DMARC?

Empiece con el TXT en _dmarc más el dominio exacto de la dirección From visible. Identifique también el dominio de política seleccionado mediante las reglas vigentes de descubrimiento de DMARC, porque puede aplicarse una política organizacional o de subdominio cuando el primer nombre consultado no tiene un registro válido.

¿Encontrar v=DMARC1 significa que DMARC da pass?

No. Solo contribuye a que el registro de política sea válido. Un mensaje obtiene un resultado pass cuando SPF o DKIM autentican con un dominio alineado con el dominio From visible. Pruebe un mensaje real e inspeccione los resultados de autenticación del receptor.

¿Puede DMARC dar pass cuando SPF no está alineado?

Sí. Una firma DKIM verificada correctamente puede producir el identificador autenticado y alineado que necesita DMARC. También es posible lo contrario: un SPF alineado puede sustentar un resultado pass cuando DKIM no lo hace, aunque depender de un solo mecanismo reduce la resiliencia.

¿Que DMARC dé pass demuestra la llegada a la bandeja de entrada?

No. Valida el uso autorizado del dominio del autor para ese mensaje. Un receptor aún puede aplicar señales de reputación, contenido, destinatario, abuso y política local al aceptar, rechazar, poner en cuarentena o clasificar el mensaje.

¿Debe una aplicación pasar directamente a p=reject?

Normalmente no sin evidencia de inventario y monitoreo. Identifique a cada remitente legítimo, valide la alineación en mensajes controlados, revise los informes agregados, corrija los fallos y coordine los cambios de política con el propietario del dominio antes de solicitar un manejo más estricto.

¿Qué se debe volver a comprobar después de cambiar de proveedor de correo?

Vuelva a comprobar la política descubierta para cada dominio From, los dominios MAIL FROM y DKIM del proveedor, el DNS del selector, los resultados de SPF y DKIM, la alineación relajada o estricta, los informes agregados y cada clase de mensaje controlado de la aplicación antes de aumentar el tráfico de producción.

Fuentes