Escolha a política DMARC certa
para o seu domínio
A política DMARC (tag p=) indica aos servidores de e-mail de recebimento o que fazer com as mensagens que falham na autenticação DMARC. Existem três opções - none, quarantine e reject - e todo domínio deve seguir o mesmo caminho, do monitoramento à aplicação total. Cada política é publicada no seu registro DMARC e, se a autenticação de e-mail é novidade para você, comece por o que é DMARC.
De acordo com a RFC 7489, a política se aplica apenas quando TANTO o alinhamento de SPF QUANTO o alinhamento de DKIM falham. Se um dos dois passar e alinhar, a mensagem passa no DMARC independentemente da política.
none, quarantine, reject
Cada política é uma etapa na jornada de aplicação. Comece pela visibilidade, ganhe confiança e então aplique.
p=none Somente monitorar Veja tudo. Não bloqueie nada.
Os servidores de e-mail de recebimento não tomam nenhuma medida de aplicação sobre as mensagens que falham no DMARC. Eles ainda enviam relatórios agregados de volta ao proprietário do domínio, oferecendo visibilidade total sobre cada fonte que envia e-mails a partir do domínio.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - Risco zero para a entrega de e-mails legítimos
- Visibilidade total sobre todas as fontes de envio por meio de relatórios agregados
- Primeiro passo obrigatório - você precisa monitorar antes de aplicar
- Atende ao requisito mínimo do Google/Yahoo para remetentes em massa
- Não oferece nenhuma proteção contra spoofing ou phishing
- Os atacantes ainda podem enviar e-mails em nome do seu domínio, e eles serão entregues
- Não melhora a reputação do domínio junto aos receptores
Comece sempre por aqui. Implante p=none com relatórios rua= e monitore por pelo menos 90 dias. Use esta fase para identificar cada remetente legítimo, corrigir a configuração de SPF/DKIM deles e confirmar o alinhamento antes de passar para a aplicação.
O e-mail falha no alinhamento de SPF + DKIM
O receptor verifica a política DMARC: p=none
O e-mail é entregue normalmente na caixa de entrada
Relatório agregado enviado ao proprietário do domínio
p=quarantine Encaminhar para o spam E-mails suspeitos vão para o spam. E-mails legítimos continuam fluindo.
As mensagens que falham no DMARC são encaminhadas para a pasta de spam ou lixo eletrônico do destinatário. A mensagem ainda existe - os destinatários podem encontrá-la se procurarem - mas está claramente sinalizada como suspeita. Esta é a etapa de aplicação que serve de rede de segurança.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - Proteção ativa - as mensagens falsificadas saem da caixa de entrada
- Rede de segurança para remetentes mal configurados (as mensagens não são perdidas)
- Sinaliza aos receptores que você leva a segurança de e-mail a sério
- Bom meio-termo durante a transição para a aplicação
- Remetentes legítimos com autenticação quebrada caem no spam
- Os destinatários podem não verificar as pastas de spam, causando e-mails perdidos
- Alguns receptores tratam quarantine como reject na prática
Após mais de 90 dias em p=none, com todos os remetentes legítimos identificados e passando na autenticação. Passe para cá somente quando seus relatórios agregados mostrarem alinhamento consistente de SPF/DKIM para cada fonte autorizada.
O e-mail falha no alinhamento de SPF + DKIM
O receptor verifica a política DMARC: p=quarantine
O e-mail é encaminhado para a pasta de spam/lixo eletrônico
Relatório agregado enviado ao proprietário do domínio
p=reject Bloquear totalmente Aplicação total. E-mails falsificados nunca chegam.
As mensagens que falham no DMARC são rejeitadas no nível SMTP - o destinatário nunca as vê e o servidor de envio recebe uma devolução (bounce). Esta é a proteção mais forte e o objetivo final para todo domínio.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com - Proteção máxima contra spoofing de domínio e phishing
- Os atacantes não conseguem entregar e-mails se passando pelo seu domínio
- Sinal de reputação de domínio mais alto para os servidores de e-mail receptores
- Qualifica para o BIMI (Brand Indicators for Message Identification)
- Remetentes legítimos mal configurados são bloqueados por completo - nem sequer vão para o spam
- Cadeias de encaminhamento de e-mail que quebram o alinhamento falharão
- Requer monitoramento minucioso antes da implantação
Após mais de 90 dias em p=quarantine com relatórios agregados limpos. Todos os remetentes legítimos precisam passar consistentemente no alinhamento de SPF ou DKIM. A jornada completa de p=none até p=reject costuma levar de 9 a 18 meses.
O e-mail falha no alinhamento de SPF + DKIM
O receptor verifica a política DMARC: p=reject
O e-mail é rejeitado no nível SMTP - nunca entregue
Relatório agregado enviado ao proprietário do domínio
O caminho até a aplicação total
Todo domínio segue a mesma progressão. A linha do tempo depende da complexidade - quanto mais remetentes, mais tempo para configurar. Planeje 9 a 18 meses do primeiro registro até o p=reject total.
p=none Fase 1: Monitorar
no mínimo 90 diasPublique o registro DMARC com p=none e relatórios rua=. Analise os relatórios agregados para identificar cada fonte que envia e-mails a partir do seu domínio. Corrija SPF e DKIM para todos os remetentes legítimos.
p=quarantine Fase 2: Quarentena
no mínimo 90 diasPasse para p=quarantine. Comece com pct=10 e aumente gradualmente. Monitore os relatórios em busca de qualquer remetente recém-afetado. Corrija os problemas de autenticação restantes.
p=reject Fase 3: Rejeitar
ContínuoAvance para p=reject com plena confiança de que todos os e-mails legítimos passam. Continue monitorando - novos remetentes, mudanças de IP e atualizações de fornecedores podem quebrar a autenticação a qualquer momento.
Linha do tempo total: 9-18 meses
Organizações com poucos remetentes podem chegar a p=reject mais rápido. Ambientes complexos, com dezenas de serviços terceirizados, levam mais tempo. O essencial são decisões baseadas em dados - nunca pule as fases de monitoramento.
A tag pct=:
aplicação com uma rede de segurança
A tag pct= controla qual porcentagem das mensagens que falham recebe a ação de aplicação. As mensagens fora da porcentagem são tratadas como se a política fosse p=none. Isso permite implantar a aplicação gradualmente enquanto você monitora os problemas.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com 25% das mensagens que falham são colocadas em quarentena. Os 75% restantes são entregues normalmente.
pct=10 Aplica a ação de aplicação a 10% das mensagens que falham. Os 90% restantes são tratados como p=none. Ideal para os testes iniciais.
2-4 semanaspct=25 Aumente para 25%. Monitore os relatórios agregados em busca de qualquer remetente legítimo recém-afetado.
2-4 semanaspct=50 Metade das mensagens que falham agora recebe a ação de aplicação. A maioria dos problemas é revelada nesta etapa.
2-4 semanaspct=100 Aplicação total. Todas as mensagens que falham no alinhamento DMARC recebem a ação da política publicada. Este é o padrão quando pct= não é especificado.
Permanentev=DMARC1; p=reject; sp=quarantine; rua=... O domínio principal está totalmente aplicado. Os subdomínios ficam em quarentena enquanto são configurados.
A tag sp=: controle de subdomínios
A tag sp= define uma política DMARC separada para os subdomínios. Sem ela, os subdomínios herdam a política p= do domínio principal. Isso é útil quando o seu domínio principal está pronto para a aplicação, mas os subdomínios precisam de mais tempo.
- sp=none - os subdomínios são monitorados enquanto são configurados
- sp=quarantine - os subdomínios recebem aplicação intermediária
- sp=reject - os subdomínios são totalmente aplicados (igual à ausência de sp= quando p=reject)
- Omitir sp= - os subdomínios herdam a política p=
Erros comuns de política DMARC
Estes são os erros que mais vemos em implantações de DMARC. Cada um deles pode ser evitado com monitoramento adequado e uma abordagem em fases.
Aplicar rápido demais
Pular para p=reject sem pelo menos 90 dias em p=none faz com que e-mails legítimos sejam bloqueados. Plataformas de marketing, ferramentas de CRM e sistemas de chamados costumam falhar no DMARC se não forem configurados corretamente.
Nenhum monitoramento após a aplicação
O DMARC não é do tipo configurar e esquecer. Novas fontes de envio, mudanças de IP e atualizações de fornecedores podem quebrar a autenticação a qualquer momento. O monitoramento contínuo detecta problemas antes que afetem a entrega.
Ignorar remetentes terceirizados
Todo serviço que envia e-mails em seu nome - Mailchimp, HubSpot, Salesforce, Zendesk - precisa ter includes de SPF ou assinatura DKIM configurados. Esquecer apenas um causa falhas na aplicação.
Esquecer os subdomínios
Sem uma tag sp=, os subdomínios herdam a política do domínio principal. Mas se você aplicar p=reject sem verificar os remetentes dos subdomínios, poderá bloquear e-mails legítimos de subdomínios. Defina sp= explicitamente.
Publicar sem rua=
Um registro DMARC sem relatórios rua= é o mesmo que voar às cegas. Você não tem visibilidade sobre os resultados de autenticação, nenhuma forma de detectar spoofing e nenhum dado para tomar decisões de aplicação.
Usar alinhamento relaxed quando strict é necessário
O alinhamento relaxed (padrão) permite que mail.example.com se alinhe com example.com. Para a maioria das organizações isso é correto, mas domínios de alta segurança podem precisar de alinhamento strict para evitar o abuso de subdomínios.
Perguntas sobre a política DMARC
Qual é a melhor política DMARC?
A melhor política DMARC é p=reject, que oferece proteção máxima contra spoofing de domínio. No entanto, você precisa chegar a p=reject por meio de uma abordagem em fases: comece em p=none (monitore por mais de 90 dias), passe para p=quarantine (mais de 90 dias) e então aplique p=reject. Pular direto para reject faz com que e-mails legítimos sejam bloqueados.
Por quanto tempo devo permanecer em p=none antes de aplicar?
Permaneça em p=none por no mínimo 90 dias - um trimestre completo. Isso lhe dá dados de relatórios agregados suficientes para identificar todas as fontes de envio legítimas e corrigir a autenticação delas. Algumas organizações com muitos remetentes terceirizados podem precisar de mais tempo. A jornada completa até p=reject costuma levar de 9 a 18 meses.
A política p=quarantine oferece proteção suficiente?
Quarantine é um avanço significativo em relação a p=none, pois as mensagens falsificadas não chegam mais à caixa de entrada. No entanto, elas ainda existem na pasta de spam. Para proteção total, p=reject é o objetivo - ele impede que mensagens falsificadas sejam entregues. Alguns frameworks de conformidade (como o PCI DSS v4.0) exigem especificamente p=reject.
O que acontece se eu definir p=reject e um remetente legítimo falhar?
O e-mail do remetente legítimo será rejeitado - o destinatário não o receberá. É por isso que o monitoramento em p=none e p=quarantine é essencial antes de aplicar. Use a tag pct= para implantar a aplicação gradualmente (pct=10 para começar), de modo a detectar configurações incorretas antes que afetem todos os e-mails.
Posso ter políticas diferentes para meu domínio e meus subdomínios?
Sim. A tag sp= (política de subdomínio) permite definir uma política separada para os subdomínios. Por exemplo, você poderia aplicar p=reject no seu domínio principal e manter sp=none nos subdomínios que ainda estão sendo configurados. Se sp= não for definido, os subdomínios herdam a política do domínio principal.
O que é a tag pct= e como devo usá-la?
A tag pct= controla qual porcentagem das mensagens que falham recebe a ação de aplicação. Em pct=10, apenas 10% das mensagens que falham são colocadas em quarentena ou rejeitadas - o restante é tratado como p=none. Aumente gradualmente de 10 para 25, 50 e 100 ao longo de várias semanas para fazer a transição com segurança até a aplicação total.
Veja sua política DMARC atual em ação
Teste gratuito - monitore relatórios agregados, identifique remetentes e planeje sua jornada de aplicação.
Iniciar teste gratuitoEquipes confiam no DMARC Report para a aplicação
Rated 4.8/5 on G2 · 469 verified reviews
Zunaid K.
Director
"Essential tool for email delivery"
This tool helps us to implement DMARC reporting for our domains in an easy to use manner.
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Larry H.
Research & Development Manager
"Good tool to buy"
I have used many tools for monitoring DMARC reports. But DMARC Report is a good tool to use. It helps avoid sending emails to spam.