Monitoramento da saúde do domínio de e-mail: o que verificar e quando

O seu domínio de e-mail é, no fundo, um punhado de registros DNS. Eles estavam corretos no dia em que você os publicou, e depois alguém trocou de hospedagem, adicionou uma ferramenta de envio, rotacionou uma chave ou limpou entradas TXT "sem uso". Nada avisa do estrago. Os e-mails continuam saindo por um tempo, até que as devoluções e a entrada no spam vão crescendo e ninguém sabe dizer quando começou. Este guia explica o que significa saúde do domínio de e-mail, quais registros ela cobre, o que quebra sem fazer barulho e como uma verificação pontual se diferencia de um monitoramento que roda todo dia.

A resposta curta#

Saúde do domínio de e-mail é a pergunta "os registros DNS que permitem ao mundo entregar e confiar em e-mails deste domínio estão presentes, válidos e inalterados?". Na prática, são seis itens: MX (alguém consegue entregar para você), SPF (quais servidores podem enviar em seu nome), DKIM (sua chave de assinatura está publicada), DMARC (o que os receptores devem fazer quando as verificações falham), além de MTA-STS e BIMI, que são extras opcionais. Uma verificação pontual mostra o estado agora. O monitoramento repete a verificação em intervalos e avisa quando algo muda, o que importa porque a maioria das falhas são regressões, não erros de configuração inicial. Rode hoje o verificador gratuito de saúde do domínio para ter uma linha de base e depois decida se vale a pena uma vigilância diária nos domínios dos quais você depende.

O que uma verificação de saúde do domínio cobre#

Cada registro da tabela responde a uma pergunta diferente, e cada um pode falhar por conta própria.

Os quatro primeiros são os que decidem se o seu e-mail é entregue e recebe confiança. Configurar o DMARC e a visão geral de SPF, DKIM e DMARC em conjunto explicam como escrevê-los. MTA-STS e TLS-RPT e BIMI são reforços opcionais, então a falta de um deles é informação, não emergência.

Lembre-se de que os provedores de caixa postal já exigem isso. Os requisitos de remetente do Google e do Yahoo esperam SPF, DKIM e um registro DMARC de quem envia em massa, com o domínio do From alinhado ao SPF ou ao DKIM, e a Microsoft aplica regras parecidas a remetentes de alto volume para endereços do Outlook.com. Um registro que desaparece sem alarde pode levar você de em conformidade a fora de conformidade da noite para o dia.

O que quebra sem ninguém perceber#

As falhas de autenticação raramente parecem falhas. O e-mail ainda é aceito, parte dele cai no spam, e a causa é um registro que ninguém olha há meses. Estes são os casos que aparecem de novo e de novo.

• Uma migração de DNS perde registros TXT. Você troca de host de DNS, a ferramenta de importação copia os registros A e CNAME, e as entradas TXT de SPF, DKIM e DMARC somem ou saem alteradas. A história completa está em quando SPF, DKIM e DMARC param de funcionar.
• Aparece um segundo registro SPF. Uma ferramenta de marketing manda alguém "adicionar este registro TXT", e agora o domínio tem dois registros SPF. Os receptores tratam isso como erro permanente, então o SPF falha para tudo.
• O SPF passa de 10 consultas DNS. Cada nova ferramenta adiciona um include:, e um dia o registro cruza o limite. SPF com consultas DNS demais explica a contagem e a correção.
• Uma chave DKIM é rotacionada ou removida. O provedor passa para um novo seletor, ou alguém apaga a chave antiga enquanto os e-mails ainda são assinados com ela. Como encontrar o seu seletor DKIM mostra como saber qual chave um remetente realmente usa.
• O DMARC é apagado ou nunca recebe relatórios. Ou o registro sumiu, ou o rua= aponta para um lugar inútil, e você não consegue ver quem envia em seu nome.
• Uma chave DKIM curta fica esquecida. Uma chave de 1024 bits ainda funciona, e é justamente por isso que ela permanece por anos. O padrão diz que os assinantes devem usar pelo menos 2048.

Nenhum desses casos precisa de um atacante. São manutenção comum, e por isso uma revisão humana periódica não os pega: nada parece quebrado até os números se mexerem.

Verificação pontual ou monitoramento diário#

A verificação pontual é a ferramenta certa em três situações: depois de publicar ou alterar registros, ao diagnosticar uma reclamação específica e ao assumir um domínio que você não configurou. Ela é gratuita, leva segundos e entrega uma foto do momento. Rode o verificador de saúde do domínio para ver o quadro completo, ou o verificador de SPF, DKIM e DMARC quando você precisar apenas dos registros de autenticação.

O monitoramento responde a outra pergunta: o que mudou desde ontem, e quem precisa saber? As falhas acima acontecem todas entre uma verificação e outra. O intervalo que importa é o tempo entre "o registro quebrou" e "alguém percebeu", e em um processo manual esse intervalo dura o que levar para a taxa de devolução motivar uma investigação. A verificação diária o reduz a no máximo um dia.

Uma forma justa de decidir:

1. Um domínio, poucas mudanças, uma ferramenta de envio: uma verificação pontual após cada mudança provavelmente basta.
2. Vários domínios, vários remetentes, ou mais de uma pessoa com acesso ao DNS: uma vigilância diária se paga na primeira vez que alguém editar um registro sem avisar.
3. Domínios estacionados ou secundários dos quais você nunca envia: verifique de vez em quando, porque um registro DMARC ausente ou frouxo ali é um convite à falsificação.

O que merece um alerta#

Um alerta só é útil se for raro e específico. Os registros pelos quais vale acordar alguém são aqueles em que uma mudança significa que o e-mail está falhando agora. Como regra prática, nós os separaríamos assim.

Agir no mesmo dia:

• MX ausente ou um host MX que não resolve mais.
• SPF ausente, SPF publicado duas vezes, erro de sintaxe ou consultas acima de 10.
• DMARC ausente ou inválido, incluindo dois registros DMARC.
• Um seletor DKIM do qual você depende e que não devolve mais uma chave (o produto só consegue informar isso para os seletores que você cadastrou).

Revisar nesta semana:

• SPF com 9 ou 10 consultas, a uma adição de falhar.
• DMARC ainda em p=none, ou sem endereço rua= para receber relatórios.
• Uma chave DKIM de 1024 bits, ou uma chave ainda marcada como teste (t=y).
• Um qualificador ?all, ou o mecanismo ptr, desaconselhado, no SPF.

Apenas informativo:

• Registros MTA-STS e BIMI que aparecem ou desaparecem.

O monitoramento de saúde do domínio da Qualisend traduz isso em duas severidades: 20 códigos de problema em MX, SPF, DKIM e DMARC, cada um marcado como "grave" ou "aviso", e uma nota do domínio que é simplesmente a pior severidade presente. Tudo o que está na primeira lista é "grave" e tudo o que está na segunda é "aviso". Ele envia um e-mail quando um problema aparece e quando é resolvido. Erros de DNS, como timeouts, marcam a verificação como "não foi possível verificar" e nunca geram alerta, para que um problema no resolvedor não vire alarme falso. Um problema só é considerado resolvido após a segunda verificação sem falhas, então o aviso de normalização pode demorar até dois dias, a menos que você verifique de novo manualmente.

Uma linha de base e uma rotina#

Você não precisa de uma plataforma para obter a maior parte do valor. Faça isto uma vez por domínio.

1. Anote os seus remetentes. Liste todo sistema que envia em nome do domínio: provedor de caixa postal, plataforma de marketing, serviço transacional, CRM, helpdesk, faturamento. Cada um deve estar refletido no SPF e assinado com DKIM.
2. Faça uma verificação de linha de base e guarde o resultado. Anote a contagem de consultas do SPF, os seletores DKIM que existem e a sua política DMARC.
3. Registre os seletores DKIM que cada remetente usa. Os nomes de seletor são fáceis de esquecer e difíceis de adivinhar depois. Como encontrar um seletor DKIM mostra onde lê-los.
4. Publique um endereço de relatórios no DMARC para que as falhas deixem rastro. Como ler os relatórios e monitoramento de DMARC explicam o que fazer com eles.
5. Verifique de novo após cada mudança de DNS e após adicionar ou remover qualquer ferramenta de envio, e depois uma vez por mês de qualquer forma.

Se um domínio importa para a receita, esse último passo é o que as pessoas deixam de fazer, e é o que o monitoramento substitui.

O que o monitoramento não enxerga#

Seja claro sobre os limites para não confiar nele no que ele não faz.

• Ele lê o DNS público. Não envia e-mails de teste, não observa suas mensagens de saída reais e não mede a entrada na caixa de entrada. Um registro SPF pode ser perfeitamente válido e ainda assim deixar de fora um remetente que você esqueceu de adicionar. Para ver como uma mensagem real se autentica e o que um servidor receptor enxerga, use o teste de entregabilidade de e-mail. Ele também não mede a entrada na caixa de entrada.
• O DMARC é lido por completo; MTA-STS e BIMI são verificados apenas quanto à presença. Não busca o arquivo de política do MTA-STS nem valida o logotipo ou o certificado do BIMI.
• Ele observa domínios, não IPs de envio, e nunca altera o seu DNS. Você corrige os problemas no seu próprio host de DNS.
• Diário significa diário. Uma mudança é detectada em até 24 horas, não em tempo real.
• Ele não diz quem está enviando em nome do seu domínio. Para isso servem os relatórios agregados de DMARC, e os relatórios DMARC são o produto separado criado em torno deles.

O preço é fixo por plano, nas tarifas padrão: US$ 8,99 por mês para um domínio, US$ 89 para até 10 e US$ 499 para até 60, sem créditos envolvidos e sem obrigação de comprar mais nada.

Mais uma coisa a ter em mente: os padrões evoluem. O DMARC foi definido na RFC 7489, que a RFC 9989 tornou obsoleta em maio de 2026, então consulte o texto atual se você depende do comportamento em casos limite.

Um DNS saudável faz o seu e-mail ser confiável, mas não limpa a lista por trás dele. O plano gratuito na página de preços inclui 100 créditos que rodam a verificação completa em uma lista, porque um domínio bem monitorado ainda precisa de uma lista saudável para conquistar a caixa de entrada.