Melhor prática para autenticação de e-mail – maneiras ideais de implantar SPF, DKIM e DMARC

Introdução

Este guia descreve três tecnologias de autenticação de e-mail predominantes em uso atualmente: SPF, DKIM e DMARC, e discute vários aspectos de sua implementação. Várias situações de arquitetura de e-mail reais são discutidas e diretrizes para implementá-las no conjunto de produtos Cisco Email Security. Como este é um guia prático de práticas recomendadas, alguns dos materiais mais complexos serão omitidos. Quando necessário, certos conceitos podem ser simplificados ou condensados para facilitar a compreensão do assunto apresentado.

Requisitos de conhecimento do produto

Este guia é um documento de nível avançado. Para dar seguimento ao material apresentado, o leitor deve possuir conhecimento do produto do Cisco Email Security Appliance até o nível de certificação do Engenheiro de Campo do Cisco Email Security. Além disso, os leitores devem ter um comando forte de DNS e SMTP e sua operação. Conhecer os conceitos básicos de SPF, DKIM e DMARC é uma vantagem.

Autenticação de e-mail - Uma breve visão geral

Sender Policy Framework (SPF)

O Sender Policy Framework foi publicado pela primeira vez em 2006, como RFC4408. A versão atual é especificada no RFC7208 e atualizada no RFC7372. Em essência, ele fornece uma maneira simples para um proprietário de domínio anunciar suas fontes de e-mail legítimas para os receptores usando DNS. Embora o SPF autentique principalmente o endereço do caminho de retorno (MAIL FROM), a especificação recomenda (e fornece mecanismo) para também autenticar o argumento SMTP HELO/EHLO (FQDN do gateway do remetente conforme transmitido durante a conversação SMTP).

O SPF usa registros de recursos DNS do tipo TXT de sintaxe bastante simples:

texto spirit.com = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"

O registro da Spirit Airlines acima permite que endereços de e-mail de @spirit.com venham de uma sub-rede /24 específica, duas máquinas identificadas por um FQDN e o ambiente Office365 da Microsoft. O qualificador "~all" no final instrui os receptores a considerar qualquer outra origem como Falha Suave - um dos dois modos de falha do SPF. Observe que os remetentes não especificam o que os receptores devem fazer com as mensagens com falha, apenas em que grau elas falharão.

A Delta, por outro lado, emprega um esquema SPF diferente:

texto delta.com = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

Para minimizar o número de consultas de DNS necessárias, a Delta criou um único registro "A" listando todos os seus gateways SMTP. Eles também fornecem um registro SPF separado para seus fornecedores em "_spf.vendor.delta.com". Eles também incluem instruções para falha grave em qualquer mensagem não autenticada pelo SPF (qualificador "all"). Podemos pesquisar ainda mais o registro SPF dos fornecedores:

_spf.vendor.delta.com texto = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

Assim, os e-mails dos remetentes @delta.com podem vir legitimamente de, por exemplo, gateways de e-mail da Air France.

O United, por outro lado, usa um esquema SPF muito mais simples:

texto de united.com = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"

Além de seus próprios gateways de correio corporativo, eles incluem seus provedores de marketing por e-mail ("usa.net" e "enviaremails.com.br"), gateways legados da Continental Air Lines, bem como tudo relacionado em seus registros MX ("mecanismo MX"). Observe que o MX (um gateway de entrada de e-mails para um domínio) pode não ser o mesmo que de saída. Embora para empresas menores elas sejam geralmente as mesmas, as empresas maiores terão uma infraestrutura separada para lidar com o recebimento de e-mails e com o envio de e-mails.

Além disso, vale a pena observar que todos os exemplos acima fazem uso extensivo de referências de DNS adicionais (mecanismos de "inclusão"). No entanto, devido a motivos de desempenho, a especificação SPF limita o número total de pesquisas de DNS necessárias para recuperar um registro final a dez. Qualquer pesquisa SPF com mais de 10 níveis de recursão DNS falhará.

DKIM (Domain Keys Identified Mail, E-mail identificado das chaves de domínio)

O DKIM, especificado nos RFCs 5585, 6376 e 5863 é uma fusão de duas propostas históricas: DomainKeys do Yahoo e Internet Mail Identificado da Cisco. Ele fornece uma maneira simples para os remetentes assinarem criptograficamente as mensagens enviadas e incluir as assinaturas (juntamente com outros metadados de verificação) em um cabeçalho de e-mail ("DKIM-Signature"). Os remetentes publicam sua chave pública no DNS, facilitando a recuperação da chave por qualquer receptor e a verificação de assinaturas. O DKIM não autentica a origem das mensagens físicas, mas baseia-se no fato de que, se a origem estiver na posse da chave privada da organização do remetente, ela está implicitamente autorizada a enviar um e-mail em seu nome.

Para implementar o DKIM, a organização de envio geraria um ou mais pares de chaves públicas e publicaria as chaves públicas no DNS como registros TXT. Cada par de chaves seria referenciado por um "seletor" para que os verificadores DKIM possam diferenciar as chaves. As mensagens enviadas seriam assinadas e o cabeçalho DKIM-Signature inserido:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:To:From:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYgwYqT01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9b BacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo=

O formato da assinatura é bastante simples. "a" tag especifica algoritmos usados para assinatura, "c" especifica o(s) esquema(s) de canonicalização usado(s) [1], "s" é o seletor ou referência de chave, "d" é o domínio de assinatura. O restante desse cabeçalho DKIM-Signature é específico da mensagem: "h" lista cabeçalhos assinados, "i" lista a identidade do usuário assinante e, finalmente, o cabeçalho termina com dois hashes separados: "bh" é um hash de cabeçalhos assinados, enquanto "b" é o valor de hash para o corpo da mensagem.

Ao receber uma mensagem assinada por DKIM, o receptor procurará a chave pública construindo a seguinte consulta DNS:

<seletor>._domainkey.<domínio de assinatura>

conforme especificado no cabeçalho DKIM-Signature. Para o exemplo acima, nossa consulta seria "united._domainkey.news.united.com":

united._domainkey.news.united.com text = "g=*\; k=rsa\; n=" "Contact" "postmaster@responsys.com" "with" "any" "questions" "regarding" "this" "signing" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB IBwIDAQAB\;"

O registro DNS retornado contém a chave, bem como outros parâmetros opcionais. [2]

O principal problema com o DKIM é que a especificação inicial não permitia a publicidade que um remetente usa. Assim, se uma mensagem vier sem uma assinatura, não há uma maneira fácil para um receptor saber que ela deveria ter sido assinada e que, nesse caso, ela provavelmente não é autêntica. Como uma única organização pode (e na maioria das vezes usará) vários seletores, não é trivial "adivinhar" se um domínio está habilitado para DKIM. Um padrão separado, Autor Domain Signing Practices, foi desenvolvido para cobrir isso, mas devido ao baixo uso e outras questões foi obsoleto em 2013 sem sucessor.

Autenticação de mensagens, relatórios e conformidade com base em domínio (DMARC)

O DMARC é a mais nova das três tecnologias de autenticação de e-mail abordadas e foi desenvolvido especificamente para lidar com as deficiências do SPF e do DKIM. Diferentemente dos outros dois, ele autentica o cabeçalho de de uma mensagem e vincula-se às verificações executadas anteriormente pelos outros dois. O DMARC é especificado no RFC7489.

O valor acrescentado de DMARC sobre SPF e DKIM compreende:

• Verificando se todas as identidades disponíveis (HELO, MAIL FROM e/ou domínio de assinatura DKIM) estão alinhadas (exatamente correspondentes ou subordinadas) com o cabeçalho From
• Fornecer um meio para que o proprietário do domínio do remetente especifique uma política para os receptores sobre como eles devem tratar as mensagens com falha
• Fornecer um recurso de feedback para que os proprietários de domínio do remetente sejam informados de qualquer mensagem com falha, facilitando a identificação de campanhas de phishing ou erros na atribuição de política SPF/DKIM/DMARC

O DMARC também usa um mecanismo simples de distribuição de política baseado em DNS:

_dmarc.aa.com text = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 A única marca obrigatória na especificação de política de DMARC é "p", especificando a política a ser usada em mensagens com falha. Pode ser um dos três: nenhum, quarentena, rejeitar.

Parâmetros opcionais usados com mais frequência têm a ver com relatórios: "rua" especifica um URL (um mailto: ou um http:// URL usando o método POST) para enviar relatórios agregados diários sobre todas as mensagens com falha que supostamente vêm de um domínio específico. "ruf" especifica uma URL para enviar relatórios de falha detalhados imediatos em cada mensagem com falha.

De acordo com a especificação, um receptor deve aderir à política anunciada. Caso contrário, eles devem notificar o proprietário do domínio do remetente no relatório agregado.

O conceito central do DMARC é o chamado alinhamento de identificador. O alinhamento do identificador define como uma mensagem pode passar a verificação DMARC. Os identificadores SPF e DKIM são alinhados separadamente e uma mensagem precisa passar qualquer um deles para passar o DMARC em geral. No entanto, há uma opção de política DMARC em que o remetente pode solicitar que um relatório de falha seja gerado, mesmo que um alinhamento seja aprovado, mas o outro falhe. Podemos ver isso no exemplo acima com a marca "fo" sendo definida como "1".

Há duas maneiras de as mensagens aderirem ao alinhamento do identificador DKIM ou SPF, estrito e descontraído. A adesão estrita significa que o FQDN do Cabeçalho De deve corresponder totalmente ao ID de Domínio de Assinatura ("tag d") da assinatura DKIM ou ao FQDN do comando MAIL FROM SMTP para o SPF. Relaxado, por outro lado, permite que o cabeçalho do FQDN seja um subdomínio dos dois mencionados acima.  Isso tem implicações importantes ao delegar seu tráfego de e-mail a terceiros, que serão discutidos mais adiante neste documento.

Considerações de implantação do SPF

SPF para receptores

A verificação de SPF é trivial de configurar nos dispositivos virtuais do Cisco Email Security Appliance ou do Cloud Email Security. No restante deste documento, qualquer referência ao ESA também incluirá CES.

A verificação SPF é configurada em Políticas de fluxo de e-mail - a maneira mais fácil de executá-la globalmente é ativá-la na seção Parâmetros de política default do(s) ouvinte(s) apropriado(s). Se você estiver usando o mesmo ouvinte para coleta de e-mails de entrada e saída, certifique-se de que sua Política de fluxo de e-mail "RELAYED" tenha a verificação SPF definida como "Off".

Como o SPF não permite a especificação da ação da política a ser tomada, a verificação do SPF (assim como o DKIM, como veremos mais adiante) apenas verifica a mensagem e insere um conjunto de cabeçalhos para cada verificação do SPF executada:

Received-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: domínio de

  united.5765@envfrm.rsys2.com designa 12.130.136.195 como

  remetente permitido) identity=mailfrom;

  client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible; x-record-type="v=spf1"

Recebido-SPF: Nenhum (mx1.hc4-93.c3s2.smtpi.com: sem remetente

  informações de autenticidade disponíveis no domínio de

  postmaster@omp.news.united.com) identity=helo;

  client-ip=12.130.136.195; receiver=mx1.hc4-93.c3s2.smtpi.com;

  envelope-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-conformance=sidf_compatible

Observe que, para esta mensagem, duas "identidades" foram verificadas pelo SPF: "mailfrom", conforme exigido pela especificação, e "helo", conforme recomendado pelo mesmo. A mensagem transmitirá formalmente o SPF, já que apenas o primeiro é relevante para a conformidade com o SPF, mas alguns receptores podem sancionar os remetentes que não incluam registros SPF para suas identidades HELO também. Portanto, é uma boa prática incluir os nomes de host dos gateways de e-mail de saída nos registros SPF.

Depois que as Políticas de fluxo de e-mail verificam uma mensagem, cabe aos administradores locais configurar uma ação a ser executada. Isso é feito usando a regra de filtro de mensagens SPF-status() [3], ou criando um filtro de conteúdo de entrada usando o mesmo e aplicando-o às políticas de e-mail de entrada apropriadas.

Figura 1: Condição do filtro de conteúdo de verificação SPF

As ações de filtro recomendadas são para descartar mensagens com falha ("-all" no registro SPF) e colocar em quarentena as mensagens que Softfail ("~all" no registro SPF) em uma quarentena de política. No entanto, isso pode variar de acordo com seus requisitos de segurança. Alguns receptores apenas marcam mensagens com falha ou não tomam nenhuma ação visível, mas as relatam aos administradores.

Recentemente, houve um aumento significativo na popularidade do SPF, mas muitos domínios publicam registros SPF incompletos ou incorretos. Para estar no lado seguro, convém colocar em quarentena todas as mensagens com falha de SPF e monitorar a quarentena por um tempo, para garantir que não haja "falsos positivos".

Se Você Fornecer Serviços De E-Mail Para Outros Domínios Ou Terceiros

Se você fornecer serviços de entrega ou hospedagem de e-mail para terceiros, eles terão que adicionar nomes de host e endereços IP que você usa para entregar suas mensagens para seus próprios registros SPF. A maneira mais fácil de fazer isso é o provedor criar um registro SPF "abrangente" e fazer com que os clientes usem o mecanismo "incluir" em seus registros SPF.

texto suncountry.com = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:10 ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exacttarget.com ~all"

Como podemos ver, a Sun Country tem alguns de seus e-mails sob seu próprio controle, mas seu e-mail de marketing é terceirizado. A expansão do registro indicado revela uma lista de endereços IP atuais usados por seu provedor de serviços de mala direta de marketing:

cust-spf.exacttarget.com texto = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:136.111.0.0/18 ip4:13.todos"

Essa flexibilidade permite que os provedores de serviços de e-mail escalem sem ter que entrar em contato com cada cliente para modificar seus registros DNS.

Se você usa serviços de e-mail de terceiros

Da mesma forma que no parágrafo anterior, se você estiver usando qualquer serviço de e-mail de terceiros e quiser estabelecer um fluxo de e-mail totalmente verificado pelo SPF, deverá incluir seus próprios registros SPF no seu.

jetblue.com texto descritivo "v=spf1 include:_spf.qualtrics.com ?all"

A JetBlue usa o serviço de análise Qualtrics, e a única coisa que eles precisavam fazer era incluir um registro SPF correto da Qualtrics. Da mesma forma, a maioria dos outros ESPs fornece registros SPF a serem incluídos nos registros de seus clientes.

Se o seu ESP ou profissional de marketing por e-mail não fornecer registros SPF, você terá que listar os gateways de e-mail enviados diretamente no seu. No entanto, é sua responsabilidade manter esses registros precisos e, se o provedor adicionar gateways adicionais ou alterar endereços IP ou nomes de host, seu fluxo de e-mail poderá ser comprometido.

O perigo adicional de terceiros que não estão cientes de SPF vem do compartilhamento de recursos: se um ESP usa o mesmo endereço IP para entregar e-mail de vários clientes, é tecnicamente possível para um cliente gerar uma mensagem SPF válida fingindo ser outro cliente que entrega através da mesma interface. É por isso que, antes de implementar qualquer restrição de SPF, você deve investigar as políticas de segurança do MSP e a percepção da autenticação de e-mail. Se eles não tiverem respostas para suas perguntas, considerando como o SPF é um dos mecanismos básicos de confiança na Internet, você é altamente aconselhado a reconsiderar sua escolha de MSP. Não se trata apenas de segurança - o SPF, DKIM, DMARC e outras práticas recomendadas de remetentes [4]empregadas pelos MSPs são uma garantia de entrega. Se o seu MSP não segui-los ou segui-los incorretamente, isso reduzirá sua confiabilidade com grandes sistemas receptores e possivelmente atrasará ou até mesmo bloqueará suas mensagens.

(Sub)Domínios sem tráfego de e-mail

Atualmente, a maioria das organizações possui vários domínios para fins de marketing, mas usa apenas um deles ativamente para o tráfego de e-mail corporativo. Mesmo que o SPF seja implantado corretamente no domínio de produção, os agentes mal-intencionados ainda podem usar outros domínios que não são usados ativamente em um e-mail para falsificar a identidade de uma empresa. O SPF pode evitar que isso ocorra por meio de um registro SPF especial "deny all" - para qualquer um de seus domínios (e subdomínios!) que não gerem tráfego de e-mail, publique "v=spf1 -all" no DNS. Um excelente exemplo é openspf.org - o site do Conselho do SPF.

Como a delegação SPF é válida apenas para um único domínio, é essencial publicar também registros SPF "deny all" para quaisquer subdomínios que você esteja usando que possam não gerar um e-mail. Mesmo que o seu domínio de produção tenha um registro SPF "regular", faça um esforço extra para adicionar registros "deny all" (negar todos) aos seus subdomínios sem tráfego. E, novamente - não se esqueça de que receber e-mails não é equivalente a enviar: um domínio pode muito bem receber e-mails, mas nunca será uma fonte. Isso é muito verdadeiro para domínios de marketing de curto prazo (por exemplo, eventos, promoções por tempo limitado, lançamentos de produtos...), em que os e-mails recebidos para esses domínios seriam enviados ao seu domínio de produção, e qualquer resposta a esses e-mails será enviada do domínio de produção. Esses domínios de curto prazo terão um registro MX válido, mas devem ter um registro SPF que os identifique como nenhuma fonte de e-mail também.

Considerações de implantação DKIM

DKIM para receptores

A configuração da verificação DKIM no ESA é semelhante à verificação SPF. Nos Parâmetros de política padrão das Políticas de fluxo de e-mail, basta ativar a verificação DKIM. Novamente, como o DKIM não permite nenhuma especificação de política, isso apenas verificará a assinatura e inserirá um cabeçalho "Authentication-Results":

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (assinatura verificada) header.i=MileagePlus@news.united.com

Quaisquer ações baseadas nos resultados da verificação DKIM devem ser executadas por filtros de conteúdo:

Figura 2: Condição do filtro de conteúdo de verificação DKIM

Diferentemente do SPF, que é direto, o DKIM manipula o texto da mensagem real, portanto alguns parâmetros podem ser limitados. Opcionalmente, você pode criar perfis de verificação DKIM e atribuir diferentes perfis de verificação a diferentes políticas de fluxo de e-mail. Eles permitem limitar tamanhos de chave de assinaturas que você aceitará, definir ações de falha de recuperação de chave e configurar a profundidade da verificação DKIM.

À medida que uma mensagem passa por vários gateways, ela pode ser assinada várias vezes e, assim, transportar várias assinaturas. Para que uma mensagem seja aprovada na verificação DKIM, qualquer assinatura precisa ser verificada. Por padrão, o ESA verificará até cinco assinaturas.

Devido à abertura histórica do SMTP e do correio eletrônico e à relutância da Internet em geral em se adaptar a mudanças (positivas), ainda há várias situações em que as assinaturas DKIM podem falhar legitimamente, como quando os gerentes de listas de correio retransmitem diretamente, mas modificam mensagens, ou quando as mensagens são encaminhadas diretamente, em vez de anexos, para novas mensagens. É por isso que, em geral, a melhor prática para mensagens que falham no DKIM ainda seria colocar em quarentena ou marcar, em vez de descartá-las.

Preparando-se para assinar com DKIM

Antes de ativar a assinatura DKIM na política de fluxo de e-mail RELAYED, você precisa gerar/importar as chaves, criar perfis de assinatura DKIM e publicar a(s) chave(s) pública(s) no DNS.

Se você estiver assinando para um único domínio, o processo será direto. Gere o par de chaves, crie seu único perfil de assinatura na seção Chaves de domínio das Políticas de e-mail e clique na opção "Gerar" em "Registro de texto DNS" quando seu perfil estiver pronto. Publique a chave conforme gerada no DNS. Por fim, ative a Assinatura DKIM em sua Política de fluxo de e-mail.

Fica mais complicado se você estiver assinando para vários domínios distintos. Nesse caso, você tem duas opções:

1. Use um único perfil de assinatura para assinar todos os domínios. Você armazenará a chave pública (única) na zona DNS do domínio "primário", e suas assinaturas DKIM farão referência a essa chave. Esta técnica foi frequentemente utilizada por ESP no passado - permitiu-lhes assinar em grande escala, sem ter de interagir com o espaço DNS de clientes individuais [5].
2. Crie um perfil de assinatura separado para cada domínio no qual você se inscrever. Isso torna a configuração inicial mais complexa, mas oferece muito mais flexibilidade no futuro. Crie um par de chaves para cada domínio, crie um perfil especificando apenas um domínio (e seus subdomínios) na seção "Usuários do perfil" e publique a chave pública relevante na zona DNS desse domínio específico.

Embora seja mais fácil começar com a opção #1, lembre-se de que ela acabará quebrando o DMARC. Como o DMARC exige que a ID de domínio de assinatura esteja alinhada com o cabeçalho de, o alinhamento do seu identificador com o DKIM falhará. Você pode se safar se configurar seu SPF corretamente e confiar no alinhamento do identificador SPF para passar na verificação DMARC.

No entanto, ao implementar a opção #2 desde o início, você não precisa se preocupar com o DMARC e é muito fácil revogar ou reconfigurar o serviço de assinatura para apenas um domínio.  Além disso, se você fornecer alguns serviços de e-mail para um domínio de terceiros, provavelmente precisará obter a chave para usar deles (e importá-la para seu ESA). Essa chave será específica do domínio, portanto, você precisará criar um perfil separado.

Se você usa serviços de e-mail de terceiros

Em geral, se você usa a assinatura DKIM e descarrega parte do seu processamento de e-mail (por exemplo, e-mails de marketing) para terceiros, você não quer que eles usem as mesmas chaves usadas na produção. Esta é uma das principais razões para a existência de Seletores no DKIM. Em vez disso, você deve gerar um novo par de chaves, publicar a parte pública em sua zona DNS e entregar a chave secreta para a outra parte. Isso também permitirá que você revogue rapidamente essa chave específica em caso de problemas, mantendo a infraestrutura DKIM de produção intacta.

Embora não seja necessário para DKIM (as mensagens para o mesmo domínio podem ser assinadas com várias chaves diferentes), é uma boa prática fornecer um subdomínio separado para qualquer e-mail que seja tratado por terceiros. Isso facilitará o rastreamento das mensagens e permitirá uma implementação muito mais limpa do DMARC posteriormente. Como exemplo, considere estes cinco cabeçalhos DKIM-Signature de várias mensagens da Lufthansa:

Assinatura DKIM: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

Assinatura DKIM: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

Assinatura DKIM: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

Assinatura DKIM: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

Assinatura DKIM: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;  

Podemos ver que a Lufthansa está usando cinco chaves diferentes (seletores) divididas em cinco subdomínios separados de dois domínios de produção primários (lufthansa.com e milesandmore.com). Isso significa que cada um deles pode ser controlado de forma independente e pode ser terceirizado para um provedor de serviços de mensagens diferente.

Considerações de implantação do DMARC

DMARC para receptores

A verificação de DMARC no ESA é baseada em perfil, mas ao contrário do DKIM, o perfil padrão deve ser editado para estar em conformidade com a especificação. O comportamento padrão do ESA é nunca descartar nenhuma mensagem, a menos que seja explicitamente instruído pelo cliente, portanto, o perfil de verificação DMARC padrão terá todas as ações definidas como "Sem ação". Além disso, para habilitar a geração correta de relatórios, você precisará editar "Configurações globais" da seção DMARC de "Políticas de e-mail".

Depois que um perfil é configurado, a verificação de DMARC, como as outras duas, é definida na seção Default Policy Settings (Configurações de política padrão) de Mail Flow Policies (Políticas de fluxo de e-mail). Certifique-se de marcar a caixa para enviar relatórios de feedback agregados - este é provavelmente o recurso mais importante do DMARC para o remetente. No momento em que o documento foi escrito, o ESA não suporta a geração de relatórios de falha por mensagem (tag "ruf" da política DMARC).

Como as ações de política de DMARC são aconselhadas pelo remetente, ao contrário de SPF ou DKIM, não há ações específicas configuráveis fora da configuração do perfil. Não é necessário criar filtros de conteúdo.

A verificação de DMARC adicionará outros campos ao cabeçalho Authentication-Results:

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (assinatura verificada) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

No exemplo acima, vemos que o DMARC foi verificado com base no alinhamento do identificador DKIM, e o remetente solicitou uma política de "nenhum". Isso indica que eles estão atualmente na fase de "monitoramento" da implantação do DMARC.

Se Você Fornecer Serviços De E-Mail Para Outros Domínios Ou Terceiros

A maior preocupação dos ESPs quanto à conformidade com o DMARC é obter o alinhamento adequado dos identificadores. Ao planejar o DMARC, certifique-se de que seu SPF esteja configurado corretamente, que todos os outros domínios relevantes tenham seus gateways de saída em seus registros SPF e que eles não enviem mensagens que falharão no alinhamento, principalmente usando domínios diferentes para a identidade MAIL FROM e Header From. Esse erro é mais frequentemente cometido por aplicativos que enviam notificações ou avisos por e-mail, pois os autores dos aplicativos geralmente não estão cientes das consequências da inconsistência de suas identidades de e-mail.

Conforme descrito anteriormente, certifique-se de usar um perfil de assinatura DKIM separado para cada domínio e de que seu perfil de assinatura referencia corretamente o domínio para o qual você está assinando como usado no cabeçalho De. Se você estiver usando seus próprios subdomínios, poderá assinar com uma única chave, mas certifique-se de definir sua adesão ao DKIM como relaxada na política DMARC ("adkim="r").

Em geral, se você estiver fornecendo serviços de e-mail para um número maior de terceiros sobre os quais você não tem controle direto, é uma boa prática escrever um documento de orientação sobre como enviar um e-mail com maior probabilidade de entrega. Como o e-mail de usuário para usuário é geralmente bem comportado, ele servirá principalmente como um documento de política para os autores de aplicativos nos exemplos mencionados acima.

Se você usa serviços de e-mail de terceiros

Se você usar terceiros para entregar parte do tráfego de e-mail, a melhor maneira é delegar um subdomínio separado (ou um domínio completamente diferente) ao provedor de terceiros. Dessa forma, eles podem gerenciar os registros SPF conforme necessário, ter uma infraestrutura de assinatura DKIM separada e não interferir no tráfego de produção. Em seguida, a política DMARC para e-mails terceirizados pode ser diferente da política interna. Como já mencionado, ao considerar o e-mail entregue por terceiros, sempre certifique-se de que seus identificadores serão alinhados, e sua adesão ao DKIM e SPF será definida adequadamente em sua política DMARC.

(Sub)Domínios sem tráfego de e-mail

Outra melhoria do DMARC em relação às tecnologias de autenticação de e-mail anteriores é como ele trata os subdomínios. Por padrão, a política de DMARC de um domínio específico aplica-se a todos os seus subdomínios. Ao recuperar registros de política de DMARC, se nenhum registro puder ser encontrado no cabeçalho do nível de FQDN, os receptores são obrigados a determinar o domínio organizacional [6]do remetente e procurar um registro de política lá.

No entanto, a política de DMARC para um domínio organizacional também pode especificar uma política de subdomínio separada ("sp" tag de um registro de DMARC) que se aplicará a qualquer subdomínio que não tenha uma política de DMARC explícita publicada.

No cenário discutido anteriormente no capítulo SPF, você deve:

1. Publique um registro DMARC explícito para todos os subdomínios que sejam fontes legítimas de e-mail.
2. Publique uma política de subdomínio de "rejeitar" em seu registro de política de Domínio Organizacional para rejeitar automaticamente qualquer e-mail que falsifique domínios de não envio

Esse tipo de estrutura de autenticação de e-mail fornece a melhor proteção possível da sua infraestrutura e marca.

Problemas específicos de DMARC

Há vários problemas em potencial com o DMARC, todos decorrentes da natureza e das deficiências de outras tecnologias de autenticação nas quais ele se baseia. O problema é que o DMARC trouxe esses problemas à tona, empurrando ativamente uma política para rejeitar o e-mail e correlacionando todos os diferentes identificadores de remetente em uma mensagem.

A maioria dos problemas ocorrem com listas de discussão e software de gerenciamento de listas de discussão. Quando um e-mail é enviado a uma lista de mala direta, ele é redistribuído a todos os seus destinatários. No entanto, o e-mail resultante, com um endereço de remetente do remetente original, será entregue pela infraestrutura de hospedagem do gerenciador de lista de mala direta, falhando assim nas verificações SPF para Cabeçalho De (a maioria dos gerenciadores de lista de mala direta usa o endereço da lista como Envelope De (MAIL DE) e o endereço do remetente original como Cabeçalho De).

Como o DMARC falhará para o SPF, podemos confiar no DKIM. No entanto, a maioria dos gerentes de listas de mala direta também adiciona rodapés às mensagens ou marca assuntos com o nome da lista, interrompendo assim a verificação de assinatura DKIM.

Os autores do DKIM sugerem várias soluções para o problema, todas as quais se resumem aos gerentes de listas de discussão que precisam usar o endereço da lista em todos os endereços De, e indicando o endereço do remetente original por outro meio.

Problemas semelhantes surgem a partir de mensagens que são encaminhadas apenas copiando a mensagem original sobre SMTP para o novo destinatário. No entanto, a maioria dos agentes de usuário de correio em uso atualmente formará corretamente uma nova mensagem e incluirá a mensagem encaminhada embutida ou como um anexo à nova mensagem. As mensagens encaminhadas dessa forma passarão o DMARC se o usuário de encaminhamento passar (é claro que a autenticidade da mensagem original não pode ser estabelecida).

Exemplo De Plano De Ação Para Implementar A Autenticação De E-Mail

Embora as tecnologias em si sejam simples, o caminho para implementar uma infraestrutura completa de autenticação de e-mail pode ser longo e difícil. Para as empresas menores e aquelas com fluxos de e-mail controlados, será bastante simples, enquanto os ambientes maiores podem considerá-lo excepcionalmente desafiador. Não é raro que grandes empresas contratem consultoria para gerenciar o projeto de implementação.

Etapa 1: DKIM

O DKIM é relativamente não intrusivo, já que as mensagens não assinadas não sofrerão rejeições. Antes da sua aplicação efetiva, ter em conta todos os pontos anteriormente referidos. Entre em contato com terceiros aos quais você possa delegar a assinatura, verifique se os terceiros suportam a assinatura DKIM e considere a estratégia de gerenciamento do seletor. Algumas organizações manteriam chaves separadas (seletores) para diferentes unidades organizacionais. Você pode considerar a rotação periódica de chaves para obter segurança adicional, mas certifique-se de não excluir as chaves antigas até que todas as mensagens em trânsito sejam entregues.

Deve ser dada especial atenção aos tamanhos das teclas. Embora, em geral, "mais é melhor", você deve levar em conta que a criação de duas assinaturas digitais por mensagem (incluindo canonicalização, etc.) é uma tarefa muito cara para a CPU e pode influenciar o desempenho dos gateways de e-mail de saída. Devido à sobrecarga de computação, 2048 bits é o maior tamanho de chave prático que pode ser usado, mas para a maioria das implantações, as chaves de 1024 bits fazem um bom comprometimento entre desempenho e segurança.

Para a implementação subsequente bem-sucedida do DMARC, você deve:

1. identificar todos os domínios que você envia como, incluindo subdomínios
2. gerar chaves DKIM e criar perfis de assinatura para cada domínio
3. fornecer chaves privadas relevantes a terceiros
4. publicar todas as chaves públicas nas zonas DNS relevantes
5. verifique se terceiros estão prontos para começar a assinar
6. ativar a assinatura DKIM na política de fluxo de e-mail RELAYED em todos os seus ESAs
7. notificar terceiros para começar a assinar

Etapa 2: SPF

A implementação adequada do SPF provavelmente será a parte mais demorada e problemática de qualquer implementação de infraestrutura de autenticação de e-mail. Como o e-mail era muito simples de usar e gerenciar e totalmente aberto do ponto de vista de segurança e acesso, as empresas historicamente não aplicavam políticas rígidas sobre quem e como pode usá-lo. Isso fez com que a maioria das empresas hoje não tivesse uma visão completa de todas as diferentes fontes de e-mail, tanto de dentro como de fora. O maior problema da implementação do SPF é descobrir quem está enviando e-mails legitimamente em seu nome.

Itens a serem procurados:

1. destinos óbvios - servidores Exchange ou outros servidores groupware ou gateways de e-mail de saída
2. quaisquer soluções DLP ou outros sistemas de processamento de e-mail que possam gerar notificações externas
3. Sistemas CRM que enviam informações que interagem com clientes
4. vários aplicativos de terceiros que podem enviar e-mails
5. servidores de laboratório, teste ou outros servidores que possam enviar e-mails
6. computadores pessoais e dispositivos configurados para enviar um email externo diretamente

A lista acima não está completa, pois as organizações têm ambientes diferentes, mas deve ser considerada como uma orientação geral sobre o que procurar. Depois que (a maioria das) suas fontes de e-mail forem identificadas, talvez você queira dar um passo atrás e, em vez de autorizar cada fonte existente, limpe a lista. Idealmente, todos os seus e-mails de saída devem ser entregues através dos gateways de e-mail de saída com algumas exceções justificadas. Se você tiver sua própria solução de e-mail de marketing ou usar uma solução de e-mail de marketing de terceiros, use uma infraestrutura separada dos gateways de e-mail de produção. Se sua rede de entrega de e-mail for excepcionalmente complicada, você poderá continuar documentando o estado atual em seu SPF, mas reserve um tempo para limpar a situação no futuro.

Se você atende a vários domínios na mesma infraestrutura, talvez queira criar um único registro SPF universal e fazer referência a ele em domínios individuais usando o mecanismo de "inclusão". Certifique-se de que seus registros SPF não sejam muito amplos; por exemplo, se apenas cinco máquinas em uma rede /24 enviarem SMTP, adicione esses cinco endereços IP individuais ao seu SPF, em vez de adicionar toda a rede. Tenha como objetivo que seus registros sejam o mais específicos possível para minimizar as chances de e-mails mal-intencionados comprometerem sua identidade.

Comece com uma opção softfail para remetentes não correspondentes ("~all"). Somente altere-o para falha grave (-all) depois de ter 100% de certeza de ter identificado todas as suas fontes de e-mail, caso contrário, você corre o risco de perder e-mails de produção. Mais tarde, após implementar o DMARC e executá-lo no modo de monitor por algum tempo, você poderá identificar todos os sistemas perdidos e atualizar seus registros SPF para estarem completos. Somente então será seguro definir seu SPF como falha grave.

Etapa 3: DMARC

Depois que o DKIM e o SPF estiverem configurados da maneira mais completa possível, é hora de criar suas políticas de DMARC. Considere todas as diferentes situações mencionadas nos capítulos anteriores e prepare-se para implantar mais de um registro DMARC se você tiver uma infraestrutura de e-mail complexa.

Crie aliases de email que receberão relatórios ou crie um aplicativo Web que possa inseri-los. Não há endereços de e-mail estritamente definidos para serem usados para isso, mas ajuda se eles forem descritivos, por exemplo, rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com, etc. Verifique se você tem um processo em vigor para que um operador monitore esses endereços e modifique a configuração de SPF, DKIM e DMARC adequadamente, ou alerte a equipe de segurança em caso de campanha de falsificação. Inicialmente, a carga de trabalho será substancial à medida que você ajusta os registros para cobrir qualquer coisa que possa ter perdido durante a configuração de SPF e DKIM. Depois de algum tempo, os relatórios provavelmente indicarão apenas tentativas de falsificação.

Inicialmente, defina sua política de DMARC como "none" e sua opção forense para enviar relatórios para qualquer verificação com falha ("fo=1") - isso descobrirá rapidamente quaisquer erros em seu SPF e DKIM, sem influenciar o tráfego. Quando estiver satisfeito com o conteúdo dos relatórios enviados, altere a política para "quarentena" ou "rejeitar", dependendo da política de segurança e das preferências. Novamente, certifique-se de que os operadores estejam analisando continuamente os relatórios DMARC recebidos em busca de falsos positivos.

A implementação completa e correta do DMARC não é uma tarefa pequena ou curta. Embora alguns resultados (e a "implementação" formal do DMARC) possam ser obtidos com a publicação de um conjunto incompleto de registros e uma política de "nenhum", é do interesse tanto da empresa remetente quanto da Internet como um todo que todos os usuários o implementem em toda a extensão de seus recursos.

Em relação aos cronogramas, aqui está um esboço bastante aproximado das etapas individuais de um projeto típico. Novamente, como cada organização é diferente, elas estão longe de serem precisas:

1. Planeamento e preparação da DKIM	2 a 4 semanas
2. Execuções de teste DKIM	2 semanas
3. SPF - identificação legítima do remetente	2 a 4 semanas
4. Preparação da política DMARC	2 semanas
5. Execução de teste de registros SPF e DMARC	4 a 8 semanas
6. Execução de ensaio SPF com falha grave	2 semanas
7. Execução de teste de DMARC com quarentena/rejeição	4 semanas
8. Acompanhamento dos relatórios do DMARC e adaptação do SPF/DKIM em conformidade	contínuo

As empresas menores provavelmente experimentarão uma duração mais curta da maioria das etapas, especialmente as etapas 3 e 4. Não importa o quão simples sua infraestrutura de e-mail seja, sempre aloque tempo suficiente durante a execução dos testes e monitore os relatórios de feedback com atenção para qualquer coisa que você possa ter perdido.

Empresas maiores podem experimentar uma duração ainda maior das mesmas etapas, com requisitos de teste mais rigorosos. Não é raro empresas com infraestruturas de e-mail complexas contratarem ajuda externa, não apenas para o aspecto técnico da implementação da autenticação de e-mail, mas também para gerenciar todo o projeto e coordenar equipes e departamentos.

Referências adicionais

• O site de referência do SPF: http://www.openspf.org
• Conselho DKIM: http://www.dkim.org
• Site principal do DMARC, executado pelo The Trusted Domain Project: http://www.dmarc.org
• dmarcian - um site de ajuda e recursos administrado por Tim Draegen, um dos autores do DMARC. Visite a seção "Ferramentas": http://www.dmarcian.com
• Ferramenta Record Validator da Online Trust Alliance: https://otalliance.org/resources/spf-dmarc-record-validator
• Assistente de registro DMARC - outra ferramenta útil para ajudá-lo a criar seus registros DMARC: http://www.kitterman.com/dmarc/assistant.html
• Ferramentas de teste de registro SPF: http://www.kitterman.com/spf/validate.html
• "Don’t Be A Phish: Deep Dive Into Email Authentication Techniques" (Não seja um phishing: aprofunde-se nas técnicas de autenticação de e-mail), uma apresentação do Cisco Live 2014 BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] A canonização está fora do escopo deste documento. Consulte o material na seção "Referências adicionais" para obter mais informações sobre a canonização DKIM.

[2] Os parâmetros de registro DNS DKIM também estão fora do escopo deste documento.

[3] A criação de filtros de mensagens está fora do escopo deste documento. Consulte os guias do usuário do AsyncOS for Email para obter assistência.

[4] A M3AWG definiu um excelente conjunto de práticas recomendadas aplicadas e honradas pela maioria do setor. O documento de práticas recomendadas comuns do remetente está disponível em https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] Esse comportamento aproveita o fato de que, originalmente, o DKIM não verifica a origem da mensagem conforme declarado em MAIL FROM ou Header From. Ele apenas verifica se o ID de domínio de assinatura ("d" parâmetro da assinatura DKIM e "Domain Name" parâmetro em seu perfil de assinatura) está realmente hospedando a chave pública do par usado para assinar a mensagem. A autenticidade do remetente está implícita em ter o cabeçalho "De" assinado. Apenas certifique-se de listar todo e qualquer domínio (e subdomínios) em que você se inscreve na seção "Usuários com perfil".

[6] Geralmente, um domínio um nível abaixo do TLD ou prefixo ccTLD relevante (.ac.uk, .com.sg etc...)