Una entrega directa exitosa no es prueba suficiente para una aplicación más estricta. DMARC política. Un servicio de reenvío cambia la ruta de envío y una lista de correo puede alterar el contenido firmado. Cree un pequeño conjunto de pruebas que represente las rutas que la empresa realmente necesita. Evalúe la autenticación por separado de la entrega para que una excepción en un receptor no parezca compatibilidad universal.
Establecer la línea de base
Referencias: RFC 9989 §4.4, RFC 9989 §5.3.5.
Elija cuentas de remitente y destinatario autorizadas y contenido inofensivo. Registre el dominio Desde, remitente del sobre, enviando IP, Selector DKIM y firma de dominio. Conserve una copia de entrega directa y los resultados de autenticación del receptor confiable. Capture la política DMARC aplicable y alineación modo en el momento de la prueba. Si la línea base ya está desalineada, repare ese remitente antes de diagnosticar el reenvío.
Bajo RFC 9989, un paso alineado SPF o DKIM El mecanismo puede satisfacer DMARC . El pase SPF bajo el dominio de un reenviador no se alinea automáticamente con el dominio del autor. RFC 6376 explica por qué la preservación del contenido firmado es importante para DKIM . Registre qué mecanismo sobrevive en lugar de tratar un resultado general ecológico como una explicación.
Ejercer variantes significativas
Referencias: RFC 6376 §3.4, RFC 8617 §7.2.1.
Incluya reenvío sin cambios, reescritura de sobres, inserción de pie de página de lista, modificación de asunto y cualquier transformación MIME que realice el servicio real. Pruebe varios tipos de mensajes legítimos, especialmente aquellos con archivos adjuntos o rutas de envío de terceros. La pregunta relevante es si la transformación cambia el material cubierto por la firma real y canonicalización, no si el mensaje parece idéntico en un cliente.
Mantenga un control negativo cuya firma alineada sea deliberadamente inválida en un laboratorio aislado. Un receptor que acepta tanto los casos válidos como los inválidos puede estar aplicando la política local. Esa observación es útil, pero no prueba que ambos mensajes sean auténticos. Si ARC está presente, la validación de la cadena de registro, la decisión de confianza del sellador y del receptor por separado. RFC 8617 no convierte cada cadena válida en un comando de entrega. Como se verificó el 8 de noviembre de 2026, el RFC sigue siendo Experimental y un borrador activo propone un estado Histórico; considere esa propuesta antes de crear una nueva dependencia ARC .
Leer el aparato reproducible
Referencias: RFC 6376 §6.
El laboratorio retenido firma un mensaje Author.test inofensivo con una clave RSA temporal y lo verifica con dkimpy. El caso directo pasa. Una copia reenviada sin cambios aún se verifica. Un cambio de sobre estilo SRS también deja DKIM válido, aunque la identidad SPF simplificada ahora es forwarder.test y no se alinea. Un pie de página adjunto al cuerpo firmado no supera la verificación ni el modelo DMARC de dominio exacto.
Cada caso conserva el resumen del mensaje, la IP de la ruta, la identidad del sobre, el dominio de firma y el veredicto. La clave de verificación es pública; no se retiene ninguna clave privada. Volver a ejecutar el dispositivo generador de claves original crearía claves nuevas y, por lo tanto, hashes de mensajes nuevos; no se volvió a ejecutar aquí. Los veredictos esperados se mantienen estables. Esta es una prueba local reproducible, no un solucionador SPF completo, una implementación DMARC , un validador ARC o una prueba de un proveedor de buzones de correo comercial.
Decidir si continuar
Referencias: RFC 9989 §8.
Cree una matriz de ruta que muestre el remitente, el intermediario, el receptor, la variante del mensaje, el resultado de la autenticación y la disposición final probados. Marque las combinaciones no probadas como desconocidas. La matriz de muestra debe incluir un control directo y una modificación fallida, no sólo mensajes exitosos seleccionados después del hecho. La falla del pie de página del laboratorio es una razón para mantener esa ruta para reparación o una excepción aprobada por separado.
Utilice una implementación controlada con autoridad de reversión designada y monitoreo apropiado para la demora en la presentación de informes del proveedor. No asuma que las recetas históricas de políticas porcentuales todavía se aplican a la especificación DMARC actual. Confirme el comportamiento actual del receptor y de la plataforma, luego conserve la política del antes y el después y la evidencia de los mensajes. Un cambio de política tiene éxito cuando las rutas críticas legítimas continúan funcionando y la organización comprende las fallas restantes, no simplemente cuando un verificador DNS ve un valor más estricto.
Ruta de reenvío controlada retenida
Referencias: RFC 7208 §4, RFC 6376 §6, RFC 8601 §5.
La captura retenida del 7 de noviembre de 2026 a las 21:32:53 UTC registra un dispositivo separado que envía el mensaje firmado a través de conexiones SMTP de bucle real. Estas sesiones de red se inspeccionaron y no se volvieron a ejecutar para esta revisión. El origen se vincula a 127.0.0.2 , el reenviador envía desde 127.0.0.3 y el receptor final almacena cada mensaje. Estas direcciones están confinadas a la máquina local. Los casos directos, de reenvío sin cambios, de sobre reescrito y de pie de página tienen cada uno un seguimiento de transacción real con marcas de tiempo, identidades de sobre y aceptación final. La reescritura es una sustitución de dominio estilo SRS para esta práctica de laboratorio, no una completa. SRS implementación.
Cada límite de recepción calcula SPF usando pyspf 2.0.14 con respuestas TXT locales inyectadas explícitamente y DKIM usando dkimpy con la clave pública retenida. El receptor añade el suyo Authentication-Results y campos Recibido después de la evaluación. Se confía en esos resultados sólo dentro de este dispositivo controlado, donde se conocen el código de inserción y el límite. No acepta textos de pase incrustados arbitrarios como su propio veredicto. La política DNS es una entrada local estática, no una afirmación sobre DNS público.
En el receptor final, los resultados SPF son aprobado, reprobado, aprobado y aprobado respectivamente. Los resultados DKIM son aprobado, aprobado, aprobado y reprobado. Por lo tanto, el modelo de alineación de dominio exacto conserva la autenticación DMARC para los primeros tres casos y falla en el caso del pie de página. Este no es un descubrimiento completo de la política DMARC . El laboratorio almacena deliberadamente incluso el mensaje fallido para su inspección, por lo que su respuesta 250 no es evidencia de que un proveedor de producción lo entregaría.
El ejemplo de excepción y la retención de implementación están vinculados a esa ruta de pie de página histórica: la ruta sin cambios conserva la firma, mientras que el pie de página del intermediario controlado la rompe. Mantener cualquier asignación sin aprobar hasta que se revise su alcance real, propietario, vencimiento y comportamiento del receptor. Estas transacciones controladas históricas documentan la comparación de rutas locales; La compatibilidad entre el buzón de correo de producción y el proveedor, la autorización del flujo de negocios real y cualquier aprobación de excepción operativa permanecen sin realizarse.