DMARC Explicado

Em 2012, engenheiros da Microsoft, do PayPal, do Yahoo! e do Google se reuniram para discutir como tornar a autenticação de e-mails ainda mais segura. Logo depois, eles lançaram o DMARC para o mundo.

Qual é a finalidade do DMARC, como ele se parece e funciona, além de muitas outras perguntas relacionadas a este famoso protocolo de autenticação, são respondidas no texto abaixo. Certifique-se de continuar lendo!

O que é DMARC?

Vamos começar este artigo com a pergunta presente na mente da maioria dos leitores: “O que significa DMARC?”. E a resposta é: Domain-based Message Authentication, Reporting & Conformance [Autenticação de Mensagens, Relatórios e Conformidade Baseados em Domínio, em tradução livre].

O DMARC não apenas tem o nome mais complicado dos três principais protocolos de autenticação de e-mail, mas também é o mais eficaz. E é muito fácil de entender o porquê.

O DMARC utiliza as verificações DKIM (DomainKeys Identified Mail) e/ou SPF (Sender Policy Framework) para realizar uma validação mais avançada em cada mensagem de e-mail recebida.

A autenticação DKIM usa assinaturas DKIM para verificar a integridade do conteúdo de um e-mail e sua origem. O SPF, por outro lado, permite que o proprietário de um domínio autorize endereços de IP a enviar e-mails sob o nome do domínio e é usado por provedores de serviços de Internet como Gmail, Yahoo, etc.

Com a autenticação DMARC, o proprietário de um domínio pode especificar seu próprio procedimento de autenticação, também conhecido como política DMARC. Usando a política, eles instruem um servidor de entrada sobre o que fazer se um e-mail não passar no teste DMARC.

Por fim, a política também pode fornecer relatórios com os detalhes de cada verificação para aprimorar os processos e avisar imediatamente se alguém falsificar o domínio.

Como o DMARC funciona?

A chave para entender o DMARC e como o DMARC funciona é saber que ele requer um registro SPF ou um registro DKIM – ou, melhor ainda, ambos – para ser definido.

Quando um e-mail é recebido, um servidor de recebimento faz uma pesquisa no DNS (Domain Name System) e verifica se há um registro DMARC existente.

O DKIM/SPF é executado como de costume.

Em seguida, o servidor receptor executa o chamado “teste de alinhamento DMARC” para verificar se:

• No caso do SPF, o endereço de e-mail “envelope from” no cabeçalho técnico oculto do e-mail corresponde ao endereço “return-path”. Em outras palavras, ele verifica se o endereço de e-mail do qual a mensagem foi enviada é o mesmo que o endereço para o qual uma possível resposta seria enviada.
• No caso do DKIM, o valor por trás da tag “d” (domínio do remetente do e-mail) corresponde ao domínio do qual o e-mail foi enviado.

Obviamente, se ambas as autenticações forem configuradas, ambos os testes de alinhamento serão realizados.

Os requisitos de alinhamento podem ser “strict” (os domínios precisam corresponder com precisão) ou “relaxed” (os domínios de base precisam corresponder, mas subdomínios diferentes são permitidos).

O DMARC será bem-sucedido nos seguintes cenários:

• Se apenas uma das autenticações for configurada, sua verificação deverá ser bem-sucedida, juntamente com um respectivo teste de alinhamento.
• Se ambas as autenticações forem configuradas, uma delas precisará ser bem-sucedida com o respectivo teste de alinhamento, mas ambas não são necessárias.

Observe como o DMARC ainda será bem-sucedido mesmo se, por exemplo, o DKIM e o alinhamento do DKIM falharem, mas o SPF e seu alinhamento forem bem-sucedidos (ou o contrário).

Agora, vamos supor que um e-mail tenha falhado em uma verificação DMARC por qualquer motivo.

O DMARC permite que você instrua o servidor de entrada sobre o que deve acontecer com os e-mails que falham na autenticação.

Há três opções disponíveis (chamadas de “políticas”):

• “none” – o e-mail deve ser tratado da mesma forma que se nenhum DMARC estivesse configurado (a mensagem ainda pode ser entregue, colocada em spam ou descartada com base em outros fatores). Normalmente, ela é usada para observar o ambiente e analisar os relatórios sem influenciar a entregabilidade.
• “quarantine” – permite o e-mail, mas não o entrega em uma caixa de entrada. Normalmente, essas mensagens vão para a pasta de spam.
• “reject” – descarta imediatamente o e-mail que falhou na verificação.

Essas políticas também podem ser personalizadas. Por exemplo, com uma política “quarantine”, você pode dizer ao servidor de e-mail para enviar apenas 10% dos e-mails com falha na verificação para a pasta de spam e ignorar (“none”) os outros 90%.

Observe que o fato de você instruir o servidor sobre o que fazer não significa que ele seguirá totalmente sua orientação. Ainda assim, isso lhe dá muito mais controle do que no caso das autenticações DKIM e SPF.

Por fim, um servidor receptor enviará relatórios para cada verificação do DMARC com falha, com dados agregados sobre verificações malsucedidas. Isso é inestimável para analisar o desempenho de sua mensagem e mantê-lo informado caso ocorra algum golpe de phishing.

Por que usar o DMARC?

Já dissemos isso algumas vezes, mas vale a pena repetir: O DMARC é a maneira mais eficaz de se proteger contra spoofing. Ponto final.

O HMRC estima que o número de e-mails de phishing enviados de seu domínio diminuiu em 500 milhões em apenas um ano e meio após a implementação do DMARC.

Sem listar nenhum outro benefício do DMARC, isso por si só já deve ser um motivo bom o suficiente para adicionar a implementação do DMARC ao seu próximo sprint.

Mas, se você precisar de mais, há dois benefícios principais do DMARC a serem considerados:

• É muito mais provável que os criminosos cibernéticos desistam de tentar falsificar um domínio se virem (configurados corretamente) registros DMARC no DNS do domínio. A implementação do DMARC ainda não está muito difundida, portanto, não será difícil encontrar algo que valha a pena.
• Os servidores receptores também sabem que os e-mails provenientes de domínios protegidos por DMARC têm muito mais probabilidade de serem legítimos do que aqueles protegidos com apenas um dos outros métodos de autenticação (sem mencionar aqueles sem nenhuma segurança).

Em que consiste um registro DMARC?

Entendeu os fundamentos? Ótimo! Agora, vamos analisar um registro DMARC.

Em vez de nos basearmos em dados fictícios, usaremos o registro da Square, uma unicórnio provedora de serviços financeiros para pequenas empresas. Muitos criminosos cibernéticos provavelmente sonham em falsificar seus e-mails, portanto, não é surpresa que tenham optado por se proteger com o DMARC.

Você pode acessar o registro da Square neste link, que leva a um site que mostrará registros DMARC para qualquer domínio, considerando, é claro, que ele tenha sido configurado.

v=DMARC1; p=reject; rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com; ruf=mailto:dmarc-ruf@squareup.com

Vamos examinar cada parâmetro DMARC do registro acima, um por um.

v=DMARC1

Esse é o identificador (uma versão do DMARC) que sempre deve ser incluído no registro DNS, pois o servidor de e-mail receptor sempre o procura. Se v=DMARC1 estiver ausente ou for modificado de alguma forma, toda a verificação será ignorada.

p=reject

Essa é a política que a Square escolheu usar, que rejeita todos os e-mails que não passam na verificação do DMARC. É claro que elas ainda poderão ser entregues, mas um forte sinal será enviado ao servidor receptor para não permitir tais mensagens.

rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com

Esses três endereços receberão relatórios agregados diários sobre e-mails que falharam na verificação. Os relatórios conterão dados de alto nível sobre os motivos das falhas, sem fornecer detalhes sobre cada uma delas. Todos os endereços adicionados aqui devem ser precedidos de “mailto:”, como no exemplo acima.

ruf=mailto:dmarc-ruf@squareup.com

Esse é um endereço de e-mail para o qual os relatórios forenses individuais (também conhecidos como relatórios de falhas) serão enviados em tempo real, incluindo os detalhes de cada falha.

Outros registros de exemplo de DMARC

No exemplo do registro Square DMARC, mostramos um registro com uma política “reject”. Para cobrir as duas variações de política restantes, usaremos alguns dados fictícios simplesmente para fins de demonstração.

Registro DMARC com uma política “none”:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Explicação:

• “p=none” especifica uma política “none”, o que significa que nenhuma ação deve ser tomada em e-mails que falham na autenticação DMARC.

Registro DMARC com uma política “quarantine”:

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;

Explicação:

• “p=quarantine” especifica uma política “quarantine”, o que significa que os e-mails que falharem na autenticação DMARC devem ser colocados em quarentena ou sinalizados como suspeitos pelo sistema de e-mail do destinatário, mas ainda assim entregues na caixa de entrada do destinatário.

Algumas tags DMARC opcionais para personalização

Como normalmente acontece, também há diversos campos opcionais que podem ser adicionados a um registro DMARC para personalizá-lo um pouco.

Tag	Significado
pct	Definir a porcentagem de e-mails com falha aos quais a política definida deve ser aplicada. O valor deve ser um número entre 1 e 100.
sp	Definir uma política específica para e-mails enviados de subdomínios. Por exemplo, você pode optar por ignorar e-mails com falha enviados do domínio principal (p=none), mas colocar em quarentena aqueles enviados de subdomínios.
adkim	Você pode escolher aqui a abordagem mencionada anteriormente para determinar o grau de rigor que o DMARC deve ter ao comparar o domínio do remetente com a tag “d” do DKIM. Conforme mencionado anteriormente, as opções possíveis são “strict” e “relaxed”. Por padrão, a abordagem é “relaxed”.
aspf	A mesma escolha que a anterior, apenas para o alinhamento do SPF. Você decide se o SPF deve buscar uma correspondência perfeita entre o domínio “envelope from” e o endereço “return-path” ou se os subdomínios do domínio “envelope from” também devem ser permitidos. Além disso, você pode optar por ser “strict” ou “relaxed”.
ri	Definir os intervalos para a frequência com que você deseja receber relatórios agregados com resultados de autenticação (tag “rua”). O valor é expresso em segundos e, por padrão, é 86400 (a cada 24 horas).
fo	Configurações para os relatórios forenses (tag “ruf”). Você pode optar por enviar o relatório se: “0” – todas as verificações subjacentes não retornarem um resultado DMARC positivo; “1” – qualquer mecanismo falhar; “d” – falha na verificação do DKIM; “s” – falha na verificação do SPF. Por padrão, é “0”.

Como implementar registros DMARC

Todo o processo de implementação do DMARC se resume às seguintes etapas:

• Validar se o SPF/DKIM está configurado e se os domínios estão alinhados.
• Geração de um registro DMARC e especificação das configurações DMARC.
• Adicioná-lo ao DNS de seu domínio.

Verificar se o DKIM e/ou o SPF estão configurados corretamente 

Conforme mencionado anteriormente, é obrigatório ter DKIM ou SPF para que o DMARC funcione. Mas o fato de qualquer um deles retornar resultados negativos para e-mails legítimos também não será bom. O teste do DMARC falhará automaticamente se houver falha no SPF ou no DKIM.

Se você tiver apenas o SPF configurado, verifique se os dois itens a seguir correspondem:

• Endereço “Envelope from” – o endereço de onde os e-mails são enviados.
• Endereço “Return-path” – o endereço para o qual os e-mails serão direcionados se um destinatário responder a um e-mail.

Se você depender apenas do DKIM, verifique se os dois itens a seguir correspondem:

• Endereço “Envelope from” – o endereço de onde os e-mails são enviados.
• Tag “d” do seu registro DKIM.

Se você usar os dois métodos (e com razão!), faça as duas verificações, é claro.

Escolher uma conta de e-mail para receber os registros DKIM

Um aspecto positivo do DMARC é que, quando configurado, o servidor começa a enviar relatórios diários sobre o desempenho dos e-mails (relatórios agregados e forenses separados). Dessa forma, você pode identificar rapidamente qualquer anormalidade e melhorar seu desempenho usando dados.

Lembre-se de que os relatórios são enviados em um formato bruto e de difícil leitura, portanto, talvez seja necessário usar ferramentas como Dmarcian ou MXToolbox para obter o máximo dos dados.

Gerar o registro DMARC

E agora, vamos finalmente gerar um registro DMARC.

O dmarc.org recomenda uma série de recursos para essa tarefa. Além disso, há diversas tags mencionadas anteriormente que você precisa usar no registro e uma série de outras opcionais.

Observe que a tag “p” (como em “policy”) representará diretamente a etapa anterior.

Adicionar o registro DMARC ao DNS do seu domínio

Depois de ter seu registro, você pode adicioná-lo como um registro DNS. Talvez você consiga fazer isso sozinho ou, em alguns casos, pode ser necessária a ajuda do provedor de hospedagem.

No registrador de domínios, é necessário adicionar o DMARC recém-criado como um registro TXT. Não entraremos em detalhes aqui, pois o processo é diferente para cada provedor de hospedagem.

Se tiver feito tudo corretamente, você deverá receber seus primeiros relatórios nas próximas 24 horas.

Três grandes mitos do DMARC quebrados

O DMARC é definido apenas por motivos de segurança

Parcialmente verdadeiro. De fato, o DMARC tem como objetivo evitar ataques de spoofing e phishing em e-mails. No entanto, o DMARC é mais do que isso.

As políticas de aplicação do DMARC e os recursos avançados de geração de relatórios melhoram significativamente a entrega de e-mails legítimos. Eles ajudam a criar e melhorar a confiança e a análise da marca. Dessa forma, o DMARC pode dar um grande impulso a qualquer campanha de marketing.

O DMARC é apenas para domínios que enviam e-mails

Falso. O fato de seu domínio não enviar e-mails não significa que ele não possa ser falsificado. Na verdade, quanto mais famosa for sua marca, empresa, organização ou personalidade, maiores serão as chances de algum spammer querer falsificar seu domínio e usá-lo para atividades maliciosas, como o envio de e-mails fraudulentos, sejam eles de marketing ou transacionais.

Os destinatários de e-mails mal-intencionados enviados da “sua” marca provavelmente não conseguirão identificar que seu domínio não está configurado para enviar e-mails. Como resultado, você terá que enfrentar muitas consequências desagradáveis relacionadas à sua reputação e credibilidade.

Configurar a política DMARC como “none” é suficiente para a segurança de e-mail

Errado. Definir a política do DMARC como “none” geralmente é a primeira etapa para garantir que os relatórios e a entrega do DMARC estejam configurados corretamente, mas isso não melhora sua segurança nem ajuda a proteger seu domínio contra falsificação de identidade.

Eventualmente, para aproveitar ao máximo a segurança do DMARC e o aprimoramento do marketing, você precisará usar a política de (pelo menos) p=quarantine ou (o melhor de tudo) p=reject em um pct=100.Além disso, caso decida acompanhar o tempo e adotar o BIMI como a mais recente estratégia de autenticação de marca, seu registro DMARC deverá ser definido com a política “reject” para se qualificar para a certificação BIMI.

Considerações finais

A segurança de e-mail nunca deve ser subestimada. Quanto maior for a sua empresa, mais você terá a perder se alguém falsificar seu domínio e induzir seus clientes a algo que você provavelmente não aprovaria.

Considerando a facilidade de adicionar cada método de autenticação e o quanto você ganha com a configuração adequada de todos eles, não há motivo para não experimentar.

O que é absolutamente interessante no DMARC é que você pode começar com uma política “none” e observar o que acontece. Isso basicamente significa que seus e-mails passarão pelas verificações relevantes no lado do recebimento, mas se eles falharem, isso não influenciará a entregabilidade do seu e-mail.

Além disso, você receberá toneladas de dados por meio dos relatórios DMARC que abrangem problemas de autenticação. Com isso, você pode identificar rapidamente se alguém está tentando falsificar o seu domínio e possivelmente pedindo aos destinatários que forneçam informações confidenciais ou se o problema está do seu lado, para que você possa fazer a solução de problemas adequada.