DMARC. Passo a passo.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) é o pré-requisito inegociável para o BIMI. Um domínio com p=none nunca exibirá um logotipo no Gmail ou Apple Mail, independentemente de quão perfeitamente o arquivo SVG esteja configurado. Este guia aborda o caminho completo desde a implantação inicial até a aplicação total.

Pré-requisitos

Antes de criar um registro DMARC, confirme que os seguintes itens já estão configurados:

1. Registro SPF — Um registro TXT no domínio raiz especificando quais servidores de e-mail estão autorizados a enviar em seu nome. Exemplo: v=spf1 include:_spf.google.com -all
2. Registro DKIM — Uma chave pública publicada no DNS que os servidores receptores usam para verificar suas assinaturas de e-mail. Seu provedor de e-mail gera isso.
3. Acesso ao DNS — Acesso de escrita à zona DNS do seu domínio (Cloudflare, Route 53, GoDaddy ou o painel de controle do seu registrador).

O DMARC requer que pelo menos um dos protocolos, SPF ou DKIM, esteja corretamente configurado e alinhado com o domínio do cabeçalho From: para funcionar.

Etapa 1: Criar um Registro de Monitoramento (p=none)

Comece com uma política apenas de monitoramento. Isso registra falhas de autenticação sem afetar a entrega de e-mails.

_dmarc.seudominio.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Referência das tags:

| Tag | Obrigatória | Descrição | |---|---|---| | v=DMARC1 | Sim | Versão do protocolo. Deve vir primeiro. | | p=none | Sim | Política: apenas monitoramento, nenhuma ação tomada. | | rua=mailto: | Recomendada | Endereço de e-mail para relatórios agregados. | | pct=100 | Opcional | Porcentagem de e-mails sujeitos à política (padrão: 100). |

Publique este registro e aguarde de 48 a 72 horas para a propagação do DNS.

Etapa 2: Leia Seus Relatórios Agregados

Os relatórios agregados (RUA) chegam como anexos XML, geralmente uma vez por dia por fonte de envio. Eles mostram:

• Quais endereços IP enviaram e-mails usando seu domínio
• Se o SPF e o DKIM passaram ou falharam
• Quantas mensagens foram enviadas de cada fonte

O que observar: Qualquer serviço de envio legítimo (seu ESP, CRM, sistema de tickets, plataforma de marketing) que esteja falhando no alinhamento SPF ou DKIM deve ser corrigido antes de avançar para a aplicação. Migrar para p=reject com falhas de alinhamento não resolvidas fará com que e-mails legítimos sejam bloqueados.

Fontes comuns que requerem configuração separada de DKIM/SPF: Mailchimp, Salesforce, HubSpot, Zendesk, SendGrid, Google Workspace, Microsoft 365.

Etapa 3: Avançar para p=quarantine

Quando todas as fontes de envio legítimas passarem na autenticação, atualize a política para quarentena das mensagens que falharem:

_dmarc.seudominio.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

Comece com pct=25 para aplicar a política de quarentena a apenas 25% das mensagens que falharem. Monitore por uma a duas semanas. Se nenhum e-mail legítimo estiver sendo colocado em quarentena, aumente para pct=100.

Etapa 4: Avançar para p=reject

Aplicação total. Mensagens não autenticadas são rejeitadas imediatamente e nunca são entregues.

_dmarc.seudominio.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Este é o requisito mínimo para o BIMI. O Gmail e o Apple Mail não processarão seu registro BIMI a menos que seu domínio tenha p=quarantine ou p=reject com pct=100. Uma política de p=none é invisível para o BIMI — o logotipo nunca aparecerá, independentemente de quão corretamente o restante da configuração esteja.

Por Que p=none Bloqueia o BIMI

A especificação BIMI exige que os provedores de caixa de correio verifiquem se o domínio remetente possui uma política DMARC aplicada antes de exibir o logotipo. A lógica: um logotipo é um sinal de confiança. Exibir um logotipo para um domínio que não aplicou controles anti-spoofing permitiria que atacantes exibissem logotipos verificados em e-mails de phishing. p=none não oferece aplicação, então os provedores se recusam a honrar o registro BIMI.

Alinhamento: O Detalhe Que a Maioria dos Guias Ignora

O DMARC passa apenas quando o domínio autenticado está alinhado com o domínio do cabeçalho From:. Existem dois modos de alinhamento:

• Relaxado (padrão): O domínio organizacional deve corresponder. mail.exemplo.com se alinha com exemplo.com.
• Estrito: O domínio exato deve corresponder. mail.exemplo.com não se alinha com exemplo.com.

Para o BIMI, use alinhamento relaxado (adkim=r; aspf=r) a menos que você tenha um motivo específico para o estrito. O alinhamento estrito causa falhas para subdomínios e serviços de envio de terceiros.

Referência Completa do Registro

_dmarc.seudominio.com  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; pct=100"

| Tag | Valor | Significado | |---|---|---| | p=reject | Reject | Bloquear e-mails não autenticados | | sp=reject | Reject | Aplicar mesma política aos subdomínios | | adkim=s | Strict | Alinhamento DKIM deve ser exato | | aspf=s | Strict | Alinhamento SPF deve ser exato | | rua= | E-mail | Destino dos relatórios agregados | | pct=100 | 100% | Aplicar a todos os e-mails |

Próximos Passos

Quando seu domínio atingir p=reject:

1. Gere seu SVG BIMI — Use o makeBIMI™ para produzir um arquivo de logotipo em conformidade com o W3C SVG Tiny P/S. Gratuito, sem necessidade de cadastro.
2. Execute uma auditoria DMARC — A ferramenta makeBIMI Domain Audit verifica o status dos seus registros DMARC, SPF e BIMI em tempo real.
3. Obtenha um certificado — Para exibição do logotipo no Gmail, é necessário um VMC ou CMC. O veriBIMI℠ intermedia todo o processo de certificação, incluindo gerenciamento da aplicação DMARC, preparação do SVG e solicitação junto à CA.