vida após p=rejeição

Os proprietários de domínios cometem frequentemente o erro de assumir que a sua viagem de autenticação de e-mail termina com a aplicação da lei. Mal sabem eles, a vida após p=rejeição é uma fase importante que determina a força global da postura de segurança do seu domínio de correio electrónico. Para uma protecção continuada contra ataques de spoofing e phishing, é imperativo formular uma estratégia de segurança de correio electrónico que só começa logo depois de se conseguir a aplicação da lei.

O que é P=Rejeitar? 

O Política DMARC tem 3 modos definitivos de aplicação que se podem utilizar, eles são:

  1. p=nenhuma (nenhuma acção tomada)
  2. p=quarantina (emails de quarentena que falham o DMARC) 
  3. p=rejeitar (rejeita e-mails em caso de O DMARC falha)

Rejeitar sendo a política máxima de aplicação para DMARC, ajuda os proprietários de domínios a bloquear e-mails falsificados ou de phishing antes de chegarem às caixas de entrada dos clientes. Aqueles que desejam utilizar DMARC para proteger os seus domínios contra vectores de ataque baseados em correio electrónico podem achar que p=rejeitar é um modo de política adequado. 

Como Chegar a P=Modo de Rejeitar? 

Na maioria das vezes, os proprietários de domínios tentam apressar o seu processo de implementação de protocolos e esperam conseguir a sua aplicação o mais rapidamente possível. No entanto, isto não é recomendado. Vamos explicar porquê: 

Riscos associados ao DMARC na rejeição

  • A passagem à aplicação da lei a um ritmo muito rápido pode levar a problemas de entregabilidade de correio electrónico 
  • Pode levar à perda de mensagens de correio electrónico legítimas 
  • Pode resultar em falhas de DMARC para e-mails enviados fora do seu próprio domínio 

Qual é a prática recomendada?

Embora a política de rejeição venha com o seu próprio conjunto de avisos e isenções de responsabilidade, a sua eficácia na prevenção de uma variedade de ataques de fraude por correio electrónico é inegável. Por isso, exploremos agora formas de mudar para uma rejeição segura: 

  • Comece com p=nenhuma

Em vez de começar com uma política aplicada, é fortemente encorajado a começar com algo que ofereça mais flexibilidade e liberdade: e é exactamente isso que p=ninguém faz. Esta política, embora não faça muito em termos de protecção, pode servir como uma excelente ferramenta de monitorização para ajudar na sua jornada de implementação. 

  • Activar o relatório DMARC

A monitorização dos seus canais de correio electrónico pode ajudá-lo a evitar falhas de entrega indesejadas devido a protocolos mal configurados. Pode permitir-lhe visualizar e detectar erros, e resolvê-los mais rapidamente. 

Os relatórios DMARC podem ajudá-lo a identificar a eficácia da sua política de autenticação por correio electrónico.

Embora a autenticação por e-mail não seja uma bala de prata, pode ser uma ferramenta eficaz no seu arsenal de segurança. Com os relatórios DMARC, pode ver se os seus esforços estão a funcionar e onde poderá ter de ajustar a sua estratégia.

Existem 2 Tipos de Relatórios: 

  • O Aggregate (RUA) foi concebido para o ajudar a localizar as suas fontes de envio de correio electrónico, endereços IP dos remetentes, domínios organizacionais e geolocalizações 
  • Forense (RUF) é concebida para funcionar como relatórios de alerta de incidentes quando um evento forense como a falsificação ocorre
  • Configurar tanto SPF como DKIM juntamente com DMARC

Demasiados cozinheiros não estragam o caldo quando se trata da implementação do DMARC. Pelo contrário, os peritos em segurança recomendam o emparelhamento do DMARC com o SPF e o DKIM para uma maior protecção, bem como a possibilidade negativa de falsos positivos. Também pode evitar falhas indesejadas de DMARC. 

O DMARC precisa de SPF ou DKIM para passar a autenticação.

Isto desempenha um papel fundamental para o ajudar a implementar com segurança uma política de rejeição, assegurando que mesmo que SPF falhe e DKIM passe ou vice-versa, MARC passará para a mensagem pretendida.

  • Inclua todas as suas fontes de envio

Faltar ao envio de fontes no seu registo SPF pode ser especialmente prejudicial quando se tenta evitar falhas indesejadas de DMARC. É importante fazer uma lista de todas as suas fontes de envio de correio electrónico (que incluiria fornecedores de correio electrónico de terceiros e fornecedores de serviços como o Gmail, Microsoft O365, Yahoo Mail, Zoho, etc.) 

Isto é especialmente importante se estiver a usar SPF apenas em combinação com DMARC. Sempre que adicionar ou remover uma fonte de envio, o seu registo SPF deve reflectir as mesmas alterações. 

Para resumir a sua vida após p=rejeitar

A monitorização dos seus protocolos de autenticação de e-mail é uma parte essencial da vida após p=rejeição. Não só assegura que a eficácia das suas medidas de segurança é mantida, mas também lhe dá uma visão mais profunda das suas funcionalidades para determinar o que funciona melhor para si. A Analisador DMARC ajuda-o a desfrutar de uma transição mais suave de p=ninguém para rejeitar, evitar problemas de entregabilidade, monitorizar os seus canais de correio electrónico, actualizar as políticas de protocolo e resolver problemas numa única plataforma, facilmente.

Últimos posts de Ahona Rudra (ver todos)