Uma política DMARC reject solicita rejeitar mensagens que falham no DMARC. Com p=none, você solicita relatórios sem restrições, mas o envio deles não é garantido; quarantine já solicita uma medida de aplicação. Passar cedo demais a p=reject pode afetar faturas, recuperação de senhas e suporte legítimos. Para as bases, comece por e-mail empresarial.
Monitorar sem inventariar remetentes deixa problemas; endurecer uma política DMARC reject sem testes também cria riscos. Este guia reúne pré-requisitos, uma transição orientativa e falhas relevantes em 2025 e 2026.
| Pré-requisito | Objetivo | Por que verificar antes de reject |
|---|---|---|
| Observação do tráfego | 30 dias como referência inicial | Revisar ciclos mensais e ampliar para fluxos raros ou trimestrais |
| Auditoria de alinhamento | 100% dos remetentes legítimos alinhados como objetivo | SPF ou DKIM válido sem alinhamento não basta ao DMARC |
| Reputação | Taxa de spam abaixo de 0.1% conforme recomendações do destinatário | Reputação e falhas DMARC podem coexistir |
| Encaminhamento | DKIM válido e alinhado preservado | SPF pode falhar em rotas indiretas |
| Subdomínios | Tag sp revisada | A herança pode afetar subdomínios antigos ou de desenvolvimento |
O que DMARC reject faz
Uma política DMARC reject solicita que o destinatário rejeite mensagens quando nem SPF nem DKIM passam com o alinhamento exigido para o domínio. Pode reduzir algumas falsificações quando aplicada, mas não garante o bloqueio de toda falsificação nem a entrega na caixa de entrada.
Alinhamento é essencial: pelo menos uma autenticação válida precisa alinhar com o domínio From visível, conforme o modo relaxado ou estrito. Um indicador SPF ou DKIM positivo sozinho não basta.
Pela RFC 7489, destinatários podem considerar pct e aplicar julgamento local. Uma política DMARC reject não corrige reputação, conteúdo ou configuração de envio.
Pré-requisito 1: observar 30 dias antes de reject
Não baseie uma política DMARC reject em apenas uma semana favorável. Trinta dias são uma referência prática, não garantia: cobrança mensal, relatórios trimestrais e automações raras exigem testes ou observação prolongada.
Revisar sete dias, publicar p=reject e depois descobrir faturas rejeitadas é um risco a reduzir com inventário e testes de cada ciclo.
Exemplo: a ferramenta de cobrança só envia no começo do mês. Autentica com o domínio do provedor, sem alinhar ao seu. Com
p=none, a falha pode passar despercebida; comp=reject, faturas podem ser rejeitadas.
Procure remetentes raros mas importantes: cobrança, RH, scanners, formulários e suporte. Avalie a política DMARC reject depois de identificá-los, sem usá-la como substituto do inventário.
Confira DNS antes de interpretar relatórios. O guia de registros DNS obrigatórios do TrekMail descreve SPF, DKIM, MX e DMARC conforme a modalidade de serviço.
Pré-requisito 2: auditar alinhamento e autenticação
Antes de uma política DMARC reject, confira SPF ou DKIM válidos e alinhados em cada remetente legítimo. Um serviço pode autenticar corretamente para o próprio domínio sem alinhar ao seu From.
Um exemplo SaaS comum:
From visível:
support@yourcompany.com
Return-Path:bounce.vendor-mail.com, com SPF válido
DKIM:d=vendor-mail.com, com DKIM válido
Resultado: DMARC falha parayourcompany.com
O painel do provedor pode mostrar autenticação válida sem alinhamento do domínio. Uma política DMARC reject pode afetar essas mensagens.
Correções comuns:
- Publicar registros DKIM do provedor e configurar assinatura com seu domínio.
- Configurar domínio de devolução ou return-path próprio para alinhamento SPF.
- Testar mensagens reais e ler cabeçalhos.
Revise SPF: o limite é de dez mecanismos ou modificadores avaliados que provocam consultas DNS, não de todas as requisições de rede. Vários TXT SPF produzem erro permanente. O guia de configuração de domínio explica registros SPF duplicados.
Pré-requisito 3: conferir reputação
Uma política DMARC reject pode limitar parte da falsificação, mas não melhora sozinha a reputação. Mensagens autênticas também podem receber denúncias, filtragem ou rejeição por outras causas.
As diretrizes Google citadas recomendam a remetentes em massa spam abaixo de 0.1% e evitar 0.3% ou mais, o que pode afetar medidas de mitigação. Yahoo também cita 0.3% como limite. Confira os requisitos atuais e a definição das métricas.
Se Postmaster mostra 0.18%, investigue listas e relevância. Isso não exclui um problema DMARC simultâneo; revise ambos antes de alterar a política.
Antes de uma política DMARC reject, confira:
- A taxa de spam Google Postmaster Tools do domínio de envio.
- Picos de denúncias ligados a campanhas, listas ou ferramentas.
- Devoluções que sugerem dados antigos ou endereços funcionais.
- Reputação compartilhada entre mensagens transacionais e marketing.
Referências: perguntas frequentes sobre diretrizes Google e boas práticas Yahoo.
Pré-requisito 4: testar encaminhamentos com reject
Antes de uma política DMARC reject, teste encaminhamentos. SPF pode falhar porque o servidor intermediário não é autorizado pelo domínio original. DKIM válido e alinhado pode permitir DMARC quando os dados assinados são preservados.
Falha SPF em agregados não comprova falsificação. Se DKIM passa alinhado, DMARC passa, mas listas e gateways podem alterar dados assinados e invalidar DKIM.
Confira canonicalização e assinatura nos fluxos importantes antes da política DMARC reject. SRS pode ajudar SPF com o novo envelope sem necessariamente restaurar alinhamento original; ARC depende do destinatário.
A documentação TrekMail descreve SPF inválido com DKIM válido após encaminhamento e envio gerenciado disponível conforme o plano. Confira a assinatura do domínio em mensagens reais. Consulte encaminhamento de e-mail para examinar modificações de rota.
Consulte também Meus e-mails vão para o spam e configurações IMAP e SMTP. Autenticação alinhada não garante entrega, e SMTP de saída depende do plano.
Pré-requisito 5: revisar subdomínios antes de reject
Uma política DMARC reject do domínio organizacional pode ser herdada por dev.example.com ou alerts.example.com na ausência de política própria. Revise sp e os registros específicos antes das restrições.
Inventarie desenvolvimento, impressoras, scanners e ferramentas antigas. Produção correta não comprova que esses fluxos estejam prontos.
Este exemplo usa sp para diferenciar a herança:
v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.comSolicita reject no domínio principal e none nos subdomínios que herdam o registro, não nos que têm política própria. Avalie depois o endurecimento deles.
Relatórios podem revelar CRMs ou relays esquecidos, mas a cobertura é parcial e origem desconhecida não comprova abuso. A política DMARC reject exige inventário independente.
Aplicar reject por etapas
Avalie uma política DMARC reject após testes e observação. Quarantine já solicita restrição; pct solicita aplicação parcial conforme o destinatário, sem garantir uma transição segura.
Exemplo orientativo:
- Solicitar quarantine a 10% durante uma semana com resposta a incidentes preparada.
- Considerar quarantine a 100% por mais uma ou duas semanas e ampliar conforme os ciclos.
- Considerar reject após testar suporte, cobrança, autenticação e encaminhamentos.
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.comv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comOs registros são alternativas sucessivas: publique apenas um. Quarantine não garante recuperação; reject pode produzir devoluções e, conforme o erro, novas tentativas. Uma política DMARC reject pode rejeitar uma mensagem legítima antes de chegar à caixa de entrada.
Gerenciar reject em vários domínios
Uma política DMARC reject exige mais coordenação com dez, cinquenta ou quinhentos domínios. Cada provedor tem sua configuração DKIM, e cada domínio precisa de inventário atualizado.
Abordagem dispersa: revisar XML à mão, investigar IPs, corrigir domínio por domínio e depender de avisos informais de novos remetentes.
Abordagem coordenada: centralizar domínios, documentar DNS e manter testes reproduzíveis.
O TrekMail anuncia planos pagos desde $3.50 por mês com SMTP gerenciado conforme os termos e painel para domínios, caixas IMAP, encaminhamento e DNS. Nano é oferecido gratuitamente para até 10 domínios com SMTP próprio. Consulte hospedagem multidomínio e confira recursos vigentes.
Coordenação pode reduzir tarefas repetidas, mas não garante economia nem menos incidentes. Mantenha procedimentos de atualização dos remetentes antes de uma política DMARC reject.
Consulte registros DNS obrigatórios e trekmail.net/pricing. Planos pagos podem incluir avaliação de 14 dias com cartão exigido; Nano é oferecido sem cartão conforme os termos atuais.
Conclusão: quando publicar reject
Para avaliar uma política DMARC reject, observe pelo menos 30 dias como referência e amplie para ciclos raros, confira autenticação alinhada, denúncias, encaminhamentos e herança dos subdomínios. Nenhum indicador isolado comprova preparação completa.
Inventarie remetentes, leia cabeçalhos e corrija DNS e rotas antes da política DMARC reject. Continue monitorando: a solicitação pode ajudar contra falsificação sem cobrir todos os abusos.
Para coordenar a infraestrutura, consulte TrekMail ou compare planos em trekmail.net/pricing.
