Você publicou um registro DMARC com um endereço em rua=, esperou alguns dias e a sua caixa de entrada continua vazia. Nenhum relatório, nenhum erro, nada que diga se o registro está quebrado ou se você só chegou cedo. As causas são poucas e fáceis de verificar quando se conhece a ordem certa. Este guia percorre o checklist, do teste mais barato (paciência) aos mais técnicos, como a autorização de destino externo, e explica como cada falha se apresenta.
A resposta curta#
Relatórios DMARC ausentes quase sempre se devem a uma de sete coisas: você ainda não esperou 24 a 48 horas, o registro está no nome de DNS errado, há mais de um registro DMARC, o valor de rua= está malformado (precisa começar com mailto:), o endereço de relatórios está em outro domínio sem autorização, o seu domínio envia pouco e-mail para os receptores terem o que reportar, ou a caixa postal filtra os anexos compactados. Verifique nessa ordem. Uma consulta ao vivo de _dmarc.seudominio.com resolve as quatro primeiras em menos de um minuto. dig TXT _dmarc.seudominio.com +short é o que revela um segundo registro, porque o verificador de SPF, DKIM e DMARC gratuito mostra só o primeiro e não confere a sintaxe de rua=. Se o registro está limpo e já passaram alguns dias, olhe a caixa postal de destino.
Passo 1: dê tempo e saiba quem envia relatórios#
Os provedores agrupam o que viram ao longo de um dia e enviam um relatório por domínio, então os primeiros relatórios chegam de 24 a 48 horas depois de o registro entrar no ar, e às vezes mais tarde. Nada chegará no primeiro dia.
Mais dois pontos ajustam as expectativas:
- Nem todo receptor envia relatórios. Os grandes provedores de caixa postal enviam. Muitos menores nunca vão enviar. Você está coletando uma amostra de provedores, não um registro completo.
- Um receptor só reporta se viu e-mail seu. Se o seu domínio não enviou nada para um determinado provedor ontem, esse provedor não tem nada a reportar.
Se você esperou três dias inteiros, passe para o registro.
Passo 2: confirme que o registro está onde deveria#
Os registros DMARC ficam em um nome específico: _dmarc. na frente do seu domínio. Um registro publicado no domínio puro, ou em dmarc.example.com, é ignorado. Consulte o que está realmente publicado:
dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"
O que conferir na resposta:
- O registro existe. Alguns provedores de DNS querem só
_dmarcno campo de host, não o nome completo. Digitar o nome completo faz com que eles acrescentem o seu domínio duas vezes. Os passos específicos por provedor estão em guias como Cloudflare e GoDaddy. - Ele começa com
v=DMARC1, exatamente assim, sem nada antes. - Inclui uma tag
p=. Pela RFC 9989, um registro semp=válido mas comrua=válido é tratado comop=nonee ainda recebe relatórios, então isso normalmente não é a causa de relatórios ausentes, mas publique a tag de forma explícita mesmo assim. - As tags são separadas por ponto e vírgula.
Lembre-se do cache de DNS. Se você acabou de editar o registro, os receptores podem usar a cópia antiga até o TTL expirar.
Passo 3: garanta que há um único registro DMARC#
Um domínio deve publicar um único registro DMARC. Se dois registros TXT em _dmarc começam com v=DMARC1, os receptores tipicamente ignoram os dois e os relatórios param. Isso acontece quando alguém adiciona um registro novo sem apagar o antigo, ou quando uma migração de DNS copia o registro duas vezes.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:new@example.com"
Apague um, mantenha o outro e junte os endereços em uma única lista rua=. Vários destinos de relatórios são separados por vírgulas dentro de um só registro, não publicando mais registros.
Passo 4: confira a sintaxe do rua#
O valor de rua= é uma lista de URIs, e cada uma deve começar com mailto:. Erros típicos:
| O que está publicado | Problema |
|---|---|
rua=reports@example.com | Falta o mailto: |
rua=mailto:reports@example.com mailto:other@example.com | Dois endereços sem vírgula entre eles |
rua=mailto:reports@exmaple.com | Erro de digitação no domínio, então os relatórios não vão a lugar nenhum |
v=DMARC1; rua=mailto:reports@example.com | Sem a tag p=. A RFC 9989 a trata como p=none quando o rua é válido, mas um receptor que siga as regras antigas pode ignorar o registro, então publique o p= de forma explícita |
apenas ruf=mailto:reports@example.com | O ruf pede relatórios de falha, que muitos provedores não enviam. Relatórios agregados exigem rua |
A última linha pega muita gente. Os relatórios agregados vêm do rua. Definir só o ruf renderá quase nada. A lista completa de tags está em como configurar o DMARC.
Passo 5: autorize relatórios para outro domínio#
Esta é a causa que mais passa despercebida. Se o seu endereço rua= está em um domínio diferente daquele que o registro protege, os receptores verificam se o outro domínio concordou em receber os relatórios. Caso contrário, qualquer pessoa poderia apontar enxurradas de relatórios para a caixa postal de uma vítima.
Veja este registro para example.com:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"
Como o endereço está fora de example.com, o domínio receptor precisa publicar um registro de autorização com um nome construído a partir do seu domínio:
example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1;"
Se esse registro TXT não existe, os receptores que seguem o padrão descartam o relatório. Você pode verificar com:
dig TXT example.com._report._dmarc.thirdparty.example.net +short
Duas observações práticas:
- Se você controla os dois domínios, basta adicionar o registro de autorização no destino. Se um fornecedor recebe os relatórios por você, ele normalmente publica isso para você ou pede que você o faça.
- Enviar relatórios para uma caixa postal no seu próprio domínio evita a verificação por completo, e é por isso que um simples encaminhamento
dmarc@seudominio.comé a configuração menos frágil.
Passo 6: verifique a caixa postal de destino#
Se o registro é válido e a autorização está em vigor, os relatórios podem estar chegando e se perdendo:
- Filtragem de anexos. Os relatórios chegam como anexos
.gzou.zip, às vezes XML puro. Filtros de e-mail que removem anexos compactados os descartam em silêncio. Verifique spam, quarentena e qualquer regra que apague arquivos compactados. - Caixa postal cheia. Um domínio movimentado pode gerar dezenas de relatórios por dia. Uma caixa compartilhada pequena enche rápido e começa a rejeitá-los.
- Alias ou encaminhamento que reescreve. Um alias de grupo que bloqueia remetentes externos vai recusar relatórios dos provedores.
Procure assuntos que incluam "Report Domain" e o nome do seu domínio. Se você não encontrar nenhum depois de verificar a filtragem, o problema está a montante.
Uma caixa postal dedicada, ou um serviço que receba os relatórios por você, evita a maior parte disso. O XML bruto em uma caixa pessoal também enterra o sinal, como explicado em como ler relatórios DMARC.
Se você usa um endereço de relatórios da Qualisend#
Se o seu rua= aponta para um endereço <key>@dmarc.qualisend.com dos Relatórios DMARC, as verificações de destino são tratadas para você. A Qualisend publica um registro de autorização curinga, então os provedores enviam para esse endereço para qualquer domínio, e você não precisa adicionar o registro de autorização do passo 5. Estas são as coisas extras que ainda podem bloquear os dados:
- O domínio não está coberto. Os relatórios só são armazenados para domínios com a cobertura ativada no seu workspace, ou um subdomínio de um deles. Um relatório de um domínio não coberto é aceito mas não é salvo, então o painel continua vazio.
- A assinatura não está ativa. Relatórios enviados a um endereço cujo workspace não tem assinatura ativa de DMARC são recusados.
- O endereço foi rotacionado. Depois de uma rotação, o endereço antigo deixa de aceitar e-mail na hora, então todo
rua=que ainda o liste perderá relatórios até você atualizar o DNS. - O registro não lista o endereço. Se já existe um registro DMARC, adicione
,mailto:<address>à listarua=dele e mantenha a política e os outros endereços.
A Qualisend nunca edita o seu DNS. A alteração do registro é sua, no seu provedor de DNS. A página informa que os primeiros relatórios costumam chegar em 24 a 48 horas, o que corresponde ao que os provedores fazem.
Subdomínios e o registro que vale#
Se os relatórios ausentes são de um subdomínio, olhe o que está de fato publicado ali. Um subdomínio com o seu próprio registro DMARC usa esse registro, e se ele não tem rua=, nada é enviado ao endereço do domínio pai. Um subdomínio sem registro recorre ao registro do domínio pai e à política sp= dele. Os relatórios nomearão o domínio da política, então procure por eles sob esse nome, e não sob o seu domínio principal.
Vale passar o domínio inteiro por uma verificação de saúde do domínio depois de qualquer alteração de DNS. Ela sinaliza um registro DMARC ausente, um registro sem tag de política e uma política p=none, e mostra o registro publicado para você ler o valor de rua= por conta própria. O monitoramento de saúde do domínio pago também avisa quando uma política válida não tem nenhum rua=. Se isso continua acontecendo depois de edições de DNS, o guia de monitoramento de saúde do domínio explica como detectar antes que os relatórios parem.
Um checklist final#
- Espere 48 horas depois de o registro entrar no ar.
- Execute
dig TXT _dmarc.seudominio.come leia o resultado. - Confirme que há um registro, começando com
v=DMARC1, com ump=explícito. - Confirme
rua=mailto:com vírgulas entre os endereços. - Se o endereço está em outro domínio, verifique o registro de autorização
_report._dmarc. - Verifique spam, quarentena, limites de tamanho e filtros na caixa postal de destino.
- Certifique-se de que o domínio realmente enviou e-mail a provedores que reportam.
Quando os relatórios finalmente chegarem, o trabalho seguinte é entendê-los, o que é tratado em monitoramento de DMARC e quem está enviando em nome do seu domínio.
Perguntas frequentes
01Quanto tempo leva para receber relatórios DMARC?
Os provedores agrupam o que viram ao longo de um dia e enviam um relatório por domínio, então os primeiros relatórios normalmente chegam de 24 a 48 horas depois de o registro entrar no ar, e às vezes mais tarde. Se você já esperou três dias inteiros, verifique o registro, a sintaxe e a caixa postal de destino em vez de esperar mais.
02Por que preciso de um registro TXT em _report._dmarc para endereços externos?
Se o seu endereço rua está em um domínio diferente daquele que o registro protege, os receptores verificam se o outro domínio concordou em aceitar os relatórios. O destino publica um registro TXT com o nome do seu domínio, seguido de _report._dmarc e do domínio dele, com o valor v=DMARC1;. Sem ele, os receptores que seguem o padrão descartam os relatórios.
03Por que recebo relatórios DMARC de alguns provedores e de outros não?
Nem todo receptor envia relatórios agregados, e um receptor só reporta quando viu e-mail do seu domínio no período. Os grandes provedores de caixa postal enviam de forma confiável, muitos menores nunca enviam. Seus relatórios descrevem os provedores que reportam, não todo o seu e-mail.
04Dois registros DMARC no mesmo domínio podem interromper os relatórios?
Sim. Um domínio deve publicar um único registro DMARC. Se dois registros TXT em _dmarc começam com v=DMARC1, os receptores tipicamente ignoram os dois e os relatórios param. Apague um e junte os endereços em uma única lista rua, separados por vírgulas, dentro do registro que restar.
Fazer os relatórios DMARC fluírem mostra quem envia em nome do seu domínio, mas não se a sua lista está limpa. Se você quer conferir a lista em seguida, o plano gratuito na página de preços dá 100 créditos para a verificação completa, e o verificador de e-mail gratuito cuida de endereços avulsos. Uma autenticação funcionando ainda precisa de uma lista saudável para chegar à caixa de entrada.
