O que é o DMARC e como funcionam as políticas?

Como é um registro DMARC, e o que significam as tags?

A RFC 7489 define o DMARC como um registro TXT publicado em _dmarc.dominio, usando o mesmo estilo de tag=valor do SPF e do DKIM. As tags mais importantes:

• v=DMARC1 - a tag de versão, obrigatória e precisa vir primeiro.
• p= - a política solicitada para o próprio domínio: none, quarantine ou reject.
• sp= - uma política separada e opcional para subdomínios; sem ela, os subdomínios herdam p=.
• pct= - a porcentagem de mensagens que falham a que a política se aplica, de 0 a 100 (padrão 100).
• rua= - um ou mais endereços mailto: que recebem relatórios agregados diários resumindo o que passou e o que falhou.
• adkim= / aspf= - modo de alinhamento para DKIM e SPF respectivamente, r para relaxado (o padrão) ou s para estrito.

O que as três políticas realmente fazem?

p=none pede aos receptores que não tomem nenhuma ação especial em uma mensagem que falha; ela ainda é entregue normalmente, mas o dono do domínio começa a receber relatórios sobre o que está falhando e por quê. p=quarantine pede aos receptores que tratem uma mensagem que falha como suspeita, o mais comum sendo encaminhá-la para uma pasta de spam ou lixo eletrônico em vez de rejeitá-la de imediato. p=reject pede aos receptores que recusem a mensagem durante a própria transação SMTP, então ela nunca chega a uma caixa de entrada.

Nenhuma dessas é uma ordem que um servidor receptor é forçado a obedecer; o DMARC é um pedido que o dono do domínio publica, e o quão rigorosamente um provedor de caixa de entrada específico o respeita depende desse provedor. Na prática, os grandes provedores de caixa de entrada aplicam de perto as políticas DMARC publicadas, e é exatamente por isso que acertar o registro antes de torná-lo mais rígido importa. O caminho seguro é começar em p=none com o rua apontado para um endereço que alguém lê, confirmar que toda fonte de envio legítima está passando no alinhamento, e só então avançar para quarantine e por fim reject, muitas vezes com o pct aumentado aos poucos em vez de saltar direto para 100.

O que é alinhamento, e por que uma mensagem pode passar no SPF mas ainda falhar no DMARC?

O DMARC não pergunta só "o SPF passou" ou "o DKIM passou" isoladamente. Ele exige que o domínio no cabeçalho visível From:, o endereço que uma pessoa realmente lê, esteja alinhado com o domínio que o SPF ou o DKIM autenticou. A RFC 7489 define dois modos de alinhamento: relaxado, em que o domínio organizacional precisa coincidir (então news.example.com se alinha com example.com), e estrito, em que os domínios precisam coincidir exatamente.

É por isso que uma mensagem pode passar no SPF e ainda assim falhar no DMARC. O SPF verifica o domínio do remetente de envelope, o endereço usado na transação SMTP, que muitas vezes é um domínio diferente daquele mostrado no cabeçalho visível From:, muitas plataformas de marketing e serviços de encaminhamento usam o próprio domínio deles como remetente de envelope enquanto exibem o domínio do cliente em From:. O SPF em si passa sem problemas para o domínio dessa plataforma, mas a verificação de alinhamento do DMARC compara esse domínio aprovado com o domínio de From:, não encontra correspondência e falha. A mesma lógica se aplica ao DKIM: uma mensagem validamente assinada por um domínio terceiro sem relação nenhuma não ajuda o DMARC, a menos que o domínio de assinatura (d=) também se alinhe com o From:. Uma mensagem precisa que pelo menos um entre SPF ou DKIM passe e esteja alinhado com o domínio de remetente visível para que o DMARC passe no geral.

Para que servem os relatórios agregados?

A tag rua indica para onde os receptores devem enviar relatórios agregados, documentos XML resumindo, em um período de aproximadamente um dia por vez, quais fontes de envio mandaram e-mail alegando ser do domínio, e se cada uma passou ou falhou no SPF, no DKIM e no alinhamento. Esses relatórios são a ferramenta prática para encontrar toda fonte de envio legítima antes de apertar uma política: um domínio muitas vezes descobre um serviço de e-mail transacional esquecido, ou uma plataforma de marketing antiga que ainda envia e-mail que falharia no alinhamento, bem antes de esse e-mail começar a ser rejeitado. O formato XML é feito para ser processado por uma ferramenta de leitura de relatórios, não para leitura direta a olho nu, então a maioria dos domínios encaminha esses relatórios por um software que os transforma em um resumo legível em vez de abrir os arquivos brutos diretamente.

Para que serve o pct, e por que usá-lo?

A tag pct limita a política solicitada a apenas essa porcentagem das mensagens que falham no DMARC, escolhidas ao acaso; o restante das mensagens que falham é tratado como se a política fosse none. Um registro com p=quarantine; pct=25 só pede quarentena para aproximadamente um quarto do tráfego que falha. Isso existe especificamente para uma implantação cautelosa: em vez de passar direto do monitoramento para a aplicação total em cada mensagem, um domínio pode aplicar a política mais rígida a uma fatia do tráfego que falha, observar o efeito e aumentar a porcentagem aos poucos até chegar a 100.

Como funciona a política de subdomínio?

A tag sp define uma política especificamente para subdomínios, separada da tag p principal. Sem sp, todo subdomínio herda o que p diz. Isso importa porque os subdomínios são um alvo comum de falsificação justamente porque muitos domínios nunca configuraram e-mail neles, uma política como p=reject; sp=reject fecha essa brecha rejeitando e-mail que alega vir de qualquer subdomínio, mesmo os que nunca foram configurados para enviar e-mail. A tag só define uma regra geral para todos os subdomínios juntos; ela não consegue definir uma política diferente para cada subdomínio individualmente.

Um exemplo completo

v=DMARC1; p=quarantine; sp=reject; pct=50; rua=mailto:[email protected]; adkim=r; aspf=r

Esse registro coloca em quarentena metade do e-mail que falha e que alega vir do próprio domínio, enquanto avança em fases rumo à aplicação total, rejeita todo e-mail que falha e alega vir de qualquer subdomínio, usa alinhamento relaxado tanto para SPF quanto para DKIM, e envia relatórios agregados diários para o endereço indicado.

O DMARC só faz sentido depois que SPF e DKIM já estão configurados: veja o que é um registro SPF e o que é o DKIM para esses dois registros, e como verificar os três para os comandos que confirmam se cada um está realmente funcionando. A ferramenta gratuita de consulta MX lista os servidores de e-mail de um domínio a partir da própria rede de pontos de verificação da HostTracker, útil junto com uma verificação de DMARC ao revisar a configuração completa de e-mail de um domínio.

Perguntas frequentes

Preciso ter SPF e DKIM configurados antes de adicionar um registro DMARC?

O registro DMARC em si não exige que eles existam, mas, sem pelo menos um funcionando e alinhado, praticamente todo o e-mail do domínio falha no DMARC. Configure o SPF e o DKIM primeiro, depois adicione o DMARC em p=none para observar os resultados antes de pedir qualquer aplicação.

O que acontece com uma mensagem que falha sob uma política de quarentena?

O DMARC só carrega o pedido; o sistema de e-mail receptor decide como agir sobre ele. Quarentena, na maioria das vezes, significa que a mensagem cai em uma pasta de spam ou lixo eletrônico em vez da caixa de entrada, mas o tratamento exato é escolha do receptor.

Subdomínios diferentes podem ter políticas DMARC diferentes?

Não somente pelo registro DMARC. A tag sp define uma única política que se aplica a todos os subdomínios em conjunto; não existe uma substituição por subdomínio dentro do próprio DMARC.

Por que alguns domínios ficam em p=none indefinidamente?

Geralmente porque ninguém voltou para revisar os relatórios agregados e apertar a política depois da configuração inicial. Um registro deixado em none coleta dados para sempre, mas nunca bloqueia de fato uma mensagem forjada, o que é uma lacuna comum e evitável coberta no próximo guia.

O DMARC impede phishing que não usa o nome do domínio protegido?

Não. O DMARC só rege e-mails que alegam vir exatamente do domínio (ou dos subdomínios) que publicou o registro. Um domínio parecido, com um caractere trocado, por exemplo, é um domínio totalmente diferente e não é afetado pela política DMARC de outro domínio.