Exemplos de registro DMARC: 12 registros prontos para copiar, explicados tag por tag

Um registro DMARC funcional é um único registro TXT em _dmarc.seudominio.com. A versão mínima que já tem utilidade é v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com. Os 12 exemplos abaixo vão desse ponto de partida até a aplicação total da política, passando pelos casos especiais (subdomínios, domínios que nunca enviam e-mail, serviços de relatórios de terceiros, relatórios de falha), com cada tag explicada.

Todos os registros aqui podem ser montados ou adaptados no nosso gerador de DMARC, que cuida de p, sp, pct, rua e do alinhamento estrito. As demais tags você acrescenta à mão. Depois que o registro estiver no ar, confirme o que os receptores enxergam com o verificador de DMARC.

Uma observação sobre os padrões. As definições das tags abaixo vêm da RFC 7489, a especificação de 2015 que praticamente todo receptor implementou, e da RFC 9989, que a substituiu em maio de 2026. Onde as duas divergem, o exemplo avisa. Se a dúvida é quando passar de um registro para outro, isso está em como migrar o DMARC de p=none para p=reject. Este post é a referência.

As tags em resumo

Tag	Significado	Padrão	Situação
v	Versão; precisa ser DMARC1 e vir primeiro	Obrigatória	Ambas as RFCs
p	Política do domínio: none, quarantine, reject	none se ausente (RFC 9989)	Ambas
sp	Política para subdomínios existentes	Herda p	Ambas
np	Política para subdomínios inexistentes	Herda sp, depois p	RFC 9989 (vinda da RFC 9091)
rua	Para onde enviar relatórios agregados	Nenhum, então sem relatórios	Ambas
ruf	Para onde enviar relatórios de falha	Nenhum	Ambas
fo	Quando gerar relatórios de falha	0	Ambas
adkim / aspf	Alinhamento de DKIM / SPF: r relaxado ou s estrito	r	Ambas
pct	Porcentagem do e-mail reprovado a que a política se aplica	100	Só RFC 7489; removida na RFC 9989
t	Modo de teste: y ou n	n	Só RFC 9989
ri, rf	Intervalo dos relatórios, formato do relatório de falha	86400, afrf	Só RFC 7489; removidas na RFC 9989
psd	Marca um domínio de sufixo público	u	RFC 9989; não serve para domínios comuns

As duas RFCs dizem que tags desconhecidas devem ser ignoradas, e é por isso que tags antigas e novas podem conviver no mesmo registro sem problema.

Registros de monitoramento

1. O registro inicial

v=DMARC1; p=none; rua=mailto:dmarc@example.com

• v=DMARC1: identifica o registro. A RFC 9989 diz que essa tag "DEVE ser a primeira tag da lista".
• p=none: nada muda no tratamento do e-mail reprovado. Você está pedindo dados, não aplicação de política.
• rua=mailto:dmarc@example.com: os receptores que enviam relatórios mandam para cá arquivos XML agregados diários. A RFC 9989 é explícita: sem rua, os receptores "NÃO DEVEM gerar relatórios de feedback agregados".

Use este registro no primeiro dia. Um registro p=none sem rua é o registro DMARC menos útil que existe: cumpre a exigência de "pelo menos p=none" do Gmail e do Yahoo e não diz nada a você.

2. Monitoramento com dois destinos de relatório

v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:x7k2@reports.dmarc-vendor.example

• O rua aceita uma lista separada por vírgulas. Aqui, uma cópia vai para a sua própria caixa e outra para um serviço que interpreta os relatórios e transforma o XML em algo legível.

Os relatórios agregados chegam como XML compactado de todos os receptores participantes, todos os dias. Acima de alguns milhares de mensagens por dia, poucas equipes os leem em estado bruto.

3. Monitoramento com alinhamento estrito

v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc@example.com

• adkim=s: o domínio d= do DKIM precisa ser exatamente igual ao domínio do From. mail.example.com deixa de se alinhar com example.com.
• aspf=s: o mesmo para o domínio do SPF (o remetente do envelope).

A maioria dos domínios deve manter as duas no padrão relaxado. O alinhamento estrito quebra toda plataforma que assina ou recebe bounces por um subdomínio seu. Rode primeiro em p=none, para que os relatórios mostrem o que seria reprovado.

Registros com aplicação de política

4. Quarantine em uma porcentagem (estilo RFC 7489)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

• p=quarantine: o e-mail reprovado deve ser tratado como suspeito, o que normalmente significa a pasta de spam.
• pct=25: a RFC 7489 diz que os receptores "NÃO DEVEM aplicar a política solicitada" a mais de 25% do e-mail reprovado. Os outros 75% passam pela filtragem normal do receptor.

Este é o registro que a maioria dos guias mais antigos recomenda. A RFC 9989 removeu o pct porque, nas palavras dela, ele "geralmente não era aplicado com precisão, a não ser que o valor especificado fosse 0 ou 100". Um receptor no padrão novo o ignora e aplica p=quarantine a tudo o que for reprovado.

5. Quarantine em modo de teste (funciona nos dois padrões)

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

• t=y: o modo de teste da RFC 9989. O receptor aplica a política "um nível abaixo" da publicada, então quarantine vira none.
• pct=0: o equivalente na RFC 7489. O e-mail reprovado não vai para quarantine e recebe a classificação local do receptor.

Os dois tipos de receptor chegam mais ou menos ao mesmo resultado: "não coloque em quarentena ainda, mas mande relatório". É um ensaio geral que você pode publicar antes do registro 6.

6. Quarantine completo

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

Sem pct nem t, valem os padrões (100 e n): todo e-mail reprovado vai para quarentena.

7. Reject em modo de teste

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc@example.com

• t=y com p=reject significa quarantine na RFC 9989.
• Na RFC 7489, o e-mail que o pct exclui do reject "DEVERIA" ser tratado "como se a política 'quarantine' se aplicasse".

Aqui os dois padrões concordam exatamente, o que faz deste o passo mais seguro entre os registros 6 e 8.

8. Reject completo

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

• p=reject: os receptores são orientados a recusar o e-mail reprovado durante a conversa SMTP. Nada é entregue, então ninguém consegue resgatar um falso positivo da pasta de spam.

Mantenha o rua aqui. É pelos relatórios que você percebe uma ferramenta nova que alguém do marketing conectou sem configurar o DKIM.

Registros para subdomínios

9. Reject no domínio principal, mais brando nos subdomínios

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

• sp=quarantine: vale para subdomínios existentes (news.example.com, billing.example.com) que não têm registro DMARC próprio. As duas RFCs dizem que, se sp estiver ausente, os subdomínios recebem a política p.

Útil quando o domínio principal está limpo, mas um subdomínio ainda tem um remetente que você não corrigiu. Faça o inverso (p=quarantine; sp=reject) se os seus subdomínios estão bem controlados e o domínio principal ainda não.

10. Bloquear subdomínios inventados

v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com

• np=reject: a política da RFC 9989 para subdomínios que não existem no DNS, como secure-login.example.com. Ela "se aplica apenas a subdomínios inexistentes", não a subdomínios reais nem ao próprio domínio.

Como nada legítimo consegue enviar de um subdomínio que não existe, np=reject costuma ser seguro muito antes de p=reject. Receptores que não reconhecem np o ignoram e recorrem a sp e, depois, a p.

11. Um subdomínio com registro próprio

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

Um registro publicado diretamente em um subdomínio prevalece para aquele subdomínio. Repare que o sp dentro do registro do próprio subdomínio é ignorado; as duas RFCs dizem isso, porque a política de subdomínios é lida no registro do domínio organizacional.

12. Um domínio que nunca envia e-mail

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s

Para domínios estacionados e domínios usados só para sites. Toda mensagem que diz vir deles é falsa, então rejeite tudo. Combine com um registro SPF v=spf1 -all (nenhum servidor pode enviar) para que os receptores também tenham uma reprovação clara de SPF. Incluir rua é opcional. Ele mostra quem está falsificando o domínio, o que é interessante, mas raramente gera alguma ação.

Variações de relatórios

Enviar relatórios para um serviço de terceiros

Quando o endereço do rua está em um domínio organizacional diferente do seu, os receptores conferem se o destino concordou em receber seus relatórios. A RFC 7489 (seção 7.1) e a sua sucessora, a RFC 9990, descrevem a checagem: o receptor procura um registro TXT montado com o seu domínio, _report._dmarc e o domínio de destino.

example.com._report._dmarc.dmarc-vendor.example.  TXT  "v=DMARC1"

Quem publica esse registro é o serviço de relatórios, não você. Se os relatórios não estão chegando a um fornecedor, consulte esse registro primeiro. A RFC 7489 também permitia um sufixo de limite de tamanho, como !10m, nos endereços de relatório. A RFC 9989 o removeu, então deixe-o de fora dos registros novos.

Pedir relatórios de falha

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1

• ruf: para onde enviar relatórios de falha por mensagem.
• fo=1: gera um relatório se qualquer mecanismo deixar de produzir uma aprovação alinhada. O padrão fo=0 só reporta quando todos falham. fo=d e fo=s pedem relatórios de falha específicos de DKIM ou de SPF.

Espere poucos. O suporte dos receptores a relatórios de falha é bem mais irregular do que aos relatórios agregados, e a RFC 9991, que agora os define, alerta que eles "podem conter Informações de Identificação Pessoal". Use uma caixa postal com acesso restrito. Se você opera no Brasil, vale lembrar que dados pessoais nesses relatórios também estão sob a LGPD (Lei 13.709/2018), então trate essa caixa com o mesmo cuidado de acesso e retenção que você dá a outros dados pessoais.

Erros que vemos em registros reais

• Dois registros DMARC no mesmo nome. Publique exatamente um registro TXT começando com v=DMARC1 em _dmarc. A RFC 7489 diz que, se a descoberta encontrar vários registros, "o processamento DMARC não é aplicado"; ou seja, dois registros valem o mesmo que nenhum.
• Registro no nome errado. Ele vai em _dmarc.example.com, não em example.com.
• v=DMARC1 fora da primeira posição. As duas RFCs exigem que seja a primeira tag.
• rua sem mailto:. Um endereço de e-mail solto não é uma URI válida.
• Aspas e ponto e vírgula copiados errado. Muitos painéis de DNS adicionam as aspas externas automaticamente. Aspas curvas coladas de um documento quebram o registro.
• Pular direto para p=reject. Sem um período de relatórios em p=none, você não vai saber quais das suas próprias ferramentas são reprovadas.

Para uma visão mais ampla de como esses registros convivem com SPF e DKIM, veja SPF, DKIM e DMARC explicados. Para ver como outras empresas configuraram os delas, o nosso estudo de adoção de DMARC mostra quais políticas 200 empresas de SaaS publicam.