Resposta rápida
Como configuro o DMARC para o meu domínio?
Publique um registro TXT em _dmarc.seudominio que diga v=DMARC1; p=none; rua=mailto:voce@seudominio, leia os relatórios agregados por cerca de um mês, depois eleve a política para quarantine e por fim reject. O DMARC é definido pela RFC 9989 desde maio de 2026. A Postelva hospeda o registro no seu editor de DNS gratuito.
As três políticas DMARC e o que cada uma faz
| Política | Registro | Efeito sobre uma mensagem que falha no DMARC | Quando usar |
|---|---|---|---|
| Monitorar | v=DMARC1; p=none; rua=mailto:[email protected] | Entregue normalmente; os relatórios são enviados a você | Primeiras semanas, para ver todos os remetentes |
| Quarentena | v=DMARC1; p=quarantine; rua=mailto:[email protected] | Tratada como suspeita, geralmente enviada para o spam | Depois que SPF e DKIM passam em todo o seu e-mail legítimo |
| Rejeitar | v=DMARC1; p=reject; rua=mailto:[email protected] | Recusada pelo servidor receptor | Quando os relatórios não mostram mais nenhuma falha legítima |
Configure o DMARC em seis passos
Confirme primeiro o SPF e o DKIM
O DMARC precisa que pelo menos um deles passe e esteja alinhado com o seu domínio From. Publique os dois antes do DMARC, usando os guias de SPF e DKIM.
Escolha uma caixa de e-mail para os relatórios
Crie um endereço como dmarc@seudominio. A RFC 9989 diz que o titular deve configurar uma caixa de e-mail para receber e analisar relatórios agregados.
Publique o registro de monitoramento
Adicione um registro TXT com host _dmarc e o valor v=DMARC1; p=none; rua=mailto:dmarc@seudominio.
Leia os relatórios por cerca de um mês
Os relatórios chegam cerca de uma vez por dia dos receptores que os enviam. Procure e-mails legítimos que falham no alinhamento de SPF e DKIM e corrija esses remetentes.
Passe para quarantine
Mude p=none para p=quarantine. Mantenha por um período semelhante e compare nos relatórios como as mensagens foram tratadas.
Passe para reject, ou pare em quarantine
Mude para p=reject quando os relatórios estiverem limpos. Se você publica em listas de e-mail a partir deste domínio, fique em quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"O que um registro DMARC contém?
Um registro DMARC é um registro TXT em _dmarc.seudominio que começa com v=DMARC1 e lista tags separadas por ponto e vírgula. A tag de versão vem primeiro e diferencia maiúsculas de minúsculas. A RFC 9989 define estas tags: p (política para o domínio), sp (política para subdomínios existentes), np (política para subdomínios inexistentes), adkim e aspf (alinhamento, r para relaxado ou s para estrito, relaxado por padrão), rua (endereços de relatórios agregados), ruf (endereços de relatórios de falha), fo (opções de falha), t (modo de teste, y ou n) e psd.
Se p estiver ausente, o receptor trata a política como none. Se sp estiver ausente, a política p cobre os subdomínios. Se rua estiver ausente, nenhum relatório agregado é produzido. Um registro mínimo útil tem, portanto, três partes: a versão, uma política e um endereço de relatório.
A tag pct, que muitos guias mais antigos ainda mostram, foi removida pela RFC 9989 porque raramente era aplicada com precisão, exceto em 0 e 100. A tag t a substitui: t=y se comporta como pct=0 e t=n como pct=100, e n é o padrão. Retire o pct de registros antigos. O contexto mais amplo está em SPF vs DKIM vs DMARC.
O que significa alinhamento no DMARC?
Alinhamento significa que o domínio autenticado pelo SPF ou pelo DKIM corresponde ao domínio do endereço From visível. No modo relaxado, o padrão, os dois só precisam ter o mesmo domínio organizacional, então mail.example.com se alinha com example.com. No modo estrito, devem ser idênticos. A RFC 9989 observa que quase todos os titulares de domínio consideram suficiente o alinhamento relaxado.
Uma mensagem passa no DMARC quando o SPF ou o DKIM passa e está alinhado. Um dos dois basta. Um provedor de caixa de e-mail como o Proton Mail ou o Fastmail assina com o seu próprio domínio por meio dos registros CNAME de DKIM, então o alinhamento se mantém sem trabalho extra. A armadilha é um serviço de terceiros que assina com o próprio domínio: o DKIM dele passa, mas não se alinha até que você configure um domínio de assinatura personalizado para ele.
A RFC 9989 encontra o domínio organizacional por uma busca na árvore do DNS, com no máximo oito consultas, em vez de uma lista de sufixos públicos. Para um domínio comum em .com ou .me, isso não muda nada do que você precisa fazer.
Por quanto tempo devo ficar em p=none?
Fique em p=none por pelo menos um mês, depois em p=quarantine por um período semelhante, antes de p=reject. Essa é a ordem que a RFC 9989 aconselha em suas orientações de implantação, e coincide com as páginas de ajuda dos provedores. O Mailbox.org começa seu registro de exemplo em p=none e avisa que uma política estrita definida cedo demais pode devolver e-mails legítimos. A Proton recomenda p=quarantine e a passagem para p=reject quando o e-mail legítimo passar.
Segundo a leitura de Postelva de 12 de novembro de 2026 das orientações de DMARC dos 3 provedores que as publicam (Proton Mail, Mailbox.org e Mailfence), 2 começam em p=none e 1 recomenda p=quarantine.
Duas cautelas se aplicam a p=reject. A RFC 9989 diz que um domínio que o usa não deve depender apenas do SPF e deve assinar com DKIM, porque o SPF quebra no encaminhamento. Diz também que domínios cujos usuários publicam em listas de e-mail não devem publicar p=reject. As listas costumam modificar as mensagens, o que quebra a assinatura.
Para onde vão os relatórios DMARC e o que eles mostram?
Os relatórios agregados vão para o endereço mailto: em rua, geralmente uma vez por dia de cada receptor, e listam as fontes que enviaram e-mail com o seu domínio na linha From. A RFC 9989 exige que os receptores aceitem endereços mailto: e recomenda enviar relatórios agregados pelo menos a cada 24 horas. Os relatórios agregados são definidos na RFC 9990.
Os relatórios de falha, solicitados com ruf, são cópias por mensagem. Muitos receptores os retêm ou os editam por privacidade, então não conte com eles. Se o endereço rua fica fora do seu domínio, o titular desse outro domínio precisa autorizá-lo com um registro TXT em seudominio._report._dmarc.outrodominio contendo v=DMARC1;, uma regra que impede o abuso de caixas de e-mail de terceiros. Para um pequeno domínio pessoal a lista de fontes é curta: o seu provedor e pouco mais.
Para ler o que o seu DNS publica antes e depois de cada etapa, use os comandos para verificar registros MX, SPF, DKIM e DMARC.
Meu domínio pessoal precisa de DMARC?
Sim, para qualquer domínio que envia e-mail: custa um registro TXT e bloqueia mensagens falsificadas que usam o seu nome. O Google exige DMARC, bastando uma política none, de remetentes acima de 5,000 mensagens por dia para contas do Gmail, e a Microsoft aplica o mesmo limite ao Outlook.com. Uma caixa de e-mail pessoal fica muito abaixo desses limites. O registro ainda diz aos receptores o que você quer que seja feito com uma falsificação.
Para um domínio que não envia nada, defina p=reject de imediato, com SPF -all e um MX nulo. A Postelva oferece um modelo "sem e-mail" para esse caso. Para um domínio com caixa de e-mail, comece em none. O lado do transporte da mesma proteção, a criptografia entre servidores, é tratado em como configurar MTA-STS e TLS-RPT.
Uma definição citável: o DMARC é a política de DNS que diz aos receptores o que fazer com e-mails cujos resultados de SPF e DKIM não se alinham com o domínio From, e para onde enviar relatórios sobre isso.
Perguntas sobre a configuração do DMARC
A RFC 9989 exige p=reject?
Não. O padrão define três políticas e deixa a escolha ao titular do domínio. Ele aconselha um caminho gradual e adverte contra p=reject para domínios cujos usuários publicam em listas de e-mail.
A RFC 9989 muda meu registro DMARC atual?
Os registros ainda começam com v=DMARC1, então um registro que funciona continua funcionando. A tag ri foi descartada, o pct foi removido e t, np e psd foram adicionados.
O que acontece se eu publicar p=reject cedo demais?
E-mails legítimos que falham no alinhamento, como uma ferramenta de newsletter esquecida, são recusados pelos receptores. Os relatórios em p=none existem para encontrar esses remetentes primeiro.
Posso usar uma caixa de e-mail gratuita para os relatórios?
Sim, qualquer caixa de e-mail que você leia. Um endereço ou alias separado mantém os arquivos diários de relatório fora da sua caixa de entrada principal.
Quantos registros DMARC um domínio pode ter?
Um por nome, em _dmarc.seudominio. Os subdomínios podem ter o próprio registro ou herdar a política do domínio pai por meio de sp.
Em resumo
- O DMARC é um registro TXT em _dmarc.seudominio que começa com v=DMARC1.
- A RFC 9989 (maio de 2026) é a especificação atual; ela torna obsoleta a RFC 7489 e remove o pct.
- Comece em p=none com um endereço rua e leia os relatórios por cerca de um mês.
- Depois p=quarantine por um período semelhante e então p=reject.
- Uma mensagem passa quando o SPF ou o DKIM passa e se alinha com o domínio From; o alinhamento relaxado é o padrão.
- Um domínio em p=reject não deve depender apenas do SPF e não deve ser usado com listas de e-mail.
- A Postelva hospeda o registro em DNS gratuito; um .com custa US$ 12,49/ano todos os anos.
Fontes (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (lido em 2026-11-12)
- RFC 7489, DMARC (obsoleta) — RFC Editor (lido em 2026-11-12)
- SPF, DKIM e DMARC para um domínio personalizado — Mailbox.org (lido em 2026-11-12)
- Domínio personalizado e antifalsificação — Proton (lido em 2026-11-12)
- Diretrizes para remetentes de e-mail — Google Workspace Admin Help (lido em 2026-11-12)
- Reforçando a segurança de e-mail: novos requisitos para remetentes de alto volume — Microsoft Tech Community (lido em 2026-11-12)