Un mensaje puede pasar DMARC y aún así no cumple con los requisitos de remitente del proveedor de buzones de correo. Eso no es necesariamente una contradicción. DMARC responde a una pregunta de identidad específica; un receptor también puede requerir mecanismos que funcionen, transporte seguro, construcción adecuada del mensaje y comportamiento de envío responsable.
Comience con la decisión del protocolo.
Referencias: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989, publicado en mayo de 2026, deja obsoletos los RFC 7489 y 9091 heredados. Según su sección 4.1, DMARC se aprueba cuando existe un registro de política para el dominio del autor y ese dominio se alinea con un identificador autenticado del mensaje. El principio de paso alineado permanece: al menos un mecanismo de autenticación compatible debe pasar con alineación al dominio Desde visible. Para SPF Dentro de DMARC , la identidad relevante es el SMTP CORREO DE dominio según RFC 9989 §4.4.2; un resultado SPF independiente basado en HELO no sustituye esa identidad DMARC . Para DKIM, es el dominio d= de una firma válida. Un mecanismo exitoso sin la alineación requerida no aporta un pase DMARC . RFC 9989 secciones 3.2.10 y 4.1–4.3.
La alineación tiene modos estrictos y relajados. Estricto compara exactamente los dominios aplicables; relajado utiliza su relación de dominio organizacional. RFC 9989 sección 4.10 define Caminata por el árbol DNS descubrimiento en lugar del enfoque heredado de lista pública de sufijos. Verifique la versión implementada del receptor o evaluador antes de asumir su comportamiento de descubrimiento. No implemente una alineación relajada comprobando si una cadena de dominio simplemente termina con otra. Un sufijo engañoso o un cálculo incorrecto del dominio organizacional pueden producir un resultado incorrecto.
Agregue los requisitos del proveedor como una capa separada
La guía de soporte de alto volumen para consumidores de Microsoft requiere que se aprueben tanto SPF como DKIM , además de DMARC . Los requisitos masivos de Yahoo exigen ambos mecanismos y la aprobación DMARC . Estas son puertas operativas además de la lógica de mecanismo alineado del protocolo. Revise la fuente actual para el destino en lugar de inferir una regla universal de un proveedor. Soporte de Microsoft y Requisitos Yahoo.
Cree una columna para el resultado DMARC y columnas separadas para los controles requeridos de autenticación, DNS , transporte, formato y cancelación de suscripción. Un indicador verde general sin esas columnas dificulta saber si el software está evaluando el protocolo, una lista de verificación del proveedor o solo la sintaxis DNS publicada.
Utilice una tabla de verdad para exponer la diferencia.
Referencias: RFC 9989 §5.3.5.
El paquete de revisión privada incluye un accesorio sintético de dos cajas. Primero, SPF y DKIM pasan pero ninguno se alinea: DMARC falla. En segundo lugar, SPF falla mientras DKIM pasa y se alinea: DMARC pasa. El segundo caso aún puede fallar en la puerta de un proveedor que de forma independiente requiere el éxito SPF .
Estas entradas son valores booleanos deliberadamente simples, no una implementación del descubrimiento DNS Tree Walk, el descubrimiento heredado basado en sufijos públicos, la evaluación SPF o la criptografía DKIM . Ambos casos suponen que existe un registro de política DMARC aplicable. Hacen que la distinción lógica sea reproducible sin pretender probar a un proveedor. En una investigación real, reemplace cada booleano con un resultado observado confiable y su identidad evaluada.
No confundas publicación con evaluación
Referencias: RFC 9989 §5.4.
Publicación p=none establece una política de monitoreo solicitada, no un resultado exitoso de autenticación de mensajes. La publicación de una clave pública DKIM no firma el correo saliente. Agregar un Registro SPF no prueba que la conexión real utilizó una dirección autorizada. Cada artefacto de configuración necesita una observación correspondiente de la ruta de envío prevista.
De manera similar, pasar de p=none a p=reject no repara la alineación. Cambia el manejo solicitado por el propietario del dominio en caso de fallas. Haga un inventario de las rutas legítimas antes de cambiar la aplicación de la ley, mantenga un plan de reversión y evalúe el efecto sobre los flujos indirectos. El receptor todavía aplica su propia política de disposición local; una acción DMARC solicitada no es una garantía de entrega.
Cree un registro de cierre útil
Referencias: RFC 8601 §5.
Para cada muestra investigada, conserve De, remitente del sobre, IP de conexión, firmante DKIM y selector, resultados del mecanismo, modo de alineación y respuesta de recepción final. Identifique la fuente confiable de esos resultados. No acepte encabezados copiados arbitrariamente como autorizados simplemente porque contienen la palabra "aprobar".
Cerrar el hallazgo del protocolo y el hallazgo de cumplimiento del proveedor por separado. Esto hace posible decir con precisión que DMARC pasó mientras que otro requisito quedó sin resolver, y asignar la corrección al propietario del derecho sin debilitar los controles no relacionados.