Identificar la ruta de envío frontal
Front puede presentar bandejas de entrada similares mientras utiliza diferentes transportes de salida. Comience registrando el tipo de canal, dirección, dominio y propietario de la cuenta. Distinga la sincronización Gmail u Office 365 , el reenvío SMTP con autenticación proporcionada por Front y SMTP personalizado. No autorices un segundo servicio de entrega simplemente porque aparece un buzón en el Frente.
La documentación sobre capacidad de entrega de Front dice que la sincronización nativa Gmail y Office 365 utiliza las API de los proveedores y no necesita las funciones adicionales de Front. SPF/ Registros DKIM . Los canales reenviados por SMTP, incluidos los Grupos de Google configurados de esa manera, requieren una evaluación por separado. SMTP personalizado utiliza el servidor elegido; siga los requisitos de autenticación de ese servidor. Esta distinción de rutas es el requisito previo más importante para el cambio.
El límite práctico es el transporte, no la marca. Un mensaje redactado en Front y enviado por un buzón conectado debe compararse con la configuración del dominio de ese proveedor de buzón. Un canal reenviado por SMTP que utiliza la infraestructura de envío de Front debe compararse con los registros DNS proporcionados por Front. Mantenga dos registros de aceptación si la organización utiliza ambos.
Recopile requisitos DNS específicos de la cuenta
Para canales SMTP compartidos, un administrador de la empresa abre la configuración de la empresa, Seguridad y luego Capacidad de entrega. La pestaña depende de tener un canal SMTP compartido. Seleccione el dominio y obtenga sus registros mostrados. Para un canal SMTP individual, utilice la configuración de Canales del compañero de equipo y la opción Mejorar tasas de entrega - SPF / DKIM sección. Publique los registros proporcionados y ejecute Comprobar configuración DNS ; el estado de éxito documentado está Verificado.
Esos pasos describen la configuración documental, no un inquilino al que accedimos. Solicite al administrador autorizado que exporte los nombres de registros, tipos, valores y cualquier campo de prioridad de la cuenta real. Mantenga el nombre completo del propietario previsto junto a la etiqueta de entrada del editor DNS . Esto evita que un campo de nombre relativo agregue el dominio dos veces.
No transfiera selectores de otro cliente de Front ni reemplace la política SPF raíz con un ejemplo de servicio genérico. Los valores mostrados de la cuenta son la autoridad de configuración. Si la interfaz de usuario entra en conflicto con un documento anterior, deténgase y resuelva el canal y servicio exactos antes de escribir DNS .
Mantenga el enrutamiento entrante separado
Front documenta un propietario MX de correo frontal dedicado para su configuración de autenticación, distinto del dominio raíz Registros MX Se utiliza para recibir correo ordinario. No reemplace los registros MX raíz existentes para que desaparezca una advertencia de autenticación. En un editor MX , la prioridad es un campo numérico separado del nombre del host de destino.
Antes de publicar, examine cada nombre de propietario solicitado para determinar su uso existente. Una instrucción del proveedor para agregar registros no es un permiso para destruir los registros de un servicio diferente. Registre cualquier colisión y obtenga una alternativa compatible en lugar de sobrescribirla silenciosamente. Verifique que la zona autorizada sea la que está editando, especialmente si el registrador y el host DNS difieren.
La página de configuración del canal ofrece la posibilidad de elegir entre registros SMTP y SPF / DKIM personalizados. Si su servicio DNS no puede admitir la configuración requerida, investigue la ruta SMTP personalizada documentada con el administrador de correo. No improvise colocando registros en una etiqueta cercana sin usar: las firmas y el envío de sobres requieren los nombres exactos previstos.
Acepta DNS y correo de forma independiente
La validación de productos y DNS autorizado responden a diferentes preguntas. Consulta el propietario esperado y escribe en cada servidor autorizado. Compare la respuesta con los valores de cuenta aprobados. Si las respuestas autorizadas no están de acuerdo, primero repare el estado de la zona. Si están de acuerdo pero Front aún ve una respuesta anterior, permita la vida útil de la caché anterior y repita la verificación sin reescribir repetidamente los registros de trabajo.
Luego envíe un mensaje controlado a través del canal frontal real a un buzón cuyo mensaje recibido sin procesar esté disponible. Registre el dominio visible, la identidad del sobre, todos los valores DKIM d= y s= y los resultados de autenticación del receptor confiable. Un pase SPF se refiere a la identidad del sobre. Un pase DKIM se refiere a un dominio de firma. DMARC necesita al menos una ruta de paso alineada con el dominio Desde visible. Recibir una respuesta o ver un mensaje en Enviados no establece ese resultado.
Ejemplo sintético, no es un valor predeterminado de Front observado: un mensaje de soporte tiene De help@example.com , sobre bounce@front-mail.example.com y un firma DKIM con d=example.com. El dominio DKIM se alinea exactamente. El sobre es un subdominio en lugar de una coincidencia exacta de dominio, por lo que su SPF alineación Depende del modo aplicable. Si la firma falla y se requiere una alineación estricta SPF , una aprobación SPF para ese subdominio no rescata el ejemplo.
Diagnosticar la capa defectuosa específica
La falta de una pestaña de Entregabilidad es una pregunta de acceso o alcance del canal, no una prueba de que DKIM no sea compatible. Una advertencia DNS después de un cambio puede indicar una zona incorrecta, duplicación de sufijos, un error de tipo de registro o datos almacenados en caché. Una verificación DNS aprobada con un mensaje sin firmar apunta al estado de activación o transporte saliente seleccionado. Un mensaje alineado que llega a spam requiere una investigación separada de la reputación, el contenido y la política del destinatario; la autenticación no garantiza la ubicación de la bandeja de entrada.
Conserve los conjuntos de registros DNS antiguos y la última configuración del canal de trabajo antes de realizar un cambio. Pruebe el correo entrante normal por separado de la firma saliente y pruebe las respuestas esperadas. Si es necesaria la recuperación, restaure solo la configuración afectada según un cambio aprobado; evite reemplazar registros raíz no relacionados o deshabilitar todo el dominio Aplicación DMARC como atajo.
Completar el récord honestamente
El paquete de aceptación debe nombrar el canal Front, el propietario de la empresa, el propietario DNS , los registros proporcionados, las respuestas autorizadas, el resultado de la validación Front y la evidencia de identidad del mensaje recibido. Etiquete cada ruta probada. Esta guía tiene evidencia documental y solo un ejemplo sintético: no se recopilaron configuraciones de inquilinos, observaciones DNS en vivo ni resultados de mensajes entregados. La aceptación de la producción queda en manos del administrador autorizado después de estas comprobaciones.
Mantenga dos canales en filas de evidencia separadas
El caso escrito FR-01 supone que help@example.com es un canal de sincronización nativo Microsoft 365 , mientras que group@example.com es un grupo reenviado por SMTP que utiliza envío frontal. El primero tiene un pase DKIM confiable estipulado con d=example.com, s=demo1; el segundo no tiene evidencia de mensaje recibido. La primera ruta alineada no valida la segunda ruta ni autoriza nuevos cambios DNS para la primera. Solicite al propietario del canal que confirme el transporte del grupo y obtenga sus valores generados, preservando MX raíz y todos los registros del proveedor de buzones. Si el grupo utiliza posteriormente SMTP personalizado, vuelva a evaluar ese servidor. En este ejemplo no se accedió a ningún canal, búsqueda DNS o mensaje.
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.