DMARC em Email Marketing: O Que É e Como Configurar com Segurança

SPF autoriza o caminho. DKIM assina a mensagem. DMARC (Domain-based Message Authentication, Reporting and Conformance) é a política que junta os dois e responde: “se a autenticação falhar, o que o provedor deve fazer?” — e ainda manda relatório de quem tentou usar o seu domínio.

Sem DMARC, você autentica no escuro. Com DMARC mal feito (p=reject cedo demais), corta email legítimo. Com DMARC certo, a entregabilidade de email marketing ganha proteção contra spoofing e visibilidade de falha.

Este é o post 5: o que é DMARC, alinhamento, políticas none / quarantine / reject, relatórios e um caminho seguro pra implementar.

O que é DMARC (em operação)

DMARC é um registro TXT no DNS, em geral:

_dmarc.seudominio.com.br

Ele diz:

1. Exijo que SPF e/ou DKIM passem e estejam alinhados com o From.
2. Se falhar, a política é none, quarantine ou reject.
3. Mandem relatórios agregados (e opcionalmente forenses) pra estes emails.

Alinhamento (do post de DKIM): o domínio autenticado precisa combinar com o domínio do From que a pessoa vê — modo relaxed (mesmo domínio organizacional) ou strict (match exato), conforme a tag adkim / aspf.

Por que DMARC importa no email marketing

1. Anti-spoofing — dificulta golpe usando @suaempresa.com.br.
2. Sinal moderno pra Gmail/Yahoo e afins — política publicada virou expectativa.
3. Diagnóstico — relatórios mostram falha de ESP, forwarding e abuso.
4. Fecha o trio — SPF + DKIM sem DMARC é autenticação incompleta.

Anatomia do registro DMARC

Exemplo inicial (só monitoramento):

v=DMARC1; p=none; rua=mailto:dmarc@suaempresa.com.br; ruf=mailto:dmarc-forense@suaempresa.com.br; fo=1

Tag	Função
v=DMARC1	Versão
p=	Política: none / quarantine / reject
sp=	Política pra subdomínios (opcional)
rua=	Relatórios agregados (XML)
ruf=	Relatórios forenses (cuidado com volume/PII)
pct=	% de mensagens sob a política (útil na subida)
adkim / aspf	r relaxed (padrão) ou s strict

Começa simples: p=none + rua. Forense (ruf) só se souber tratar.

Caminho seguro: none → quarantine → reject

Fase 1 — p=none (obrigatória)

Publica, espera relatório, não bloqueia ainda.

Olha:

• Envios legítimos falhando (ESP sem DKIM, SPF errado, From desalinhado)
• Fontes desconhecidas (spoof / marketing paralelo / tool esquecida)

Corrige os legítimos antes de apertar a política.

Fase 2 — p=quarantine

Falhas tendem a ir pro spam. Use pct=10 (depois 25, 50…) se quiser subir gradual.

Fase 3 — p=reject

Falhas tendem a ser rejeitadas. Só quando a telemetria estiver limpa e todos os caminhos de envio autenticados.

Erro clássico: pular pra reject no mesmo dia em que descobriu DMARC. Vai quebrar boleto, CRM, helpdesk e o ESP “esquecido”.

DMARC no dia a dia com vários remetentes

Mapeia tudo que manda com From no seu domínio:

• ESP de marketing
• Transacional
• Google / Microsoft
• CRM, suporte, ferramenta de cobrança

Cada um precisa de SPF include e/ou DKIM alinhado. DMARC não “conserta” DNS — ele expõe o que está quebrado.

Ferramenta de parsing de relatório (ou o próprio ESP) ajuda a ler o XML do rua. Sem leitura, p=none vira teatro.

Exemplo de leitura rápida de um fail no relatório

Quando o XML (ou o dashboard) mostrar fail, pergunta nesta ordem:

1. É um serviço nosso? (ESP, cobrança, CRM) → consertar SPF/DKIM/alinhamento.
2. É encaminhamento (lista interna, “forward to Gmail”)? → às vezes esperado; DMARC + forwarding é terreno conhecido — não aperta reject sem entender.
3. É desconhecido / volume suspeito? → spoof; sobe a política quando o resto estiver limpo.

Essa triagem evita tratar todo fail como ataque — e o erro inverso de ignorar tool legítima fora do DNS.

Relação com entregabilidade (sem milagre)

DMARC bom:

• Reduz abuso do domínio
• Melhora confiança dos filtros
• Dá mapa de falhas

DMARC não:

• Substitui lista limpa
• Compensa reclamação em massa
• Transforma conteúdo ruim em inbox

É o fecho da autenticação — não o fim da série.

Checklist: esta semana

1. Publica _dmarc com p=none e um rua que alguém vai ler.
2. Confirma SPF (#3) e DKIM (#4) nos caminhos reais de envio.
3. Uma semana de relatórios: lista fontes fail.
4. Corrige legítimos; trata abuso.
5. Só então planeja quarantine (com pct se fizer sentido).
6. Documenta quem pode criar From no domínio — senão a política vira briga interna.

FAQ

Preciso de DMARC se já tenho SPF e DKIM?

Sim, se leva marca e entregabilidade a sério. É a política + o reporting.

p=none já ajuda?

Ajuda a ver. Proteção forte vem com quarantine/reject — depois dos dados.

Subdomínio precisa de DMARC próprio?

Pode herdar via sp= ou ter registro próprio. Se news. envia marketing, trata alinhamento nesse nome.

Relatório DMARC é a mesma coisa que Postmaster Tools?

Não. DMARC mostra autenticação/abuso por fonte. Postmaster (post 9 da série) olha reputação no Gmail. Os dois se complementam.

Próximo passo

Com SPF, DKIM e DMARC no lugar, a autenticação deixa de ser o buraco óbvio. Na sequência da série: spam na prática, hard bounce, engajamento e monitoramento (incluindo cenário BR).

Enquanto isso: p=none, lê o rua, fecha falhas legítimas. Apertar a política sem telemetria é tiro no próprio From.