Comience con la ruta de reenvío en lugar de la etiqueta Gmail
Un mensaje que llega a Gmail después del reenvío tiene un historial de entrega diferente al de un mensaje enviado allí directamente. El servicio de reenvío puede cambiar el sobre SMTP , conservar o alterar el mensaje original y adjuntar sus propias observaciones de autenticación. Diagnostica ese historial antes de pedirle al remitente original que cambie DNS . Una entrega directa exitosa establece una comparación útil, pero no prueba que la ruta indirecta conserve la misma ruta de autenticación.
Identifique el tipo de cuenta final y el mecanismo de reenvío. Las pautas generales para remitentes de Google abordan explícitamente las cuentas personales Gmail , mientras que el enrutamiento de Google Workspace de una organización puede implicar opciones administrativas adicionales. Registre si el intermediario es un servicio de alias, una regla de buzón, una puerta de enlace o un sistema de correo. No aplique una regla para un producto o ruta simplemente porque ambos destinos muestran una interfaz familiar Gmail .
Lea la guía del proveedor dentro de su alcance.
actual de google guía de reenvío recomienda utilizar el dominio de reenvío en el remitente del sobre, autorizando la infraestructura de reenvío en ese dominio SPF política, limitando el reenvío de spam y evitando cambios que interfieran con DKIM. También dice que Gmail realiza sus propias comprobaciones de autenticación. Esas recomendaciones no prometen la entrega de la bandeja de entrada ni hacen que el pase de un servidor anterior sea autorizado en Gmail .
Mantenga esa guía separada de la Requisitos personales del remitente Gmail. Los requisitos varían según el volumen de envío y el propósito del mensaje. Este artículo no sustituye la determinación de qué requisitos se aplican al remitente real. Tampoco propone cambiar la configuración de la cuenta de un usuario, permitir el reenvío o agregar una dirección a cualquier lista confiable sin la decisión apropiada del propietario.
Siga el sobre y la identidad visible por separado.
En la conexión SMTP final, SPF evalúa la identidad relevante utilizando la dirección del servidor de conexión. Un reenviador es un nuevo servidor que se conecta, por lo que conservar el sobre original puede cambiar el resultado SPF . RFC 7208 sección 10.3 explica el problema del mediador. La dirección De remitente visible del mensaje es una identidad separada y puede permanecer sin cambios en todo momento.
Un sobre reescrito bajo el dominio del reenviador puede obtener autorización SPF para ese dominio. No se alinea, simplemente por contener la dirección original en una parte local, con el dominio del autor original. Bajo RFC 9989 sección 4.4, DMARC requiere un identificador autenticado de paso con la relación de dominio requerida. Registre los dominios reales y alineación modo en lugar de tratar un pase SPF como la respuesta completa.
Para realizar una investigación, solicite la identidad del sobre original a los registros de entrega confiables, cuando estén disponibles. una final Return-Path puede ser útil pero no describe de forma independiente cada transacción SMTP anterior. Marque los valores anteriores no disponibles como desconocidos en lugar de reconstruirlos a partir de un nombre para mostrar o un texto de mensaje entrecomillado.
Preservar la firma alineada cuando el reenvío lo permita
DKIM puede sobrevivir al reenvío cuando el contenido cubierto aún se verifica. Que una modificación invalide una firma depende de los campos del encabezado firmados, la cobertura del cuerpo, canonicalización y los bytes reales en la verificación. RFC 6376 secciones 3.4 y 5.4 proporcionar esas reglas. No afirme que cada encabezado agregado rompe DKIM o que cada mensaje con un cuerpo visible sin cambios debe verificarse.
Inspeccione el dominio de firma de la firma original y selector, sus encabezados firmados listados y el resultado de la verificación del receptor. Un prefijo de asunto, pie de página, conversión MIME o transformación de archivo adjunto pueden afectar el material cubierto. Compare los mensajes antes y después de la transformación sospechada. Agregar una nueva firma desde un dominio de reenvío no relacionado no repara la firma original ni establece la alineación para el autor original.
Un receptor podría considerar ARC pruebas según su propia política. RFC 8617 describe ese mecanismo experimental; una cadena válida no es un pase DMARC automático ni una garantía de entrega. A partir de esta revisión, el propuesta para reclasificar ARC sigue siendo un trabajo en progreso. No convierta un borrador de propuesta en una afirmación sobre lo que Gmail ha habilitado o deshabilitado.
Comparación ficticia de recibos directos y reenviados.
Imagine que el remitente ficticio de Tickets de ejemplo envía un recibo directamente a un buzón de correo controlado Gmail y otro recibo equivalente a través de un alias en example.net . El dominio de autor previsto es example.com . En este escenario inventado, la copia directa tiene una firma alineada válida, mientras que la copia reenviada conserva esa firma pero adquiere un pie de página que cambia su cuerpo cubierto.
Supongamos que el sobre final se reescribe en example.net y SPF pasa por esa identidad. Ese pase hipotético no se alinea con example.com . A continuación, el revisor inspeccionaría si sobrevive alguna otra firma alineada válida y qué informa el receptor final. El ejemplo no afirma un veredicto Gmail , una anulación ARC ni un rechazo observado; no se enviaron ni recopilaron mensajes.
La pregunta de reparación propuesta es estrecha: ¿puede el transportista autorizado conservar el material del mensaje relevante y al mismo tiempo satisfacer las necesidades del servicio? Esto es más útil que agregar el reenviador a la política del remitente original sin comprender las consecuencias de identidad y autorización.
Conserve un paquete de pruebas antes de declarar el éxito
Utilice cuentas de prueba consentidas y mensajes no confidenciales aprobados. Capture tiempos de entrega directos e indirectos, identificadores de ruta, observaciones de sobres, firmas completas y resultados de autenticación finales confiables. Registre la disposición real por separado: la aceptación SMTP , la entrega al buzón de correo, la colocación de spam y la visibilidad del usuario no son resultados intercambiables. Si una copia intermedia no está disponible, indique qué transformación no se puede localizar.
Evalúe un cambio propuesto comparándolo con formatos y rutas representativos, no solo con un mensaje de texto sin formato. Conserve la configuración anterior y defina qué desencadenaría la recuperación. La puerta exacta del catálogo permanece abierta: muestras de entrega directa e indirecta comparadas con ruta, sobre, firmas y resultados confiables. Este manuscrito contiene un ejercicio ficticio y orientación documental actual, no esas muestras originales ni una implementación verificada Gmail .