DMARC p=none vs. quarantine vs. reject: um guia para quem opera e-mail

O dilema central

Escolher uma política DMARC é escolher entre visibilidade e aplicação. p=none oferece monitoramento sem afetar a entrega. p=quarantine envia e-mails suspeitos para a pasta de spam. p=reject bloqueia totalmente os e-mails não autenticados. O caminho mais seguro é uma implantação em fases: comece com none para identificar todos os remetentes legítimos, passe para quarantine para testar o impacto e, por fim, chegue a reject para proteger totalmente seu domínio contra spoofing.

Por que a política importa para a fila de incidentes

Se você é o engenheiro responsável pela entregabilidade, seu objetivo principal é garantir que os e-mails transacionais legítimos cheguem ao destinatário e, ao mesmo tempo, impedir que atacantes usem seu domínio. Se você pular direto para p=reject sem uma fase de monitoramento, provavelmente vai disparar um incidente de alta prioridade quando algum sistema legado esquecido ou uma ferramenta de marketing de terceiros parar de entregar e-mails de repente.

O DMARC (Domain-based Message Authentication, Reporting, and Conformance) depende do alinhamento de SPF e DKIM. Se uma mensagem falhar nos dois, a tag p= diz ao servidor de e-mail receptor exatamente o que fazer com ela.

Os três níveis de política

1. p=none (modo de monitoramento)

Nesse modo, o receptor não faz nada com a mensagem, independentemente do resultado da autenticação. Ele serve apenas para coletar dados.

Quando usar:

• Na configuração inicial do DMARC.
• Quando você não tem certeza de todos os serviços que enviam e-mails em seu nome.
• Durante uma migração para uma nova API de e-mail.

O registro:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

O custo: você não tem nenhuma proteção contra spoofing. Atacantes ainda podem enviar e-mails como se fossem o seu domínio, mas você verá isso nos relatórios RUA (agregados).

2. p=quarantine (aplicação branda)

Mensagens que falham no DMARC são tratadas como suspeitas. A maioria dos receptores as move para a pasta de spam ou lixo eletrônico.

Quando usar:

• Depois de analisar os relatórios de p=none e confirmar que todos os fluxos legítimos estão alinhados.
• Como margem de segurança antes de passar para a rejeição total.

O registro:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

O custo: reduz a visibilidade dos e-mails falsificados, mas não os elimina. Alguns e-mails legítimos ainda podem cair no spam se as chaves DKIM forem rotacionadas de forma incorreta ou se os registros SPF atingirem o limite de 10 consultas DNS.

3. p=reject (aplicação total)

Este é o padrão de referência em segurança de domínio. O servidor receptor se recusa a aceitar a mensagem se ela falhar no DMARC.

Quando usar:

• Quando seu monitoramento mostrar 99,9% de alinhamento em todo o tráfego legítimo.
• Quando o risco de spoofing do domínio for maior que o risco de uma falha de entrega ocasional.

O registro:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

O custo: não há rede de proteção. Se um sistema crítico estiver mal configurado, o e-mail se perde. Você verá essas falhas nos relatórios RUA, mas o usuário nunca recebe a mensagem.

Checklist de implantação para operadores

Não mude de política com base em intuição. Mude com base nos dados dos seus relatórios agregados. Use uma ferramenta como o Verificador de DNS de e-mail do SendHQ para confirmar que seus registros estão se propagando corretamente antes de cada mudança.

Fase 1: descoberta (p=none)

1. Publique p=none com um endereço rua.
2. Aguarde de 7 a 14 dias para capturar um ciclo de negócios completo de e-mails (incluindo relatórios semanais).
3. Analise os relatórios em busca de tráfego "não alinhado".
4. Identifique os remetentes terceiros legítimos (por exemplo, Zendesk, Salesforce, Shopify).
5. Configure o DKIM para cada remetente identificado. Essa é a forma mais confiável de garantir o alinhamento.

Fase 2: testes (p=quarantine)

1. Altere a política para p=quarantine.
2. Acompanhe os tickets de suporte com mensagens como "Não recebi o e-mail" ou "O e-mail caiu no spam".
3. Verifique nos relatórios RUA se houve novos picos de falhas.
4. Se houver falhas, corrija a autenticação e permaneça em quarantine por mais uma semana.

Fase 3: endurecimento (p=reject)

1. Altere a política para p=reject.
2. Confirme que seus fluxos transacionais mais críticos (redefinição de senha, faturas) continuam sendo entregues.
3. Mantenha o monitoramento. O DMARC não é uma configuração do tipo "configure e esqueça".

O e-mail como efeito colateral

Para engenheiros de produto que constroem agentes de IA ou fluxos automatizados, enviar um e-mail é um efeito colateral externo. Isso significa que ele pode falhar por motivos alheios à lógica da sua aplicação (problemas de DNS, rejeição por DMARC, limites de taxa).

Idempotência e aprovação

Quando um agente de IA dispara um e-mail, você precisa evitar envios duplicados durante as novas tentativas. Use uma chave de idempotência nas suas requisições de API para garantir que um timeout de rede não faça o cliente receber o mesmo e-mail cinco vezes.

Além disso, agentes não devem ter permissão autônoma para enviar e-mails críticos. Implemente uma fila de aprovação para o conteúdo gerado por agentes, garantindo que o endereço "From" e o conteúdo estejam de acordo com sua marca e suas políticas de autenticação.

O custo da infraestrutura de entrega

A escolha do provedor de envio afeta a forma como você gerencia o DMARC. Alguns provedores tornam a configuração do DKIM trivial, enquanto outros exigem entradas DNS manuais para cada subdomínio.

Ao avaliar custos, considere o custo total de propriedade. Por exemplo, enviar 50.000 e-mails custa aproximadamente 5 USD no Amazon SES na modalidade avulsa (a 0.10 USD por 1.000 e-mails), enquanto os planos do Postmark custariam cerca de 66 USD pelo mesmo volume (15 USD por 10.000 mais excedentes entre 1.20 e 1.80 USD por 1.000).

Outras opções incluem o Resend, que oferece um plano gratuito de 3.000 e-mails por mês (limitado a 100 por dia), ou o Mailgun, a partir de 15 USD por mês para 10.000 e-mails. O SendGrid agora usa um teste de 60 dias no lugar do plano gratuito, com o Essentials a partir de 19.95 USD por mês.

Seja qual for o provedor, a política DMARC continua sendo o principal escudo do seu domínio. Se você usa um provedor que só oferece suporte a SPF, corre mais risco de falhas de entrega ao passar para p=reject, porque o SPF quebra no encaminhamento de e-mails. O DKIM é a única forma de manter o alinhamento em encaminhamentos.

Modos de falha comuns

A armadilha do encaminhamento

O usuário A envia um e-mail ao usuário B. O usuário B tem um encaminhamento automático para o usuário C. O servidor que encaminha costuma trocar o remetente do envelope pelo próprio domínio para não ser marcado como spam. Isso quebra o alinhamento do SPF. Se você tem p=reject e nenhuma assinatura DKIM, o usuário C nunca verá o e-mail.

O limite de consultas DNS

Os registros SPF são limitados a 10 consultas DNS. Se você adicionar provedores demais ao seu registro SPF, o receptor retornará um permerror. Isso causa uma falha de DMARC. Para resolver, use um provedor que priorize a autenticação por DKIM ou use SPF flattening.

O problema da "shadow IT"

Equipes de marketing costumam assinar ferramentas novas (por exemplo, um novo serviço de newsletter) sem avisar a engenharia. Elas enviam e-mails a partir do seu domínio, falham no DMARC e são rejeitadas. É por isso que a fase p=none não é negociável.

Tabela-resumo para operadores

Política | Ação | Risco | Visibilidade | Uso recomendado

p=none | Nenhuma | Baixo | Alta | Descoberta e auditoria

p=quarantine | Pasta de spam | Médio | Alta | Testes e transição

p=reject | Bloqueio | Alto | Média | Segurança total em produção

Para se aprofundar na implementação técnica desses registros, consulte nosso guia sobre DKIM, SPF e DMARC.

Gerenciar esses registros manualmente é trabalhoso. O SendHQ simplifica isso oferecendo envio transacional com domínio verificado e ferramentas para deixar sua infraestrutura pronta para agentes.

Saiba mais em https://sendhq.cc.