Comience con el remitente del sobre así como la dirección De remitente visible. La referencia turboSMTP sitúa su SPF autorización en el dominio de dirección del sobre. Un inicio de sesión SMTP exitoso demuestra permiso para enviar correo al retransmisor; no prueba que el destinatario autentique el dominio De elegido.
Publicar los registros de autenticación de retransmisión aplicables
El ejemplo oficial de autorizaciones include:spf.turbo-smtp.com. Fusionar ese mecanismo en la única política SPF existente cuando corresponda, antes de su mecanismo terminal. No copie a, mx o ?all del ejemplo en una política establecida sin decidir si esas autorizaciones y semántica de fallas son las previstas.
La referencia proporciona una clave pública TXT para turbo-smtp. _domainkey . Copie la clave completa actual de la referencia oficial o de la configuración confirmada por su proveedor, no una clave inventada a partir del selector nombre. Confirme que la firma saliente real utiliza ese selector y su dominio de firma esperado. La página contiene una frase inconsistente en su DMARC sección: DMARC pertenece a _dmarc .<dominio>, como muestra su propia tabla, no al selector DKIM . Siga el estándar DMARC para ese nombre de propietario. referencia de configuración turboSMTP
No reemplace una política de cumplimiento existente con la de la página. p=none ejemplo simplemente para completar la configuración. El lenguaje de entrega de un proveedor no es una garantía de bandeja de entrada. Si su cuenta expone diferentes valores de autenticación, resuelva la diferencia con soporte y conserve las instrucciones específicas de la cuenta antes de cambiar DNS .
Verifique DNS y un resultado de recepción real
Antes de cambiar la configuración del remitente de retransmisión SMTP , exporte los valores DNS existentes, registre la diferencia aprobada y nombre el propietario de la reversión. Confirme si el editor DNS espera una etiqueta relativa o un nombre completo; duplicar el sufijo del dominio crea un récord que ningún verificador previsto encontrará. Consulta el nombre del propietario real después de guardar, incluido cualquier CNAME objetivo, en lugar de confiar en el banner de éxito del editor.
SPF debe seguir siendo una política en el dominio relevante y permanecer dentro de los límites del término de consulta DNS en RFC 7208. Agregar una inclusión no establece por sí solo alineación. Bajo RFC 9989, DMARC pasa cuando al menos un SPF exitoso o DKIM El resultado se alinea con el dominio De visible en el modo aplicable. No exija que ambos mecanismos se alineen como condición impuesta por el estándar, y no confunda un pase de dominio de proveedor con un pase de dominio de cliente alineado.
Envíe un mensaje enviado a través de las mismas credenciales SMTP y la misma aplicación utilizada en producción a un buzón que usted controle. Guarde los resultados de autenticación confiable del sistema receptor, visibles desde, identidad del sobre, valores DKIM d= y s=, marca de tiempo y estado del proveedor. Una búsqueda DNS solo muestra la clave disponible; RFC 6376 La verificación también evalúa la firma del mensaje recibido. Utilice contenido no confidencial y evite exponer mensajes completos de los clientes a verificadores públicos.
Utilice una decisión de aceptación y reversión limitada
Un caso de aceptación ilustrativo es un mensaje de alerts@example.com con una firma válida usando d=example.com. Esa coincidencia exacta de dominio admite la alineación DKIM en cualquier modo. Una firma válida que utilice únicamente d=vendor.example.net no se alinea con example.com ; sin SPF alineado, esa muestra no pasa la prueba de aceptación DMARC . Estos son ejemplos de razonamiento, resultados de TurboSMTP no observados.
Si la prueba falla, separe DNS faltantes, el selector incorrecto, la configuración del proveedor inactivo, el enrutamiento inesperado y la modificación de mensajes antes de realizar otro cambio. Vuelva a probar el mismo flujo de trabajo después de cada corrección aprobada. No debilite la política DMARC de todo el dominio para ocultar un problema de un solo remitente. Cuando sea necesario realizar una reversión, restaure el enrutamiento anterior aprobado o la configuración del remitente y conserve los registros clave mientras los mensajes firmados en cola aún los necesiten. Guarde las pruebas de prueba y las excepciones no resueltas con el inventario de dominio. No se realizó ningún acceso de inquilino, cambio DNS ni envío real durante la preparación de esta guía.
Separe una póliza extraviada de una firma que funcione
El caso escrito TS-01 supone que se recibió un mensaje antes de que se realizara la edición DNS errónea de alerts@example.org y un pase DKIM confiable con d=example.org, s=turbo-smtp. Esto proporciona una alineación DKIM exacta. Por otra parte, un administrador colocó por error un valor DMARC TXT en turbo-smtp._domainkey.example.org ; se desconoce la política real en _dmarc.example.org . Ese valor fuera de lugar no es una política DMARC utilizable en el propietario del descubrimiento requerido, y mezclarlo con datos clave justifica una investigación. El propietario DNS debe preservar la clave pública correcta y conciliar la política prevista en _dmarc.example.org sin reemplazar la aplicación existente. El resultado de la firma hipotética no valida el cambio DNS erróneo. No se inspeccionó ni modificó ningún mensaje, clave o zona.
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.