Infraestrutura de e-mail
DMARC de p=none para p=reject, com segurança.
Passar o DMARC de p=none para p=reject é o que de fato impede que outros falsifiquem o seu domínio — e p=none, apesar de publicado, não oferece nada dessa proteção. O caminho seguro não é um calendário, mas uma sequência: publique p=none, leia os relatórios agregados, faça cada remetente legítimo passar SPF ou DKIM com alinhamento, e então avance por p=quarantine até p=reject só quando o e-mail que ainda falha for e-mail que você não autoriza. A pressa bloqueia e-mail real; feito a partir dos relatórios, aplicar é uma mudança controlada que ainda libera o BIMI.
Em resumo
- p=none é monitoramento, não proteção. Em p=none qualquer um pode falsificar o seu domínio e os receptores entregam mesmo assim.
- Os relatórios marcam o ritmo, não o calendário. Avance só quando o e-mail legítimo passa; nunca enquanto falha e-mail real.
- Os remetentes de terceiros quebram mais. Marketing, CRM e fornecedores transacionais são a causa principal de falhas DMARC.
- O DMARCbis removeu o pct. A implantação em etapas agora é operacional, não uma porcentagem no registro; np e t são as novas tags.
- p=reject libera o BIMI e detém a falsificação — mas não coloca por si só o e-mail na caixa de entrada.
Por que p=none não está te protegendo de verdade?
Um registro DMARC em p=none diz aos servidores receptores para não tomar nenhuma ação sobre as mensagens que falham a autenticação. Cada mensagem é entregue normalmente, passe ou falhe; a única função do registro é gerar os relatórios agregados que mostram quem envia e-mail como o seu domínio. Isso faz de p=none uma ferramenta de descoberta, não uma defesa — e um domínio que fica ali de forma permanente está vendo a falsificação acontecer sem detê-la.
Isto não é teórico. Audite um domínio em p=none e os seus relatórios mostram rotineiramente e-mail de IPs em países onde a organização não tem presença, enviado por servidores que ela nunca usou. Essas mensagens falsificadas são marcadas como spam e denunciadas como phishing pelos destinatários, e os provedores de caixa integram esse comportamento na reputação do seu domínio — eles não distinguem entre o e-mail que você enviou e o que outro enviou em seu nome. Ficar em p=none deixa esse dano se acumular.
A magnitude da lacuna impressiona. Entre os domínios engajados o bastante para rodar uma ferramenta de monitoramento, cerca de quarenta por cento ainda ficam permanentemente em p=none, e dos dez milhões de domínios com mais tráfego só uma pequena porcentagem aplica quarantine ou reject. Alcançar a aplicação, portanto, faz mais que te proteger — coloca você à frente da imensa maioria da internet que publicou DMARC mas nunca o ativou.
Qual a aparência de um registro DMARC em aplicação?
O destino é um único registro TXT em _dmarc do seu domínio. As partes importantes são a
política em si, as políticas de subdomínios, os modos de alinhamento e um endereço de relatórios que
você de fato leia. Aqui está um registro em aplicação total, escrito para estar pronto para o
DMARCbis — repare que não há tag pct, porque a implantação em etapas já não é algo que se expressa no
registro.
# _dmarc.example.com — registro TXT em aplicação total (pronto para DMARCbis)
v=DMARC1; p=reject; sp=reject; np=reject;
adkim=s; aspf=r;
rua=mailto:dmarc-agg@example.com;
ruf=mailto:dmarc-forensic@example.com; fo=1
# pct some no DMARCbis — a implantação em etapas agora é operacional, não uma tag
Mantenha exatamente um registro DMARC nesse nome — vários registros TXT fazem os receptores ignorarem
a política por completo. O endereço rua é o que torna possível toda a migração, porque
sem relatórios agregados você não consegue ver quais remetentes passam e quais falham, e não pode
aplicar o que não consegue ver.
A especificação de 2026
Quais tags DMARC mudaram no DMARCbis?
O DMARCbis — RFC 9989 / 9990 / 9991 (replaces RFC 7489) — substitui o RFC 7489. Os seus registros v=DMARC1 — there is no "DMARC2" seguem válidos; algumas tags se moveram.
| Tag | O que faz | Status no DMARCbis |
|---|---|---|
| p | Política do próprio domínio organizacional: none, quarantine ou reject. | Sem mudança |
| sp | Política para subdomínios existentes. Se você omite, os subdomínios herdam p. | Sem mudança |
| np | Política para subdomínios inexistentes — fecha a falsificação de subdomínios que você nunca publicou. | Nova no DMARCbis |
| t | Modo de teste binário; rebaixa a aplicação um nível em vez de uma porcentagem. | Nova (substitui a intenção do pct) |
| pct | Implantação em etapas por porcentagem. Os receptores agora tratam pct<100 como pct=100. | Removida |
| rua / ruf | Para onde vão os relatórios agregados e forenses. Mantenha rua em cada registro. | Sem mudança |
A mudança que mais importa para uma migração é a remoção do pct. Era o único mecanismo do
protocolo para a implantação em etapas, e era usado tão poucas vezes corretamente que a especificação o
retirou; um receptor DMARCbis agora trata pct<100 como se fosse 100. A consequência
prática é que a implantação em etapas agora é totalmente operacional — você avança corrigindo
remetentes e observando relatórios, não girando um botão de porcentagem. A nova tag t
oferece um modo de teste binário, mas rebaixa a aplicação um nível em vez de aplicá-la a uma fração do
e-mail.
A migração
O caminho em etapas do monitoramento à aplicação
Seis fases, cada uma condicionada pelo que os seus relatórios mostram e não por quanto tempo passou. A pausa após um problema é a parte mais importante.
- 1
Publique p=none e colete relatórios
Comece em p=none com um endereço rua válido. Os receptores não agem mas te enviam relatórios agregados mostrando cada IP que envia como o seu domínio — este é o seu período de descoberta, não um ajuste de proteção.
- 2
Inventarie cada remetente legítimo
A partir dos relatórios, liste cada sistema que envia por você: automação de marketing, CRM, ticketing, ESP transacional e aplicações legadas. Os remetentes de terceiros são a causa mais comum de falhas DMARC, então encontre-os agora.
- 3
Corrija o alinhamento de SPF e DKIM
Faça cada remetente passar DKIM e SPF com alinhamento ao seu domínio From visível. Vigie o limite de 10 consultas DNS do SPF, os CNAMEs de DKIM quebrados após migrações e as instruções de fornecedor que simplesmente estão erradas até serem corrigidas.
- 4
Passe para p=quarantine e segure
Quando os relatórios mostrarem o seu e-mail legítimo passando, avance para quarantine. O e-mail que falha cai agora no spam em vez da caixa de entrada, então fique aqui tempo suficiente para capturar remetentes semanais e agendados, não só os diários.
- 5
Avance para p=reject quando as falhas estiverem limpas
Quando o único e-mail que ainda falha for e-mail que você não autoriza, passe para reject. Considere p=reject com sp=quarantine brevemente para dar aos subdomínios um pouso mais suave, e então aperte sp quando estiverem limpos.
- 6
Continue monitorando após a aplicação
A aplicação não é configurar e esquecer. Novas ferramentas, migrações de plataforma e aquisições reintroduzem falhas em silêncio; continue lendo os relatórios agregados para que um domínio alinhado há seis meses não saia de conformidade.
A única regra sob os seis passos: se uma fonte falha depois de você apertar a política, pare. Corrija a fonte, espere relatórios frescos e então continue. Tratar a rampa como uma corrida é como se bloqueia e-mail legítimo e como uma reversão em pânico desfaz meses de progresso.
Os remetentes de terceiros que quebram a aplicação
Se uma migração falha, a causa quase sempre é um remetente que você esqueceu que tinha. Os relatórios os trazem à luz, mas só se você os ler: uma plataforma de marketing adicionada ano passado, um help desk que envia em seu nome, um sistema de cobrança num servidor legado, o domínio antigo de uma aquisição que ainda envia faturas. Cada um tem que passar DKIM ou SPF com alinhamento ao seu domínio From visível antes de você apertar a política, e cada um tende a falhar do seu jeito silenciosamente específico.
O SPF é limitado a dez consultas DNS, e esse teto é fácil de estourar à medida que você acopla ferramentas. Some um CRM, um help desk, uma plataforma de marketing e um provedor transacional, e os includes encadeados podem passar de dez, ponto em que o SPF devolve um erro permanente e cai direto em falhas DMARC para e-mail legítimo. A correção é auditar e achatar o registro, mantendo-o dentro do limite, e tirar do SPF raiz os provedores que enviam dos seus próprios subdomínios onde a plataforma permitir.
O DKIM tem os seus próprios modos de falha que se escondem até a aplicação pegá-los. Assinaturas configuradas corretamente no início se quebram durante uma migração — muda um provedor de site, troca um CRM, o DNS se muda para outro host — e ninguém verifica se os registros DKIM vieram junto. Os registros são aplicados a um subdomínio www em vez da raiz, valores de TTL provocam falhas de validação em receptores rígidos, e as instruções CNAME do fornecedor simplesmente estão erradas até o fornecedor emitir valores corrigidos. Nada disso aparece enquanto você está em p=none; tudo bloqueia e-mail real no momento em que você chega a quarantine, que é justo por que a fase de monitoramento existe.
O que alcançar a aplicação libera
A aplicação vale o cuidado que custa, e não só porque detém a falsificação. Uma política reject é a condição prévia para o BIMI, o padrão que coloca o seu logotipo verificado ao lado do e-mail autenticado nas caixas compatíveis — um sinal de confiança visível que eleva o reconhecimento e, por várias medidas, o engajamento. O BIMI precisa do seu DMARC em quarantine ou reject antes de funcionar, e o selo verificado do Gmail quer um Verified Mark Certificate; a barreira baixou há pouco porque o Gmail agora também aceita um Common Mark Certificate, que não exige uma marca registrada.
O cenário de conformidade também premia a aplicação. Além das regras de remetente em massa do Gmail, Yahoo e Microsoft, uma lista crescente de frameworks espera uma política reject: os domínios governamentais de vários países a exigem, e os contextos de pagamento e federais cada vez mais a requerem em vez de só recomendá-la. Um domínio em p=reject não está só protegido da falsificação; está posicionado à frente da direção regulatória em vez de correr para alcançá-la depois.
Há ainda um dividendo de reputação. Como o e-mail falsificado enviado em seu nome danifica a reputação do seu domínio quer você o tenha enviado ou não, fechar esse canal protege a entregabilidade do e-mail que você de fato envia. A mesma aplicação que impede um atacante de falsificar o seu departamento de cobrança impede também que o spam dele arraste as suas faturas legítimas para o spam — a proteção e o benefício de entregabilidade são a mesma ação vista de dois lados.
E os subdomínios e as tags sp e np?
Os subdomínios são onde muitos projetos de aplicação vazam em silêncio. Se você omite a tag
sp, os subdomínios herdam a sua política p automaticamente — então uma raiz
em p=reject também rejeita por cada subdomínio, que costuma ser o que você quer. A má configuração a
caçar é a oposta: p=reject junto a sp=none, que tranca o seu domínio raiz
enquanto deixa cada subdomínio falsificável. sp governs existing subdomains; np governs non-existent ones. Omit sp and subdomains inherit p. The p=reject with sp=none mismatch is the misconfiguration to watch.
O DMARCbis adiciona np para subdomínios que não existem de jeito nenhum. Um atacante pode
falsificar e-mail de um subdomínio que você nunca criou, e sem np um receptor recorre à sua política sp
ou p para esses nomes. Pôr np=reject fecha essa lacuna, mas teste primeiro — alguns
serviços levantam subdomínios dinâmicos, e um np=reject geral pode pegar e-mail legítimo que você havia
esquecido. Sob o novo DNS Tree Walk, os receptores encontram o seu domínio organizacional subindo pela
árvore DNS em vez de consultar a Public Suffix List, o que não muda nada no dia a dia mas pode importar
em hierarquias de domínio profundas.
Uma orientação do DMARCbis merece menção direta: The spec explicitly advises against p=reject for domains with active mailing-list traffic, to avoid breaking subscribers. Se a sua gente publica em listas de projetos de código aberto, fóruns do setor ou boletins de associações a partir do seu domínio principal, um reject total pode quebrar essas mensagens para os assinantes. A correção habitual é enviar o tráfego de listas de um subdomínio dedicado com a sua própria política, mais suave, mantendo o domínio raiz rígido.
Uma armadilha do DMARCbis merece o seu próprio aviso, porque surpreende administradores cuidadosos. A
nova tag de teste t=y pretende deixar você sinalizar «ainda estou testando a aplicação»
sem aplicar a política completa — mas só funciona em receptores que já entendem o DMARCbis. Para a
grande população de receptores que ainda rodam a especificação anterior em 2026, t é uma
tag desconhecida, então a ignoram e aplicam o seu p=reject diretamente, sem rebaixamento.
O resultado são duas populações de receptores se comportando de forma diferente diante do mesmo
registro: uns tratando o seu e-mail como teste, outros rejeitando as falhas de cara. Se você recorre a
t=y esperando um lançamento suave universal, não vai conseguir, e o caminho mais seguro continua sendo
a rampa operacional — prove que os seus remetentes passam e então se comprometa com a política em vez
de confiar numa tag de teste cujo efeito depende de quem a lê.
A rampa
Ler a rampa como um espectro
Três estados de política, e o portão que você deve cruzar antes de se mover para a direita.
O portão entre cada estado é a mesma pergunta: quais sistemas legítimos ainda falham DMARC? Em p=none você responde a partir dos relatórios; em p=quarantine confirma que a resposta é estável; em p=reject as únicas falhas que sobram deveriam ser e-mail que você nunca autorizou. Lido da esquerda para a direita, o espectro vai da pura visibilidade sem proteção à proteção total — e o avanço para a direita se ganha com relatórios limpos, nunca com uma data no calendário.
Onde nós estamos
Hospedamos infraestrutura de envio, então alcançar a aplicação importa para nós: o e-mail enviado de infraestrutura limpa e bem autenticada é o que torna uma política reject segura em primeiro lugar. Mas a migração em si é sua, guiada pelos seus relatórios, e o conselho honesto é do tipo pouco vistoso — vá devagar, corrija remetentes antes de apertar, e nunca avance uma etapa para cumprir um prazo. Um domínio empurrado a p=reject que bloqueia as próprias faturas não melhorou a sua segurança; criou uma interrupção.
Se você gerencia o seu envio conosco, vamos garantir que os seus fluxos passem SPF e DKIM com alinhamento e manter a sua reputação limpa o bastante para que aplicar seja um não-evento. Se você auto-hospeda ou envia por um ESP, a mesma sequência se aplica seja quem for que opere os servidores: publique p=none, leia os relatórios, corrija cada remetente legítimo e suba a política só à medida que os dados permitirem. A recompensa no fim é real — falsificação detida, reputação protegida e BIMI ao alcance.
Perguntas
Respondidas com clareza
As perguntas que os times fazem antes de apertar uma política DMARC em produção.
Quanto tempo leva para ir de p=none a p=reject?
Não há prazo fixo — quem marca são os seus relatórios, não o calendário. Um domínio B2B pequeno com poucos remetentes pode percorrer as etapas em algumas semanas; uma organização grande com muitas plataformas de terceiros, subdomínios e sistemas agendados costuma precisar de uma semana ou mais em cada etapa para capturar os padrões normais de envio. A única regra que importa: nunca avance uma etapa enquanto ainda falha e-mail legítimo. A pressa é exatamente como os times bloqueiam e-mail real e revertem para p=none, às vezes para sempre.
O que mudou com o DMARCbis em 2026?
O DMARCbis é a revisão de 2026 publicada como RFC 9989, 9990 e 9991, que substitui o RFC 7489 original. Os seus registros v=DMARC1 existentes seguem válidos — não há «DMARC2». As mudanças principais são a remoção da tag pct (então não há mais implantação em etapas dentro do protocolo), a adição de np para subdomínios inexistentes e t para modo de teste, e um DNS Tree Walk que substitui a Public Suffix List para encontrar o seu domínio organizacional. A especificação também desaconselha agora explicitamente p=reject para domínios com tráfego ativo de listas de discussão.
O que a tag np faz, e eu preciso dela?
np define a política para subdomínios que não existem de jeito nenhum — os que você nunca criou. Um atacante pode falsificar e-mail de inventado.example.com mesmo que você só envie do seu domínio raiz, e sem np um receptor recorre à sua política sp ou p para esses. Pôr np=reject fecha esse buraco. Importa mais em domínios sensíveis; teste primeiro, porque alguns serviços criam subdomínios dinâmicos e np=reject poderia pegar e-mail legítimo que você esqueceu.
Por que meus boletins caíram no spam depois de passar para quarantine?
Quase sempre porque um remetente de terceiros legítimo foi omitido durante o monitoramento e agora é pego pela política mais rígida. A correção não é reverter às cegas — encontre a fonte que falha nos seus relatórios agregados, corrija o alinhamento SPF ou DKIM dela, confirme que passa de forma consistente e só então continue. Os ESPs que exigem um include de SPF no domínio raiz e os fornecedores cujos valores CNAME de DKIM estão errados até serem corrigidos são culpados comuns.
p=reject garante que meu e-mail chega à caixa de entrada?
Não. A aplicação do DMARC impede que outros falsifiquem o seu domínio e protege a sua reputação, mas não coloca por si só o e-mail na caixa de entrada — reputação, engajamento, taxa de reclamações e o resto da sua autenticação seguem decidindo isso. O que p=reject libera é o BIMI: com quarantine ou reject no lugar e um Verified Mark Certificate (ou agora um Common Mark Certificate para o Gmail), o seu logotipo pode aparecer ao lado do e-mail autenticado, que é um sinal de confiança visível.
Devo definir sp explicitamente?
Normalmente não. Se você omite sp, os subdomínios herdam a sua política p automaticamente, que é o padrão seguro. Defina sp de propósito só quando os subdomínios enviarem por uma infraestrutura diferente da raiz, ou quando você quiser aplicar neles mais rápido ou mais devagar que na raiz. A única combinação a evitar é p=reject com sp=none, que tranca o seu domínio raiz enquanto deixa cada subdomínio falsificável — uma má configuração presente em cerca de um a cada treze domínios em aplicação total.
Quer que aplicar seja um não-evento?
Conte como você envia, e vamos te ajudar a chegar a p=reject de infraestrutura limpa e bem autenticada — sem bloquear uma única mensagem legítima.