No DMARC record found: a linha que falta no seu domínio

Em resumo

• A mensagem significa que não existe um registro TXT em _dmarc.yourdomain.com. O seu servidor de email não está com defeito.
• Adicione um registro TXT com o host _dmarc e o valor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Com p=none, a entrega continua exatamente como era.
• O Gmail, o Yahoo e o Outlook.com só exigem o registro de remetentes em massa. Adicione mesmo assim: o Google conta o domínio inteiro e nunca retira o status de remetente em massa, e os relatórios só começam quando existe um registro.
• Se um verificador ainda não encontra nada, procure o provedor de DNS errado, um nome de host duplicado ou dois registros DMARC. Dois registros se anulam.
• A norma mudou em maio de 2026 com a RFC 9989: pct saiu, t e np são novos. A ajuda do Google ainda descreve pct em outubro de 2026.

“No DMARC record found” (nenhum registro DMARC encontrado) significa que um verificador pediu ao DNS um registro TXT em _dmarc.yourdomain.com e não recebeu nada de volta. Não há nada com defeito no seu servidor de email. A correção é um registro TXT com o host _dmarc e o valor v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Com p=none, os seus emails são entregues exatamente como antes. Você só informa aos servidores de recebimento que participa e começa a receber relatórios.

O DMARC é o terceiro dos três registros de email, ao lado do SPF e do DKIM. O SPF lista os servidores que podem enviar pelo seu domínio. O DKIM assina cada mensagem. O DMARC diz ao servidor de recebimento o que fazer quando nenhum dos dois responde pelo domínio do seu endereço From e para onde enviar um resumo diário. Desde maio de 2026, ele é definido na RFC 9989, que substituiu a antiga RFC 7489. Muitos guias ainda descrevem a versão antiga, e a página de ajuda do Google também, em outubro de 2026.

O registro a adicionar

Faça login onde o DNS do seu domínio é gerenciado. É a empresa para a qual os seus servidores de nomes (nameservers) apontam, que nem sempre é aquela em que você comprou o domínio. Adicione um novo registro com estes valores:

Escrito como uma linha em um arquivo de zona, o registro pronto fica assim:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Troque example.com pelo seu próprio domínio. As três partes fazem o seguinte:

• v=DMARC1 identifica a linha como um registro DMARC. Precisa vir primeiro, com DMARC1 em maiúsculas. Caso contrário, os servidores de recebimento ignoram o registro inteiro.
• p=none é a política: tratem os meus emails como tratariam de qualquer forma. Nada é bloqueado nem movido para o spam por causa deste registro.
• rua=mailto:… é o endereço para os relatórios diários. Crie esse endereço, ou um alias que encaminhe para você, antes de publicar o registro.

O Google lista os mesmos três campos em Configurar o DMARC. Ele também pede que o SPF e o DKIM estejam funcionando há 48 horas antes de você adicionar o DMARC. Se o seu verificador também aponta esses dois, corrija-os primeiro.

Como conferir se funcionou

Consulte o DNS você mesmo. No macOS ou no Linux, abra um terminal e use dig. No Windows, use nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Se o registro está no ar, a linha volta entre aspas. Foi isto que o próprio domínio do Google respondeu em 5 de outubro de 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Uma resposta vazia significa que o registro ainda não está lá, ou não está onde os servidores de recebimento procuram. Quando a sua própria consulta mostrar a linha, rode de novo o verificador que deu a mensagem. O MXToolbox, por exemplo, descreve o problema como “No DMARC Record found” e explica que “o seu domínio não tem um registro DMARC publicado”.

O que significa cada parte de um registro DMARC

Um registro é uma lista de pares tag=value separados por ponto e vírgula. Só v é obrigatório na norma, e precisa vir primeiro. Coloque p em segundo lugar: a ajuda do Google afirma que “as tags v e p devem ser listadas primeiro”, e a norma antiga esperava a mesma ordem. Estas são as tags da RFC 9989, seção 4.7:

Registros mais antigos costumam terminar em pct=100. A tag servia para aplicar uma política a uma parte dos emails que falham. A RFC 9989 a removeu, junto com rf e ri, e dá o motivo:

A experiência operacional mostrou que a tag “pct” normalmente não era aplicada com precisão, a não ser que o valor especificado fosse 0 ou 100 (o padrão), e as imprecisões com outros valores variavam muito de uma implementação para outra.

Os servidores de recebimento precisam ignorar as tags que não conhecem, então um pct=100 antigo não faz mal. Os registros de yahoo.com e microsoft.com ainda o traziam em 5 de outubro de 2026, e a página de ajuda do Google ainda recomenda pct para uma implantação gradual. Em um registro novo, deixe-o de fora.

Você precisa de DMARC se envia só alguns emails por dia?

Pelas regras publicadas dos grandes provedores de email, um registro DMARC é obrigatório quando você envia em massa. Abaixo disso, é uma recomendação.

As fontes são as diretrizes para remetentes de email do Google, as boas práticas para remetentes do Yahoo e o anúncio para remetentes de alto volume da Microsoft, todas em outubro de 2026. Se você envia trinta emails por dia de uma caixa de email, nenhuma delas exige o registro. Ainda assim, há três motivos para adicioná-lo agora.

• O limite é contado por domínio e não volta a zero. O Google soma todas as mensagens para contas pessoais do Gmail que vêm do mesmo domínio principal, incluindo subdomínios. As perguntas frequentes para remetentes do Google dizem: “Os remetentes que atendem aos critérios acima pelo menos uma vez são considerados remetentes em massa permanentemente.”
• O Google e o Yahoo recomendam o registro para todos. O Google escreve: “recomendamos que você sempre configure SPF, DKIM e DMARC para os seus domínios”. O Yahoo “pede enfaticamente que todos os remetentes publiquem uma política DMARC para cada domínio que envia emails”.
• Sem o registro, você não recebe relatórios. É por eles que você vê quais servidores enviam emails com o seu domínio na linha From, tanto as suas próprias ferramentas quanto desconhecidos.

Para remetentes em massa, a falta do registro tem consequências. As perguntas frequentes para remetentes do Google listam o erro temporário 4.7.31 para isso: “o domínio de envio não tem um registro DMARC, ou o registro DMARC não especifica uma política DMARC”. A mesma página diz que, desde novembro de 2025, os emails que não cumprem os requisitos enfrentam “rejeições temporárias e permanentes”.

Adicionou o registro e o verificador ainda não encontra nada?

Então a causa costuma ser uma destas. Percorra a lista com a consulta dig acima.

• Você editou o DNS no lugar errado. Se os seus servidores de nomes estão em uma empresa diferente do seu registrador de domínio, os registros inseridos no registrador nunca são consultados. dig +short NS example.com mostra quem responde pelo seu domínio.
• O host está errado. O registro está no próprio example.com ou em um nome duplicado, como descrito acima. Os servidores de recebimento só consultam _dmarc.example.com.
• Há dois registros DMARC. A norma é rígida aqui: “Se vários registros de política DMARC forem retornados para um único alvo, todos são descartados.” Junte-os em um só. Dois endereços de relatório vão em um único rua, separados por vírgula.
• A primeira tag não é exatamente v=DMARC1. Minúsculas, um erro de digitação como DMARC 1 ou p= na frente tornam o registro inválido.
• O tipo do registro não é TXT, ou o valor foi colado de um documento com aspas curvas. Digite o valor como texto simples, sem aspas, a menos que a ajuda do seu provedor de DNS peça.
• Uma resposta antiga ainda está em cache. Os resolvedores de DNS guardam o “registro inexistente” por um tempo. Consulte diretamente um dos seus próprios servidores de nomes acrescentando o nome dele à consulta, por exemplo dig +short TXT _dmarc.example.com @ns1.example.net. Se o registro aparecer ali, os verificadores logo vão encontrá-lo também.

Para onde vão os relatórios, e o que fazer com eles

Todo servidor de recebimento que recebeu emails com o seu domínio na linha From envia um relatório para o endereço rua. Segundo a página Sobre os relatórios DMARC do Google, eles são “geralmente enviados uma vez por dia por email”. O relatório é um arquivo XML, normalmente compactado, anexado a um email. A RFC 9990 descreve o formato.

O Google avisa que grandes organizações “podem receber até centenas ou mesmo milhares de relatórios por dia” e recomenda um grupo ou uma caixa de email dedicada. O número depende de quanto você envia e para quantos domínios, então uma ou duas caixas de email geram bem menos. Um alias como dmarc@ com um filtro para uma pasta própria é suficiente.

O endereço deve estar no mesmo domínio do registro. Se você quer os relatórios em outro lugar, o outro domínio precisa concordar publicando um registro próprio. Sem ele, os servidores de recebimento devem ignorar o endereço (RFC 9990, seção 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

É por isso que um endereço gratuito do Gmail não funciona como endereço de relatórios: gmail.com não publicava esse registro quando conferimos em 5 de outubro de 2026.

No arquivo, cada bloco record representa um servidor de envio: o endereço IP, o número de mensagens e, em policy_evaluated, se o DKIM e o SPF passaram para o seu domínio. Você procura duas coisas. Servidores que você conhece e que mostram fail precisam de correção, e DMARC falha embora SPF e DKIM passem explica como. Servidores que você não conhece são uma ferramenta que você esqueceu ou alguém usando o seu nome.

Depois de p=none: quando endurecer a política

p=none é um modo de monitoramento. Ele cumpre o mínimo que os provedores de email pedem e não impede ninguém de falsificar o seu endereço. Só fazem isso p=quarantine, que pede aos servidores de recebimento que tratem como suspeitos os emails que falham, e p=reject, que pede que os recusem.

Antes de endurecer, toda fonte legítima dos seus emails precisa passar. A RFC 9989 diz que essas lacunas “DEVEM ser resolvidas antes de qualquer tentativa” de aplicar a política e que, dependendo da frequência com que você envia, “pode levar muitos meses” de relatórios para ter certeza. A página de implantação do Google considera uma semana de relatórios “geralmente suficiente”. Com uma caixa de email e uma ou duas ferramentas, você está mais perto do número do Google, mas espere algumas semanas para que o envio mensal de faturas e o formulário de contato também apareçam.

Sobre o passo em si, as duas fontes divergem. O Google ainda sugere p=quarantine; pct=5 e ir aumentando o número. A norma abandonou pct e oferece isto no lugar:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y pede aos servidores de recebimento que, por enquanto, tratem as falhas um nível abaixo, isto é, como none. Quando os relatórios continuarem limpos, remova t=y. Saiba que um servidor de recebimento que não conhece a tag a ignora e aplica quarantine por inteiro, e que as páginas do Google não mencionam t em outubro de 2026. Se uma política mais rígida atingir emails que você ainda não consegue corrigir, fique em p=none.

Onde o WarmupBay entra

Quando você conecta uma caixa de email, o WarmupBay verifica SPF, DKIM e DMARC do domínio dela. Se o registro DMARC estiver faltando, ele mostra um pronto para copiar. Você pode começar o aquecimento mesmo assim. Se depois de 72 horas os registros ainda estiverem faltando, o aquecimento para.

O WarmupBay não pode adicionar o registro por você, já que o DNS é seu, e não coleta nem lê relatórios DMARC. O que ele faz é o passo depois dos registros: a sua caixa de email troca alguns emails por dia com outras caixas de email em uma rede compartilhada, começando com três e aumentando um por dia, para que a atividade de envio cresça gradualmente. É grátis para 10 emails por dia. Veja o que a verificação e o aquecimento cobrem ou conecte sua caixa de email quando o registro estiver no lugar.

Perguntas frequentes

Um registro DMARC em example.com também cobre subdomínios como news.example.com?

Sim. O servidor de recebimento primeiro procura um registro em _dmarc.news.example.com. Se não houver, ele recorre ao registro do domínio organizacional, example.com. A política aplicada ao subdomínio é a de sp, se você a definiu; caso contrário, a de p.

Posso publicar v=DMARC1; p=none sem um endereço rua?

Sim. É um registro válido e conta como política publicada. Você não vai receber relatórios, então não vai ver se os seus próprios emails passam nem quem mais usa o seu domínio. O Yahoo diz que um endereço rua que funcione é fortemente recomendado, e o Google recomenda sempre incluir um.

Preciso de um registro DMARC para um segundo domínio que só uso para prospecção?

Sim. Os servidores de recebimento consultam o domínio do endereço From de cada mensagem, então um registro no seu domínio principal não cobre um domínio diferente. Use a mesma linha no segundo domínio. Se os relatórios dele devem ir para um endereço no seu domínio principal, o domínio principal precisa publicar o registro de autorização descrito em “Para onde vão os relatórios”.

O que deve publicar um domínio que nunca envia email?

O par rígido. O M3AAWG recomenda o registro SPF v=spf1 -all e um registro DMARC com p=reject para domínios que nunca enviam email, para que ninguém possa usá-los em um endereço From. No DMARC, é a linha v=DMARC1; p=reject em _dmarc.

p=none é pior para os meus emails do que p=quarantine ou p=reject?

As regras publicadas para remetentes do Gmail, do Yahoo e do Outlook.com pedem pelo menos p=none e nada mais rígido. A política decide o que acontece com os emails que falham no DMARC, o que inclui emails falsificados em seu nome. Um recurso precisa de mais: o BIMI, o logotipo ao lado das suas mensagens, exige quarantine ou reject, segundo a ajuda do Google.

Fontes

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)