Registro DMARC: como configurar o DMARC passo a passo (p=none → quarantine → reject)

Um registro DMARC é uma linha de texto no DNS, mas ele decide o que acontece com e-mails que dizem vir do seu domínio e falham na autenticação. Se for configurado sem cuidado, você acaba não protegendo nada ou bloqueando as suas próprias faturas. Este guia percorre cada tag, traz exemplos prontos e um plano de implantação de p=none até p=reject.

Se SPF, DKIM e alinhamento são novidade para você, comece por SPF, DKIM e DMARC explicados, pois o DMARC se baseia nos dois.

Onde fica o registro DMARC

O DMARC é um registro TXT no subdomínio _dmarc do domínio usado no endereço From:

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

Só pode haver um registro DMARC por nome. Se um servidor receptor encontrar dois, ele ignora o DMARC desse domínio. Um subdomínio sem registro próprio herda o registro do domínio organizacional (example.com).

Tags do DMARC explicadas

Alinhamento relaxado vs estrito. Relaxado significa que os domínios só precisam compartilhar o domínio organizacional: uma assinatura DKIM com d=news.example.com se alinha com o From example.com. O estrito exige correspondência exata. O relaxado é a escolha certa para quase todo mundo.

Exemplos de registros DMARC

Somente monitoramento: o ponto de partida seguro:

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

Quarentena para um quarto dos e-mails com falha:

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

Proteção total, incluindo subdomínios:

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

Um domínio que nunca envia e-mails (combinado com v=spf1 -all):

v=DMARC1; p=reject; sp=reject

Você pode colar qualquer um destes no verificador de DMARC depois de publicar, para confirmar a sintaxe e ver como cada tag é interpretada.

Como configurar o DMARC passo a passo

1. Verifique primeiro se SPF e DKIM funcionam. Confira-os com o verificador de SPF e o verificador de DKIM. DMARC sem eles apenas coleta relatórios de falhas.
2. Escolha um endereço para os relatórios. Os relatórios agregados são arquivos XML, muitas vezes dezenas por dia em um domínio ativo. Use uma caixa de e-mail dedicada ou um serviço de relatórios DMARC em vez da sua caixa de entrada pessoal.
3. Publique p=none com rua no painel do seu provedor de DNS: host _dmarc, tipo TXT.
4. Colete relatórios por 2 a 4 semanas para que apareçam os remetentes semanais e mensais (faturas, folha de pagamento, newsletters).
5. Corrija toda fonte legítima que falhar: ative o DKIM com o seu domínio nesse serviço ou adicione-a ao SPF com um Return-Path alinhado.
6. Passe para p=quarantine, opcionalmente com pct=25, depois 50 e 100, acompanhando os relatórios após cada etapa.
7. Passe para p=reject quando a quarentena funcionar sem problemas por algumas semanas.

Como ler relatórios agregados

Cada relatório cobre um destinatário e um período, geralmente um dia. Dentro dele você encontrará linhas como estas, simplificadas:

Como interpretar:

• Ambos alinhados: seu servidor de e-mail principal, tudo certo.
• SPF passa mas não está alinhado, DKIM falha: um serviço de terceiros típico, que envia com o próprio Return-Path e sem a sua chave DKIM. Descubra a quem pertence o IP e ative o DKIM para o seu domínio nele. Com p=reject, esse e-mail seria bloqueado.
• Tudo falha em um IP desconhecido: ou é um sistema esquecido ou alguém está falsificando o seu domínio. Combater a falsificação é a função do DMARC; antes, só confirme que não é um servidor seu que foi esquecido.

Além das linhas, todo relatório tem um cabeçalho: o nome da organização que o enviou (Google, Yahoo, Microsoft e outras), o intervalo de datas que ele cobre e a política encontrada no seu DNS naquele momento. Essa última informação é uma boa verificação de consistência: se o relatório mostra p=none uma semana depois de você publicar quarantine, o destinatário ainda está vendo um registro antigo ou duplicado. Os relatórios são enviados como anexos compactados (zip ou gzip), um por destinatário por dia, então um domínio ativo acumula centenas de arquivos rapidamente.

O XML bruto é difícil de ler em grande volume, por isso a maioria das equipes usa um serviço de análise. Mesmo sem um, abrir alguns relatórios manualmente durante a primeira semana basta para identificar remetentes desconhecidos.

Política de subdomínios

A tag sp define a política para subdomínios que não têm um registro DMARC próprio. Duas configurações típicas:

• p=reject; sp=reject: tudo protegido quando você estiver confiante.
• p=reject; sp=none: o domínio principal está protegido, os subdomínios ainda estão em teste. Não deixe assim por muito tempo: invasores adoram falsificar billing.example.com.

Um subdomínio que envia o próprio e-mail, como news.example.com, pode ter seu próprio registro _dmarc.news.example.com, que substitui o sp.

Envio de relatórios para outro domínio

Se o endereço rua estiver em um domínio diferente, normalmente um serviço de análise de relatórios, esse domínio precisa concordar em receber os seus relatórios. Caso contrário, os destinatários ignoram o endereço. A autorização é um registro TXT no lado receptor:

example.com._report._dmarc.reports-provider.net.  TXT  "v=DMARC1"

Os serviços de relatórios geralmente o publicam para você, ou uma versão com curinga que cobre todos os clientes. O verificador de DMARC confere esse registro para cada endereço externo em rua e ruf.

Erros comuns em registros DMARC

• Nome de host incorreto. O registro deve ficar em _dmarc, não no próprio domínio. Se o seu painel de DNS acrescenta o domínio automaticamente, digite apenas _dmarc, caso contrário você acaba com _dmarc.example.com.example.com.
• v=DMARC1 fora da primeira posição ou com erro de digitação, por exemplo v=DMARC 1 com um espaço. Os provedores de destino tratam o registro como inexistente.
• Falta de mailto: em rua. O valor deve ser um URI: rua=mailto:dmarc@example.com, e não apenas o endereço.
• Dois registros DMARC deixados para trás após a troca de serviço de relatórios. Mantenha exatamente um e coloque vários endereços em rua, separados por vírgulas.
• Política endurecida, mas ninguém lê os relatórios. Um registro p=reject com uma caixa de correio rua cheia ou sem leitura significa que você não vai perceber quando um novo serviço começar a falhar.

Após cada alteração, dê tempo para o DNS atualizar (geralmente de alguns minutos a algumas horas, dependendo do TTL do registro) e confira o resultado com o verificador de DMARC. Os primeiros relatórios agregados normalmente chegam em até um ou dois dias, porque a maioria dos provedores os envia uma vez por dia.

O que quebra com p=reject

• Listas de e-mail que adicionam rodapés ou tags no assunto quebram o DKIM, e o IP do servidor da lista quebra o SPF. Muitas listas hoje reescrevem o endereço From para evitar isso; o ARC ajuda os provedores a confiar em e-mails encaminhados.
• Encaminhamento simples quebra o SPF, mas mantém o DKIM se a mensagem não for modificada: mais um motivo para tornar o DKIM sua principal verificação alinhada.
• Formulários de site que enviam "de" o endereço do visitante ou do seu domínio por meio do e-mail do próprio servidor de hospedagem. Envie por um serviço autenticado com o seu domínio.

Antes de uma mudança de domínio desse porte, verifique também se os seus registros MX estão corretos com a consulta de MX: os relatórios voltam por e-mail e precisam de um lugar para chegar.