DMARC quarantine e reject: como sair do p=none sem perder e-mails legítimos

1. O que p=none, quarantine e reject pedem aos destinatários

A tag p do registro DMARC em _dmarc.example.com diz o que você gostaria que os destinatários fizessem com mensagens cujo domínio From falha no DMARC, ou seja, quando nem o SPF nem o DKIM passaram para um domínio alinhado a ele. É um pedido, não uma ordem. A RFC 9989, o padrão DMARC publicado em maio de 2026 que substitui a RFC 7489, deixa a decisão final para a política local de cada destinatário.

Dois pontos definem a implantação. Primeiro, p=none não protege nada sozinho; ele gera relatórios, e só se o registro tiver um endereço rua. Segundo, nem todos os destinatários aplicam a política do mesmo jeito. A RFC 9989 orienta que não recusem uma mensagem só porque a política diz reject, e alguns colocam essa mensagem em quarentena, então a mesma mudança pode ter efeitos diferentes em cada provedor de e-mail. Planeje a transição como uma sequência de passos pequenos e reversíveis, e não como um interruptor.

Os grandes provedores de e-mail já exigem um registro DMARC de quem envia em massa, mas aceitam p=none. O guia para verificar SPF e DMARC resume essas exigências e explica cada tag do registro.

2. Como ler os relatórios agregados do DMARC (rua)

São os relatórios agregados que tornam a mudança segura. Inclua um endereço de relatórios no registro, por exemplo rua=mailto:dmarc-reports@example.com, e os destinatários que enviam relatórios vão mandar um arquivo XML compactado, normalmente referente a um dia UTC, com cada endereço IP que enviou mensagens com o seu domínio no From e o resultado de cada um. O formato é definido pela RFC 9990. Um nome de arquivo como receiver.example!example.com!1791590400!1791676800.xml.gz indica o destinatário que reporta, o seu domínio e o início e o fim do período em timestamps Unix.

Cada <record> do arquivo agrupa mensagens por origem e resultado. Estes são os campos que mais importam:

A diferença entre a última linha e policy_evaluated é a lição mais útil aqui. Uma plataforma de newsletter pode mostrar um DKIM pass em auth_results para mailer.example.net e mesmo assim falhar no DMARC, porque esse domínio não está alinhado com example.com. Só policy_evaluated mostra a conclusão do DMARC.

Leia os relatórios ao longo de várias semanas, não de um dia: faturas mensais, newsletters trimestrais e avisos de renovação anual chegam no seu próprio ritmo. Com algum volume, o XML bruto fica cansativo; um parser ou ferramenta de relatórios que agrupe as linhas por origem, alinhamento e disposição a cada dia torna a análise viável. Nem todo destinatário envia relatórios agregados, então uma semana tranquila não significa um domínio tranquilo. Se o endereço rua estiver em outro domínio organizacional, esse domínio precisa publicar um registro de autorização como example.com._report._dmarc.reports.example.net começando com v=DMARC1; caso contrário, os destinatários ignoram o endereço (RFC 9990, seção 4).

3. Encontre todos os remetentes legítimos antes de aplicar a política

Aplicar a política só é seguro quando você conhece cada sistema que coloca o seu domínio no From. Monte a lista pelos dois lados: o que a empresa usa e o que os relatórios mostram. Fontes comuns:

• A plataforma de e-mail que a equipe usa no dia a dia.
• Marketing e newsletters, inclusive aquela ferramenta de campanhas antiga em que alguém ainda entra.
• E-mails transacionais da sua aplicação: confirmações de cadastro, redefinição de senha, recibos.
• Ferramentas de negócio: CRM, faturamento e cobrança, atendimento, RH e recrutamento, agenda e assinatura eletrônica.
• Formulários e plugins do site que enviam como noreply@example.com.
• Dispositivos e scripts: scanners, alertas de monitoramento, tarefas agendadas e relays próprios.

Depois, associe cada origem dos relatórios a um item da lista. Uma consulta reversa do IP (dig +short -x 192.0.2.10) costuma revelar o provedor, e a documentação dele explica o include de SPF e a configuração de DKIM que ele suporta. Registre o resultado em uma tabela como esta:

A última linha é o objetivo do exercício. Quando todas as fontes conhecidas passam, o que continua falhando é sobretudo e-mail falsificado ou mal configurado, e é exatamente isso que a política deve barrar. As fontes que enviam de vez em quando são as mais esquecidas, então pergunte ao financeiro, ao RH e ao atendimento quais ferramentas eles usam antes de confiar em um mês tranquilo.

4. Alinhamento de SPF e DKIM: relaxado ou estrito

O DMARC passa quando o SPF ou o DKIM passa e o domínio verificado está alinhado com o domínio From. Um resultado alinhado basta. No SPF, o domínio verificado é o do remetente do envelope (RFC 7208); no DKIM, é o valor d= de uma assinatura válida (RFC 6376). As tags aspf e adkim definem o quanto eles precisam coincidir:

• Relaxado (r, o padrão): os dois domínios compartilham o mesmo domínio organizacional, então bounce.example.com e news.example.com estão alinhados com example.com.
• Estrito (s): os domínios precisam ser idênticos.

A RFC 9989 determina o domínio organizacional com uma varredura da árvore DNS (DNS Tree Walk), consultando registros _dmarc do nome completo para cima, em vez da lista de sufixos públicos usada pela RFC 7489.

A RFC 9989 observa que quase todos os donos de domínio acham o alinhamento relaxado suficiente. O estrito quebra o padrão comum de um subdomínio de bounce por provedor, então mantenha o padrão, a menos que haja um motivo concreto, como subdomínios delegados a fornecedores, em que o alinhamento relaxado deixaria uma mensagem autenticada para vendor.example.com passar por example.com. Seja qual for a escolha, faça do DKIM o método alinhado de todas as fontes. O SPF quebra quando a mensagem é encaminhada, porque o servidor que encaminha não está no seu registro; uma assinatura DKIM em geral sobrevive ao encaminhamento enquanto a mensagem não é alterada.

5. Implantação em etapas: o pct saiu, use t=y

Guias antigos escalonam com pct: p=quarantine; pct=10, depois 25, 50 e 100, para que a política cubra uma amostra crescente das mensagens que falham. Pela RFC 7489, o que ficava fora da amostra recebia a política imediatamente inferior. A RFC 9989 removeu a tag; o apêndice A.6 explica que valores diferentes de 0 e 100 quase nunca eram aplicados com precisão e que o desvio variava muito entre implementações.

A remoção tem uma armadilha. A RFC 9989 manda os destinatários ignorarem tags que não conhecem, então um destinatário que segue o novo padrão lê p=quarantine; pct=25 como um simples p=quarantine e aplica a política a todas as mensagens que falham. Não dá mais para confiar em um pct parcial para limitar o impacto.

O substituto é o indicador de teste t. Com t=y, os destinatários são convidados a aplicar um nível abaixo da política publicada: p=quarantine; t=y é tratado como none, e p=reject; t=y como quarantine. Os relatórios continuam chegando normalmente, e o destinatário pode registrar o desvio com o motivo policy_test_mode. A RFC 9989 apresenta t=y e t=n como equivalentes de pct=0 e pct=100.

Durante a transição, alguns destinatários ainda implementam só a RFC 7489 e ignoram t, enquanto os mais novos ignoram pct. Como pct=0 nas regras antigas e t=y nas novas pedem o mesmo tratamento, você pode publicar os dois durante o teste:

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Acompanhe os relatórios por algumas semanas e depois remova as duas tags para que p=quarantine valha por completo. Repita o padrão antes do reject: p=reject; t=y; pct=0 pede quarentena, e retirar as duas tags ativa a recusa.

Você também pode escalonar por fluxo de e-mail em vez de por porcentagem. Um subdomínio como news.example.com pode ter o próprio registro DMARC e entrar na aplicação antes ou depois do domínio principal; o próprio exemplo de implantação da RFC 9989 testa p=quarantine com t=y em um subdomínio antes de endurecer a política.

6. Política de subdomínios: sp e np

Um registro DMARC em example.com também cobre os subdomínios que não têm registro _dmarc próprio. Duas tags permitem que a política dos subdomínios seja diferente de p:

Algumas regras deixam o comportamento previsível. O sp só tem efeito no registro do domínio organizacional; um subdomínio que publica o próprio registro segue o p desse registro. Definir np=reject enquanto o p ainda está em none é um primeiro passo de baixo risco: mensagens falsificadas vindas de nomes inventados como billing-support.example.com são recusadas, e os destinatários que não suportam np simplesmente usam sp ou p. Antes de contar com isso, confira se cada subdomínio do qual você realmente envia tem pelo menos um registro DNS, para que conte como existente. E lembre que o SPF não é herdado: cada nome usado como remetente do envelope precisa do próprio registro SPF, independentemente da política DMARC.

7. Um cronograma realista de p=none a p=reject

Nenhum cronograma serve para todos os domínios, e a RFC 9989 avisa que podem ser necessários muitos meses de relatórios até que o dono do domínio esteja pronto para aplicar a política. Para domínios cujos usuários participam de listas de discussão, ela sugere pelo menos um mês em p=none e outro tanto em p=quarantine, comparando os resultados, e mesmo assim recomenda que esses domínios não publiquem reject. Uma empresa com poucos serviços de envio poderia planejar assim:

Antes de cada mudança, reduza o TTL do registro TXT _dmarc, por exemplo para 300 segundos, com pelo menos um período do TTL antigo de antecedência, para que um retorno chegue rápido aos resolvers. Faça as mudanças no começo da semana, avise a equipe de atendimento sobre o que observar e mantenha um histórico datado de cada valor publicado. A RFC 9989 exige que todo domínio que publica p=reject assine suas mensagens com assinaturas DKIM válidas em vez de depender só do SPF. Reject não é o único bom destino: para um domínio que a equipe usa em listas de discussão, uma quarentena bem monitorada pode ser a melhor escolha, enquanto um domínio usado só para faturas e notificações é um candidato natural ao reject.

8. Quando e-mails legítimos falham: diagnosticar, corrigir, voltar atrás

Cedo ou tarde, um relatório ou um colega vai mostrar e-mails legítimos falhando. Encontre as linhas correspondentes nos relatórios agregados, ou peça os cabeçalhos completos de uma mensagem afetada e leia o cabeçalho Authentication-Results; depois compare o padrão:

Se a falha for grande, ou atingir e-mails ligados a receita, como recibos e redefinições de senha, volte atrás primeiro e investigue depois: acrescente t=y e pct=0, ou retorne à política anterior. Com um TTL curto, a mudança chega à maioria dos resolvers em minutos. Uma recusa 5xx é definitiva, então a mensagem já recusada não será entregue depois; diga à equipe afetada quais mensagens precisam ser reenviadas. Em seguida, corrija a fonte, acompanhe alguns dias de relatórios até ela passar e avance de novo. Encaminhadores e listas que preservam os resultados de autenticação com ARC (RFC 8617) ajudam, mas a RFC 9989 observa que nenhum mecanismo desse tipo é amplamente usado ainda; por isso, DKIM em todas as fontes continua sendo a correção confiável.

9. Como conferir o registro DMARC publicado

Confira o que está realmente publicado, e não o que o painel do seu DNS mostra:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

As duas primeiras linhas mostram o que os resolvers retornam; a última consulta diretamente um servidor autoritativo, que mostra a mudança antes de as respostas em cache expirarem. Confirme que:

• existe exatamente um registro TXT em _dmarc começando com v=DMARC1; se houver dois, os destinatários descartam ambos e o domínio se comporta como se não tivesse DMARC;
• v=DMARC1 é a primeira tag e p tem o valor none, quarantine ou reject;
• a caixa do rua existe e, se estiver em outro domínio, está autorizada com um registro _report._dmarc;
• as tags estão separadas por ponto e vírgula, sem aspas tipográficas nem caracteres soltos copiados de um documento.

Depois, envie uma mensagem de cada serviço para uma caixa que você controla e leia o cabeçalho Authentication-Results: dmarc=pass junto com o seu domínio From é o veredito do destinatário, e é ele que vale.

Para uma visão rápida de fora, o verificador gratuito de registros SPF e DMARC lê o registro _dmarc no nome exato que você digitar, sem recorrer ao domínio pai. Ele aponta um registro ausente (médio, se o host tiver registros MX) e p=none (baixo, como modo de monitoramento); quarantine e reject não geram sinal. Ele não lê seus relatórios nem avalia sp, np, t, pct, rua ou o alinhamento. A mesma verificação de DNS de e-mail também lê SPF, MTA-STS e CAA, e é uma das oito verificações passivas do snapshot gratuito de prontidão para lançamento, que não exige cadastro e devolve uma pontuação com o resultado de cada verificação. Para uma revisão contínua, veja o guia de segurança de e-mail e DNS.