A configuração de DNS para e-mail envolve seis ou sete registros. Vários contêm sequências longas em que um único caractere errado provoca uma falha difícil de relacionar a um erro de digitação. Uma chave DKIM ocupa algumas centenas de caracteres em base64. Um registro SPF reúne mecanismos cuja ordem importa e um fechamento que muda o sentido da política. O DMARC usa um nome de subdomínio que também é fácil digitar errado.
Ao configurar um domínio, você provavelmente acerta. Com quarenta domínios de clientes, a chance de deixar passar um erro aumenta. Talvez ele só apareça um mês depois, quando uma nota fiscal cair no spam.
A configuração automática evita copiar os valores manualmente. Há dois caminhos: autorizar a alteração de um domínio no provedor e voltar ao TrekMail sem fornecer um token, ou usar um token de API com permissões restritas para administrar até uma centena de domínios, divididos em lotes. Nos dois casos, você pode revisar as alterações antes de aplicá-las.
Quais registros DNS o e-mail precisa
| Registro | Tipo | Função | É necessário? |
|---|---|---|---|
| MX | MX | Indica onde entregar o e-mail recebido | Sim, para direcionar o recebimento ao serviço de e-mail configurado |
| SPF | TXT na raiz | Autoriza servidores para o domínio do remetente do envelope, conforme o RFC 7208 | Sim, para autenticação por SPF |
| DKIM | TXT em um seletor | Publica a chave usada para verificar a assinatura das mensagens enviadas | Necessário em muitos cenários de envio |
| DMARC | TXT em _dmarc | Define a política quando nem SPF nem DKIM passa com alinhamento e informa os destinos dos relatórios | Necessário em muitos cenários de envio |
| MTA-STS | TXT + uma política hospedada | Exige TLS de servidores compatíveis na entrega de e-mails recebidos, conforme a política | Recomendado |
| TLS-RPT | TXT em _smtp._tls | Solicita relatórios sobre problemas de entrega relacionados a TLS | Recomendado |
| autoconfig / autodiscover | CNAME | Ajuda aplicativos compatíveis a obter as configurações a partir do endereço | Opcional; pode reduzir chamados de suporte |
“Necessário em muitos cenários” não significa que os RFCs obriguem todo domínio a publicar DKIM e DMARC. Google e Yahoo introduziram requisitos para remetentes de grande volume em 2024; a aplicação depende da categoria do remetente e das regras vigentes. Destinatários corporativos também podem ter exigências próprias. A ausência desses registros não impede automaticamente todo envio, mas pode dificultar a autenticação e a aceitação das mensagens.
Quatro erros na configuração manual do DNS
Publicar dois registros SPF. É um erro comum, com consequências importantes. O nome consultado deve ter apenas um registro SPF. Adicionar outro para um novo serviço de envio não amplia a política: uma avaliação conforme o protocolo retorna permerror. É preciso reunir os mecanismos em um único registro. Veja os exemplos de registros SPF.
Danificar a chave DKIM ao colar. A representação de uma chave de 2048 bits ultrapassa o limite de 255 caracteres por sequência TXT. Por isso, o registro precisa conter várias sequências, concatenadas na leitura. Alguns painéis DNS fazem isso automaticamente; outros exigem que você prepare a divisão, e alguns podem cortar o valor. Uma chave incompleta impede a verificação da assinatura sem deixar a causa evidente.
Publicar DMARC no nome errado. O registro pertence a _dmarc.example.com. Se estiver na raiz, não será encontrado na consulta da política DMARC desse domínio.
Ultrapassar o limite de consultas do SPF. O SPF limita a dez os termos que exigem consultas DNS durante a avaliação. Cada include: avaliado conta, inclusive nas inclusões aninhadas. O provedor de e-mail, um CRM, uma ferramenta de marketing e um sistema de atendimento podem ultrapassar o limite, dependendo das políticas usadas. Nesse caso, o resultado é permerror. O problema pode surgir meses depois da configuração inicial, quando alguém adiciona outra ferramenta. Veja o limite de consultas DNS do SPF.
A automação reduz erros de cópia e identifica conflitos, mas não dispensa a revisão. Combinar o SPF evita criar um segundo registro; não comprova que a política resultante respeita o limite de avaliação.
Caminho 1: configurar o DNS com um clique, sem token
Para um domínio cujo DNS está na Cloudflare, esse é o caminho mais direto. Você não precisa fornecer ao TrekMail um token nem as credenciais da conta.
- Abra a aba DNS e status do domínio.
- Clique em Configurar DNS automaticamente.
- A Cloudflare mostra os registros propostos antes de você autorizar a operação.
- Clique em Autorizar.
- Você volta ao TrekMail e uma verificação é solicitada. Esse retorno, sozinho, não comprova que os registros foram publicados corretamente.
O processo usa Domain Connect, um protocolo aberto para essa troca: o serviço descreve os registros necessários, o provedor DNS apresenta as alterações ao responsável pelo domínio e ele aprova. Nenhum token de API reutilizável é criado ou armazenado. A autorização se refere à operação proposta naquele domínio.
Os servidores de nomes do domínio precisam apontar para a Cloudflare. Se o domínio foi registrado nela, mas o DNS está hospedado em outro lugar, esse caminho não está disponível. Os registros devem ser alterados onde a zona DNS realmente é mantida.
Caminho 2: configurar o DNS com um token de API restrito
Para vários domínios, ou quando o Domain Connect não está disponível, um token permite configurar as zonas autorizadas da conta.
Na Cloudflare, crie o token com o modelo Edit zone DNS e a permissão Zone → DNS → Edit. Nos recursos de zona, escolha All zones para todas ou Specific zone para limitar o acesso. Verifique se as restrições de IP e a validade permitem o uso previsto; não é necessário alterá-las sem motivo. Copie o token quando ele for exibido e cole no TrekMail.
O importante é entender o que essas permissões permitem e o que fica fora delas:
| O token permite | O token não permite |
|---|---|
| Ler e alterar registros DNS nas zonas selecionadas | Alterar servidores de nomes |
| Gerenciar cobrança, WAF, regras de página, Workers ou configurações de SSL | |
| Transferir ou excluir um domínio | |
| Acessar zonas que você não incluiu |
O TrekMail armazena o token criptografado e evita registrar seu valor nos logs. Você pode desconectá-lo de um domínio no TrekMail ou revogá-lo na Cloudflare para impedir novas solicitações com ele. Desconectar um domínio não revoga necessariamente um token compartilhado com outros. A revogação também não desfaz alterações já aplicadas.
Após a conexão, as zonas disponíveis da Cloudflare aparecem com a ação prevista: Configurar DNS para um domínio que já está na sua conta TrekMail, ou Adicionar + DNS para incluir e configurar no mesmo processo. Domínios com DNS fora da Cloudflare não aparecem como zonas configuráveis por essa integração.
A prévia e seus cinco status
Antes de aplicar a configuração, você pode revisar cada registro. A prévia usa cinco status:
| Status | Significado | Precisa de uma decisão? |
|---|---|---|
| Será adicionado | O registro não existe e sua criação é proposta | Não há conflito a resolver |
| Será combinado | O SPF existente será ampliado para incluir o TrekMail, preservando seus mecanismos | Não há conflito a resolver |
| Já configurado | O valor esperado já está presente | Não há conflito a resolver |
| Será substituído | Há um conflito, como outra política DMARC ou um CNAME autodiscover do provedor anterior | Sim: escolha substituir ou manter |
| Ignorado | Você desmarcou o registro | A decisão já foi tomada |
Cada registro tem uma caixa de seleção. Você pode aplicar MX e SPF agora e deixar DKIM para depois, ou excluir da operação um registro administrado por outro meio. Os registros desmarcados não são aplicados nessa operação.
Leia os conflitos em vez de confirmar sem conferir. Uma política DMARC p=none não está errada: pode fazer parte de uma fase deliberada de monitoramento. Substituí-la por p=quarantine antes de revisar os relatórios pode prejudicar mensagens legítimas que ainda não se autenticam corretamente. Mantenha a política quando necessário, conclua a implantação e só depois aumente o rigor. Veja como escolher uma política DMARC.
Por que combinar o SPF existente
O SPF merece cuidado especial porque uma única política pode autorizar vários serviços de envio. Substituir o registro sem revisar esses serviços pode remover autorizações ainda necessárias.
Se o seu domínio já publica:
v=spf1 include:_spf.google.com ~alla política autoriza a infraestrutura do Google, como o Workspace ou uma ferramenta que envia por ela. Trocar esse registro por outro que inclui apenas o TrekMail não se limita a adicionar um remetente: remove a autorização anterior. Os envios que dependiam dela podem começar a falhar no SPF.
Por isso, um registro SPF existente e válido normalmente é combinado:
v=spf1 include:_spf.trekmail.net include:_spf.google.com ~allOs dois serviços continuam autorizados em um único registro, com o qualificador final preservado. Assim, você adiciona o TrekMail sem remover a autorização anterior. Isso não significa “nunca substituir”: registros SPF duplicados ou malformados podem exigir a resolução de um conflito. A política final precisa ser revisada.
Depois, confira dois pontos. O novo include: conta para o limite de dez termos com consultas DNS e pode levar a inclusões aninhadas; avalie a política completa. Se o provedor antigo realmente não envia mais pelo seu domínio, remova sua autorização manualmente depois de confirmar isso. Um período sem atividade não prova que o serviço deixou de ser usado.
Configuração de DNS em lote
Com um token autorizado para todas as zonas, o assistente pode percorrer os domínios compatíveis, adicionar os novos, configurar seus registros e apresentar os resultados por domínio. São até 50 domínios por lote. Os novos contam para o limite do plano: 10 no Nano, 50 no Starter, 100 no Pro e 1,000 no Agency, conforme a configuração descrita no artigo original. Confira os limites atuais da conta antes de começar.
Para uma agência que recebe um cliente com uma dúzia de domínios, o processamento em lote pode economizar bastante trabalho manual. Isso também torna a prévia mais importante. Imagine doze domínios, dois com uma política DMARC conflitante e um com um CNAME autodiscover ainda apontando para o provedor que foi deixado em 2023. É um exemplo do que procurar, não uma frequência garantida.
O alcance das alterações
É uma pergunta justa antes de conceder a um aplicativo permissão para alterar seu DNS.
A integração foi projetada para gerenciar registros de e-mail: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT e os CNAME de configuração automática. Ela não deve alterar registros A, CNAME do site ou TXT de outros serviços. Porém, a permissão DNS do token permite editar os registros das zonas autorizadas, não apenas os de e-mail. A preservação dos demais também depende do comportamento do aplicativo. Essa permissão não permite alterar servidores de nomes.
Substituir um registro em conflito pode remover uma configuração anterior, por isso exige confirmação. Revise também as demais alterações e a possível limpeza de duplicados associada a uma ação: não é seguro assumir que tudo o mais não tem consequências. Guarde os valores anteriores se precisar restaurá-los.
Um status pendente pode resultar dos caches DNS, mas também de um registro incorreto ou de uma operação incompleta. O original menciona até 48 horas; não é um prazo universal, pois o TTL e as condições do provedor influenciam. A verificação é repetida automaticamente e Verificar DNS solicita uma nova consulta. Se a falha continuar no dia seguinte, confira os valores publicados e consulte a solução de problemas de DKIM quando o problema envolver essa assinatura.
Perguntas frequentes
Preciso de uma conta Cloudflare para configurar o DNS com um clique?
A Cloudflare precisa hospedar o DNS do domínio, e você precisa ter acesso à conta correspondente para autorizar a alteração. Não é necessário fornecer um token de API ao TrekMail: você aprova a operação na interface da Cloudflare e nenhum token reutilizável é armazenado.
E se meu DNS não estiver na Cloudflare?
Essa integração automática não configura o outro provedor. Os registros precisam ser criados manualmente. A página DNS do domínio mostra os valores com botões para copiar; há instruções por provedor em configuração de DNS em provedores populares.
A configuração automática pode afetar meu site?
A integração foi projetada para alterar registros de e-mail e preservar registros A, CNAME do site e TXT sem relação com o correio. Isso não significa que o token seja incapaz de editá-los: suas permissões abrangem os registros DNS das zonas autorizadas. Revise as alterações propostas. A permissão descrita não permite mudar servidores de nomes.
O que acontece com meu registro SPF existente?
Normalmente ele é combinado: o include do TrekMail é adicionado e o qualificador é mantido. Assim, outros serviços autorizados não são removidos por engano. SPF duplicados ou malformados podem exigir uma substituição confirmada. Confira também o limite de consultas da política final.
Posso aplicar apenas alguns registros?
Sim. Cada registro tem uma caixa de seleção na prévia. Desmarque os que você administra por outro meio para excluí-los dessa operação.
Quantos domínios uma execução pode configurar?
Até 50 por lote, respeitando o limite total de domínios do plano. Os novos domínios adicionados pelo assistente contam para esse limite.
Meu token de API está protegido?
O TrekMail o armazena criptografado e evita registrar seu valor nos logs. Com as permissões descritas, ele pode editar DNS nas zonas selecionadas, mas não gerenciar cobrança, WAF, servidores de nomes ou transferências de domínios. Revogue-o na Cloudflare para impedir novas solicitações; isso não desfaz alterações anteriores. Autorize apenas as zonas necessárias.
Por que um registro que nunca criei aparece como “já configurado”?
Um provedor anterior pode tê-lo criado, ou uma configuração autorizada já foi executada. Compare o valor publicado com o proposto. Se forem iguais, não é necessário substituir o registro, mas confira se ele continua adequado à sua configuração.
