Confirme el producto y la ruta exactos de GoodData
El procedimiento propio que respalda esta guía se denomina GoodData Legacy Growth, Configure DKIM para correo electrónico saliente. Se trata de correo saliente con etiqueta blanca y requiere trabajo tanto por parte del cliente como de GoodData. No lo aplique automáticamente a GoodData Cloud actual, a otro plan o a un servicio de notificación diferente.
Comience confirmando el producto, el dominio de marca blanca, las direcciones de origen previstas y los flujos de trabajo de mensajes reales con el propietario de la cuenta. Identifique al administrador DNS y al propietario del soporte de GoodData que maneja la configuración de marca blanca. Una URL de aplicación personalizada o un tema de marca no es prueba de que el correo electrónico saliente esté firmado con el mismo dominio.
La tarea del lector es establecer un acuerdo de firma compatible y luego probar el correo previsto. La amplia etiqueta de proveedor del catálogo no justifica afirmar que todos los productos GoodData admiten el mismo selector, proceso de retransmisión o gestión de claves. Si el alcance heredado documentado no coincide con su inquilino, obtenga el procedimiento propio correspondiente antes de cambiar DNS .
Elija una disposición de claves compatible
La documentación de Legacy Growth describe el uso de una clave privada específica, con una clave única generada por GoodData como alternativa, o el uso de una clave compartida de GoodData. En la ruta de clave compartida, Support proporciona un registro DNS que contiene la clave pública. En la ruta de clave específica, las partes coordinan el selector y el dominio con la configuración de firma. No se proporciona ningún selector universal ni valor de clave pública para que los clientes copien de esta guía.
Prefiera un acuerdo que se ajuste a la política de propiedad de claves de firma de la organización y minimice la exposición innecesaria. Aclare quién genera la clave, quién puede usarla, cómo se coordina la rotación y cómo se eliminará la autoridad de firma del proveedor cuando se retire el servicio. Un registro DNS público puede ser ampliamente visible; una clave privada no puede tratarse de la misma manera.
La documentación del proveedor describe la transferencia cifrada cuando se utiliza una clave privada proporcionada por el cliente. No pegue una clave privada en el chat, un comentario de soporte ordinario, un documento público o DNS . Haga que el propietario del valor autorizado verifique el destinatario previsto y el proceso de transferencia segura. Solicitar o aceptar una alternativa generada por el proveedor aún requiere comprender quién posee y controla el material de firma privado.
Publicar únicamente el material de verificación pública.
Obtenga el tipo de registro exacto, el propietario completo, el selector y el valor público de la configuración admitida. Compárelos con el dominio de firma aprobado. Registre la etiqueta del editor DNS requerida por separado porque un campo de nombre relativo puede agregar la zona automáticamente. Compruebe si un selector existente ya pertenece a otro servicio de correo antes de realizar un cambio.
A firma DKIM con d=example.com y s=analytics1 busca su clave en analytics1._domainkey.example.com . Este es un ejemplo de construcción de nombre sintético, no un valor predeterminado de GoodData. Una clave publicada correctamente en un selector o dominio diferente no verificará esa firma. Preservar el valor público completo y los límites del registro cuando el editor representa una larga registro TXT como múltiples cadenas.
Después de la publicación, consulte DNS autorizado para conocer al propietario exacto. Conserve las respuestas y confirme que la delegación activa esté entregando el registro que editó. Luego, pídale al propietario del soporte que complete la configuración del lado de GoodData. La publicación DNS sin activación de firma es solo la mitad de la tarea.
Mantenga SPF opcional distinto del alineado
Las listas de páginas Legacy Growth include:relays.gooddata.com como opción SPF además de autorizar sus retransmisiones de correo. Confirme que esta es la ruta aplicable antes de usarla. No la agregue únicamente porque existe un flujo de trabajo GoodData no relacionado en la organización y no cree una segunda política SPF para el mismo propietario.
Revise cualquier actualización SPF necesaria en su totalidad: conserve los remitentes aprobados existentes, verifique las dependencias de búsqueda de DNS de la política y confirme el comportamiento de su terminal. Evite copiar direcciones IP de retransmisión en una lista de permitidos estática sin un plan de mantenimiento explícito. Un objetivo de autorización administrado por el proveedor y una lista congelada de las respuestas actuales tienen diferentes consecuencias operativas.
El éxito SPF por sí solo no demuestra DMARC alineación. La identidad evaluada es la remitente del sobre dominio. Si un mensaje utiliza un sobre propiedad del proveedor mientras muestra su dominio en Desde, un pase SPF para ese dominio del proveedor no se alinea con su dominio. Una firma DKIM pasajera alineada con el Desde visible puede proporcionar la ruta requerida.
Pruebe un mensaje real con etiqueta blanca
Active cada flujo de trabajo de material dentro del alcance a un buzón de prueba controlado y autorizado. Conserve el mensaje recibido sin procesar y anote el flujo de trabajo, la configuración del remitente y el tiempo de prueba. Registre el origen visible, la identidad del sobre, cada dominio y selector de firma DKIM y los resultados de autenticación del receptor confiable. No infieras estos valores únicamente a partir de la URL de marca blanca o de una visualización firmada.
Ejemplo de aceptación sintética: en reports@example.com , la firma DKIM del mensaje se verifica con d=example.com y el receptor evalúa DMARC exitosamente en esa ruta alineada. Incluso si SPF pasa solo por un dominio de envolvente no relacionado, DKIM alineado exactamente puede proporcionar la ruta DMARC . Si, en cambio, la firma utiliza un dominio diferente no relacionado, un pase DKIM por sí solo no es suficiente para respaldar esta conclusión de aceptación.
Repita el ejemplo después de la rotación de claves o un cambio en el transporte de correo. Si la firma esperada no está, verifique la activación del lado de GoodData y el flujo de trabajo real antes de agregar más registros. Si la firma está presente pero no es válida, compare el selector, el dominio, la clave pública y cualquier modificación del mensaje. Si la autenticación pasa pero la entrega es deficiente, investigue otros factores del receptor y de reputación por separado.
Rotación de planes, jubilación y recuperación.
Mantenga el conjunto de registros previo al cambio y un propietario documentado para cada parte del acuerdo de firma. Coordine el momento en que el proveedor comienza a firmar con un nuevo selector y el momento en que la clave pública esté disponible. No asuma que la eliminación de un solo registro revoca todas las capacidades o que eliminar inmediatamente una clave antigua es seguro para el correo ya enviado que aún se entrega.
Al retirar la integración, verifique que ningún flujo de trabajo aún la necesite antes de eliminar selectores o permisos SPF . Concilie la retención de clave privada y el acceso a la firma del proveedor bajo el proceso de seguridad de la organización. Si es posible que una clave haya quedado expuesta, utilice un proceso de incidente y rotación en lugar de tratar el problema como un retraso normal en la caché DNS .
Esta es una guía documental para un producto heredado específicamente etiquetado. Los ejemplos son sintéticos. No se accedió ni se probó ninguna clave privada, configuración de inquilino, cambio DNS , intercambio de soporte o mensaje GoodData entregado. La verificación de la producción y cualquier decisión más amplia sobre el alcance del producto quedan en manos de los propietarios de la cuenta y de la seguridad.
Utilice un libro de activación antes de completar la ruta
El caso escrito GD-01 supone que el inquilino tiene un crecimiento heredado confirmado, el remitente aprobado es reports@example.com y el selector ilustrativo acordado es análisis1. El propietario DNS tiene una clave pública estipulada en analytics1._domainkey.example.com , mientras que la activación de la firma por parte del proveedor sigue sin confirmarse. DNS por sí solo no puede cerrar la tarea. Pídale al propietario de la marca blanca que obtenga la confirmación de la configuración de firma admitida y luego inspeccione una notificación autorizada inofensiva. Un hipotético paso DKIM confiable posterior con d=example.com, s=analytics1 proporcionaría una alineación exacta, pero hasta que exista esa evidencia, el resultado del mensaje seguirá siendo desconocido. Aquí no se utilizó ninguna clave privada, solicitud de soporte, búsqueda DNS o acción del inquilino.
Preservar el límite de aplicación
RFC 9989 La sección 7.4 requiere DKIM válido, no solo SPF , para la publicación de dominios p=rejecty advierte sobre la interoperabilidad del correo indirecto y de las listas de correo. Una sola prueba exitosa de mensajes directos no es prueba de que todas las rutas legítimas estén listas para una política más fuerte. Mantener la protección aprobada existente mientras se diagnostica la brecha real; cualquier cambio de política necesita su propia decisión.