E-mails não autorizados enviados do seu domínio podem passar pela autenticação SPF e DKIM, chegar às caixas de entrada parecendo legítimos e prejudicar a confiança antes que você detecte o problema. A aplicação da política DMARC (p=none, p=quarantine, p=reject) controla como os servidores receptores lidam com mensagens não autenticadas que alegam ser do seu domínio.

A maioria das organizações inicia a implantação do DMARC em p=none para coletar visibilidade sem risco de aplicação. O desafio é saber quando progredir para p=quarantine e p=reject sem interromper e-mails legítimos ou expor lacunas na cobertura de autenticação.

Este guia explica o que cada nível de política DMARC faz, quando a progressão da política pode falhar e como escalonar a aplicação com base na maturidade do remetente, função de negócios e prontidão operacional.

I. O Que os Níveis de Política DMARC Realmente Controlam

A política DMARC (p=) instrui os servidores de e-mail receptores sobre como lidar com mensagens que falham no alinhamento DMARC. Os três níveis de aplicação são:

• p=none: Apenas monitoramento. Os resultados da autenticação são relatados, mas o servidor receptor não aplica nenhuma aplicação baseada em DMARC.
• p=quarantine: Quando respeitada pelo servidor receptor, as mensagens não autenticadas são normalmente movidas para pastas de spam ou lixo eletrônico.
• p=reject: Quando respeitada pelo servidor receptor, as mensagens não autenticadas são recusadas durante a entrega SMTP e não devem chegar à caixa de entrada ou pasta de spam.

O Que Pode Dar Errado com a Aplicação da Política DMARC

A aplicação da política DMARC depende de três condições que podem falhar independentemente:

1. Falha de alinhamento apesar da autenticação passar: SPF ou DKIM podem autenticar com sucesso, mas se o domínio no cabeçalho From: não estiver alinhado com o domínio SPF ou o domínio de assinatura DKIM, o DMARC falha. Isso comumente acontece quando remetentes terceirizados assinam com seu próprio domínio ou quando o encaminhamento de e-mail quebra o alinhamento SPF.
2. O servidor receptor não respeita a política: Algumas listas de discussão, encaminhadores e servidores de e-mail mal configurados ignoram a política DMARC. Mesmo em p=reject, uma pequena porcentagem de e-mails ainda pode ser entregue se a infraestrutura receptora não aplicar o DMARC.
3. Lacunas silenciosas de aplicação: Mover diretamente de p=none para p=reject sem validação escalonada pode bloquear e-mails legítimos que não estavam visíveis nos relatórios agregados, como remetentes de baixo volume, ferramentas de TI paralela ou cenários de encaminhamento.

A aprovação do DMARC não garante a colocação na caixa de entrada. A falha do DMARC nem sempre significa rejeição imediata. Os provedores de caixa de correio avaliam o DMARC juntamente com reputação, conteúdo, taxas de reclamação, contexto de encaminhamento e sinais internos de abuso.

II. p=none: Visibilidade Sem Aplicação

Em p=none, o DMARC está ativo, mas a política instrui os servidores receptores a monitorar e relatar resultados de autenticação sem tomar ação de aplicação.

Quando p=none É Apropriado

• Implantação inicial do DMARC: Você precisa de visibilidade sobre quais remetentes autenticam com sucesso e quais não, antes de aplicar a política.
• Ambientes de envio complexos: Seu domínio é usado por múltiplas unidades de negócios, plataformas terceirizadas, ferramentas de suporte, sistemas de marketing e remetentes transacionais que não foram inventariados.
• Comportamento desconhecido de encaminhamento ou lista de discussão: Você espera que e-mails legítimos fluam através de serviços de encaminhamento ou listas de discussão que podem quebrar o alinhamento SPF.

O Que Pode Falhar em p=none

Mesmo em p=none, o DMARC pode produzir sinais de falha:

• SPF passa mas o alinhamento falha: Um serviço terceirizado autentica com SPF mas usa seu próprio domínio no remetente do envelope (Return-Path), então a verificação de alinhamento contra o domínio do cabeçalho From: falha.
• DKIM passa mas o alinhamento falha: Um remetente assina e-mail com DKIM, mas o domínio de assinatura (d=) não corresponde ao domínio organizacional no cabeçalho From:.
• Relatórios agregados não são coletados ou analisados: Publicar um registro DMARC com rua=mailto:[email protected] não analisa, agrega ou age automaticamente nos relatórios XML enviados pelos servidores receptores.

Duração Recomendada em p=none

Permaneça em p=none até que:

1. Você tenha identificado todas as fontes de envio legítimas.
2. Todos os remetentes legítimos passem no SPF com alinhamento ou passem no DKIM com alinhamento.
3. Os relatórios agregados mostrem sucesso consistente de autenticação por pelo menos dois ciclos de negócios completos (comumente 30-60 dias para a maioria das organizações, mais longo para remetentes sazonais).

Em uma implantação gerenciada pelo Skysnag, use o destino de relatórios gerado pelo Skysnag. O seguinte é apenas um exemplo manual:

v=DMARC1; p=none; rua=mailto:[email protected]

Um registro estático tradicional pode funcionar, mas apenas se os relatórios forem ativamente recebidos, analisados e tratados. O Skysnag automatiza esse processo e identifica lacunas de autenticação que requerem correção antes da aplicação da política.

III. p=quarantine: Aplicação Escalonada

Em p=quarantine, os servidores receptores que respeitam a política DMARC normalmente movem mensagens não autenticadas para pastas de spam ou lixo eletrônico em vez de entregá-las na caixa de entrada.

Quando Migrar para p=quarantine

Migre para p=quarantine quando:

1. Os relatórios agregados mostrem que remetentes legítimos consistentemente passam no alinhamento DMARC.
2. As falhas de autenticação nos relatórios correspondam a uso não autorizado conhecido, remetentes mal configurados ou tentativas de falsificação.
3. Você tenha validado que e-mails críticos de negócios (notificações transacionais, respostas de suporte, redefinições de senha, faturas) passam nos testes de alinhamento.

O Que Pode Falhar em p=quarantine

p=quarantine introduz risco de aplicação que não existe em p=none:

• E-mail legítimo colocado em quarentena devido a encaminhamento: O encaminhamento de e-mail frequentemente quebra o alinhamento SPF. Se um remetente legítimo depende apenas do SPF e a mensagem é encaminhada, o DMARC falha e a mensagem pode ser colocada em quarentena.
• Remetentes de baixo volume não visíveis nos relatórios: Um remetente que envia e-mail para seu domínio uma vez por trimestre pode não aparecer nos relatórios agregados durante o período de monitoramento, mas pode ser bloqueado quando a aplicação começar.
• Listas de discussão e serviços de digest: Alguns softwares de lista de discussão reescrevem o cabeçalho From:, causando falha de alinhamento mesmo quando o remetente original autenticou com sucesso.

Escalonando p=quarantine por Domínio ou Subdomínio

Em vez de aplicar p=quarantine globalmente, escalone a aplicação isolando diferentes fluxos de e-mail:

• Subdomínios transacionais primeiro: noreply.example.com ou notifications.example.com normalmente têm menos remetentes e padrões de autenticação mais previsíveis.
• Domínios de marketing ou em massa em seguida: Esses domínios são alvos comuns de falsificação e frequentemente têm configurações maduras de SPF e DKIM.
• Domínio corporativo principal por último: @example.com frequentemente cobre a maior variedade de remetentes, incluindo e-mail de funcionários, integrações terceirizadas e sistemas legados.

Exemplo de registro DMARC para um subdomínio em p=quarantine:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

Evite depender da implantação baseada em porcentagem como estratégia principal. Programas atuais com consciência de DMARC devem escalonar a aplicação por domínio, subdomínio, grupo de remetentes e função de negócios.

Em uma implantação gerenciada pelo Skysnag, use o destino de relatórios gerado pelo Skysnag.

IV. p=reject: Aplicação Completa

Em p=reject, os servidores receptores que respeitam a política DMARC recusam mensagens não autenticadas durante a entrega SMTP. A mensagem não deve chegar à caixa de entrada ou pasta de spam.

Quando Migrar para p=reject

Migre para p=reject quando:

1. Você tenha operado em p=quarantine por pelo menos 30 dias sem colocar e-mail legítimo em quarentena.
2. Os relatórios agregados não mostrem falhas DMARC inesperadas de remetentes conhecidos.
3. Você tenha validado cenários de encaminhamento de e-mail (encaminhamento de ex-alunos, encaminhamento de tickets de suporte, regras de encaminhamento pessoal) e confirmado que remetentes críticos usam DKIM (que sobrevive ao encaminhamento) ou que os serviços de encaminhamento estão excluídos do domínio de aplicação.

O Que Pode Falhar em p=reject

p=reject representa a postura de aplicação mais forte, mas lacunas de aplicação ainda existem:

• Encaminhamento quebra SPF, DKIM não configurado: Se um remetente depende apenas do SPF e a mensagem é encaminhada, o alinhamento SPF falha. Se o DKIM não estiver configurado, a mensagem falha no DMARC e é rejeitada.
• Listas de discussão ou caixas de entrada compartilhadas: Alguns softwares de lista de discussão e plataformas de caixa de entrada compartilhada reescrevem cabeçalhos de mensagem de maneiras que quebram o alinhamento, mesmo quando a mensagem original autenticou com sucesso.
• Servidores receptores não conformes: Alguns servidores receptores não respeitam a política DMARC, especialmente infraestrutura de e-mail mais antiga ou sistemas que priorizam a reputação histórica do remetente sobre sinais de autenticação.

Mesmo em p=reject, a investigação é mais difícil porque o monitoramento mostra resultados de autenticação, mas o domínio não está instruindo receptores a bloquear uso não autenticado. Organizações que exigem atribuição de incidentes de falsificação ou phishing comumente operam em p=reject para reduzir ambiguidade na análise forense.

V. Política de Subdomínio: Controlando sp= Independentemente

O DMARC permite aplicação de política separada para subdomínios usando a tag sp=.

Exemplo de registro DMARC com política de subdomínio:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

Esta configuração aplica p=reject em example.com mas aplica p=quarantine a todos os subdomínios, a menos que um subdomínio publique seu próprio registro DMARC.

Quando Usar sp= para Implantação Escalonada

Use sp= quando:

• Fluxos de e-mail de subdomínio são menos maduros: Subdomínios de marketing, staging ou legados podem ter autenticação inconsistente, então aplicar sp=quarantine fornece aplicação sem o risco de rejeitar e-mail legítimo.
• A autenticação de subdomínio é gerenciada separadamente: Diferentes unidades de negócios gerenciam e-mail de subdomínio independentemente, e você deseja aplicar política no domínio principal enquanto os proprietários de subdomínio validam seus remetentes.

O Que Pode Falhar com sp=

• Registros DMARC de subdomínio sobrescrevem sp=: Se um subdomínio publica seu próprio registro DMARC, o valor sp= no registro do domínio organizacional é ignorado. Isso pode criar lacunas de política se os proprietários de subdomínio publicarem p=none enquanto o domínio organizacional opera em p=reject.

VI. Como Escalonar a Progressão da Política DMARC em 2026

Escalonar a aplicação da política DMARC por grupo de remetentes, função de negócios e maturidade do fluxo de e-mail reduz o risco de aplicação e melhora a cobertura de autenticação.

Etapa 1: Implante p=none e Colete Relatórios

Inicie o monitoramento DMARC através do Skysnag e obtenha um registro DMARC gerenciado gerado para seu domínio. Isso fornece análise automatizada de relatórios e identificação de remetentes.

Etapa 2: Identifique Remetentes Legítimos

Revise relatórios agregados para identificar:

• Quais remetentes passam no alinhamento SPF
• Quais remetentes passam no alinhamento DKIM
• Quais remetentes falham em ambos (comumente e-mail não autorizado ou falsificado)

Para remetentes que falham no alinhamento:

• Configure assinatura DKIM se o remetente suportar (DKIM sobrevive ao encaminhamento)
• Adicione o mecanismo de inclusão SPF do remetente se o remetente usar seu domínio no remetente do envelope
• Migre para um subdomínio se o remetente não puder autenticar com seu domínio principal

Etapa 3: Valide E-mail Crítico de Negócios

Antes de migrar para aplicação, valide que e-mail crítico passa no DMARC:

• E-mail transacional (redefinições de senha, notificações de conta, confirmações de pedido)
• Sistemas de tickets de suporte (Zendesk, Freshdesk, Intercom, plataformas de help desk)
• Plataformas de marketing (Mailchimp, SendGrid, HubSpot, Marketo)
• Aplicativos internos (sistemas de RH, plataformas de despesas, CRM, ERP)
• Ferramentas SaaS terceirizadas (notificações Slack, alertas GitHub, ferramentas de monitoramento)

Se algum remetente crítico falhar no DMARC, resolva a lacuna de autenticação antes da aplicação.

Etapa 4: Migre para p=quarantine em Subdomínios Isolados

Aplique p=quarantine primeiro a subdomínios com padrões de envio previsíveis:

• noreply.example.com
• notifications.example.com
• marketing.example.com

Monitore por e-mail legítimo em quarentena. Se nenhum aparecer após 30 dias, prossiga.

Etapa 5: Migre para p=reject em Subdomínios Validados

Aplique p=reject a subdomínios onde a autenticação está madura e nenhum e-mail legítimo foi colocado em quarentena.

Etapa 6: Migre Domínio Principal para p=quarantine

Após a aplicação de subdomínio estar estável, migre o domínio organizacional principal (example.com) para p=quarantine.

Etapa 7: Migre Domínio Principal para p=reject

Após operar em p=quarantine sem problemas por pelo menos 30 dias, migre o domínio principal para p=reject.

VII. Falhas Comuns de Progressão de Política e Como Evitá-las

1. E-mail Legítimo Rejeitado Devido a Encaminhamento

Condição de falha: Um usuário encaminha e-mail de [email protected] para uma conta pessoal do Gmail. A mensagem encaminhada falha no alinhamento SPF porque o remetente do envelope ainda mostra example.com, mas o IP de envio agora é o servidor de encaminhamento. Se o DKIM não estiver configurado, a mensagem falha no DMARC e é rejeitada.

Como evitar: Configure DKIM em todos os remetentes legítimos. Assinaturas DKIM sobrevivem ao encaminhamento porque viajam com o corpo da mensagem, diferentemente do SPF que depende do IP de envio.

2. Lista de Discussão ou Caixa de Entrada Compartilhada Quebra o Alinhamento

Condição de falha: Uma lista de discussão ou plataforma de caixa de entrada compartilhada reescreve o cabeçalho From: para cumprir a política de envio da plataforma. O cabeçalho reescrito não se alinha mais com o domínio do remetente original, causando falha DMARC.

Como evitar: Identifique o comportamento de lista de discussão e caixa de entrada compartilhada durante a fase p=none. Se a plataforma não puder preservar o alinhamento, considere usar um subdomínio com política relaxada ou migrar para uma plataforma que suporte envio compatível com DMARC.

3. Remetentes de TI Paralela Descobertos Após Aplicação

Condição de falha: Uma unidade de negócios usa uma ferramenta terceirizada não autorizada para enviar e-mail de @example.com. A ferramenta não aparece nos relatórios agregados porque envia com pouca frequência. Quando p=reject é aplicado, o e-mail da ferramenta é bloqueado, interrompendo um processo de negócios.

Como evitar: Conduza descoberta de remetentes em unidades de negócios antes da aplicação. Use o Skysnag Protect para identificar fontes de envio não autorizadas e validar a cobertura de autenticação.

VIII. Reversão de Política DMARC: Quando Reduzir a Aplicação

Se a aplicação causar bloqueio de e-mail legítimo, reduza a política temporariamente:

1. Volte de p=reject para p=quarantine
2. Identifique o remetente causando a falha nos relatórios agregados
3. Resolva a lacuna de autenticação (adicione inclusão SPF, configure DKIM, migre para subdomínio)
4. Valide a correção nos relatórios
5. Retorne a p=reject

Reduzir a aplicação temporariamente é mais seguro do que deixar e-mail legítimo bloqueado durante a solução de problemas.

IX. Como o Skysnag Suporta a Progressão de Política

Migrar de p=none para p=quarantine e p=reject requer visibilidade contínua, validação de remetentes e evidência de aplicação.

Skysnag Protect fornece:

• Análise automatizada de relatórios DMARC e identificação de remetentes
• Detecção de lacunas de autenticação para remetentes legítimos
• Pontuação de prontidão de aplicação antes de mudanças de política
• Gerenciamento e validação de política de subdomínio

Use o Skysnag Protect para identificar remetentes legítimos, detectar fontes não autorizadas e migrar para aplicação sem interromper e-mail de negócios.

X. Principais Conclusões

• A aplicação da política DMARC depende do alinhamento, não apenas da autenticação passando
• O encaminhamento quebra o alinhamento SPF mas assinaturas DKIM sobrevivem, tornando o DKIM essencial para prontidão de aplicação
• Aplicação escalonada por subdomínio e grupo de remetentes reduz o risco em comparação com implantação baseada em porcentagem
• p=quarantine expõe lacunas de aplicação sem risco de rejeição completa
• p=reject fornece a proteção mais forte mas requer validação de cenários de encaminhamento e remetentes de baixo volume
• A aplicação depende de servidores receptores respeitarem a política, o que não é universal

Inicie o monitoramento DMARC através do Skysnag e obtenha seu registro DMARC gratuito.