Política DMARC: escolher none, quarantine ou reject

Uma política DMARC informa ao destinatário o tratamento solicitado para mensagens que usam seu domínio e falham no DMARC. Pode ajudar contra falsificação, mas o destinatário mantém suas regras locais. Aplicá-la cedo demais também pode afetar faturas, suporte e encaminhamentos legítimos. Para entender a configuração completa, comece pelo e-mail empresarial.

O problema costuma ser um inventário incompleto: manter p=none sem analisar os relatórios ou passar a p=reject antes de verificar a autenticação e o alinhamento de cada serviço. Isso pode colocar mensagens válidas em risco.

Uma abordagem comum usa p=none para observar remetentes, considera p=quarantine após corrigir a autenticação alinhada e avalia p=reject depois de investigar as falhas restantes. Nem toda falha é falsificação, e não existe um calendário seguro para todos os domínios.

O que é uma política DMARC?

A política solicita uma ação quando uma mensagem que usa seu domínio falha no DMARC. As opções são none, quarantine e reject. A escolha depende principalmente da autenticação válida e alinhada dos remetentes legítimos.

O destinatário verifica SPF, DKIM e o alinhamento dos respectivos domínios com o From visível. Para aprovar DMARC, pelo menos um precisa passar na autenticação e estar alinhado.

Se SPF passa e está alinhado, DMARC passa.

Se DKIM passa e está alinhado, DMARC passa.

Se nenhum oferece autenticação válida e alinhada, a política solicitada é avaliada.

Qual política DMARC escolher primeiro?

Comece com p=none se ainda não verificou a autenticação alinhada de todos os remetentes. Observar tráfego real ajuda a avaliar o risco antes de solicitar medidas mais restritivas.

Um registro inicial de monitoramento é:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Esse modo não solicita bloqueio contra falsificação nem garante entrega. Pode trazer visibilidade quando destinatários participantes enviam relatórios, mas não necessariamente cobre todo o tráfego.

Remetentes frequentemente esquecidos:

1. Sistemas contábeis que enviam faturas.
2. Ferramentas de RH e recrutamento.
3. Plataformas de CRM e marketing.
4. Sistemas de suporte que respondem com o domínio principal.
5. Regras pessoais de encaminhamento que afetam SPF no próximo salto.

Sem observar esses fluxos, uma política restritiva pode afetar processos reais. Publicar um TXT não significa ter identificado todos os remetentes.

Para remetentes em massa, publicar DMARC faz parte dos requisitos de alguns destinatários, como o Google. Confira as exigências aplicáveis de autenticação e alinhamento. O padrão é descrito na RFC 7489.

Por quanto tempo manter none?

Manter none por duas a quatro semanas pode servir como referência inicial, sem garantir a observação de fluxos mensais, trimestrais ou excepcionais. Ajuste o monitoramento aos ciclos reais de envio.

Três dias costumam fornecer pouca informação: faturas mensais, comunicados trimestrais e aplicações antigas de recuperação de senha podem ficar fora da amostra.

O período deve abranger:

1. E-mail empresarial habitual.
2. Campanhas de marketing.
3. Ciclos de cobrança.
4. Escalonamentos de suporte.
5. Mensagens encaminhadas.
6. Automações de terceiros.

Compare os relatórios agregados com seu inventário: sistemas legítimos a corrigir, falsificação provável e falhas ainda sem explicação. Os relatórios nem sempre permitem determinar a causa sozinhos.

Exemplo: a plataforma de newsletter assina com o próprio domínio, e SPF também passa para um domínio não alinhado. DMARC falha apesar da autenticação válida. Antes de solicitar rejeição, corrija o alinhamento desse remetente legítimo.

No TrekMail, o fluxo DNS pode ajudar a verificar os registros indicados conforme a modalidade de envio. Consulte adicionar um domínio e registros DNS obrigatórios. As verificações não substituem o inventário dos serviços externos.

Por que encaminhamentos complicam DMARC?

O encaminhamento pode fazer SPF falhar porque o servidor de envio muda. DKIM válido e alinhado costuma permitir que DMARC passe se os dados assinados forem preservados. Confira DKIM sem presumir que todo encaminhamento o conserva.

A diferença entre identidades de remetente é essencial.

O usuário vê From; o servidor usa um remetente de envelope para devoluções. SPF verifica essa identidade e a IP de envio. DMARC confere se um resultado SPF válido está alinhado ao From visível.

Ao encaminhar, a IP muda e pode deixar de ser autorizada pelo SPF original. DKIM pode permanecer válido quando os dados assinados não mudam além do que sua canonicalização tolera.

Assim, estes resultados podem coexistir:

1. SPF falha após o encaminhamento.
2. DMARC passa porque DKIM passa e está alinhado.

Antes de solicitar medidas restritivas, teste os encaminhamentos importantes para sua operação e as assinaturas alinhadas dos remetentes. Consulte encaminhar e-mail de domínio ao Gmail e, para problemas de rota, encaminhamento de e-mail.

ARC transporta o contexto de autenticação entre intermediários e listas. Não substitui seu alinhamento nem garante a aceitação pelo destinatário. O protocolo está na RFC 8617.

Quando passar a quarantine?

Considere quarantine depois de verificar que os remetentes legítimos passam SPF ou DKIM com alinhamento. A política solicita tratar as falhas como suspeitas; o destinatário pode aplicar exceções ou outras medidas.

O registro é:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

Um remetente esquecido pode acabar no spam e revelar o problema, mas não conte com a preservação de todas as mensagens ali nem com a percepção dos usuários.

Para tratar uma ocorrência:

1. Receba e confirme o relato de mensagem ausente.
2. Examine o remetente e o alinhamento.
3. Corrija SPF, DKIM ou ambos conforme a causa.
4. Teste novamente antes de considerar reject.

Algumas equipes usam pct=25 ou pct=50 para solicitar aplicação parcial. Os destinatários não respeitam todos esse percentual da mesma forma. Mesmo 100% continua sendo uma solicitação, não garantia de cobertura. Avance conforme riscos e evidências, não apenas o percentual.

Nos planos TrekMail que incluem SMTP gerenciado, confira se a assinatura sai válida e alinhada ao seu domínio. Em encaminhamentos, SPF pode falhar e DKIM passar; consulte meus e-mails vão para o spam para o diagnóstico.

Quando passar a reject?

Considere reject depois de resolver falhas legítimas e investigar causas desconhecidas. A política solicita rejeitar mensagens que falham no DMARC, mas os destinatários podem manter exceções locais.

O registro é simples:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

É um objetivo comum quando o tráfego legítimo do domínio já foi verificado.

Essa política pode ajudar porque:

1. Dificulta alguns usos diretos do domínio para falsificação quando o destinatário a aplica.
2. Pode reduzir parte do risco de phishing e fraude empresarial.
3. Comunica aos destinatários o tratamento solicitado para falhas.
4. Integra uma estratégia de proteção da marca, sem cobrir todos os golpes.

O Google descreve limitações e rejeições ligadas à autenticação e ao alinhamento, com códigos como 4.7.31 e 4.7.32. Algumas devoluções mencionam 5.7.26 e a política do domínio. Consulte as perguntas frequentes sobre diretrizes para remetentes do Google para o contexto vigente.

Atenção: se a área financeira ainda usa um serviço sem autenticação alinhada, as faturas podem ser rejeitadas. Confira esse fluxo antes de endurecer a política.

Qual registro DMARC publicar no DNS?

Publique um único TXT de política em _dmarc.yourdomain.com. Mesmo um valor curto pode influenciar o tratamento solicitado para mensagens do domínio.

Estes exemplos são alternativas; não publique os três ao mesmo tempo:

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

No TrekMail, confira MX, SPF, DKIM e DMARC conforme a configuração real. O padrão abaixo é ilustrativo: quarantine não é uma recomendação para aplicar restrições antes do inventário de remetentes.

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

Não publique vários SPF nem invente chaves DKIM. Revise os MX atuais antes de alterá-los. Com seu próprio provedor de saída, SPF e DKIM precisam corresponder a esse serviço, não necessariamente ao exemplo. Consulte SMTP próprio (BYO) e verifique o alinhamento.

Quais erros de política DMARC evitar?

Erros comuns incluem p=none sem análise, aplicação prematura, dependência apenas de SPF e esquecimento dos subdomínios. Podem deixar a proteção incompleta ou afetar mensagens legítimas.

Confira estes pontos:

1. Manter none por meses sem plano de revisão: não solicita bloqueio, e os relatórios dependem dos participantes.
2. Ignorar o alinhamento DKIM porque SPF passa: encaminhamentos podem expor essa dependência.
3. Esquecer a herança dos subdomínios; use sp= quando precisar de outra política.
4. Ultrapassar o limite SPF de 10 termos avaliados que provocam consultas DNS pode gerar PermError; não é apenas a contagem de requisições de rede.
5. Confiar em um serviço que usa seu domínio sem verificar como autentica e assina.

Um exemplo para subdomínios:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

Solicita reject no domínio principal e none nos subdomínios que herdam essa política. Não se limita a um subdomínio específico; registros próprios podem alterar o comportamento.

Como o TrekMail ajuda a configurar DMARC

O TrekMail pode coordenar domínios, armazenamento e verificações DNS conforme o plano. Isso reduz o trabalho entre ferramentas, mas a política ainda exige conhecer os remetentes externos e seus resultados reais.

Como referência, o Starter é anunciado a partir de $3.50 por mês com SMTP gerenciado conforme suas condições. O Nano é oferecido gratuitamente com SMTP próprio. O TrekMail usa IMAP e oferece domínios próprios, catch-all, encaminhamento, migração e API conforme o plano e a configuração; confira os termos vigentes.

Para DMARC, publicar o TXT não basta: é preciso controlar e verificar os sistemas que enviam com seu domínio.

Conforme a configuração disponível, você pode:

1. Gerenciar vários domínios em um painel.
2. Verificar os registros DNS antes da ativação.
3. Usar SMTP gerenciado nos planos correspondentes ou configurar SES/SendGrid no Nano.
4. Separar hospedagem de caixas da escolha do provedor de saída.
5. Importar mensagens antigas por uma migração IMAP compatível.

Para a configuração completa, consulte configurar e-mail no meu domínio. Para várias marcas ou clientes, hospedagem de e-mail multidomínio explica o modelo operacional.

Conclusão: avançar de none a reject com evidências

Uma abordagem comum começa com none, corrige autenticação e alinhamento, avalia quarantine e depois reject. Cada etapa deve se apoiar em testes e observação.

Em resumo:

1. Use p=none por 2 a 4 semanas como referência inicial, ampliando para cobrir seus ciclos.
2. Configure SPF ou DKIM válidos e alinhados para cada remetente legítimo; confira DKIM para encaminhamentos.
3. Considere p=quarantine para solicitar tratamento intermediário.
4. Considere p=reject depois de resolver falhas legítimas e investigar as demais.

Essa abordagem pode reduzir falsificação sem perder de vista mensagens válidas, mas não garante entrega nem proteção total. Para coordenar caixas, encaminhamentos e migrações conforme suas necessidades, consulte a documentação ou compare os planos TrekMail em https://trekmail.net/pricing.