Construtor de Registro DMARC

O DMARC Record Builder cria registros DNS Domain-based Message Authentication, Reporting, and Conformance (DMARC) através de uma interface interativa que o guia através de todas as tags de política disponíveis. Selecione uma política como p=reject configure endereços de relatório e obtenha um registro completo como v=DMARC1; p=reject; rua=mailto:[email protected] pronto para publicar em _dmarc.yourdomain.com.

Entendendo DMARC

DMARC é a camada de política que liga SPF e DKIM em um sistema coerente de autenticação de email. Por si só SPF verifica se o servidor de envio está autorizado. Por si só DKIM verifica que a mensagem não foi adulterada. Mas nenhum deles diz aos servidores receptores o que fazer quando verificações falham e nenhum requer que o domínio autenticado corresponda ao domínio no cabeçalho From que os usuários realmente veem. DMARC preenche ambas as lacunas: ele define uma política para lidar com falhas e requer alinhamento de domínio tornando muito mais difícil para atacantes falsificarem seu domínio em campanhas de phishing.

Quando você publica um registro DMARC você está dizendo a cada servidor de correio receptor na internet três coisas: como lidar com mensagens que falham em verificações SPF e DKIM (ignore-as, coloque-as em quarentena ou rejeite-as), para onde enviar relatórios sobre resultados de autenticação para que você possa monitorar o que está acontecendo e quão rigorosamente os domínios autenticados devem corresponder ao seu domínio de cabeçalho From. Sem DMARC um atacante phishing pode enviar um email que falha em SPF e DKIM para seu domínio mas o servidor receptor não tem política dizendo para rejeitar a mensagem -- pode aceitá-la mesmo assim e deixá-la cair na caixa de entrada do destinatário.

O outro grande benefício de DMARC é relatório. Quando você define um endereço rua servidores receptores enviam para você relatórios XML diários resumindo todas as mensagens que viram afirmando vir de seu domínio junto com os resultados SPF e DKIM para cada. Esses relatórios revelam remetentes não autorizados que você não sabia -- sejam phishers abusando seu domínio serviços legítimos que você esqueceu de adicionar ao seu registro SPF ou servidores de encaminhamento quebrando autenticação. Esta visibilidade é essencial antes que você aperte sua política porque mudar para p=reject sem entender seu ecossistema de email quase certamente bloqueará algum email legítimo.

Como Construir um Registro DMARC

1. Escolha sua política (p=): none para monitoramento, quarantine para pasta de spam, ou reject para bloquear falhas
2. Opcionalmente defina uma política de subdomínio (sp=) se subdomínios precisam de tratamento diferente
3. Defina a porcentagem (pct=) para aplicar gradualmente a política (por exemplo comece em 10%)
4. Digite o endereço de relatório agregado (rua=) para receber relatórios XML diários
5. Opcionalmente digite o endereço de relatório forense (ruf=) para relatórios de falha individuais
6. Configure modos de alinhamento (aspf=, adkim=) para correspondência estrita ou relaxada
7. Copie o registro gerado e publique-o como um registro TXT em _dmarc.yourdomain.com

Exemplos de Registro DMARC

Referência de Tag DMARC

Quando Usar o DMARC Record Builder

• Iniciando autenticação de email em um domínio sem política DMARC existente
• Rollout progressivo de DMARC -- mudança de p=none para quarantine para reject ao longo de semanas
• Configuração de relatórios DMARC para ganhar visibilidade em quem está enviando email como seu domínio
• Definição de políticas de subdomínio separadas quando subdomínios têm requisitos de email diferentes
• Auditoria de configurações de alinhamento para decidir entre correspondência estrita e relaxada para SPF e DKIM
• Cumprimento de requisitos de conformidade que obrigam imposição de DMARC (PCI DSS, NIST, mandatos governamentais)

Como a Autenticação DMARC Funciona

O Fluxo de Autenticação

Quando um servidor receptor obtém um email de seu domínio avalia DMARC nesta ordem:

1. Verificar SPF: O IP de envio corresponde ao registro SPF? O domínio RFC5321.MailFrom se alinha com o domínio do cabeçalho From?
2. Verificar DKIM: Há uma assinatura DKIM válida? O domínio de assinatura (d=) se alinha com o domínio do cabeçalho From?
3. Aplicar DMARC: Se um SPF ou DKIM passar e se alinhar DMARC passa. Se ambos falham ou nenhum se alinha aplique a política DMARC.

Alinhamento Relaxado vs. Estrito

• Relaxado (aspf=r, adkim=r): O domínio autenticado e o domínio From devem compartilhar o mesmo domínio organizacional. Exemplo: mail.example.com se alinha com example.com.
• Estrito (aspf=s, adkim=s): O domínio autenticado deve corresponder exatamente ao domínio From. mail.example.com não se alinha com example.com.

Alinhamento relaxado é o padrão e é apropriado para a maioria das organizações. Alinhamento estrito fornece proteção mais forte mas pode quebrar fluxos de email legítimo de subdomínios.

Estratégia de Rollout Recomendada

Semana 1-2:  v=DMARC1; p=none; rua=mailto:[email protected]
           -> Monitorar relatórios identificar todos os remetentes legítimos

Semana 3-4:  v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
           -> Quarentena 10% de falhas observar falsos positivos

Semana 5-6:  v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
           -> Aumentar para 50%

Semana 7-8:  v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]
           -> Começar a rejeitar 25% de falhas

Semana 9+:   v=DMARC1; p=reject; rua=mailto:[email protected]
           -> Imposição completa

Implantação DMARC na Prática

O maior risco em implantação DMARC é mudar para p=reject muito rapidamente. Muitas organizações publicam um registro DMARC com p=none coletam relatórios por uma ou duas semanas e então pulam direto para p=reject porque os relatórios parecem limpos. O problema é que alguns fluxos de email legítimo apenas acontecem periodicamente -- newsletters mensais notificações de cobrança trimestrais lembretes de renovação anuais -- e podem não aparecer em uma janela de relatório curta. A tag pct existe precisamente para este cenário: permite que você aplique sua política apenas uma porcentagem de mensagens com falha para que possa capturar problemas em escala sem bloquear todo seu email se algo der errado.

Uma surpresa comum durante implantação DMARC é descobrir quantos serviços enviam email em seu nome. Marketing envia através de Mailchimp tickets de suporte vêm do Zendesk faturas vão através de QuickBooks redefinições de senha vêm de Auth0 e alertas do sistema rotam através de PagerDuty. Cada um desses serviços precisa tanto passar em SPF (ao estar incluído em seu registro SPF) quanto passar em DKIM (ao assinar com uma chave alinhada ao seu domínio). A fase de monitoramento p=none é sua oportunidade de identificar todos esses serviços antes que a imposição comece. Use os relatórios agregados para construir um inventário completo de seus serviços de envio de email.

A política de subdomínio (sp=) merece pensamento cuidadoso. Por padrão subdomínios herdam a política do domínio pai. Se você defina p=reject em example.com também se aplica a mail.example.com, app.example.com e todos os outros subdomínios. Se alguns subdomínios enviam email através de infraestrutura diferente ou ainda não estão configurados para DKIM defina sp=none ou sp=quarantine para se dar espaço trabalhar em autenticação de subdomínio separadamente do domínio principal.

Perguntas Frequentes

Onde publico o registro DMARC em DNS?

Registros DMARC sempre são publicados como um registro TXT em _dmarc.yourdomain.com. Por exemplo se seu domínio é example.com o registro vai em _dmarc.example.com. Este é um local fixo definido pela especificação DMARC -- não há flexibilidade na nomenclatura.

Qual é a diferença entre relatórios rua e ruf?

A tag rua especifica onde os relatórios agregados são enviados -- estes são resumos XML diários mostrando resultados de autenticação para todas as mensagens. A tag ruf especifica relatórios forenses -- relatórios detalhados sobre mensagens individuais que falharam em autenticação. Muitos provedores apenas suportam relatórios agregados devido a preocupações de privacidade com dados forenses. Comece com rua apenas; adicione ruf se precisar de investigação de falha detalhada.

Posso enviar relatórios DMARC para um endereço de email em um domínio diferente?

Sim mas o domínio receptor deve publicar um registro de autorização DNS. Se seu domínio é example.com e relatórios vão para [email protected] então monitor.com deve publicar um registro TXT em example.com._report._dmarc.monitor.com com o valor v=DMARC1. Isto evita abuso onde alguém publica um registro DMARC direcionando uma enchente de relatórios para um endereço de email arbitrário.

O que pct=25 significa na prática?

Significa apenas 25% de mensagens que falham em DMARC terão a política aplicada. Os outros 75% são tratados como se a política fosse none (monitorados mas não acionados). Servidores receptores usam este porcentual probabilisticamente. Isto permite rampar gradualmente imposição e observar o impacto antes de ir para imposição completa em pct=100 (qual é o padrão quando pct é omitido).

Como leio relatórios agregados DMARC?

Relatórios agregados DMARC são arquivos XML comprimidos com gzip ou zip. Eles contêm dados sobre cada mensagem recebida de seu domínio: IP de envio resultado SPF resultado DKIM e a disposição (none quarantine ou reject). Ler XML bruto é impraticável em escala. A maioria dos administradores usa um serviço de relatório DMARC que analisa o XML e apresenta dashboards mostrando taxas de sucesso/falha de autenticação remetentes não autorizados e problemas de alinhamento.

DMARC afeta encaminhamento de email?

Sim. Encaminhamento de email é um dos maiores desafios com imposição DMARC. Quando uma mensagem é encaminhada por um intermediário (como uma lista de discussão ou endereço de encaminhamento de alunos de universidade) o IP de envio muda quebrando SPF. Se o encaminhador também modifica a mensagem (adicionando rodapé mudando o assunto) DKIM também quebra. Com p=reject a mensagem encaminhada será rejeitada pelo servidor do destinatário final. Soluções incluem ARC (Authenticated Received Chain) que alguns receptores suportam para preservar autenticação através de encaminhamento.

Ferramentas Relacionadas

• SPF Record Builder - Crie registros SPF com sintaxe apropriada
• SPF Record Length Checker - Verifique o comprimento do registro SPF e limites de lookup
• DKIM TXT Record Formatter - Formata registros DKIM com quoting apropriado
• DNS Record Set Deduper - Encontre e remova registros DNS duplicados
• Zone File Linter - Verifique arquivos de zona para erros de sintaxe e duplicatas