O DMARC é um registro TXT em _dmarc.<your domain> que diz aos receptores o que fazer com as mensagens que usam o seu domínio no cabeçalho From e falham tanto no SPF quanto no DKIM alinhados, e para onde enviar relatórios. p=none só pede relatórios, p=quarantine pede aos receptores que tratem as mensagens reprovadas como suspeitas e p=reject pede que eles as recusem.

O Gmail, o Yahoo e a Microsoft aceitam p=none de remetentes em massa, por isso muitos domínios publicam essa política e param por aí: recebem relatórios sobre quem falsifica o domínio, mas não bloqueiam ninguém. Uma análise da Red Sift com 73,3 milhões de domínios, citada em abril de 2026, concluiu que 14,9% tinham alguma política DMARC e que 2,5% aplicavam p=reject. O EasyDMARC, outro fornecedor de DMARC, informou em 2025 que 62,7% das empresas da Fortune 500 com DMARC usavam p=reject, contra 15,2% das empresas da Inc. 5000.

Veja a seguir um plano de 30 dias até p=reject, registro por registro, para um domínio que envia pelo e-mail corporativo, por um ou dois ESPs, por um help desk e por uma ferramenta de cobrança. Trinta dias servem para um subdomínio de envio. Um domínio que a sua equipe usa no e-mail do dia a dia precisa de mais tempo.

Pontos-chave

• Publique v=DMARC1; p=none; rua=mailto:... no dia 1. Sem rua, os receptores não podem enviar relatórios agregados.
• Todo remetente legítimo precisa passar no SPF ou no DKIM alinhado ao domínio do From. Na maioria das ferramentas, isso significa assinar o DKIM com o seu domínio.
• Mantenha o SPF com no máximo 10 termos que geram consultas DNS, contando os includes aninhados, ou todas as suas mensagens recebem permerror.
• Passe para p=quarantine no dia 15 e para p=reject no dia 22, sempre depois de uma semana de relatórios limpos. Para um domínio que a equipe usa no e-mail do dia a dia, a RFC 9989 pede um mês em cada uma das duas primeiras fases.
• A RFC 9989 (maio de 2026) classifica pct como histórico. Dispense a rampa com pct=10 e pct=50.
• O BIMI exige p=quarantine ou p=reject no domínio organizacional, nenhum sp=none, um logo em SVG Tiny PS e, no Gmail, um VMC ou um CMC.

O que mudou no DMARC em 2026

Em maio de 2026, a IETF substituiu a RFC 7489, um documento informativo (Informational) de 2015, pelo DMARCbis: a RFC 9989, uma proposta de padrão (Proposed Standard) que também torna obsoleta a RFC 9091, mais a RFC 9990, sobre relatórios agregados. Três mudanças importam aqui:

• pct passa a ser histórico. O Apêndice A.6 diz que ele “geralmente não era aplicado com precisão, a não ser que o valor especificado fosse 0 ou 100”.
• t=y substitui pct=0. Os receptores aplicam um nível abaixo da sua política, então p=reject; t=y funciona como quarantine. É uma chave de teste.
• np é novo. Ele cobre subdomínios que não existem no DNS, e os receptores mais antigos precisam ignorá-lo.

Para encontrar o domínio organizacional, uma busca na árvore do DNS (DNS tree walk) também substitui a lista de sufixos públicos.

Os três registros de que o DMARC depende

O DMARC passa quando o SPF ou o DKIM passa e o domínio aprovado está alinhado com o domínio do From. Basta uma aprovação alinhada.

O SPF e o limite de 10 consultas

O SPF autoriza servidores para o domínio do envelope (MAIL FROM ou return-path), a única identidade que o DMARC usa; o HELO não entra. A RFC 7208, seção 4.6.4, limita a 10 os termos que geram consultas DNS: include, a, mx, ptr, exists e redirect, contados em todos os includes aninhados. ip4, ip6 e all não entram na conta. Acima disso, o resultado é permerror. A seção também permite no máximo duas “consultas vazias” (void lookups), em geral um include de um hostname que não existe mais.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Esse registro já gasta 4 consultas antes de contar o que cada fornecedor aninha, então resolva cada include com dig +short TXT <name> ao longo da cadeia. Para não passar de 10, remova ferramentas que ninguém usa mais ou dê a cada ESP o próprio subdomínio de return-path, como bounce.example.com, com uma cota própria de 10. O guia de configuração do SPF da Microsoft recomenda terminar com -all em domínios que também usam DKIM e DMARC.

Muitos ESPs usam por padrão o próprio domínio de return-path, que não se alinha com o seu. Configure um return-path personalizado ou conte com o DKIM.

DKIM: chaves de 2048 bits, seletores e rotação

O DKIM assina cada mensagem com um domínio d= e um seletor s=; o receptor busca a chave em <selector>._domainkey.<d domain>. Uma ferramenta que assina com d=vendor-mail.example passa no DKIM e falha no DMARC.

A RFC 8301 diz que quem assina precisa usar chaves RSA de pelo menos 1024 bits e deveria usar 2048. As diretrizes para remetentes do Google dizem o mesmo para os e-mails enviados a contas pessoais do Gmail. Uma chave de 2048 bits passa do limite de 255 caracteres de uma string TXT, então ela entra como várias strings entre aspas em um único registro, que a maioria dos provedores de DNS divide para você.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Dê a cada sistema de envio o próprio seletor e nunca reutilize um nome. Uma data, como s202610, deixa o histórico fácil de ler. As práticas de rotação de chaves do M3AAWG recomendam rotacionar pelo menos a cada seis meses:

1. Publique o novo seletor e aguarde a propagação.
2. Passe a assinar com a nova chave.
3. Mantenha a chave pública antiga no DNS por 7 a 30 dias, para que as mensagens em trânsito ainda sejam verificadas.
4. Desative o seletor antigo com um p= vazio. Não o exclua.

Alinhamento: relaxado ou estrito

A RFC 9989 define dois modos:

A RFC 9989 observa que “quase todos os proprietários de domínios consideraram o alinhamento relaxado suficiente”. Deixe aspf e adkim de fora. O alinhamento estrito do SPF quebra o return-path usual em um subdomínio.

O plano de 30 dias

O registro de cada fase. Avance só depois de uma semana de relatórios limpos.

Se a semana 2 revelar uma fonte que ninguém consegue corrigir, fique em p=none. Rejeitar as suas próprias faturas é pior do que aplicar a política com atraso.

Dias 1 a 7: publique p=none com relatórios

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

Os relatórios são arquivos XML compactados com gzip, que cada receptor envia pelo menos uma vez por dia; por isso, aponte o rua para um processador de relatórios, não para uma pessoa. Se o endereço estiver em outro domínio organizacional, a RFC 9990 determina que os receptores o ignorem, a menos que example.com._report._dmarc.<report domain> o autorize. Os processadores publicam esse registro; nos seus próprios domínios, adicione-o você mesmo.

Publique exatamente um registro DMARC. Se os assistentes de configuração deixarem dois registros v=DMARC1 em _dmarc.example.com, os receptores descartam os dois.

Dispense o ruf. A RFC 9989 observa que receptores preocupados com a privacidade removem boa parte do conteúdo dos relatórios de falha ou nem os enviam, e as perguntas frequentes do anúncio da Microsoft para remetentes de alto volume dizem que ela envia relatórios rua e não tem planos de enviar ruf.

Como ler um relatório agregado

A RFC 9990 descreve relatórios XML “diários (ou mais frequentes)”, um por domínio de política. Veja um registro, adaptado do exemplo da RFC:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Em policy_evaluated, dkim e spf são resultados de alinhamento, e disposition é o que o receptor fez. auth_results traz os resultados brutos e os respectivos domínios. Aqui, os dois passam para vendor.example, então os dois falham no alinhamento: é um fornecedor enviando em seu nome sem assinar como você. Ative o DKIM personalizado ou a autenticação de domínio desse fornecedor.

Dias 1 a 7: encontre os remetentes desconhecidos

Agrupe por source_ip, envelope_from e pelo domain mais o selector do DKIM, ordene por count e classifique:

Para identificar a origem de um IP, rode dig -x 192.0.2.123 +short e confira o seletor, que muitas vezes traz o nome do fornecedor. Depois, pergunte ao financeiro, ao suporte e a vendas o que envia e-mails em nome da empresa: cobrança, help desk, convites de agenda, scanners do escritório.

Mensagens encaminhadas e de listas vão falhar de formas que você não tem como corrigir, e as perguntas frequentes para remetentes do Google não exigem alinhamento nesses casos, então não deixe que elas atrasem o plano.

Dias 8 a 14: corrija cada fonte legítima

Comece pelo maior count e vá descendo:

1. E-mail corporativo (Google Workspace, Microsoft 365). Ative o DKIM no console de administração, com 2048 bits quando houver essa opção, e confirme que o include do provedor está no SPF.
2. ESPs e ferramentas de marketing. Configure a autenticação de domínio para que eles assinem com o seu d=, além de um return-path personalizado, se houver essa opção.
3. Help desk, cobrança, CRM. O mesmo que nos ESPs. Se algum não conseguir assinar com o seu domínio, use um subdomínio para o qual ele consiga assinar ou o próprio domínio dele.
4. Ferramentas abandonadas. Remova os includes e os seletores delas.

Depois, conte de novo as consultas do SPF.

Dia 15: p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Quarentena geralmente significa a pasta de spam. Fique de olho em fontes legítimas com a disposição quarantine. Para ensaiar, p=quarantine; t=y pede aos receptores que seguem a RFC 9989 que apliquem none, embora a RFC tenha só alguns meses e nem todo receptor respeite t ainda.

Dia 22: p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

Os receptores que respeitam p=reject recusam as mensagens reprovadas na própria sessão SMTP, mas a RFC 9989 orienta que eles as coloquem em quarentena quando a política é a única evidência que têm; por isso, parte delas cai no spam.

A mesma RFC diz que um domínio em p=reject “NÃO DEVE depender apenas do SPF” e precisa assinar com DKIM, já que o encaminhamento quebra o SPF, mas não o DKIM. Antes, confirme o DKIM alinhado em todas as fontes.

Mantenha o rua para sempre. A ferramenta nova do próximo trimestre vai aparecer nos seus relatórios antes de aparecer na fila do suporte.

Quando estender o plano

A RFC 9989, na seção 7.4, diz que domínios cujos usuários publicam em listas de discussão “NÃO DEVERIAM” publicar p=reject e que, quando o fazem, deveriam passar primeiro “pelo menos um mês” em p=none e “um período igualmente longo” em p=quarantine. É o caso da maioria dos domínios raiz de empresas, então dê um mês a cada uma das duas primeiras fases nesses domínios. Um subdomínio usado só pelo seu ESP não tem tráfego de listas e pode manter o ritmo de 30 dias.

Política de subdomínios: sp= e np=

p cobre o domínio e os subdomínios dele. sp o substitui nos subdomínios que existem, e np, nos que não existem. Um subdomínio com registro próprio usa esse registro, e a RFC 9989 ignora o sp nesse caso.

Um subdomínio de envio dedicado, como mail.example.com, usado por um único ESP com SPF e DKIM verificados, pode publicar p=reject desde o primeiro dia. p=none; sp=reject no domínio raiz protege os subdomínios enquanto você termina o domínio principal, mas impede o BIMI.

Domínios estacionados devem publicar v=spf1 -all, como indica o guia de SPF da Microsoft, além de v=DMARC1; p=reject; em _dmarc.

Do dia 30 em diante: BIMI

O BIMI exibe o seu logo ao lado das mensagens autenticadas nas caixas de entrada compatíveis:

O rascunho do BIMI está na revisão 14 (maio de 2026) e continua sendo um Internet-Draft escrito com base na RFC 7489, daí o pct. Deixe o pct de fora e não defina t=y.

A regra do domínio organizacional pega quem envia por subdomínio: com mail.example.com em p=reject e example.com em p=none, os receptores não podem exibir o logo, então o domínio raiz também precisa concluir o plano.

As orientações do BIMI Group para o SVG recomendam um logo quadrado e centralizado, sobre fundo sólido, com menos de 32 KB. O Google passou a aceitar CMC em setembro de 2024. O registro, segundo o guia de implementação do BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Registrar uma marca leva meses; se você vai precisar de um VMC, comece agora.

O que o Gmail, o Yahoo e a Microsoft exigem

Nenhum dos três exige a aplicação da política, apenas um registro DMARC e alinhamento.

Fontes: as diretrizes para remetentes do Google e as perguntas frequentes, as boas práticas para remetentes do Yahoo e, da Microsoft, o comunicado de abril de 2025 e a página de suporte do erro 5.7.515. A Microsoft começou a aplicar as regras em 5 de maio de 2025, depois que uma atualização de 29 de abril trocou o envio para a pasta Lixo Eletrônico pela rejeição.

As perguntas frequentes do Google dizem que o alinhamento com o SPF e com o DKIM “em algum momento será um requisito para remetentes”, então alinhe os dois na semana 2. Sobre taxas de descadastro e de spam, veja o que continua valendo quando um agente envia os seus e-mails e o nosso guia de entregabilidade.

DMARC em um domínio de envio do Brew

A configuração de domínio do Brew pede:

• DKIM: um registro TXT em um seletor ._domainkey dentro do seu domínio de envio. Obrigatório.
• SPF: um registro MX e um TXT em send.<your sending domain>, o return-path do Brew. Obrigatório.
• DMARC: um registro TXT em _dmarc.<your sending domain>. Opcional e recomendado.
• Um CNAME para o rastreamento de cliques, só se você usar um subdomínio de rastreamento personalizado.

O domínio começa a enviar assim que o SPF e o DKIM são verificados, e o Brew sugere um valor de DMARC compatível:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Um subdomínio dedicado recebe p=reject porque nada é enviado por ele antes de o SPF e o DKIM do Brew serem verificados. Um domínio raiz recebe p=none porque as suas outras ferramentas provavelmente também enviam em nome dele; nesse caso, siga o plano acima. O alinhamento fica relaxado porque o return-path send.<domain> só se alinha no modo relaxado.

O Brew lê o registro _dmarc.<sending domain> publicado quando você adiciona e verifica o domínio e a cada nova verificação. O resultado aparece em Domínios, e também em get_domain_health, via MCP, e em GET /v1/domains/{domainId}/health:

• dmarc_missing: um aviso com o registro exato a adicionar.
• dmarc_invalid: quando há dois registros DMARC no mesmo nome, uma versão ou política inválida ou tags duplicadas. O aviso indica qual registro excluir.
• Verificado: quando é encontrado exatamente um registro válido.

A configuração automática de DNS só grava o DMARC quando não existe nenhum registro, então nunca cria um duplicado. A verificação é feita no domínio de envio, não no domínio pai; por isso, dê a cada subdomínio de envio o próprio registro, inclusive um para o e-mail transacional, se você separar os dois como a documentação recomenda. É no seu processador de rua que você lê os relatórios e decide quando passar para reject.

Perguntas frequentes

Quanto tempo devo ficar em p=none antes de passar para quarantine?

Até que uma semana inteira de relatórios mostre todas as fontes legítimas passando no SPF ou no DKIM alinhado, o que costuma levar de uma a duas semanas em um subdomínio de envio. Para um domínio que a equipe usa no e-mail do dia a dia, a RFC 9989 pede pelo menos um mês. Dois anos em p=none sem ninguém lendo os relatórios não valem nada.

A tag pct do DMARC foi descontinuada?

Sim. A RFC 9989 classifica pct como “histórico” e substitui os únicos valores confiáveis dele por t: t=y se comporta como pct=0, e t=n, como pct=100. Receptores mais antigos ainda podem ler pct, mas nunca aplicaram os valores intermediários de forma consistente; por isso, avance em etapas inteiras.

O p=reject vai bloquear os meus e-mails encaminhados?

O encaminhamento simples costuma quebrar o SPF, mas não o DKIM, então o DKIM alinhado continua passando. Listas que alteram o assunto ou o rodapé quebram o DKIM, e algumas reescrevem o cabeçalho From para compensar. DKIM alinhado em todas as fontes é a sua melhor proteção.

O Gmail e o Yahoo exigem p=reject?

Não. Os dois exigem que remetentes em massa publiquem DMARC e aceitam p=none, assim como a Microsoft acima de 5.000 mensagens por dia para o Outlook.com. Aplicar a política impede o spoofing e é obrigatório para o BIMI, mas nenhum dos três exige isso.

Preciso de um VMC para o BIMI?

Para o Gmail, você precisa de um VMC, que exige uma marca registrada e exibe um selo de verificação, ou de um CMC, que mostra o logo sem o selo. O BIMI Group diz que alguns provedores, entre eles o Yahoo e o Fastmail, também exibem logos autodeclarados, sem certificado.