O meu estado DNS nunca fica verde
O DNS continua âmbar ou pendente? Diagnostique a propagação, o proxy da Cloudflare, SPF duplicado, divisão de DKIM e aprenda a ler Ver conflitos.
Detalhes do artigo
Tipo, dificuldade, planos e data da última atualização.
▼
Detalhes do artigo
Tipo, dificuldade, planos e data da última atualização.
- Tipo
- Perguntas frequentes
- Dificuldade
- Iniciante
- Planos
- Nano · Starter · Pro · Agency
- Última atualização
- 9 de set de 2026
A validação DNS verifica os registos necessários para a configuração escolhida. Um domínio que recebe correio pelo TrekMail normalmente precisa de MX, SPF, DKIM e DMARC. Registos recomendados como MTA-STS e TLS-RPT podem aparecer separadamente. Este guia ajuda a comparar o Painel com o fornecedor DNS sem adivinhar.
Comece pela tabela de registos do Painel
Abra Domínios, escolha o domínio afetado e abra o estado DNS. Copie da tabela o tipo, anfitrião, valor e, para MX, a prioridade. A tabela é a fonte correta porque os valores DKIM e alguns registos de política são exclusivos do domínio.
Antes de alterar um registo, confirme se outro serviço ainda precisa do valor atual. Em especial, mantenha apenas um registo SPF e qualquer include válido usado por outro serviço de envio.
Quanto tempo deve demorar a propagação?
As atualizações DNS podem demorar tempos diferentes conforme o fornecedor, o TTL anterior e as caches dos resolvedores. Um resultado pendente não prova que o valor está errado, e o tempo decorrido não prova que está certo.
Siga esta ordem:
- Guarde o registo no fornecedor que aloja a zona DNS autoritativa.
- Compare-o com a tabela do Painel, incluindo a prioridade MX e o valor DKIM completo.
- Use Validar DNS uma vez para pedir nova verificação ao TrekMail.
- Se continuar pendente, veja os conflitos e uma consulta independente para saber o valor público atual.
Registos obrigatórios
Para alojamento de correio normal, estes são os registos principais. Copie os valores do seu Painel em vez de usar os de outro domínio:
| Registo | Anfitrião | Valor |
|---|---|---|
| MX | @ (raiz) |
mail.trekmail.net. (prioridade 10) |
| SPF | @ (raiz) |
v=spf1 include:spf.trekmail.net -all (~all também é aceite; veja abaixo) |
| DKIM | dkim._domainkey |
O valor TXT mostrado na página do domínio (começa por v=DKIM1; k=rsa; p=...) |
| DMARC | _dmarc |
Um valor válido que comece por v=DMARC1; use a política e o endereço de relatórios escolhidos |
Os registos recomendados podem melhorar a segurança da entrega, mas não substituem os principais:
| Registo | Anfitrião | Valor |
|---|---|---|
| TLS-RPT | _smtp._tls |
O valor exato de relatórios mostrado no Painel |
| Política MTA-STS | _mta-sts |
O valor atual v=STSv1; id=... mostrado no Painel |
| CNAME MTA-STS | mta-sts |
O destino mostrado no Painel |
Os CNAME opcionais de autoconfiguração (autoconfig, autodiscover) aceleram a configuração das aplicações, mas não afetam a entrega.
Verificação 1: combine registos SPF duplicados
Apenas um TXT na raiz deve começar por v=spf1. Se existirem dois, os servidores recetores não sabem de forma fiável qual política usar e o TrekMail não consegue validar corretamente.
Sintoma: ambos aparecem no DNS, mas o TrekMail continua a indicar que o SPF não está configurado.
Solução: junte as regras num só registo. Se tiver:
v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all
Substitua por:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all
Que terminação usar: -all ou ~all
Use apenas uma. Tanto -all como ~all passam na verificação se include:spf.trekmail.net vier antes. A escolha afeta correio enviado por outros serviços.
| Terminação | Quando é normalmente adequada |
|---|---|
-all |
O TrekMail é o único serviço que envia pelo domínio. |
~all |
Mais de um serviço envia ou existe reencaminhamento. |
Uma nota informativa sobre a terminação não é uma falha de validação. O domínio pode ser validado com qualquer uma.
Não use estas terminações:
?allnão oferece uma política de autorização útil.+allautoriza todos os remetentes da Internet.
Um registo SPF pode usar no máximo dez consultas DNS. Se tiver muitos remetentes externos, reduza os include ou peça ao fornecedor relevante uma opção de consolidação suportada.
Verificação 2: um CNAME de correio da Cloudflare está sob proxy
A Cloudflare pode representar tráfego web, mas um CNAME de correio precisa de estar em Apenas DNS. Pode ser mta-sts, autoconfig, autodiscover ou outro anfitrião solicitado pelo Painel.
Sintoma: o registo aparece bloqueado ou não pode ser validado, embora conste na lista DNS da Cloudflare.
Solução: na Cloudflare, abra DNS, encontre o anfitrião e mude a nuvem laranja para o estado cinzento Apenas DNS. Depois use Validar DNS no TrekMail.
O registo A ou CNAME web principal pode continuar sob proxy. Altere apenas o anfitrião de correio identificado pelo Painel.
Verificação 3: DMARC está no anfitrião errado
O DMARC pertence a _dmarc.yourdomain.com, não à raiz. Alguns formulários preenchem @, facilitando guardar no local errado.
Sintoma: o registo DMARC existe no DNS, mas o TrekMail não o encontra.
Solução: adicione-o em _dmarc. Algumas interfaces pedem _dmarc; outras, _dmarc.yourdomain.com. Consulte a indicação do formulário. Remova um registo incorreto em @ apenas depois de confirmar que não tem outra função.
Verificação 4: DKIM foi colado ou dividido incorretamente
Os valores DKIM são longos. Os fornecedores podem guardar um TXT longo em vários segmentos ligados, mas o resultado público tem de corresponder ao valor completo do Painel.
"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"
A maioria trata disso automaticamente. Uma colagem errada pode acrescentar ou remover carateres, espaços ou aspas.
Sintoma: o DKIM é visível no DNS, mas o TrekMail mostra "DKIM key invalid" ou "p= does not match".
Solução:
- Cole o valor exatamente como aparece no Painel.
- Se o fornecedor divide automaticamente TXT longos, cole tudo e deixe-o dividir.
- Se pedir segmentos separados, siga as instruções e conserve todos os carateres.
- Use uma consulta DNS independente para confirmar que o TXT público contém a chave completa.
Verificação 5: MTA-STS precisa de atenção
MTA-STS é uma função de segurança recomendada para domínios que recebem correio pelo TrekMail. Se o Painel a mostrar, são necessários o TXT e o CNAME mta-sts indicados. Não os adicione a um domínio só de envio, salvo pedido explícito do Painel.
Bloqueado pelo DNS. O CNAME mta-sts está em falta ou aponta para outro local. Adicione-o ou corrija-o com o destino atual do Painel.
Bloqueado pela Cloudflare. O CNAME existe, mas está sob proxy. Defina o anfitrião como Apenas DNS, conforme a Verificação 2.
Degradado depois de ter funcionado. Compare o TXT e o CNAME com o Painel. Um registo alterado ou removido é a causa habitual. Restaure-o, execute Validar DNS e veja o estado atualizado.
Verificação 6: compare uma consulta pública com o Painel
A sua rede local e o TrekMail podem ver resultados diferentes durante a propagação. Uma consulta pública mostra o que outras redes veem.
Para comparar:
- Abra dnschecker.org ou whatsmydns.net.
- Introduza o anfitrião completo e o tipo. Por exemplo,
_dmarc.yourdomain.comeTXTpara DMARC. - Compare o anfitrião, valor e prioridade MX devolvidos com a tabela do Painel.
- Se a consulta mostrar o valor certo mas o TrekMail ainda indicar diferença, inclua o resultado num pedido de suporte.
Verificação 7: um valor DNS antigo continua em cache
Ao alterar um registo, o valor antigo pode permanecer em resolvedores intermédios até ao seu TTL (Time To Live, em segundos). Um TTL de 24 horas (86400 segundos) é comum em registos antigos.
Sintoma: alterou um registo há uma hora, mas as ferramentas ainda mostram o valor antigo em todo o mundo.
Solução: evite edições repetidas enquanto a mesma alteração se propaga. Para uma migração planeada, reduza o TTL antecipadamente se o fornecedor permitir. Depois de estabilizar, escolha um TTL adequado à sua gestão habitual.
Depuração passo a passo
- Abra a página Domínios e clique no domínio.
- Se Ver conflitos estiver disponível, abra-o. Separa os registos a corrigir dos itens recomendados e informativos.
- Compare cada anfitrião, valor e prioridade MX esperados com o registo guardado no fornecedor.
- Faça a menor alteração necessária e conserve os registos usados por outros serviços.
- Clique em Validar DNS no TrekMail.
- Leia o estado atualizado. O domínio fica ativo quando os registos necessários para a configuração escolhida são válidos; os recomendados podem aparecer separadamente.
Para verificar a partir de um terminal (Mac/Linux/WSL), use:
dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com
Compare a saída com os valores do seu domínio no Painel. Não copie de um exemplo uma chave DKIM, um ID de política MTA-STS ou outro valor específico do domínio.
Armadilhas comuns dos fornecedores DNS
- Cloudflare: os CNAME de correio devem estar em Apenas DNS. O fornecedor pode ocultar o ponto final do destino; compare o destino resolvido em vez de adicionar pontos duplicados.
- GoDaddy: use
@para a raiz e_dmarcpara DMARC. A GoDaddy acrescenta o nome do domínio. - Namecheap: adicione registos em Advanced DNS apenas se a Namecheap for o DNS autoritativo. Use
@para a raiz. - Route 53: selecione a zona alojada realmente ligada ao domínio e cole todo o valor do Painel.
- Criadores de sites e agentes de registo: o local onde comprou o domínio pode não controlar o DNS. Verifique os servidores de nomes e edite no fornecedor que os controla.
Quando tudo coincide mas continua vermelho
Se o Painel e uma consulta pública independente mostrarem os mesmos registos obrigatórios, mas o TrekMail ainda indicar diferença, abra um pedido com:
- O nome do domínio.
- O resultado público do registo afetado.
- Uma captura do painel Ver conflitos, se disponível.
Não inclua palavras-passe da conta ou caixa, códigos de recuperação nem tokens de acesso.
Artigos relacionados
Vá para guias próximos que dão continuidade ao fluxo de trabalho.