Como autenticar seu e-mail para ter melhores taxas de entrega

14 de maio de 2025

Ao criar aplicativos que enviam e-mails, como plataformas de marketing ou sistemas de CRM, você precisa que a sua base de usuários tenha a confiança de que as mensagens chegarão à caixa de entrada. Porém, com a evolução das medidas antispam, até mesmo e-mails legítimos podem enfrentar obstáculos.

Os protocolos de autenticação de e-mail, como SPF, DKIM e DMARC, verificam a identidade do remetente, evitam o spoofing e dão suporte a uma forte reputação do remetente. Nesta postagem explicamos como esses protocolos funcionam, como configurá-los e como confirmar que estão configurados corretamente, para que seus e-mails sejam entregues como planejado.

Se o seu aplicativo oferece funcionalidade de e-mail, você precisa ter certeza de que as mensagens sejam realmente entregues. Uma autenticação mal configurada não deve fazer com que quem usa pense que as mensagens foram enviadas, quando na verdade não foram.

Autenticação : problemas de configuração podem resultar em muitas taxas de devolução, reclamações de spame endereços IP em listas de bloqueio. Isso também abre espaço para ataques de phishing e de spoofing de e-mail, que podem causar impacto na reputação do remetente e na postura de segurança da organização.

Problemas de entregabilidade também podem consumir o tempo da equipe de desenvolvimento, o que impacta a produtividade. Pense em casos em que problemas intermitentes de entrega são escalados por meio do suporte ao cliente para a equipe de desenvolvimento. A equipe de desenvolvimento precisa então parar o que está fazendo e descobrir o que aconteceu com os e-mails afetados, se houve devolução ou se enfrentaram outros problemas de entrega. Diagnosticar esses problemas pode consumir muito tempo e acabar com a produtividade, se ocorrerem com frequência.

Felizmente, nenhum desses problemas é novo, e há soluções que você pode adotar para melhorar a entregabilidade de e-mail. Protocolos de autenticação de e-mail (incluindo SPF, DKIM e DMARC) podem ser usados para mitigar esses problemas. E, quando você os utiliza em conjunto, pode colocar seu aplicativo de envio de e-mail na melhor posição para ter sucesso com uma entrega de e-mail confiável e segura.

O SPF é um mecanismo que permite definir registros DNS, os quais rastreiam os servidores autorizados a enviar e-mails em nome de seu domínio. Sem os registros SPF, qualquer pessoa conseguiria enviar e-mails com spoofing fingindo ser do seu domínio, e não haveria como verificar essas alegações. De modo semelhante, registros SPF mal configurados podem ser problemáticos: você pode enviar um e-mail legítimo do seu próprio domínio, mas se os registros SPF não estiverem configurados para incluir o servidor de envio como uma fonte válida, é provável que o e-mail seja sinalizado como spam ou rejeitado.

Para verificar se o seu domínio já tem registros SPF, você pode usar uma ferramenta como o MxToolbox. Ou, se preferir o terminal, você pode usar o comando dig, assim:

$ dig +short TXT yourdomain.com | grep spf

Se estiver faltando um registro SPF, você não verá nenhuma saída. Porém, se você já tiver um registro, deverá ver algo assim:

v=spf1 include:mailgun.org ~all

Há três componentes principais nesse registro:

• v=spf1 indica a versão do protocolo SPF que está sendo usada. Todos os registros SPF devem começar com essa tag.
• include:mailgun.org especifica que o domínio mailgun.org tem permissão para enviar e-mails em nome do seu domínio. Quando o servidor de e-mail de recebimento recebe um e-mail do mailgun.org, ele verifica a presença de um registro SPF que inclua isso para validar o servidor de envio. Observe que você pode incluir vários domínios aqui, se desejar, como include:mailgun.org include:google.com.
• ~all especifica a política para e-mails que não correspondem às regras do SPF. Nesse caso, o ~ indica uma “falha leve”, em que os e-mails que não correspondem à política devem ser aceitos, mas marcados como suspeitos, em vez de serem totalmente rejeitados. Outra opção é usar -all para especificar uma “falha grave” nos e-mails que não correspondem à política.

Agora que você entende os componentes de um registro SPF, criar um registro para o seu domínio é apenas uma questão de adicionar um novo registro DNS TXT.

Se você não tem certeza de como fazer isso, a central de ajuda da Mailgun tem guias para os seguintes provedores de DNS:

• GoDaddy
• Cloudflare
• Namecheap
• Google Domains
• DigitalOcean

Se você já tem um registro SPF e precisa adicionar um novo domínio, saiba que não pode adicionar vários registros SPF para o mesmo domínio. Em vez disso, você precisa modificar o registro existente e adicionar um novo valor a ele. Por exemplo, se o seu registro SPF atual é v=spf1 include:example.com ~all e você deseja adicionar mailgun.org, o seu novo registro seria v=spf1 include:example.com include:mailgun.org ~all.

Embora os registros SPF básicos sejam bastante simples de criar e gerenciar, eles podem causar atritos à equipe de desenvolvimento quando você precisa gerenciar registros SPF para vários serviços de envio. Por exemplo, se você tem ferramentas de marketing, CRMs e serviços de envio de mensagens enviando e-mails do mesmo domínio, pode acabar com registros SPF longos e complexos.

O protocolo SPF também tem um limite de dez pesquisas de DNS, e apenas as primeiras dez pesquisas do seu registro SPF gerarão ações. Se o e-mail não for correspondido nessas dez pesquisas, ele será tratado como não autenticado. Quando isso acontece, há algumas coisas que você pode tentar:

• Subdomínios dedicados: você pode atribuir a cada serviço de envio um subdomínio dedicado e, em seguida, definir registros SPF simples em cada subdomínio. Isso facilita o gerenciamento de um grande número de serviços de envio e contorna o limite de pesquisas, pois cada registro é mínimo.
• Ferramentas de nivelamento de registros SPF: existem ferramentas para nivelar os registros SPF em endereços IP ou intervalos de IP, o que pode ajudar a lidar com o limite de pesquisas. Porém, isso pode introduzir novos problemas, portanto os subdomínios dedicados podem ser os preferidos.

DKIM é um protocolo de autenticação de e-mail que permite anexar uma assinatura digital aos e-mails, possibilitando a identificação e a prevenção contra falsificações. Quando um e-mail é assinado com DKIM, ocorre o seguinte fluxo:

O principal objetivo do DKIM é provar que um e-mail não foi falsificado e que chegou com o conteúdo original enviado pelo servidor do remetente signatário. Porém, como efeito colateral, ele também pode ajudar a reduzir as chances de o e-mail ser marcado como spam com base na heurística do conteúdo. Isso ocorre porque a validação consistente de e-mails com DKIM melhorará a reputação do remetente com o passar do tempo, o que acabará reduzindo a dependência dos filtros de spam em relação aos sinalizadores de spam baseados em conteúdo.

Verificar se você tem o DKIM configurado em um domínio é um pouco mais complexo do que verificar o SPF, pois o registro DNS do DKIM existe em um subdomínio especial que usa um “seletor” arbitrário. Como o seletor pode ser qualquer sequência de caracteres alfanuméricos, a única forma de determinar qual deles verificar é com o mesmo método usado pelo servidor de recebimento: examinando o cabeçalho DKIM-Signature no e-mail. Se você analisar o conteúdo bruto de um e-mail assinado com DKIM e pesquisar esse cabeçalho, verá algo semelhante a isto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=dkim; t=1672618838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:to:to:cc:mime-version:mime-version:content-type:content-type:content-transfer-encoding:content-transfer-encoding:in-reply-to:in-reply-to:references:references; bh=RKkrHxZminSEI0rxtiN3+8wFv6vKCozhmrATLVIZFcw=; b=lndiW4xUpmGqbbIxjiER0FEa67zPqpmW+MqrmMcvuvgd+Gta851Jd+lU4yJ4rmiCHSPfRA gDh+ZsPC8UWZ8U5cfg14uFuvtxUWr6N9Ncy1mntgz7ZNhMIovpknioDIOLYD2wM72mglVP BAeTy2oHVZ0B6tBQqC4/hePtzyF0dnU=

Esse cabeçalho é composto de vários componentes:

Componente	Finalidade	Exemplo de valor
v	Versão do DKIM	v=1
a	Algoritmo de assinatura	rsa-sha256
c	Método de canonicalização	relaxed
d	Domínio de assinatura	example
s	Seletor para pesquisa de chave pública de DNS	dkim
t	Timestamp	1672618838
h	Cabeçalhos incluídos na assinatura	from:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references
bh	Hash do corpo	RKkrHxZminSEI0
b	Assinatura criptográfica	lndiW4xUpmGq

O servidor de recebimento precisa dessas informações para verificar o e-mail. Ele recalcula o hash do e-mail, incluindo os cabeçalhos especificados no componente h, e recupera a chave pública do registro DNS usando o seletor no componente s (dkim, neste caso). Quando o seletor é combinado com o domínio do remetente, o local completo da chave DKIM ficará assim: ._domainkey..

Por exemplo, se o seu seletor fosse dkim e o seu domínio fosse example.com, o registro DNS estaria localizado em dkim._domainkey.example.com. Neste caso, você poderia visualizar o registro DNS usando uma ferramenta online ou dig:

$ dig +short TXT dkim._domainkey.example.com

Se um registro for encontrado, a sua saída será parecida com esta:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE...

Este registro tem três componentes:

• v=DKIM1 especifica a versão do DKIM.
• k=rsa define o tipo de chave (RSA é o padrão).
• p= contém a chave pública.

Ao configurar o DKIM, você precisa gerar um par de chaves que consiste em uma chave pública e uma privada. O servidor de envio usa a chave privada para assinar e-mails, e a chave pública é publicada como um registro DNS e usada pelo servidor de recebimento para validar esses e-mails.

Normalmente, se você estiver configurando o DKIM para um serviço de envio de e-mails, o serviço gerará as chaves para você (ou permitirá usar as suas próprias, em alguns casos). Por exemplo, o Mailgun fornece instruções passo a passo sobre como gerar e configurar registros DKIM para um determinado domínio. No entanto, é bom entender o processo subjacente e, em alguns casos, você pode preferir ter custódia total do par de chaves.

Para este exemplo, você pode gerar o par de chaves usando uma ferramenta como o openssl. Primeiro, gere a chave privada assim:

openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048

Esse comando cria um arquivo chamado private.key contendo a chave privada RSA. Em seguida, você pode usar essa chave privada com o openssl para criar a chave pública:

openssl rsa -pubout -in private.key -out public.key

Assim que tiver a chave pública, você poderá criar o registro DNS para ela com o seu seletor de preferência (dkim, neste caso). O registro DNS ficará assim:

dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE...etc"

De forma semelhante ao SPF, o DKIM pode introduzir complexidade para a sua equipe de desenvolvimento. Desafios podem surgir, como o mau gerenciamento de chaves privadas e conflitos entre serviços de remetente.

A proteção que o DKIM oferece é tão boa quanto as suas práticas de gerenciamento de chaves. Uma chave de assinatura comprometida pode expor você a agentes mal-intencionados e e-mails falsificados. Sendo assim, você deve manter uma boa higiene de segurança ao lidar com chaves privadas, armazenando-as de forma segura em um serviço como o AWS Secrets Manager ou o HashiCorp Vault. Da mesma forma, geralmente é uma boa ideia rotacionar as chaves de assinatura regularmente, pois isso limita o possível impacto de uma chave comprometida. O fato de os seletores do DKIM serem arbitrários é útil aqui, pois você pode começar a enviar e-mails com um novo seletor, assinados com uma nova chave privada, enquanto descontinua o seu par de chaves antigo.

DMARC é outro protocolo de autenticação de e-mail projetado para ajudar a mitigar spoofing, phishing e spam. O DMARC se baseia no SPF e no DKIM. Especificamente, o DMARC usa o SPF e o DKIM para realizar verificações em e-mails recebidos e aplicar a política do DMARC definida de acordo com o resultado dessas verificações.

O DMARC também realiza uma verificação de alinhamento para o SPF e o DKIM, garantindo que o domínio especificado por esses mecanismos também corresponda ao domínio no cabeçalho from: do e-mail, aumentando ainda mais o rigor para evitar o spoofing.

Os registros DMARC são publicados em um subdomínio conhecido (_dmarc) do seu domínio de envio. Por exemplo, se você quisesse verificar o registro DMARC de example.com com o dig, executaria um comando como este:

$ dig +short TXT _dmarc.example.com

Se você tivesse um registro configurado para este domínio, a sua saída seria parecida com esta:

"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=s"

Este registro de exemplo contém cinco componentes. No entanto, há mais componentes possíveis que um registro DMARC pode incluir:

Componente	Finalidade	Valor(es) de exemplo
v	Versão do DMARC	Sempre DMARC1 atualmente
p	Política a ser aplicada para e-mails não compatíveis	Os valores possíveis são none, quarantine ou reject
rua	URI de relatório para relatórios agregados (endereços de e-mail para os quais os relatórios são enviados)	mailto
ruf	URI de relatório para relatórios forenses (endereços de e-mail para os quais os relatórios detalhados são enviados)	mailto
adkim	Modo de alinhamento do DKIM	r para relaxado, s para rigoroso
aspf	Modo de alinhamento do SPF	r para relaxado, s para rigoroso
pct	Porcentagem de e-mails sujeitos à política do DMARC	0–100
fo	Opções de relatórios forenses	0 para “todas as falhas”, 1 para “somente falha do DKIM”

Um conceito-chave para o DMARC é a ideia de “alinhamento”. O alinhamento determina quão exatamente os domínios usados no SPF e no DKIM precisam corresponder ao domínio no cabeçalho from: do e-mail. O modo de alinhamento é controlado pelos componentes adkim e aspf do registro DMARC, e eles têm os seguintes significados:

• Alinhamento do DKIM:
  • Rigoroso (adkim=s): o domínio na assinatura do DKIM (d=) deve corresponder exatamente ao endereço from:.
  • Relaxado (adkim=r): o domínio na assinatura do DKIM deve compartilhar o mesmo domínio organizacional que o domínio no endereço from: . Isso significa que subdomínios são permitidos.
• Alinhamento do SPF:
  • Rigoroso (aspf=s): o domínio no Return-Path do SPF deve corresponder exatamente ao endereço from:.
  • Relaxado (aspf=r): o domínio no Return-Path do SPF deve compartilhar o mesmo domínio organizacional que o domínio no endereço from:. Subdomínios são permitidos.

Supondo que o SPF, o DKIM e o DMARC estejam configurados corretamente quando um e-mail é enviado, ocorrerá a seguinte sequência de eventos:

O DMARC é considerado aprovado se o SPF ou o DKIM for válido e estiver alinhado. Se ambos forem inválidos e/ou estiverem desalinhados, o DMARC será considerado reprovado, e a política do DMARC será aplicada.

A política é definida pelo componente p= e tem três modos possíveis:

• p=none: nenhuma ação é tomada, mas relatórios são gerados.
• p=quarantine: os e-mails são tratados como suspeitos e enviados para a pasta de spam.
• p=reject: os e-mails são rejeitados e não são entregues.

Lembre-se de que a política do DMARC que você define não afeta os seus e-mails recebidos; ela diz ao resto do mundo o que eles devem fazer com e-mails não autenticados que alegam ter vindo do seu domínio. Isso inclui as tags de relatório agregado (rua) e forense (ruf), que especificam para onde os servidores de recebimento devem enviar relatórios de conformidade sobre e-mails não autenticados que alegam vir do seu domínio.

É importante definir essas opções e garantir que as caixas de entrada para as quais elas apontam sejam monitoradas ativamente, pois esses relatórios são inestimáveis para entender o uso de e-mail do seu domínio, identificar remetentes não autorizados e refinar as suas configurações de autenticação.

Assim como com os outros mecanismos de autenticação de e-mail abordados, configurar o seu registro DMARC é simplesmente uma questão de criar o registro DNS TXT apropriado, que deve ser parecido com isto:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; aspf=s; adkim=s; pct=100"

Tenha em mente que, se você estiver configurando a autenticação de e-mail para um domínio pela primeira vez, pode ser benéfico ir aos poucos. Em vez de começar com uma aplicação rigorosa (p=reject), você pode querer começar com uma aplicação gradual (p=none) e monitorar os relatórios do DMARC para garantir que os seus e-mails estejam passando na validação conforme o esperado. Caso contrário, uma configuração incorreta poderá impactar a entregabilidade de seus e-mails legítimos.

Protocolos de autenticação de e-mail como SPF, DKIM e DMARC têm uma função importante para garantir a entregabilidade de seus e-mails e proteger a reputação de seus domínios. Uma autenticação de e-mail configurada corretamente cria confiança e melhora a reputação do remetente, reduzindo as chances de os seus e-mails serem marcados como spam.

Se você ainda não configurou ou revisou recentemente as suas configurações de autenticação de e-mail, deve reservar um tempo para revisar e implementar essas etapas para a sua infraestrutura de e-mail. Lembre-se de monitorar ativamente os seus relatórios do DMARC e testar a entregabilidade de seus e-mails para garantir que tudo esteja configurado corretamente. Se você precisa de um recurso confiável para testar e gerenciar a sua entregabilidade de e-mail, o Mailgun tem o que você precisa.