10 mitos DMARC

Quando se trata de phishing, muitas marcas cometem o erro de confiar nos seus clientes ou empregados para identificar e comunicar ataques.

Mas esta estratégia é defeituosa. 97% dos usuários pelo mundo não conseguem identificar corretamente uma mensagem sofisticada de phishing.

A tecnologia que bloqueia as mensagens mal-intencionadas antes que elas cheguem na caixa de entrada deve ser a linha de frente da defesa contra a fraude via email. E o padrão DMARC (Domain-based Message Authentication Reporting and Conformance – Mensagem Baseada em Domínio de Autenticação, Relatório e Conformidade) faz justamente isso.

Construir o seu registro de DMARC é bem simples. Mas existem muitos equívocos comuns sobre o processo de implantação do DMARC que podem sabotar os seus esforços na identificação e na mitigação dos ataques de phishing.

Como a equipe de Serviços Administrados da Return Path ouve falar destes equívocos do DMARC diariamente, pensaram que seria útil relacionar – e desmascarar – os dez principais aqui:

1. Os mecanismos de notificação do DMARC contêm dados suficientes para implantar com sucesso uma política de “rejeição” de DMARC.

Você realmente precisa de dados adicionais para fornecer o contexto RUA e RUF, ou terminará tendo que confiar em suposições, o que pode ser extremamente estressante.

2. É uma boa ideia relacionar todos os possíveis campos de cabeçalho na sua assinatura DKIM, pois isso é “mais seguro”.

A sua meta com o DKIM é validar criptograficamente que somente você poderia ter enviado a mensagem em questão. Assim, pegue somente alguns poucos campos para colocar no seu “h:array”, nenhum deles será alterado com o reenvio (o que faria com que a sua assinatura não fosse aceita).

3. Você deve adicionar instruções de “include” (include statements) no seu Registro SPF em vez de dar entrada em cada IP individualmente ou um CIDR (Classeless Inter-Domain Routing).

O seu Registro SPF precisa ser uma máquina de velocidade significativa, bonita – em termos ideais, uma lista clara e limpa de IPs. Mantenha as include statements no mínimo possível.

Isso adiciona velocidade e remove um ponto de falha potencial.

4. Adicione uma 11ª instrução de “include” ao seu Registro SPF. 

O protocolo SPF somente permite 10 include statements. Ao adicionar uma 11ª, você interrompe o registro.

5. Mandar a sua chave privada de DKIM por email para alguém não é uma grande coisa.

No momento em que a sua chave privada estiver em algum lugar que não seja o MTA que a utiliza, ela não é mais uma chave privada e precisa ser substituída.

6. Todos os seus emails devem ser enviados do domínio da organização / de nível mais alto.

Há uma série de motivos a observar aqui sobre por que é uma má ideia enviar emails de seu domínio de nível mais alto. Alguns se baseiam na segurança e na gestão de vendedores – seu sistema de reservas de férias é o mais feliz enviando de  reservas@férias.exemplo.com. Outros em bases sólidas de entrega – você nunca deseja misturar um email transacional com outro de marketing, por exemplo. Veja este recurso do Google para ter mais informações.

7. Um registro DMARC no domínio da organização / de nível mais alto é tudo o que você precisa.

Implementar o DMARC no seu domínio de nível mais alto é um bom começo, mas não é suficiente para lhe dar o controle e a fidelidade de relatórios de que você precisa. Todos os domínios pertencentes à sua empresa (para envio ou não) deverão estar protegidos com uma política de DMARC.

8. Como você envia a maioria dos seus emails de um determinado subdomínio, aqueles mal intencionados também farão isso.

Esta é uma suposição comum, e é falsa – você precisa bloquear todo o domínio (o principal domínio da organização e os subdomínios). O alvo de mais alto valor é o domínio organizacional, não o subdomínio de onde você envia o maior volume.

9. Decisões de infraestrutura anteriores foram tomadas racionalmente.

Não fique maluco tentando replicar o processo de pensamento daqueles que construíram a sua infraestrutura de email. Em vez disso, use o novo DMARC como uma oportunidade para re-desenhar e otimizar a sua (e de seus terceiros) infraestrutura e arquitetura.

10. Em 2016, todos os vendedores podem assinar o DKIM.

“Deverão” não é o mesmo que “podem”. O cenário do vendedor é muito variado. É preciso um especialista que tenha conhecimento profundo sobre como superar os inúmeros desafios que serão enfrentados fazendo com que toda a sua infraestrutura autentique de modo correto com o DKIM, em particular quando se trata de vendedores terceiros.

 

Este artigo foi escrito por Neil Hammet no blog do Return Path

Este post é parte da contribuição de Babel-Team para melhorar as práticas de email marketing.

Quero acompanhar as novidades

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.