Série de e-mails desajustados: meu e-mail não é autêntico o suficiente

Em meu último artigo, abordei os conceitos básicos e o contexto dos vários protocolos de autenticação disponíveis para os remetentes usarem a fim de mostrar aos destinatários que seus e-mails são autênticos e pertencem a suas marcas.  Recentemente, me fizeram uma pergunta: “E se o meu e-mail não for autêntico o suficiente?” Hoje, vou explicar os possíveis problemas e soluções da autenticação de e-mail inadequada, então puxe uma cadeira e fique à vontade.

Os protocolos de autenticação de e-mail são elementos técnicos.  Como em tudo que é técnico, se não forem implementados corretamente, pode haver e haverá consequências.  Algumas serão apenas um pequeno inconveniente, mas outras podem ser bem catastróficas. Neste blog, gostaria de destacar alguns dos casos mais notórios em que nossos clientes não acertaram em cheio na autenticação de e-mail e o que fazer a respeito.

Como o Mailgun costuma atuar como uma fonte secundária de e-mails de saída para um domínio, vemos clientes com dificuldades para implementar corretamente os registros SPF de todas as suas plataformas de envio.  Um problema comum que encontramos é quando um cliente adiciona um registro TXT secundário para o SPF do Mailgun, mas deixa o SPF primário intacto. Um exemplo ajudará a ilustrar as coisas e, a partir de agora, usarei nosso domínio fictício favorito, meowgun.com.  Usaremos como referência:

dig txt meowgun.com

; <> DiG 9.10.6 <> txt meowgun.com

;; ANSWER SECTION:

meowgun.com.   869    IN TXT    "v=spf1 include:mailgun.org ~all"

meowgun.com.   869    IN TXT    "v=spf1 ipv4:127.0.0.1 ~all

Aqui, vemos os dois registros SPF sendo retornados. O problema que isso representa para os servidores destinatários é que, dependendo de qual registro retornar primeiro, o destinatário pode aplicar o registro IPv4 ou o registro include:mailgun.org. Se você não quer contar com a sorte, existe uma maneira melhor.

A solução aqui é bem simples: combinar os registros em uma única entrada TXT do SPF usando a sintaxe correta. A sintaxe do SPF é bastante flexível por permitir muitas fontes de e-mail em um pequeno registro TXT, desde que você faça sua lição de casa.  Veja como recomendamos integrar os registros no cenário acima:

"v=spf1 ipv4:127.0.0.1 include:mailgun.org ~all"

Agora temos um registro SPF organizado que abrange todas as nossas fontes de e-mail.

As especificações do SPF limitam a 10 a quantidade de pesquisas de DNS que podem ser feitas em nome de um registro SPF.  A seguir, estão todos os mecanismos do SPF que acionarão uma pesquisa de DNS:

• Um
• Exists
• Include
• MX
• PTR

Para alguns remetentes com várias fontes de fluxos de e-mail para seu domínio, não demora muito para que seus registros SPF se tornem difíceis de gerenciar e acabem implementando um registro acima do limite permitido.

Em relação a esse problema, não existe uma solução única e tudo dependerá das fontes de e-mail de um remetente.  Dito isso, há algumas recomendações gerais que podemos passar para ajudar a orientar você:

• Saiba quantas pesquisas são usadas em seu mecanismo include. Os includes podem ser aninhados e resultar em mais de 1 pesquisa.  O registro SPF do Mailgun se enquadra nessa categoria e exige 3 pesquisas no total devido aos includes aninhados.
• Não use mecanismos PTR.  
• Como os mecanismos IPv4 e IPv6 referenciam IPs diretamente, eles não exigem pesquisa de DNS e você pode usá-los à vontade.
• A maioria dos servidores web e poucos servidores MX de entrada estão configurados corretamente para enviar e-mails, portanto, tenha cuidado ao usar os mecanismos A ou MX se não forem absolutamente necessários.
• Para algumas empresas, as fontes de e-mail mudam regularmente, portanto, certifique-se de revisar o registro SPF completo de vez em quando e remover todas as entradas desnecessárias.  O sistema de DNS global agradece.
• NÃO. PTR. MECANISMOS.

Falando sério por um momento, o mecanismo PTR pode sair do controle muito rápido devido à implementação, e você não encontrará muitos fornecedores de boa reputação que o recomendem.

Às vezes, ao testar ou receber feedback de um destinatário de e-mail, nossos clientes notam que algumas mensagens enviadas pela plataforma do Mailgun têm mais de uma assinatura DKIM nos cabeçalhos da mensagem.  Eles costumam entrar em contato com nossa equipe de suporte para perguntar por que isso acontece e se suas mensagens estão configuradas incorretamente de alguma forma.

Não se preocupe, suas mensagens não estão configuradas incorretamente e não há nada de malicioso acontecendo com as mensagens que têm várias assinaturas DKIM. O Mailgun adicionará uma dupla assinatura DKIM às mensagens quando forem enviadas a provedores que exigem uma assinatura DKIM do ESP como parte de seus sistemas de ciclo de feedback.

Gmail e Verizon Media Group (Yahoo/AOL/Verizon) são os maiores nomes que têm esse estilo de ciclo de feedback implementado. Sendo assim, nossas equipes de engenharia e de reputação decidiram que usaremos dupla assinatura DKIM nas mensagens para esses sistemas, de modo a garantir que possamos obter o feedback deles para nossos clientes. Mensagens com dupla autenticação e feedback dos ESPs são uma situação em que todos saem ganhando.

Como administradores teóricos do Meowgun.com, uma marca bem estabelecida dos melhores memes de gatos da internet que tem o objetivo de dominação global de memes, queremos expandir nossos domínios de envio para abranger algumas novas áreas: envios transacionais e campanhas de marketing. Portanto, transgressions.meowgun.com e meowketing.meowgun.com são escolhidos para lidar com esses dois novos fluxos de e-mail.  Esses domínios se juntarão ao meowgun.com em nossa conta do Mailgun e, por padrão, herdarão automaticamente a autoridade DKIM do meowgun.com. 

 Mas será que deveriam?

Mais uma vez, não há uma resposta única aqui, mas as principais considerações são o nível de conforto em relação à sobreposição da reputação do domínio, o nível de conforto com um procedimento de aquecimento de domínio e a vida útil do fluxo de e-mail.

Separar

• Se você não quer nenhuma sobreposição de reputação entre os fluxos de e-mail, separar é a sua resposta.  Cada versão do domínio terá pouco ou nenhum impacto na reputação dos outros.
• Separar significa que os novos domínios não terão reputação entre os provedores, então considere uma estratégia de aquecimento adequada
• É melhor manter separados os fluxos de e-mail que terão uma vida útil considerável.

Herdar da raiz

• Se a sobreposição de reputação não for um grande problema, você pode herdar sem medo.  Tenha cuidado com fluxos de marketing, pois o engajamento de marketing costuma ser menor do que o engajamento de mensagens transacionais ou de pessoa para pessoa, o que pode ter um efeito negativo na reputação do domínio primário.
• Se você precisar evitar o aquecimento de um novo domínio, considere a herança. A degradação da reputação mencionada acima também se aplica aqui.
• Se precisar de um fluxo de e-mail de curto prazo (algumas semanas a um mês) em uma escala de volume menor para um público de alto engajamento, considere a herança.

A última coisa a ter em mente sobre a autoridade DKIM é que você não fica preso à sua escolha depois de tomá-la. As configurações sempre podem ser alteradas chamando nossa API de domínios ou entrando em contato com nossa equipe de suporte, mas as considerações de reputação ainda se aplicarão após a mudança.

Como as implementações de DMARC pelos sistemas destinatários continuam ganhando força no setor e as taxas de adoção aumentam, implementar uma política de DMARC inteligente pode trazer dividendos reais para a reputação do remetente. Temos muitos clientes preocupados com a segurança que desejam aplicar imediatamente a política p=reject mais rigorosa.  Sempre parece uma boa ideia até que recebem relatórios de e-mails válidos sendo bloqueados por causa da política e clientes chateados querendo saber para onde foi o e-mail deles.

Aqui, a paciência vale a pena. Inúmeras interações com clientes nos mostraram que é melhor implementar uma política p=none por um longo período antes de tentar uma política mais rigorosa. Isso dá tempo para os administradores da política receberem relatórios sobre todos os e-mails que falham na política e ajustarem adequadamente o registro DMARC ou o fluxo de e-mail. Considere um período de algumas semanas a um mês para tentar contabilizar todos os fluxos de e-mail e suas respectivas cadências. Assim que todos os fluxos válidos passarem na política, comece a optar por uma política mais restrita, como p=quarantine ou p=reject, para começar a colher os frutos da reputação do domínio.

Esperamos que alguns desses cenários sejam úteis aos nossos clientes em suas implementações dos vários protocolos de autenticação de e-mail. No entanto, há muito mais a explorar em cada protocolo de autenticação, mas não entre em pânico. Se você ainda tiver dúvidas ou preocupações sobre seus protocolos de autenticação de e-mail, não hesite em entrar em contato com nossa equipe de suporte, que terá o maior prazer em ajudar a esclarecer sua jornada de envio de e-mails.

Autor: Levi Trejo Technical Account Manager at Sinch Mailgun