Política DMARC

O que esta verificação faz

Consulta o DNS pelo registo TXT _dmarc.<teudominio> e analisa a sua política. Reporta o valor de p= (none, quarantine, reject), a percentagem, os endereços de relatórios, e se a política está a ser aplicada (qualquer coisa para lá de p=none).

Porque é importante

O DMARC (Domain-based Message Authentication, Reporting, and Conformance) diz às caixas de entrada recetoras — Gmail, Outlook, Yahoo, Apple iCloud — o que fazer quando um email afirma vir do teu domínio mas falha as verificações SPF ou DKIM. Sem uma política DMARC, a resposta é “deixar passar” — e o teu domínio torna-se terreno gratuito para campanhas de phishing.

Desde fevereiro de 2024, Google e Yahoo exigem DMARC para qualquer remetente que envie a utilizadores seus mais de 5000 vezes por dia. A Microsoft seguiu com aplicação progressivamente mais estrita. Sites sem DMARC veem a entregabilidade cair, os clientes recebem phishing com a marca deles, e a confiança erode-se uma fatura falsa de cada vez.

Um exemplo real: uma SaaS que auditámos não tinha DMARC. Em três meses, atacantes spoofaram billing@oseudominio.com numa campanha de phishing que atingiu ~40 mil caixas de clientes deles. O cleanup custou mais do que uma década de “depois tratamos do DMARC”.

Como corrigir

Publica um registo TXT _dmarc no fornecedor de DNS do teu domínio. A progressão:

1. Começa em modo de monitorização (p=none) — recolhe dados sem afetar entregabilidade.

_dmarc.teudominio.com.   IN   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@teudominio.com; pct=100"

O endereço rua= recebe relatórios XML agregados de todas as caixas recetoras. Reencaminha-os para uma ferramenta que os analise — recomendamos o monitoring DMARC gratuito da Postmark ou o Valimail Monitor.

2. Audita o que envia legitimamente.

Os relatórios dizem-te que IPs e serviços enviam mail “como” o teu domínio. Esperado: o teu fornecedor de email transacional (Resend, Postmark, SendGrid), a tua plataforma de marketing, possivelmente Google Workspace ou Microsoft 365, e a tua ferramenta de helpdesk. Tudo o resto é um remetente não autorizado ou uma integração esquecida.

Para cada remetente legítimo, configura SPF e DKIM — o DMARC requer que um deles passe e alinhe com o cabeçalho From.

3. Passa a quarentena quando os relatórios estão limpos (nenhum remetente legítimo a falhar).

_dmarc.teudominio.com.   IN   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@teudominio.com; pct=25"

pct=25 aplica a política apenas a 25% do mail que falha — rollout gradual. Vê os relatórios, depois aumenta para 100, depois passa para p=reject.

4. Estado final: p=reject.

_dmarc.teudominio.com.   IN   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc-reports@teudominio.com; ruf=mailto:dmarc-forensics@teudominio.com; adkim=s; aspf=s"

adkim=s e aspf=s exigem alinhamento estrito entre o cabeçalho From e o domínio SPF/DKIM — travam atacantes que usem truques com subdomínios.

Configurações comuns:

• Email de marketing a partir de noreply@email.teudominio.com — configura uma política DMARC separada no subdomínio se a tua plataforma de marketing não consegue alinhar totalmente com o apex.
• Google Workspace — a chave DKIM do próprio Google tem de estar no DNS; ativa o DKIM na Consola de administração.
• Resend / Postmark / SendGrid — cada um fornece um template DNS para colar; o DMARC funciona assim que o DKIM estiver pronto.

Verifica o teu registo:

dig +short TXT _dmarc.teudominio.com
# v=DMARC1; p=reject; rua=mailto:dmarc-reports@teudominio.com; adkim=s; aspf=s

Ou usa o verificador DMARC do Mail Tester para uma sanidade em um clique.

Emparelha isto com o básico de HTTPS — HTTPS, ativar HSTS — para uma linha de base completa de segurança de email + transporte.

Perguntas frequentes

Qual a diferença entre p=quarantine e p=reject?

• quarantine — mail que falha vai para spam. Recuperável; cauteloso.
• reject — mail que falha é devolvido no servidor recetor. O remetente (real ou fake) recebe um hard bounce. Proteção máxima, mas se o teu SPF/DKIM estiver mal configurado para um serviço legítimo, os teus clientes deixam de receber mail teu. Chega sempre a p=reject depois de um período em quarantine com relatórios limpos.

Preciso também de SPF e DKIM?

Sim. O DMARC é a camada de política; SPF e DKIM são as camadas de autenticação. O SPF diz “este IP pode enviar pelo meu domínio”; o DKIM assina a mensagem criptograficamente. O DMARC diz “se nenhum alinhar, rejeita o mail”. Os três são necessários para o sistema funcionar.

O meu domínio não envia email nenhum. Continuo a precisar de DMARC?

Sim — uma política DMARC “parqueada” trava atacantes a spoofar o teu domínio inativo:

_dmarc.teudominio.com.   IN   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc-reports@teudominio.com"

Emparelha com um registo SPF que não permite nada:

teudominio.com.   IN   TXT   "v=spf1 -all"

Agora nenhum IP na terra pode enviar mail a fingir ser do teu domínio.