De p=none a p=reject: critérios de saída por etapa no DMARC

A pergunta por trás da maioria dos projetos de DMARC não é como escrever o registro, é quanto tempo ficar em p=none e o que precisa ser verdade antes de avançar. Esperar para sempre deixa o seu domínio aberto a falsificação, e avançar cedo demais manda as suas próprias faturas para o spam. Este guia traz critérios de saída por etapa, um plano para subdomínios, o que costuma quebrar e como voltar atrás. Os limites são o nosso conselho, não parte de nenhum padrão, e os identificamos assim.

A resposta curta#

Fique em p=none por pelo menos um ciclo completo de envio, em geral de duas a quatro semanas, mais se você tem e-mails mensais ou trimestrais, como extratos. Passe para quarantine quando toda origem legítima que você conhece passar no DMARC por uma verificação alinhada de SPF ou DKIM. Passe para reject depois de mais um período em quarantine sem surpresas. Não planeje a rampa em torno de pct=: o padrão atual de DMARC, a RFC 9989, remove essa tag. Ela foi publicada em maio de 2026 e substitui a RFC 7489, a especificação original do DMARC. O básico do registro em si está no guia de configuração do DMARC, que este post não repete.

As etapas e quando sair de cada uma#

Cada etapa abaixo tem um teste de saída. Todo número da tabela é uma regra prática que sugerimos, porque o seu volume e a sua mistura de remetentes determinam o que é realista.

Uma etapa está concluída quando as falhas sem explicação são pequenas e sem graça: algumas mensagens de encaminhadores, listas de e-mail ou origens que você consegue identificar como não sendo suas. Se uma origem com volume real ainda não foi identificada, você não terminou a etapa 2. O roteiro para identificá-las está no guia como ler relatórios DMARC.

Um calendário de exemplo#

Para tornar a tabela concreta, aqui está um cronograma plausível para uma empresa com um ESP, um CRM e uma ferramenta de faturamento. É uma ilustração, não uma promessa.

• Semanas 1 a 4: publique p=none, colete relatórios e monte uma lista de toda origem com o seu responsável. Inclua aquela que envia só no fim do mês.
• Semanas 5 a 8: corrija o alinhamento origem por origem, começando pela maior em volume. Reverifique os relatórios após cada mudança, não só no fim.
• Semana 9: aplique a política em domínios estacionados e que não enviam.
• Semanas 10 a 13: passe o domínio principal para quarantine e observe novas origens com falha toda semana.
• A partir da semana 14: passe para reject se o último mês foi tranquilo e adicione uma regra permanente de que novos remetentes sejam autenticados antes do lançamento.

Se uma origem demora para ser corrigida, o calendário espera por ela. A data é um plano, o teste de saída é a regra.

O que fazer com o pct#

Se você viu conselhos mais antigos, como pct=10, depois 25, 50, 100, aquilo era uma forma de aplicar uma política mais rígida a uma parte do e-mail com falha. A RFC 9989 remove a tag. A própria justificativa dela diz que a tag normalmente não era aplicada com precisão a menos que o valor fosse 0 ou 100. Ela adiciona uma tag t no lugar, com y para "testing" e n (o padrão) para o tratamento normal.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

Com t=y, um receptor que a suporte deve tratar uma mensagem com falha um nível mais leve do que a política diz: quarantine vira none, reject vira quarantine. Não tem efeito em p=none. Duas ressalvas honestas. Primeiro, o suporte à nova tag vai levar tempo para se espalhar, então não dependa dela para proteger você. Segundo, uma rampa percentual nunca foi uma rede de segurança confiável, nem antes da mudança.

Uma forma mais segura de limitar o risco é escalonar por escopo em vez de por porcentagem: aplique a política primeiro em subdomínios e domínios que não enviam, depois no domínio principal, e permaneça em quarantine por algumas semanas antes do reject. Se o seu registro atual ainda contém pct=, você não precisa correr para removê-lo, mas não adicione uma nova rampa que dependa dele.

Subdomínios e domínios que não enviam nada#

O ganho mais rápido vem de domínios que nunca enviam e-mail. Domínios estacionados e marcas aposentadas são alvos favoritos de falsificação, e não têm origens legítimas a quebrar. Publique uma política de aplicação imediatamente, mais um registro SPF que não autoriza nada:

parked.example.com.         TXT  "v=spf1 -all"
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com.  TXT  "v=DMARC1;"

A terceira linha é o registro de autorização. Como o endereço rua= está em um domínio diferente daquele que a política protege, os receptores só enviam relatórios se esse outro domínio publicar um registro TXT chamado <protected-domain>._report._dmarc.<report-domain>. Se você o omitir, ou colocar o endereço rua= no próprio domínio estacionado, os relatórios desse domínio nunca chegam. O guia de relatórios não recebidos trata dessa verificação.

Para subdomínios de um domínio que envia, a política do domínio pai se aplica, a menos que o subdomínio publique o seu próprio registro. A tag sp= define uma política diferente para subdomínios que não têm nenhum. A RFC 9989 também define uma tag np para subdomínios que não existem no DNS, útil contra hostnames inventados. Se você pretende definir sp=reject no domínio pai, confirme antes que cada subdomínio de envio passa, ou dê a ele o seu próprio registro. O guia de subdomínio de envio explica por que cada fluxo de e-mail fica melhor no seu próprio subdomínio desde o início.

O que costuma quebrar quando você aplica a política#

Quase todo incidente de aplicação remonta a um destes. Procure por eles nas etapas 1 e 2, não depois da mudança de política.

• O remetente de que ninguém se lembrava. Uma ferramenta de faturamento, uma plataforma de pesquisas ou um sistema de recrutamento que envia uma vez por mês. Um ciclo completo de relatórios pega a maioria deles, e é por isso que a etapa 1 não pode ser pulada.
• Alinhado no teste, não em produção. Um serviço passa a partir de um pool de IPs de envio e falha a partir de outro. Julgue cada origem pelo volume real ao longo do tempo.
• Encaminhadores e listas de e-mail. O encaminhamento quebra o SPF, e listas que editam uma mensagem quebram o DKIM. Você não consegue impedir isso totalmente. Espere uma pequena taxa residual de falha e decida de antemão que ela é aceitável. A RFC 9989 é explícita sobre isso: um domínio que publica p=reject não deve depender só do SPF e deve assinar o seu e-mail com DKIM, e um domínio cujos usuários postam em listas de e-mail não deve publicar p=reject de jeito nenhum. Para esse tipo de domínio ela sugere pelo menos um mês em p=none, depois um período igualmente longo em p=quarantine, antes de comparar resultados. Nossas janelas mais curtas acima servem a domínios que enviam principalmente e-mail de sistema, então alongue-as se a sua equipe posta em listas públicas.
• Uma ferramenta nova adicionada depois que você aplica a política. O time de marketing contrata uma plataforma numa terça-feira e o e-mail dela começa a voltar como bounce. Isso é um problema de processo: combine que novos remetentes tenham a autenticação configurada antes do primeiro uso.
• Alinhamento estrito deixado ligado. adkim=s ou aspf=s transformam uma configuração relaxada que funcionava em falhas. O guia de diagnóstico de alinhamento percorre cada causa.

Acompanhando a mudança com números reais#

Durante as etapas 2 a 4, você quer uma única visão: para cada origem, que parcela do seu e-mail passa no DMARC e quais origens são novas nesta semana. Os Relatórios DMARC da Qualisend mostram isso por domínio, em 7, 30 ou 90 dias, e enviam um e-mail no dia seguinte a um domínio ter pelo menos 10 mensagens falhando em SPF e DKIM, ou uma origem nova com pelo menos 5 mensagens falhando. Eles não têm nota de "pronto para reject", então o julgamento é seu: observe cada origem legítima chegar a 100% e permanecer lá. Os dados agregados também chegam com um ou dois dias de atraso e cobrem apenas os receptores que enviam relatórios, então uma semana tranquila não prova que nada falhou.

O monitoramento de saúde do domínio da Qualisend lista p=none como um aviso nos problemas de um domínio e alerta sobre pct abaixo de 100, o que ajuda se você gerencia vários domínios e quer ver quais ainda não avançaram.

Reversão#

Planeje o caminho de volta antes de avançar. Três hábitos tornam a reversão rápida.

1. Guarde o texto do registro anterior nas suas notas de mudança, para que reverter seja copiar e colar.
2. Reduza o TTL do registro _dmarc para alguns minutos mais ou menos um dia antes de uma mudança de política e depois aumente de novo quando tudo estiver estável. Os receptores guardam o DNS em cache, e um TTL longo atrasa a sua própria reversão.
3. Volte um passo, não tudo. Se uma origem legítima começar a falhar no reject, volte para quarantine enquanto a corrige. As mensagens já rejeitadas nessa janela costumam voltar como bounce ao remetente e não são recuperáveis do lado do receptor, então é melhor manter a primeira janela de aplicação curta e vigiada.

Onde a aplicação da política se conecta com todo o resto#

Chegar a quarantine ou reject no domínio organizacional também é a precondição para logotipos BIMI, e o guia de BIMI lista o que o padrão pede. Isso não elimina a necessidade dos outros fundamentos nos requisitos do Google e do Yahoo. O quadro completo de como a autenticação se encaixa com a reputação está no guia de entregabilidade.

Uma política DMARC aplicada prova que o e-mail é seu, mas não consegue transformar uma lista ruim em boa. O plano gratuito na página de preços inclui 100 créditos que rodam a verificação completa em uma lista. Um domínio protegido ainda precisa de uma lista saudável para chegar à caixa de entrada.