Un proveedor puede emitir válido DKIM firmas sin admitir el dominio de firma de su organización. Esa limitación es importante cuando la firma del servicio no se alinea con el dominio que los clientes ven en Desde. Establece la limitación exacta antes de cambiar DNS o sustituir el servicio.
Confirme lo que realmente admite el proveedor
Solicite documentación actualizada que cubra el nivel de cuenta, la interfaz de envío y el tipo de dominio que utiliza. Una dirección de remitente verificada, un dominio de seguimiento personalizado o una ruta de devolución de marca no son prueba de soporte DKIM personalizado. Obtenga un mensaje recibido sin procesar de la ruta real y registre los valores d y s de cada firma y los resultados de verificación del receptor confiable.
RFC 6376 define d como el dominio de firma y usa s con ese dominio para localizar datos de verificación. La publicación de una clave bajo su propio dominio no puede cambiar la firma que crea el proveedor. A CNAME de manera similar, necesita una configuración de firma respaldada por el proveedor; un alias DNS por sí solo no indica a un servicio que firme por usted.
Comprobar si existe otra ruta alineada
Con una política aplicable y sin errores de evaluación no resueltos, DMARC puede pasar a través de un paso alineado SPF o resultado DKIM . Evaluar el rendimiento real del servicio. CORREO DE el dominio y el resultado SPF por separado. Una ruta de retorno personalizada compatible puede proporcionar SPF alineado incluso cuando DKIM personalizado no está disponible. Verificar el alineación relación de modo y dominio; una ruta de retorno propiedad del proveedor no se alinea simplemente porque usted paga por la cuenta.
Caso ilustrativo: el correo usa From= notices@brand.example y pasa DKIM con d=vendor.example. Su dominio MAIL FROM es bounce.brand.example y pasa SPF . Suponiendo que la relación organización-dominio califique, una alineación relajada SPF puede satisfacer DMARC . Con una alineación estricta SPF , el subdominio no coincide exactamente. Este es un ejemplo de decisión sintética, no una afirmación sobre ningún proveedor.
RFC 9989 Las secciones 7.4 y 8 requieren la publicación de dominios. p=reject no confiar únicamente en SPF para un pase DMARC y aplicar firmas DKIM válidas. Por lo tanto, un pase SPF de entrega directa no es un diseño de implementación completo p=reject . Resuelva la ruta DKIM alineada que falta antes de tratar ese servicio como listo para esta política.
No describa SPF como un reemplazo idéntico para DKIM alineado. El reenvío puede cambiar la IP de conexión e interrumpir SPF , mientras que una alineación intacta firma DKIM puede sobrevivir. Evalúe las rutas importantes para sus usuarios en lugar de depender de una prueba de entrega directa.
Comparar alternativas compatibles
Las opciones prácticas son conservar el servicio con una ruta SPF alineada y documentada cuando sea compatible con la política del dominio y las limitaciones aceptadas, trasladar el envío a un servicio que admita la identidad DKIM requerida o utilizar una retransmisión autorizada compatible que firme el mensaje final. Cada uno requiere pruebas y un propietario. Una retransmisión debe preservar el comportamiento necesario de la aplicación y firmar después del procesamiento de cambio de contenido; simplemente agregar una firma no relacionada no resuelve la alineación.
Cambiar el dominio De visible es otra decisión del producto, no una solución técnica oculta. Afecta el reconocimiento y las respuestas, y el dominio de reemplazo aún necesita una autenticación válida. Evite debilitar la política DMARC de toda la organización sólo para ocultar una ruta de envío indocumentada.
Registrar la limitación aceptada.
Conserve la declaración de capacidad del proveedor, la evidencia del mensaje recibido, la ruta de alineación elegida, el propietario del negocio y el activador de la revisión. Pruebe mensajes transaccionales y escenarios de reenvío relevantes para el servicio. Si persiste una limitación, indique explícitamente la decisión de exposición y migración. La finalización significa una ruta compatible verificada o una excepción propia, no una captura de pantalla DNS verde.
Utilice un registro de decisión completo
Consideremos esta matriz de dos rutas explícitamente ficticia. La API de facturación A tiene From= brand.example , d=vendor.example, selector proveedor1, CORREO DE = bounce.brand.example , pase SPF sin formato y pase DKIM sin formato. Supongamos una alineación relajada SPF y el valor compartido indicado. dominio organizacional: su camino exitoso está alineado solo con SPF . El relé de reemplazo B tiene From= brand.example , d=brand.example, selector Relay2 y MAIL FROM= vendor.example , con ambas comprobaciones sin procesar aprobadas: su ruta exitosa está alineada solo con DKIM . Cada capacidad y resultado aquí se asume, no se observa por parte de un proveedor.
Estas comparaciones de campo explican los resultados supuestos; no se afirma ninguna ejecución de accesorios ni verificación del proveedor. La API de facturación A ilustra un resultado solo de SPF, no una ruta única aceptable para una implementación p=reject . Antes de implementar cualquiera de los diseños, obtenga instrucciones del proveedor fechadas y específicas de la ruta, valores DNS generados, correo recibido sin procesar y un resultado de receptor confiable. Compare las identidades previstas y observadas, pruebe los formatos críticos y el reenvío relevante, y registre que el propietario acepta cualquier limitación residual. Esos campos de aceptación en el mundo real siguen pendientes.
Elija el siguiente paso admitido
- Capacidad desconocida: obtenga instrucciones actualizadas para el nivel exacto de la cuenta y la ruta de envío; no adivine los valores DNS .
- Solo está disponible SPF alineado: registre los límites de entrega directa y la política actual; no lo utilice como única ruta DMARC para p=reject.
- Retransmisión de firma compatible disponible: verifique el comportamiento de la aplicación, el contenido final, d= alineado y la custodia de claves antes de la migración.
- No hay una ruta adecuada: cambiar de proveedor o tomar una decisión explícita sobre el producto sobre la identidad de From.
- Cierre: guardar evidencia del mensaje recibido, limitaciones restantes, propietario responsable y activación de la próxima revisión.