# O que é DMARC? Alinhamento, Políticas e as RFCs de 2026 URL: https://notificationharbor.com/pt/journal/o-que-e-dmarc Type: blog Locale: pt Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC diz aos receptores o que fazer quando o mail falha em alinhamento. Aqui está como o registro, políticas e relatórios funcionam, e o que mudou em 2026. O que é DMARC? É um registro DNS que avisa aos servidores de email receptores o que fazer quando uma mensagem diz vir do seu domínio no campo From, mas falha na autenticação, e onde enviar relatórios sobre isso. DMARC não autentica nada por si só. Ele verifica que SPF ou DKIM passaram e que o domínio que validaram bata com o domínio que o leitor vê. Essa correspondência é chamada de alinhamento, e é a parte que a maioria das equipes erra. Uma mensagem pode passar em SPF, passar em DKIM, e ainda assim falhar em DMARC. ## DMARC é uma camada de política em cima de SPF e DKIM SPF lista quais IPs podem enviar por um domínio. DKIM assina a mensagem para que um receptor possa verificar que ela não foi alterada e que o domínio que a assinou aprovou. Nenhum dos dois olha para o endereço From que um humano lê. DMARC fecha essa brecha. Ele faz uma única pergunta: o domínio visível no cabeçalho From se alinha com o domínio que passou em SPF ou DKIM? Se sim, a mensagem passa. Se não, o receptor aplica sua política. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) O registro fica em `_dmarc.seudominio.com.br` como um registro TXT. Um mínimo e válido se parece com isto: `_dmarc.exemplo.com.br. IN TXT "v=DMARC1; p=none; rua=mailto:relatorios-dmarc@exemplo.com.br"`Três tags fazem o trabalho real. `p` é a política, `rua` é para onde os relatórios agregados vão, e `adkim` / `aspf` definem o quão rigoroso o alinhamento é. Tudo o mais é opcional. ## O alinhamento é onde as boas configurações falham SPF autentica o envelope sender, o domínio Return-Path. DKIM autentica o domínio na tag `d=` da assinatura. DMARC precisa que pelo menos um desses bata com o domínio From, ou exatamente (estrito) ou no nível do domínio organizacional (relaxado, o padrão). Aqui está a falha que vemos com mais frequência nas traces. Uma equipe envia por um provedor terceirizado, o provedor assina com seu próprio domínio (`d=provedor-email.net`) e usa seu próprio domínio bounce. SPF passa, DKIM passa, e DMARC falha porque nenhum domínio bata com `exemplo.com.br`. A solução é um domínio de envio customizado: uma chave DKIM publicada sob seu domínio, e idealmente um return-path customizado em um subdomínio. Todo provedor sério suporta isso. Poucos ativam por padrão. ## As três políticas: none, quarantine, reject A tag `p` tem três valores, e eles não são uma escada que você sobe em um cronograma. - **`p=none`**: o receptor entrega normalmente e envia relatórios. Use-a pelas primeiras 2 a 4 semanas, enquanto você faz o inventário dos remetentes. - **`p=quarantine`**: o receptor roteia falhas para spam ou lixo eletrônico. Use-a quando os relatórios mostram que todas as fontes legítimas estão alinhadas. - **`p=reject`**: o receptor recusa falhas no estágio SMTP. Use-a quando quarantine rodar limpo por um ciclo de envio completo. `p=none` é monitoramento, não proteção. Um domínio em `none` por dois anos tem uma caixa de conformidade e sem defesa contra spoofing. Pule a tentação de deixá-lo lá porque "nada quebrou". `p=reject` é o destino para qualquer domínio que envia apenas mail que você controla. Domínios com muito tráfego de mailing list ou forwarders legados precisam de mais cuidado, porque encaminhamento frequentemente quebra SPF e pode quebrar DKIM se o intermediário editar o corpo. ## Por que as regras do Gmail e Yahoo tornaram isso urgente Desde fevereiro de 2024, as [diretrizes de remetente do Google](https://support.google.com/mail/answer/81126) exigem que quem envie mais de 5.000 mensagens por dia para contas Gmail publique um registro DMARC, com SPF e DKIM em vigor. A política pode ser `none`. O Google também pede aos remetentes em massa que mantenham a taxa de spam reportada pelos usuários em Ferramentas do Postmaster abaixo de 0,30%, e recomenda ficar abaixo de 0,10%. O [Yahoo Sender Hub](https://senders.yahooinc.com/best-practices/) afirma o mesmo requisito principal: uma política DMARC válida de pelo menos `p=none`, com o domínio From alinhado ao domínio SPF ou DKIM. O alinhamento relaxado é aceitável. Note o que está e o que não está nessas regras. O requisito é um registro publicado e alinhamento passar, não enforcement. Esse é um piso. Não é uma linha de chegada. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Os relatórios agregados são o produto, a política é a chave O endereço `rua` recebe relatórios XML diários de cada receptor que honra DMARC. Cada relatório lista IPs de origem, contagens de mensagens, os resultados de SPF e DKIM, e se o alinhamento se manteve. É assim que você encontra o remetente esquecido: a velha exportação de CRM, a ferramenta de cobrança que um contratante conectou em 2022, o formulário de marketing em um subdomínio que ninguém possui. XML bruto é ilegível em volume. Rotule `rua` para uma caixa de correio que um parser possa ingerir, ou para um serviço de relatórios DMARC hospedado, e olhe para os dados agrupados por origem. O que você quer ver é cada fonte legítima mostrando 100% alinhada, e tudo o mais claramente desconhecido. Um rollout prático roda nesta ordem: - Publique `p=none` com um endereço `rua`. - Colete 2 a 4 semanas de relatórios. Construa o inventário do remetente. - Corrija cada fonte legítima desalinhada com um domínio DKIM customizado ou return-path. - Mude para `p=quarantine`. Fique atento a tickets de suporte sobre mail desaparecido. - Mude para `p=reject` quando quarantine mostrar zero falhas legítimas. Entregue cada passo separadamente. Mudar a política e adicionar um novo provedor de envio na mesma semana torna qualquer regressão impossível de atribuir. ## DMARCbis muda as tags, não seu registro Em 2026 o IETF publicou RFC 9989, RFC 9990, e RFC 9991, que obsoletam RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) é a spec DMARC principal. Relatórios agregados e de falha se mudaram para seus próprios documentos. As mudanças práticas para um dono de registro são pequenas: - `pct`, `rf`, e `ri` foram removidos. - `t` (testing mode) substitui `pct` como chave tudo-ou-nada: `t=y` relata sem enforcer. - `np` define uma política para subdomínios inexistentes, o que bloqueia spoofing de endereços como `abc123.exemplo.com.br`. - `psd` marca domínios de sufixo público, e um tree walk DNS substitui a velha busca Public Suffix List. Registros `v=DMARC1` existentes permanecem válidos. Nada quebra se você não mudar nada hoje. Suporte do provedor pelas novas tags será lançado de forma desigual, então uma tag nova que parece não fazer nada geralmente significa que o receptor ainda não a implementou. A tag `np` é a que vale a pena adotar cedo. Definir `np=reject` enquanto `p` ainda está `none` fecha o caminho de abuso de subdomínio falso sem comprometer o resto do seu mail a enforcement. ## Subdomínios, e por que o padrão herda Um registro DMARC no domínio organizacional se aplica a subdomínios também, a menos que você o sobrescreva com `sp`. Essa herança é útil e também uma armadilha. Se marketing envia de `news.exemplo.com.br` através de um provedor separado, ele herda a política pai. Mude o pai para `p=reject` antes que esse provedor tenha alinhado DKIM e o newsletter cai no chão. Publique um registro `_dmarc.news.exemplo.com.br` separado quando um subdomínio tem sua própria frota de remetentes e seu próprio ritmo de rollout. Uma arquitetura mais limpa separa fluxos por subdomínio desde o início. Mail transacional em um, lifecycle em outro, mail humano na raiz. Cada um recebe suas próprias chaves DKIM, sua própria reputação, e seu próprio registro DMARC. ## Leia o cabeçalho Authentication-Results antes de adivinhar Quando uma mensagem falha, o servidor receptor registra por quê. No Gmail, "Mostrar original" expõe o cabeçalho `Authentication-Results`, e ele diz mais do que qualquer painel. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.provedor-email.net; dkim=pass header.d=provedor-email.net; dmarc=fail (p=NONE) header.from=exemplo.com.br`Leia da esquerda para a direita. SPF passou para `bounce.provedor-email.net`. DKIM passou para `provedor-email.net`. DMARC falhou porque o cabeçalho From diz `exemplo.com.br` e nenhum domínio que passou bata com isso. A nota `(p=NONE)` mostra a política que o receptor viu. Em `none` essa mensagem foi entregue assim mesmo. Em `reject` teria rejeitado com um erro 5.7.x, e o remetente teria ficado sabendo de um cliente. Dois checks pegam a maioria desses casos. Confirme que o valor `header.d` no resultado DKIM é seu domínio. Depois confirme que o domínio `smtp.mailfrom` é seu domínio ou um subdomínio dele. ## SPF tem um limite de lookups que DMARC expõe SPF permite dez lookups DNS por avaliação. Cada `include:` por um provedor gasta alguns deles, e includes aninhados gastam mais. Ultrapasse dez e SPF retorna um erro permanente, que conta como falha. Equipes com cinco ou seis ferramentas de envio atingem isso sem notar, porque falhas de SPF eram invisíveis antes de relatórios DMARC. Uma vez que relatórios `rua` chegam, o padrão é óbvio: uma origem de repente falhando SPF em todos os receptores no dia em que alguém adicionou outro `include:`. Essa é mais uma razão para confiar em alinhamento DKIM como o caminho primário. DKIM sobrevive a maioria dos encaminhamentos, não tem orçamento de lookups, e é atado à mensagem em vez de ao IP conectador. Mantenha SPF válido, mas não construa seu passe DMARC só nele. ## O que DMARC não vai fazer DMARC previne spoofing de domínio exato. Ele não pára domínios parecidos (`examp1e.com.br`), não julga conteúdo, e não corrige uma má reputação de remetente. Um domínio perfeitamente alinhado que envia a listas compradas ainda cai em spam. Também não substitui monitoramento. Alinhamento pode quebrar silenciosamente: uma mudança de DNS remove um seletor DKIM, um provedor gira as chaves, uma nova ferramenta começa a enviar sem seu conhecimento. Relatórios é como você descobre antes de seus usuários. Trate o registro DMARC como qualquer outra config em produção. Ele pertence a version control, mudanças passam por review, e a caixa de correio `rua` precisa de um dono. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Antes de publicar o registro Passe por isso uma vez. Leva menos de uma hora para um domínio único. - Liste cada sistema que envia mail como seu domínio: produto, cobrança, suporte, CRM, marketing, convites de calendário. - Confirme que cada um assina DKIM com seu domínio, não do fornecedor. - Defina um return-path customizado onde o provedor permite. - Escolha um destino `rua` que alguém vá ler. - Comece em `p=none`, e coloque a data em que você planeja revisar no calendário. - Verifique spam rate no Google Postmaster Tools semanalmente durante o rollout. ## Para onde ir daqui Se você nunca olhou seus relatórios, publique `p=none` com um endereço `rua` hoje e leia o que chega em duas semanas. O primeiro relatório quase sempre nomeia pelo menos um remetente que ninguém lembrava. O próximo passo concreto é decidir qual daqueles você mantém. ## FAQ ### DMARC é obrigatório? Para remetentes em massa, efetivamente sim. Google exige um registro DMARC para quem envia mais de 5.000 mensagens por dia para Gmail, e Yahoo exige uma política válida de pelo menos p=none. Enforcement não é obrigatório, mas o registro e o alinhamento são. ### O que significa p=none no DMARC? Significa monitorar apenas. Receptores entregam mail falhando normalmente e enviam relatórios. Satisfaz o mínimo do Gmail e Yahoo mas não dá proteção contra spoofing. ### Um email pode passar SPF e DKIM e ainda falhar DMARC? Sim. DMARC exige que o domínio validado por SPF ou DKIM se alinhe com o domínio From. Mail enviado através de um provedor que assina com seu próprio domínio passa ambos os checks e ainda falha alinhamento. ### Quanto tempo devo ficar em p=none? Tipicamente de duas a quatro semanas de relatórios agregados, tempo suficiente para ver cada remetente legítimo incluindo os de baixo volume. Mude assim que cada fonte legítima mostrar alinhado. ### DMARC afeta a entregabilidade? Indiretamente. Um registro publicado e alinhado é um requisito baseline em Gmail e Yahoo, e falha em alinhamento pode enviar mail para spam ou disparar rejeição sob uma política de enforcement. Não corrige reputação ruim de remetente ou taxas altas de reclamação. ### O que mudou com DMARCbis e RFC 9989? RFC 9989 obsoleta RFC 7489. Remove pct, rf e ri, adiciona t, np e psd, e substitui buscas Public Suffix List por um tree walk DNS. Registros `v=DMARC1` existentes permanecem válidos.