Seu DMARC está em none. O que ele realmente faz pelo seu e-mail?

Seu registro DMARC existe. É válido. Algo ainda diz que a política está em none, e a implicação é que você não terminou.

Faz sentido. Uma política p=none é uma política de verdade, publicá-la foi o primeiro movimento certo, e deixá-la assim indefinidamente entrega uma fração do que o DMARC existe para dar. Resposta curta: ela coleta evidência e não aplica nada, o que significa que quem falsifica seu domínio hoje ainda chega à caixa de entrada.

O que um registro p=none coleta?

Um registro DMARC fica assim:

v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1

A tag p diz aos servidores que recebem o que fazer com e-mail que alega ser do seu domínio e falha no DMARC. São três valores: none, quarantine e reject.

Em p=none, o receptor avalia a mensagem exatamente como avaliaria em qualquer outra política. Verifica se o SPF passou e se o domínio do SPF se alinha ao domínio do From que seu leitor vê. Verifica o mesmo para o DKIM. Chega a um veredito. Depois entrega a mensagem como entregaria se você nunca tivesse publicado DMARC algum, e manda um relatório por e-mail contando o que viu.

Ou seja, p=none muda o seu relatório, não a sua entrega. Uma mensagem falsificada alegando ser do seu domínio ainda chega à caixa de entrada do seu cliente. Você só fica sabendo no dia seguinte, em XML.

Isso é genuinamente útil, e é por isso que toda implantação segura começa aqui. Deixa de ser útil no instante em que ninguém lê os relatórios.

Faça isto: abra seu registro DMARC e confirme que existe um endereço rua= nele. Um registro p=none sem rua é a única configuração que não entrega absolutamente nada.

Por que domínios ficam presos em none

Três motivos cobrem quase todos os casos.

Ninguém leu os relatórios. Relatórios agregados chegam como anexos XML compactados em gzip, um por dia, de cada provedor para quem você envia. São ilegíveis por natureza em qualquer volume. Se os relatórios vão para uma caixa compartilhada que ninguém abre, o domínio fica em none para sempre, porque migrar para a aplicação sem lê-los é genuinamente perigoso.

Existe uma fonte desalinhada e ninguém é dono dela. Os relatórios mostram um IP de envio que falha no alinhamento, enviando volumes pequenos, e ninguém na empresa o reconhece. Costuma ser uma ferramenta de faturamento esquecida, um plugin de formulário ou uma caixa que um ex-funcionário configurou. Aplicar a política quebraria esse envio, então a política fica.

Um fornecedor não consegue alinhar. Algumas plataformas enviam como seu domínio do From, mas assinam com o próprio e não oferecem jeito de adicionar uma chave DKIM sua. Nesse caso a fonte nunca passa no alinhamento, e você precisa ou trocar o fornecedor, ou movê-lo para um subdomínio com política própria, ou aceitar que o e-mail dele vá para a quarentena.

A pista de cada um está nos relatórios: o primeiro aparece como uma caixa de entrada cheia que ninguém abriu, o segundo como um IP de baixo volume sem domínio DKIM correspondente, o terceiro como uma fonte de alto volume que falha no alinhamento consistentemente enquanto o SPF dela passa.

Faça isto: classifique cada fonte nas últimas duas semanas de relatórios nesses três grupos antes de tocar na política.

O alinhamento é o que as pessoas deixam passar

O DMARC não pergunta se o SPF passou. Pergunta se o domínio que passou corresponde ao domínio que seu leitor vê na linha From.

Uma mensagem enviada por um fornecedor pode passar no SPF perfeitamente, para o domínio de bounce do próprio fornecedor, e mesmo assim falhar no DMARC porque esse domínio de bounce não tem nada a ver com o seu. No relatório agregado ela aparece assim:

<row>
  <source_ip>198.51.100.24</source_ip>
  <count>412</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <spf><domain>vendor-bounces.net</domain><result>pass</result></spf>
</auth_results>

O SPF passou. O DMARC falhou. O resultado spf dentro de policy_evaluated é o veredito alinhado, e é o único que decide alguma coisa.

Esse é o motivo número um de uma configuração que parece correta em todo verificador ainda falhar no DMARC. Os verificadores confirmam que seus registros têm sintaxe válida. Alinhamento é sobre a relação entre dois domínios na hora do envio, o que nenhuma checagem estática de registro enxerga.

Faça isto: para cada fonte com falha, compare header_from com os domínios de SPF e DKIM em auth_results. Se não corresponderem, você tem um problema de alinhamento, não de registro.

Subindo a escada com segurança

O caminho é none, depois quarantine com uma porcentagem, depois reject. O critério entre cada degrau é o mesmo: nenhuma fonte legítima está falhando.

Quarantine com porcentagem é o passo que as pessoas pulam, e é justamente o que torna o processo inteiro seguro:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@example.com

Isso manda um quarto do e-mail que falha para a pasta de spam e deixa o resto em paz. Se você errou em algo, descobre com um quarto do raio do estrago. Eleve pct para 50, depois 100, então mude para p=reject e remova a tag.

Se você tem um fornecedor que não consegue alinhar, coloque-o em um subdomínio e dê ao subdomínio uma política própria mais fraca com sp=. Isso deixa o domínio raiz ir para reject enquanto o remetente problemático segue funcionando.

Faça isto: defina p=quarantine; pct=25 hoje se toda fonte sua já passa, e agende o próximo passo para daqui a duas semanas.

Confirmando que a mudança entrou em vigor

Depois de qualquer edição de DMARC, duas coisas precisam de confirmação: o registro tem a sintaxe que você pretendia, e os relatórios continuam chegando.

O gerador gratuito de registro DMARC mostra a string exata do registro para a política que você quer, que é o jeito mais rápido de conferir que nenhuma tag saiu trocada. O check gratuito de saúde de e-mail lê o registro publicado de volta do DNS depois que o TTL expira, junto com seu SPF e DKIM, para você ver o que os receptores estão vendo de fato, e não o que você pretendia publicar.

Ambos respondem para um domínio, no momento em que você pergunta.

Esse é o limite honesto. Uma política DMARC não é algo que você define e encerra. Registros são editados durante migrações de DNS sem nenhuma relação. Um fornecedor novo entra por decisão de um colega e começa a falhar no alinhamento numa segunda-feira, e os relatórios que contariam isso chegam na terça, em XML, numa caixa que ninguém abre. O vão entre publicar uma política reject e saber que ela ainda vale, com toda fonte legítima ainda passando, é onde domínios quebram em silêncio.

Esse vão é o produto. O LitInboxes reverifica cada domínio monitorado a cada 6 horas, converte os relatórios DMARC agregados e forenses numa visão fonte por fonte em vez de XML, guarda o histórico datado para você ver quando uma fonte apareceu, e alerta você na mudança, não num cronograma. Alertas por e-mail estão em todos os planos, e por Slack, Discord ou webhook no Pro. Há uma demonstração ao vivo se você quiser ver a visão de relatórios antes de assinar qualquer coisa.

Se a dúvida maior por trás disso é por que seus e-mails caem na pasta de spam, DMARC é um de quatro sinais que valem checagem, e o diagnóstico completo cobre os outros três.

O checklist

1. Confirme que seu registro tem um endereço rua= e que os relatórios estão chegando num lugar que uma pessoa olha.
2. Acumule pelo menos duas semanas de relatórios, idealmente um ciclo de faturamento completo.
3. Liste toda fonte de envio e classifique cada uma: sua, de um fornecedor autorizado ou desconhecida.
4. Compare header_from com os domínios de SPF e DKIM de cada fonte com falha para achar as lacunas de alinhamento.
5. Corrija o alinhamento de tudo que é seu, preferindo DKIM.
6. Mova todo fornecedor que não conseguir alinhar para um subdomínio com política sp= própria.
7. Publique p=quarantine; pct=25 e acompanhe as contagens de falha por duas semanas.
8. Eleve pct para 100, depois publique p=reject.