Elija la identidad comercial antes de editar DNS
FreeAgent puede enviar presupuestos y facturas utilizando su propia identidad predeterminada o un dominio personalizado verificado. Decida qué identidad deben ver los clientes y qué buzón debe recibir sus respuestas. Documente la factura y estime los flujos de trabajo, su propietario y el administrador DNS antes de cambiar cualquiera de los dos. El envío exitoso de una solicitud financiera no es lo mismo que una prueba de que el dominio comercial previsto está autenticado.
La guía de FreeAgent revisada dice que la dirección de remitente predeterminada es noreply@remail.freeagentcentral.com . Un dominio de su propiedad puede autorizarse mediante una configuración de dominio personalizado; un buzón de correo de consumidor en un dominio público compartido no puede darle control sobre DNS de ese dominio. La verificación de una dirección individual y la autorización de su dominio son pasos distintos. Fuente: FreeAgent, Autorice a FreeAgent a enviar correos electrónicos desde su dirección comercial.
Complete el flujo de trabajo de dominio personalizado actual
Abra Configuración > Envío de correos electrónicos, elija Agregar un dominio de correo electrónico personalizado y seleccione un dominio asociado con una dirección de remitente verificada. Si no está, primero agregue y verifique una dirección en ese dominio. Copie la información del host/clave y el valor que se muestra en el paso 2 en el servicio DNS autorizado, luego regrese y agregue el dominio. FreeAgent verifica esos registros. Fuente: Guía de dominios personalizados de FreeAgent.
Trate los registros mostrados de la cuenta como autorizados para esta configuración. No los reemplaces con un histórico. selector, clave o SPF valor encontrado en un artículo antiguo. Capture los tipos de registros, los nombres completos de los propietarios, los valores y la fecha en el registro de cambios. Si la pantalla y la documentación difieren, resuelva la discrepancia antes de continuar en lugar de combinar ambas generaciones de configuración.
Inspeccione los registros existentes de cada propietario antes de editarlos. Una clave pública TXT y un token de verificación pueden tener propósitos diferentes incluso cuando ambos aparecen en un asistente. Conservar las entradas de otras aplicaciones. El registrador y el host DNS pueden diferir: verifique el delegado servidores de nombres en lugar de asumir que la empresa donde se compró el dominio publica sus registros.
Revise la instrucción SPF en contexto
Los nombres actuales de la guía FreeAgent include:spf.mtasv.net cuando una política SPF estricta existente termina en -all . Dice que generalmente no se necesita una nueva política SPF separada para su flujo de trabajo. No sustituya una versión anterior de FreeAgent que se encuentre en otro lugar. Fuente: sección SPF de FreeAgent.
Esa instrucción del producto no es motivo para eliminar una política SPF que funcione, debilitar su calificador final o asumir que todo el correo ahora pasa. DMARC. Si es necesario un cambio SPF , combine la autorización en la política existente después de hacer un inventario de todos los remitentes y verificar los límites de búsqueda de DNS. Preservar otros servicios. Mantenga esta tarea de autorización limitada separada de un rediseño de políticas para todo el dominio.
Verificar el cambio mediante una ruta de facturación controlada
Antes de realizar la prueba, evite una transacción real con un cliente o un compromiso financiero. Utilice un flujo de trabajo de prueba autorizado y un destinatario controlado, con contenido claramente ficticio. Registre qué flujo de trabajo de FreeAgent envió el mensaje y si su nombre visible coincide con la dirección comercial aprobada. Verifique Responder a de forma independiente inspeccionando y, cuando corresponda, probando el destino de la respuesta.
Conservar el mensaje original recibido con un receptor de confianza Authentication-Results, De, identidad del sobre y DKIM firmando dominio/selector. SPF autentica la identidad del sobre, no automáticamente De. DKIM verifica una firma asociada con su dominio d=. DMARC necesita una identidad SPF o DKIM aprobada alineada con From según el aplicable alineación modo. La verificación del producto y la apariencia de la bandeja de entrada no pueden reemplazar esta evidencia.
Ejemplo sintético: llega una estimación con De accounts@example.com , pase SPF para un dominio de sobre propiedad del proveedor y pase DKIM con d=example.com. La coincidencia exacta firma DKIM puede proporcionar la ruta DMARC alineada; El éxito SPF no relacionado no puede. Si un mensaje posterior utiliza el De predeterminado del proveedor, puede autenticarse correctamente para esa identidad predeterminada y al mismo tiempo no cumplir con la condición de aceptación de marca. Trate la entrega y la identidad prevista como resultados separados.
Diagnosticar la reversión y mantener una recuperación segura
FreeAgent advierte que eliminar o cambiar los registros DNS requeridos puede hacer que el dominio personalizado no esté verificado y revertir la dirección De a su valor predeterminado; también envía una notificación. Supervise las consecuencias operativas de una migración DNS , no solo si se carga la nueva zona. Conserve los registros necesarios al cambiar de proveedor DNS y luego pruebe los flujos de trabajo de cara al cliente.
Si la validación falla, compare los valores de la cuenta con DNS autorizado, verificando la duplicación del sufijo del nombre del propietario y los caracteres omitidos antes de esperar a que expire la caché. Si la configuración es correcta pero falta el correo, conserve el estado de envío exacto y la evidencia del destinatario e investigue la entrega por separado. No prometa que un solo retraso solucionará el problema.
Antes de eliminar registros históricos específicos de FreeAgent, confirme que estén obsoletos y que no los utilice otra ruta activa. Conserve una copia reversible y un acuerdo de remitente aprobado y que funcione. La finalización requiere verificación de la cuenta, registros autorizados y evidencia real de los mensajes recibidos para las rutas de facturación y estimación relevantes. Esta guía documental no realizó ninguna de esas operaciones en vivo; La revisión independiente, la aprobación de las PYME humanas y la publicación siguen pendientes.
Clasificar un presupuesto entregado sin inventar una prueba de pago
El caso escrito FA-01 asume que el De aprobado es accounts@example.com , pero una muestra de estimación ficticia muestra el De predeterminado del proveedor documentado después de que se eliminaron los registros DNS requeridos. Se desconocen el resultado de la autenticación del receptor y Responder a. La entrega exitosa por sí sola no puede establecer ni la identidad deseada ni la autenticación alineada para example.com . El propietario del flujo de trabajo financiero debe conciliar la verificación de la cuenta actual y DNS con el administrador, luego utilizar una prueba no vinculante autorizada e inspeccionar los campos reales del remitente y de respuesta. No cree una factura real ni una obligación de pago simplemente para obtener encabezados. Para este caso no se accedió a ningún cliente, transacción, registro 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.