# DMARC de p=none a p=reject em 30 dias URL canônica: https://brew.new/pt-br/blog/dmarc-p-none-to-reject-in-30-days Por Thomas Park Publicado em 2026-10-04 Atualizado em 2026-10-04 O DMARC é um registro TXT em `_dmarc.` 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift), 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](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) 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](https://www.rfc-editor.org/rfc/rfc9989.html), uma proposta de padrão (Proposed Standard) que também torna obsoleta a RFC 9091, mais a [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html), 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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 `._domainkey.`. Uma ferramenta que assina com `d=vendor-mail.example` passa no DKIM e falha no DMARC. A [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) diz que quem assina precisa usar chaves RSA de pelo menos 1024 bits e deveria usar 2048. As [diretrizes para remetentes do Google](https://support.google.com/mail/answer/81126) 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ê. ```dns 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](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) 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: | Modo | Tag | Domínio aprovado no SPF/DKIM | Domínio do From | Alinhado? | |---|---|---|---|---| | Relaxado (padrão) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Sim, mesmo domínio organizacional | | Estrito | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Não, os nomes precisam ser idênticos | | Qualquer um | | `vendor.example.net` | `example.com` | Não | 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 ![Linha do tempo de 30 dias do DMARC em quatro fases: dias 1 a 7 em p=none com relatórios rua, dias 8 a 14 corrigindo remetentes, dia 15 em p=quarantine, dia 22 em p=reject e, depois, BIMI a partir do dia 30, com o registro TXT exato de cada fase.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *O registro de cada fase. Avance só depois de uma semana de relatórios limpos.* | Dias | Política | O que fazer | Critério para avançar | |---|---|---|---| | 1 a 7 | `p=none` | Publique com `rua` e liste todas as fontes | 7 dias de relatórios do Google, do Yahoo e da Microsoft | | 8 a 14 | `p=none` | Corrija o DKIM e o SPF e desative remetentes sem uso | Toda fonte legítima passa no SPF ou no DKIM alinhado | | 15 a 21 | `p=quarantine` | Fique de olho em mensagens legítimas em quarentena | 7 dias sem nenhuma fonte legítima falhando | | 22 a 30 | `p=reject` | Continue lendo os relatórios e adicione `np=reject` | Estável por uma semana | | 30+ | `p=reject` | Comece o BIMI | Certificado emitido | 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 ```dns _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.` 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](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` 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: | Padrão no relatório | Causa provável | O que fazer | |---|---|---| | DKIM ou SPF alinhado aprovado | Configuração correta | Nada | | DKIM e SPF aprovados para domínios do fornecedor | Ferramenta SaaS usando a própria identidade | Ative o DKIM personalizado | | DKIM alinhado aprovado, SPF reprovado, IP de provedor de e-mail ou de lista | Encaminhamento ou lista de discussão | Em geral, nada. O DKIM alinhado resiste ao encaminhamento | | Sem DKIM, SPF reprovado, IPs sem origem identificável | Spoofing | Nada. É isso que o `p=reject` bloqueia | 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](https://support.google.com/mail/answer/14229414) 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 ```dns _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 ```dns _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: | Requisito | Detalhe | Fonte | |---|---|---| | Política DMARC | `p=quarantine` ou `p=reject` no domínio organizacional e no domínio do From | Rascunho do BIMI | | Política de subdomínios | Se `sp` estiver publicado, não pode ser `none` | Rascunho do BIMI | | Percentual | Com quarantine, `pct` não pode ficar abaixo de 100 | Rascunho do BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, um ``, sem scripts nem referências externas, sem `x=` ou `y=` na raiz | BIMI Group | | Certificado | O Gmail exige um VMC (marca registrada, selo de verificação) ou um CMC (sem marca registrada, sem selo) | Google | O [rascunho do BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/) 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](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). O registro, segundo o [guia de implementação do BIMI Group](https://bimigroup.org/implementation-guide/): ```dns 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. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Limite de volume | Perto de 5.000 por dia para contas pessoais do Gmail, por domínio principal, permanente depois de atingido | Remetentes em massa, sem número definido | Mais de 5.000 por dia para outlook.com, hotmail.com e live.com, por domínio do From | | SPF e DKIM | Os dois | Os dois | Os dois precisam passar | | DMARC | Registro obrigatório, `p=none` aceito | Pelo menos `p=none`, `rua` fortemente recomendado | Pelo menos `p=none` | | Alinhamento | SPF ou DKIM | SPF ou DKIM, o relaxado serve | SPF ou DKIM | | Em caso de falha | Rejeições temporárias e permanentes desde novembro de 2025 | Não informado | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Fontes: as [diretrizes para remetentes do Google](https://support.google.com/mail/answer/81126) e as [perguntas frequentes](https://support.google.com/mail/answer/14229414), as [boas práticas para remetentes do Yahoo](https://senders.yahooinc.com/best-practices/) e, da Microsoft, o [comunicado de abril de 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) e a [página de suporte do erro 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). 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](/pt-br/blog/agent-email-deliverability) e o nosso [guia de entregabilidade](/pt-br/blog/email-deliverability). ## DMARC em um domínio de envio do Brew A [configuração de domínio](https://docs.brew.new/get-started/verify-your-sending-domain) 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: ```dns ; 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](/pt-br/blog/transactional-emails), 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](https://bimigroup.org/understanding-bimi-certificate-types/) diz que alguns provedores, entre eles o Yahoo e o Fastmail, também exibem logos autodeclarados, sem certificado.