Escolha a identidade comercial antes de editar DNS
O FreeAgent pode enviar orçamentos e faturas usando sua própria identidade From padrão ou um domínio personalizado verificado. Decida qual identidade os clientes devem ver e qual caixa de correio deve receber suas respostas. Documente a fatura e estime os fluxos de trabalho, seu proprietário e o administrador DNS antes de alterar qualquer um deles. O envio bem-sucedido de um aplicativo financeiro não é o mesmo que prova de que o domínio comercial pretendido foi autenticado.
O guia do FreeAgent revisado diz que o endereço De padrão é noreply@remail.freeagentcentral.com . Um domínio que você possui pode ser autorizado por meio de uma configuração de domínio personalizado; uma caixa de correio de consumidor em um domínio público compartilhado não pode lhe dar controle sobre o DNS desse domínio. A verificação de um endereço individual e a autorização do seu domínio são etapas distintas. Fonte: FreeAgent, autorize o FreeAgent a enviar e-mails do seu endereço comercial.
Conclua o fluxo de trabalho atual do domínio personalizado
Abra Configurações > Envio de e-mails, escolha Adicionar um domínio de e-mail personalizado e selecione um domínio associado a um endereço de remetente verificado. Se estiver ausente, primeiro adicione e verifique um endereço nesse domínio. Copie as informações de host/chave e valor exibidas na etapa 2 no serviço DNS autoritativo, retorne e adicione o domínio. O FreeAgent verifica esses registros. Fonte: guia de domínio personalizado do FreeAgent.
Trate os registros exibidos da conta como oficiais para esta configuração. Não os substitua por um histórico seletor, chave ou SPF valor encontrado em um artigo antigo. Capture os tipos de registro, complete os nomes dos proprietários, os valores e a data no registro de alteração. Se a tela e a documentação forem diferentes, resolva a discrepância antes de continuar, em vez de combinar as duas gerações de configuração.
Inspecione os registros existentes de cada proprietário antes de editá-los. Uma chave pública TXT e um token de verificação podem ter finalidades diferentes, mesmo quando ambos aparecem em um assistente. Preservar entradas de outros aplicativos. O registrador e o host DNS podem ser diferentes: verifique o delegado servidores de nomes em vez de presumir que a empresa onde o domínio foi adquirido publica seus registros.
Revise a instrução SPF no contexto
Os nomes atuais dos guias do FreeAgent include:spf.mtasv.net quando uma política SPF estrita existente termina em -all . Ele diz que geralmente não é necessária uma nova política SPF separada para seu fluxo de trabalho. Não substitua um FreeAgent mais antigo encontrado em outro lugar. Fonte: seção SPF do FreeAgent.
Essa instrução do produto não é motivo para remover uma política SPF em funcionamento, enfraquecer seu qualificador final ou presumir que todas as correspondências agora passam DMARC. Se for necessária uma alteração SPF , mescle a autorização na política existente após inventariar todos os remetentes e verificar os limites de pesquisa de DNS. Preservar outros serviços. Mantenha essa tarefa de autorização restrita separada de uma reformulação da política em todo o domínio.
Verifique a alteração usando um roteiro de fatura controlado
Antes de testar, evite uma transação real do cliente ou um compromisso financeiro. Utilize um fluxo de trabalho de teste autorizado e um destinatário controlado, com conteúdo claramente fictício. Registre qual fluxo de trabalho do FreeAgent enviou a mensagem e se seu De visível corresponde ao endereço comercial aprovado. Verifique Reply-To de forma independente, inspecionando e, quando apropriado, testando o destino da resposta.
Retenha a mensagem original recebida com um destinatário confiável Authentication-Results, De, identidade do envelope e DKIM assinando domínio/seletor. SPF autentica a identidade do envelope, e não automaticamente De. DKIM verifica uma assinatura associada ao seu domínio d=. DMARC precisa de uma identidade SPF ou DKIM aprovada alinhada com De sob o aplicável alinhamento modo. A verificação do produto e a aparência na caixa de entrada não podem substituir esta evidência.
Exemplo sintético: uma estimativa chega com From accounts@example.com , passe SPF para um domínio de envelope de propriedade do provedor e passe DKIM com d=example.com. A correspondência exata Assinatura DKIM pode fornecer o caminho DMARC alinhado; o sucesso não relacionado SPF não pode. Se uma mensagem posterior usar o De padrão do provedor, ela poderá ser autenticada corretamente para essa identidade padrão e ainda assim falhar na condição de aceitação da marca. Trate a entrega e a identidade pretendida como resultados separados.
Diagnosticar a reversão e manter a recuperação segura
O FreeAgent avisa que remover ou alterar seus registros DNS necessários pode tornar o domínio personalizado não verificado e reverter o endereço De para seu padrão; ele também envia uma notificação. Monitore as consequências operacionais de uma migração DNS , e não apenas se a nova zona é carregada. Preserve os registros necessários ao alterar os provedores DNS e teste os fluxos de trabalho voltados para o cliente posteriormente.
Se a validação falhar, compare os valores da conta com DNS autoritativo, verificando a duplicação do sufixo do nome do proprietário e os caracteres omitidos antes de aguardar a expiração do cache. Se a configuração estiver correta, mas faltar correio, guarde o status exato do envio e as evidências do destinatário e investigue a entrega separadamente. Não prometa que apenas um atraso resolverá o problema.
Antes de remover registros históricos específicos do FreeAgent, confirme se eles estão obsoletos e não são usados por outra rota ativa. Mantenha uma cópia reversível e um remetente aprovado e em bom funcionamento. A conclusão requer verificação de conta, registros oficiais e evidências reais de mensagens recebidas para faturas relevantes e rotas de estimativas. Este guia documental não realizou nenhuma dessas operações ao vivo; revisão independente, a aprovação e publicação das PME humanas permanecem pendentes.
Classifique uma estimativa entregue sem inventar um teste de pagamento
O caso escrito FA-01 assume que o From aprovado é accounts@example.com , mas uma amostra de estimativa fictícia mostra o padrão From do provedor documentado após a remoção dos registros DNS necessários. O resultado da autenticação do receptor e Reply-To são desconhecidos. A entrega bem-sucedida por si só não pode estabelecer a identidade pretendida ou a autenticação alinhada para example.com . O proprietário do fluxo de trabalho financeiro deve reconciliar a verificação da conta corrente e DNS com o administrador, depois usar um teste não vinculativo autorizado e inspecionar os campos reais do remetente e da resposta. Não crie uma fatura real ou uma obrigação de pagamento apenas para obter cabeçalhos. Nenhum cliente, transação, registro ou mensagem foi acessado neste caso.
Preservar o limite de aplicação
RFC 9989 A Seção 7.4 exige DKIM válido, e não apenas SPF , para publicação de domínios p=rejecte alerta sobre a interoperabilidade de correio indireto e listas de discussão. Um único teste bem-sucedido de mensagem direta não é prova de que todas as rotas legítimas estejam prontas para políticas mais fortes. Mantenha a proteção aprovada existente enquanto diagnostica a lacuna real; qualquer mudança política necessita da sua própria decisão.