A criação desses registros de DNS específicos ajuda a proteger domínios que não enviam e-mails evitando que sejam usados em ataques de falsificação de domínio.
Após ler este artigo, você será capaz de:
Copiar o link do artigo
Os domínios que não enviam e-mails ainda podem ser usados na falsificação de e-mails ou em ataques de phishing, mas há tipos específicos de registros DNS de texto (TXT) que podem ser usados para conter os invasores. Cada um desses registros estabelece regras de como e-mails não autorizados devem ser tratados pelos servidores de e-mail, tornando mais difícil para os invasores explorar esses domínios.
Um registro DNS TXT permite que os administradores do domínio insiram um texto no Domain Name System (DNS). Os registros DNS TXT são usados para processos como autenticação de e-mail porque podem armazenar informações importantes que os servidores podem usar para confirmar se um domínio autorizou ou não um remetente de e-mail a enviar mensagens em seu nome.
Exemplos de domínios que não enviam e-mails incluem domínios adquiridos para proteger um nome de marca ou para um negócio futuro. Domínios extintos ou legados também não têm motivo para enviar e-mails e poderiam se beneficiar desse tipo de registro.
Existem três tipos principais de registros DNS TXT usados para autenticação de e-mail. Cada um deles difere ligeiramente na forma de funcionamento:
Como esses registros de DNS funcionam todos de maneira ligeiramente diferente, cada um de seus componentes é único.
SPF
Os registros SPF podem ser formatados para proteger os domínios contra tentativas de ataques de phishing, rejeitando quaisquer e-mails enviados do domínio. Para isso, um registro SPF deve usar o formato a seguir.
v=spf1 -all*Observe que os registros SPF são definidos diretamente no próprio domínio, o que significa que eles não exigem um subdomínio especial.
A seguir mostramos o que significam os componentes individuais desse registro:
v=spf1 permite que o servidor saiba que o registro contém uma política de SPF. Todos os registros SPF devem começar com este componente. -all diz ao servidor o que fazer com e-mails que não estão em conformidade ou que forem enviados por quaisquer remetentes que não estejam explicitamente listados no registro SPF. Com esse tipo de registro SPF, nenhum endereço de IP ou domínio é permitido, portanto -all determina que todos os e-mails que não estão em conformidade sejam rejeitados. Para esse tipo de registro, todos os e-mails são considerados como não estando em conformidade porque não existem endereços de IP ou domínios aceitos. DKIM
Os registros DKIM protegem os domínios, garantindo que os e-mails foram realmente autorizados pelo remetente usando uma chave pública e uma chave privada. Os registros DKIM armazenam a chave pública que o servidor de e-mail então utiliza para autenticar que a assinatura do e-mail foi autorizada pelo remetente. Para domínios que não enviam e-mails, o registro DKIM deve ser configurado sem uma chave pública associada. Abaixo se encontra um exemplo:
| Nome | Tipo | Conteúdo |
|---|---|---|
*._domainkey.example.com |
TXT |
v=DKIM1; p= |
*._domainkey.example.com é o nome especializado para o registro DKIM (onde "example.com" deve ser substituído pelo seu domínio). Neste exemplo, o asterisco (denominado curinga) está sendo usado como seletor, que é um valor especializado que o provedor de serviços de e-mail gera e usa para o domínio. O seletor faz parte do cabeçalho do DKIM e o servidor de e-mail o utiliza para realizar a pesquisa de DKIM no DNS. O curinga abrange todos os valores possíveis para o seletor. TXT indica o tipo de registro de DNS.v=DKIM1 define o número da versão e informa ao servidor que este registro faz referência a uma política DKIM. p ajuda a autenticar e-mails vinculando uma assinatura à sua chave pública. Neste registro DKIM, o valor p deve estar vazio porque não existe nenhuma assinatura/chave pública a ser vinculada. DMARC
As políticas DMARC também podem ajudar a proteger os domínios que não enviam e-mails, rejeitando todos os e-mails que não foram aprovados pelo SPF e pelo DKIM. Nesse caso, todos os e-mails enviados de um domínio não configurado para enviar e-mails seriam reprovados nas verificações de SPF e DKIM. Abaixo está um exemplo de como formatar uma política dessa forma:
| Nome | Tipo | Conteúdo |
|---|---|---|
_dmarc.example.com |
TXT |
v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s |
_dmarc.example.com, que é obrigatório para as políticas DMARC.TXT indica o tipo de registro de DNS.v=DMARC1 informa ao servidor que esse registro de DNS contém uma política DMARC. p=reject indica que os servidores de e-mail devem rejeitar e-mails que não forem aprovados nas verificações pelo DKIM e pelo SPF. adkim=s representa algo chamado modo de alinhamento. Nesse caso, o modo de alinhamento é definido como "s" de estrito ("strict" em inglês). O modo de alinhamento estrito significa que o servidor do domínio de e-mail que contém o registro DMARC deve corresponder exatamente ao domínio no cabeçalho De do e-mail . Se não coincidir, a verificação DKIM falha. aspf=s tem a mesma finalidade que adkim=s, mas para o alinhamento de SPF. O Assistente de Segurança de DNS para E-mail da Cloudflare simplifica a configuração dos registros de DNS TXT corretos e impede os spammers de usarem um domínio. Leia mais sobre o Assistente aqui.