Em 2012, engenheiros da Microsoft, PayPal, Yahoo! e Google se reuniram para discutir como tornar a autenticação de emails ainda mais segura. Logo depois, eles lançaram o DMARC para o mundo.
Qual é o propósito do DMARC? Como ele funciona? Essas e outras perguntas sobre o famoso protocolo de autenticação são respondidas no texto abaixo. Continue lendo!
O que é DMARC?
Vamos começar com uma pergunta básica: “O que significa DMARC?”. A resposta é: Domain-based Message Authentication, Reporting & Conformance.
O DMARC aproveita 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 email recebida.
A autenticação DKIM usa assinaturas DKIM para verificar a integridade do conteúdo de um email e sua origem. Por outro lado, o SPF permite que o proprietário de um domínio autorize endereços IP para enviar emails em nome do nome de 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 essa política, ele instrui o servidor de entrada sobre o que fazer se um email não passar no teste DMARC.
Finalmente, a política também pode fornecer relatórios com detalhes de cada verificação para melhorar os processos e fornecer um aviso imediato caso alguém tente falsificar o domínio.
Como funciona o DMARC?
Para entender como o DMARC funciona, você deve saber que ele requer um registro SPF ou um registro DKIM — de preferência, ambos.
Quando um email é recebido, o servidor receptor faz uma consulta ao DNS (Domain Name System) e verifica se há um registro DMARC existente.
As verificações DKIM/SPF são realizadas normalmente.
O servidor receptor então realiza um chamado “teste de alinhamento DMARC” para verificar se:
- No caso do SPF, o endereço de email “envelope from” dentro do cabeçalho técnico oculto do email corresponde ao endereço “return-path”. Em outras palavras, verifica se o endereço de email do qual a mensagem foi enviada é o mesmo que o endereço para o qual uma resposta potencial iria.
- No caso do DKIM, o valor atrás da tag “d” (domínio do remetente do email) corresponde ao domínio do qual o email foi enviado.
Claro, se ambas as autenticações estiverem configuradas, ambos os testes de alinhamento são realizados.
Os requisitos de alinhamento podem ser “estritos” (os domínios precisam corresponder exatamente) ou “relaxados” (os domínios base precisam corresponder, mas subdomínios diferentes são permitidos).
O DMARC terá sucesso nos seguintes cenários:
- Se apenas uma das autenticações estiver configurada, sua verificação deve ser bem-sucedida, juntamente com um respectivo teste de alinhamento.
- Se ambas as autenticações estiverem configuradas, uma delas precisa ser bem-sucedida com o respectivo teste de alinhamento, mas ambas não são necessárias.
Observe que o DMARC ainda terá sucesso mesmo que, por exemplo, o DKIM e o alinhamento DKIM falhem, mas o SPF e seu alinhamento tenham sucesso (ou vice-versa).
Agora, vamos supor que um email falhou em um teste DMARC por qualquer motivo.
O DMARC permite que você instrua o servidor de entrada sobre o que deve acontecer com emails que falham na autenticação.
Três opções estão disponíveis (são chamadas de “políticas”):
- “none” – o email deve ser tratado da mesma forma como se nenhum DMARC estivesse configurado (a mensagem ainda pode ser entregue, colocada em spam ou descartada com base em outros fatores). Isso é tipicamente usado para observar o ambiente e analisar os relatórios sem influenciar a entregabilidade.
- “quarantine” – permitir o email, mas não entregá-lo na caixa de entrada. Normalmente, tais mensagens vão para a pasta de spam.
- “reject” – descartar imediatamente o email que falhou no teste.
Essas políticas também podem ser personalizadas. Por exemplo, com uma política de “quarantine”, você poderia dizer ao servidor de email para enviar apenas 10% dos emails com falha para a pasta de spam e ignorar (“none”) os outros 90%.
Note que só porque você instrui 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 nos casos das autenticações DKIM e SPF.
Finalmente, um servidor receptor enviará relatórios para cada verificação DMARC falhada com dados agregados sobre verificações malsucedidas. Isso é inestimável para analisar o desempenho das suas mensagens e mantê-lo informado caso ocorram golpes de phishing.
Por que usar DMARC?
Já dissemos algumas vezes, mas vale a pena repetir — DMARC é a forma mais eficaz de se proteger contra falsificação de identidade. Ponto.
Além disso, em 2024, Google e Yahoo fizeram da autenticação de email via DNS a exigência número 1 para grandes remetentes. Portanto, é necessário.
Para colocar as coisas em perspectiva, a HMRC estima que o número de emails de phishing enviados de seu domínio diminuiu em 500 milhões em apenas 1,5 anos após a implementação do DMARC.
Sem listar outros benefícios do DMARC, isso por si só já deveria ser um motivo suficiente para adicionar a implementação do DMARC à sua próxima sprint.
Mas, se você precisar de mais motivos, considere os dois principais benefícios do DMARC:
- Os cibercriminosos têm muito mais chances de desistir de tentar falsificar um domínio se virem registros DMARC (configurados corretamente) no DNS do domínio. A implementação do DMARC ainda não é muito difundida, então não será difícil encontrar algo que valha a pena para eles.
- Servidores receptores também sabem que emails provenientes de domínios protegidos com DMARC são muito mais propensos a serem legítimos do que aqueles protegidos apenas com um dos outros métodos de autenticação (sem mencionar aqueles sem nenhuma segurança).
Do que consiste um registro DMARC?
Entendeu o básico? Ótimo! Agora, vamos analisar um registro DMARC.
Em vez de usar dados fictícios, usaremos o registro da Square, uma provedora unicórnio de serviços financeiros para pequenas empresas. Muitos cibercriminosos provavelmente sonham em falsificar seus emails, então não é surpresa que eles tenham escolhido 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, desde 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.comVamos analisar cada parâmetro DMARC do registro acima, um por um.
v=DMARC1
Este é o identificador (uma versão do DMARC) que deve sempre ser incluído no registro DNS, pois o servidor de email receptor sempre o procura. Se v=DMARC1 estiver ausente ou for modificado de alguma forma, a verificação inteira será ignorada.
p=reject
Esta é a política que a Square escolheu usar, que rejeita todos os emails que falham no teste DMARC. Claro, eles ainda podem ser entregues, mas um forte sinal será enviado ao servidor receptor para não permitir tais mensagens.
<code>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 emails que falharam na verificação. Os relatórios conterão dados de alto nível sobre os motivos das falhas, sem fornecer detalhes específicos de cada um. Todos os endereços adicionados aqui devem ser precedidos por “mailto:”, como no exemplo acima.
ruf=mailto:dmarc-ruf@squareup.com
Este é um endereço de email para o qual relatórios forenses individuais (também conhecidos como relatórios de falhas) serão enviados em tempo real, incluindo detalhes de cada falha.
Outros exemplos de registros DMARC
No exemplo de registro DMARC da Square, mostramos um registro com uma política de “reject”. Para cobrir as outras duas variações de política, usaremos alguns dados fictícios apenas para fins de demonstração.
Registro DMARC com uma política de “none”:
v=DMARC1; p=none; rua=mailto:dmarcreports@exemplo.com; ruf=mailto:dmarcfailures@exemplo.com;Explicação:
- “p=none” especifica uma política de “none”, o que significa que nenhuma ação deve ser tomada em emails que falhem na autenticação DMARC.
Registro DMARC com uma política de “quarantine”:
v=DMARC1; p=quarantine; rua=mailto:dmarcreports@exemplo.com; ruf=mailto:dmarcfailures@exemplo.com;Explicação:
- “p=quarantine” especifica uma política de “quarantine”, o que significa que os emails que falham na autenticação DMARC devem ser colocados em quarentena ou marcados como suspeitos pelo sistema de email do destinatário, mas ainda entregues na caixa de entrada do destinatário.
Como geralmente acontece, também existem vários campos opcionais que podem ser adicionados a um registro DMARC para personalizá-lo um pouco.
| Tag | Significado |
pct | Define a porcentagem de emails falhados aos quais a política definida deve ser aplicada. O valor deve ser um número entre 1 e 100. |
sp | Define uma política específica para emails enviados de subdomínios. Por exemplo, você pode escolher ignorar emails falhados enviados do domínio principal (p=none), mas colocar em quarentena aqueles enviados de subdomínios. |
adkim | Aqui você pode escolher a abordagem mencionada anteriormente de quão rigoroso o DMARC deve ser ao comparar o domínio do remetente com a tag “d” do DKIM. Como mencionado anteriormente, as opções possíveis são “estrita” e “relaxada”. Por padrão, a abordagem é “relaxada”. |
aspf | A mesma escolha que a anterior, apenas para alinhamento SPF. Você decide se o SPF deve buscar uma correspondência perfeita do domínio “envelope from” e o endereço “return-path” ou se subdomínios do domínio “envelope from” também devem ser permitidos. Você pode escolher “estrito” ou “relaxado”. |
ri | Define os intervalos para a frequência com que você deseja receber relatórios agregados com os resultados da 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 escolher enviar o relatório se: “0” – todos os testes subjacentes falharem em retornar um resultado positivo do DMARC; “1” – qualquer mecanismo falhar; “d” – DKIM não verificar; “s” – SPF não verificar. Por padrão, é “0”. |
Como implementar registros DMARC
Todo o processo de implementação do DMARC se resume aos seguintes passos:
- Verificar se SPF/DKIM está configurado e os domínios estão alinhados.
- Gerar um registro DMARC e especificar as configurações DMARC.
- Adicioná-lo ao DNS do seu domínio.
Verifique se o DKIM e/ou SPF estão configurados corretamente
Como mencionado anteriormente, ter DKIM ou SPF é obrigatório para o DMARC funcionar. Mas ter qualquer um deles retornando resultados negativos para emails legítimos também não será útil. O teste DMARC falhará automaticamente se o SPF ou o DKIM falharem.
Se você tiver apenas o SPF configurado, verifique se os dois a seguir correspondem:
- Endereço “Envelope from” – o endereço de onde os emails são enviados.
- Endereço “Return-path” – o endereço para o qual os emails serão direcionados se um destinatário responder a um email.
Se você depende apenas do DKIM, verifique se os dois a seguir correspondem:
- Endereço “Envelope from” – o endereço de onde os emails são enviados.
- Tag “d” do seu registro DKIM.
Se você usar ambos os métodos (e com razão!), realize ambas as verificações, claro.
Escolha uma conta de email para receber registros DKIM
Uma grande vantagem do DMARC é que, quando configurado, seu servidor começa a enviar relatórios diários sobre como seus emails se saíram (relatórios agregados e forenses separados). Dessa forma, você pode rapidamente identificar qualquer anomalia e melhorar seu desempenho usando os dados.
Lembre-se de que os relatórios são enviados em um formato bruto, difícil de ler, então você pode querer usar ferramentas como Dmarcian ou MXToolbox para aproveitar ao máximo os dados.
Gere 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, existem várias tags mencionadas anteriormente que você precisa usar no registro e algumas opcionais.
Observe que a tag “p” (como em “policy”) representará diretamente o passo anterior.
Adicione o registro DMARC ao DNS do seu domínio
Depois de ter seu registro, você pode ir em frente e adicioná-lo como um registro DNS. Você pode ser capaz de fazer isso sozinho ou, em alguns casos, pode ser necessária a ajuda do seu provedor de hospedagem.
No registrador de domínio, você precisa adicionar o DMARC recém-criado como um registro TXT. Não entraremos em detalhes aqui, pois o processo varia para cada provedor de hospedagem.
Se tudo foi feito corretamente, você deve receber seus primeiros relatórios dentro das próximas 24 horas.
Três grandes mitos sobre DMARC desvendados
DMARC é configurado apenas por motivos de segurança
Parcialmente verdade. O DMARC de fato visa prevenir ataques de spoofing e phishing. No entanto, há mais no DMARC do que isso.
As políticas de aplicação do DMARC e suas capacidades avançadas de relatórios melhoram significativamente a entrega de emails legítimos. Eles ajudam a construir e melhorar a confiança na marca e a análise de dados. Assim, o DMARC pode fornecer um impulso significativo para qualquer campanha de marketing.
DMARC é apenas para domínios que enviam emails
Não é verdade. O fato de seu domínio não enviar emails não significa que ele não pode ser falsificado. Na verdade, quanto mais famoso for sua marca, empresa, organização ou personalidade, maiores são as chances de algum spammer querer falsificar seu domínio e usá-lo para atividades maliciosas, como enviar emails fraudulentos, seja marketing ou transacional.
Os destinatários de emails maliciosos enviados pelo “seu” domínio provavelmente não serão capazes de identificar que seu domínio não está configurado para enviar emails. Como resultado, você terá que enfrentar muitas consequências desagradáveis em relação à sua reputação e credibilidade.
Configurar a política DMARC para “none” é suficiente para segurança de email
Errado. Configurar a política DMARC para “none” geralmente é o primeiro passo para garantir que os relatórios e a entrega do DMARC estejam configurados corretamente, mas não melhora sua segurança nem ajuda a proteger seu domínio contra a falsificação.
Eventualmente, para tirar o máximo proveito da segurança do DMARC e do aprimoramento de marketing, você precisará usar a política de (pelo menos) p=quarantine ou (de preferência) p=reject com um pct=100.
Além disso, caso você decida acompanhar os tempos modernos e adotar o BIMI como a mais recente estratégia de autenticação de marca, seu registro DMARC deve estar configurado para a política “reject” para se qualificar para a certificação BIMI.
Considerações finais
A segurança do email nunca deve ser subestimada. Quanto maior você for, mais você tem a perder se alguém falsificar seu domínio e enganar seus clientes com algo que você provavelmente não aprovaria.
Dado o quão fácil é adicionar cada método de autenticação e o quanto você ganha ao tê-los todos configurados corretamente, há poucas razões para não tentar.
O que é absolutamente interessante sobre o DMARC é que você pode começar com uma política “none” e observar o que acontece. Isso basicamente significa que seus emails passarão pelas verificações relevantes no lado do receptor, mas, se falharem, isso não influenciará a entregabilidade dos seus emails.
Além disso, você receberá muitos dados por meio dos relatórios DMARC sobre problemas de autenticação.
Com isso, você pode rapidamente identificar se alguém está tentando falsificar seu domínio e potencialmente pedindo aos destinatários para fornecer informações sensíveis ou se o problema está do seu lado para que você possa fazer a devida solução de problemas.