Configuração DKIM SPF DMARC para Email Transacional

O que são DKIM, SPF e DMARC na Autenticação de Email

Quando um email transacional sai do seu sistema, ele não precisa apenas ser enviado. Ele precisa provar que pertence ao lugar onde afirma pertencer. Essa é a função do DKIM, SPF e DMARC: três padrões que trabalham juntos para ajudar os servidores de email receptores a decidirem se uma mensagem é legítima.

SPF, ou Sender Policy Framework, informa ao mundo quais servidores estão autorizados a enviar emails em nome do seu domínio. É uma lista de permissão baseada em DNS. Se sua mensagem vem de um IP de envio aprovado, o SPF pode passar. Se vem de outro lugar, pode falhar.

DKIM, ou DomainKeys Identified Mail, adota uma abordagem diferente. Ele adiciona uma assinatura criptográfica ao cabeçalho da mensagem. O servidor receptor verifica essa assinatura em relação a uma chave pública publicada no DNS. Se a assinatura corresponder, o servidor sabe que a mensagem não foi alterada durante o trânsito e que foi assinada por um domínio autorizado.

DMARC, ou Domain-based Message Authentication, Reporting and Conformance, está em cima do SPF e DKIM. Ele informa aos servidores receptores o que fazer se uma mensagem falhar na autenticação e verifica a conformidade: em termos simples, se o domínio usado no endereço visível de De corresponde ao domínio validado pelo SPF ou DKIM. O DMARC é a camada de política que une tudo.

Usados juntos, esses protocolos dão aos sistemas receptores um sinal mais forte de que sua mensagem é real. Isso é importante porque o email transacional não é apenas mais um envio de marketing. Um reset de senha, um recibo de pedido ou um alerta de segurança geralmente chega quando o usuário está esperando imediatamente. Se a autenticação for fraca ou mal configurada, essas mensagens podem cair no spam, serem sinalizadas como suspeitas ou não chegarem de forma alguma.

Por que o Email Transacional Precisa de Autenticação Adequada

Emails transacionais carregam os momentos práticos de um relacionamento com o cliente. Eles incluem resets de senha, mensagens de verificação de conta, faturas, notificações de envio, confirmações de recibo e alertas de login. Essas são as mensagens que as pessoas procuram primeiro quando algo precisa de atenção.

É por isso que uma autenticação fraca é mais do que um incômodo técnico. Se um recibo não chega, o cliente pode pensar que o pagamento falhou. Se um alerta de segurança for filtrado, o usuário pode perder uma ameaça real. Se um reset de senha for para o spam, os tickets de suporte começam a se acumular. Em outras palavras, a entregabilidade é parte da experiência do produto.

Há também uma questão de confiança. Filtros de spam e provedores de caixa de entrada são cautelosos por design, e muitas vezes tratam e-mails não autenticados como arriscados. Mesmo quando o conteúdo é perfeitamente legítimo, uma reputação de remetente fraca ou uma configuração de autenticação quebrada pode fazer a mensagem parecer não confiável. Para e-mails transacionais, isso é especialmente doloroso porque os usuários geralmente esperam uma entrega rápida e confiável.

Se você já está pensando na imagem mais ampla da entregabilidade, pode ajudar olhar para toda a cadeia em vez de uma configuração isolada. Autenticação, reputação do remetente, qualidade do conteúdo e manuseio de devoluções afetam a colocação na caixa de entrada. Para uma visão mais completa, veja ferramentas de teste de entregabilidade de e-mail.

Como Funcionam os Registros SPF e Como Configurá-los

O SPF funciona publicando um registro DNS que lista os servidores autorizados a enviar e-mails para o seu domínio. Quando um servidor destinatário recebe uma mensagem, ele verifica o IP de envio contra esse registro. Se o IP estiver incluído, o SPF pode passar. Se não, o servidor pode tratar a mensagem como não autorizada.

Um registro SPF é geralmente armazenado como um registro TXT no DNS. Ele costuma começar com v=spf1, seguido por mecanismos como ip4, ip6, ou include, e termina com um qualificativo como -all ou ~all. A estrutura exata depende da sua infraestrutura e provedor.

Para uma configuração de email transacional, você normalmente precisa identificar cada serviço que envia emails em seu nome. Isso pode incluir seu servidor de aplicação, sua plataforma de entrega de email, seu suporte técnico ou uma ferramenta de faturamento. Cada um deve ser contabilizado no registro SPF se enviar do seu domínio.

Uma configuração simples pode autorizar um provedor de email através de uma declaração de inclusão. Uma mais complexa pode listar um IP de envio dedicado e um ou mais serviços de terceiros. O importante é não adivinhar. Apenas autorize sistemas que você realmente usa.

Existem algumas regras práticas que vale a pena lembrar:

• Publique apenas um registro SPF por domínio.
• Mantenha o registro o mais conciso possível.
• Certifique-se de que os IPs de envio e as declarações de inclusão estão corretos e atualizados.
• Use o qualificativo correto no final, com base em quão rigorosamente você deseja que emails não autorizados sejam tratados.

O tempo de propagação também importa. Mudanças no DNS nem sempre aparecem em todos os lugares imediatamente, então, após atualizar o SPF, permita tempo para que os registros se espalhem antes de assumir que a configuração está concluída.

Configurando DKIM para Email Transacional

DKIM dá a cada mensagem enviada uma assinatura digital. O servidor que envia o email usa uma chave privada para assinar cabeçalhos selecionados e o corpo da mensagem. O servidor receptor procura a chave pública correspondente no DNS e verifica se a assinatura é válida.

Na prática, isso significa que você precisa de duas partes: uma chave privada mantida pelo seu sistema ou provedor de envio, e uma chave pública publicada no DNS. O registro DNS geralmente fica sob um subdomínio específico do seletor, o que permite que você gire as chaves mais tarde sem quebrar tudo de uma vez.

A maioria dos provedores de email transacional o orienta através dessa configuração com alguns passos padrão:

1. Gere ou solicite um par de chaves DKIM.
2. Adicione a chave pública do provedor ao seu DNS como um registro TXT.
3. Escolha o seletor que será usado na assinatura DKIM.
4. Ative a assinatura na sua plataforma ou aplicação de envio.
5. Envie uma mensagem de teste e confirme se a assinatura está presente e válida.

Isso parece simples, e muitas vezes é, mas os detalhes importam. Se o seletor for inserido incorretamente, o servidor receptor não encontrará a chave pública correta. Se a chave privada não estiver ativa no lado do remetente, o e-mail será enviado sem assinatura. Se outro sistema modificar a mensagem após ela ser assinada, a assinatura pode falhar.

Um hábito útil é pensar no DKIM como parte de uma cadeia de custódia. A mensagem é assinada quando sai do seu sistema, e a assinatura diz: “Esta versão veio de mim.” Se um serviço de rodapé, gateway ou sistema de encaminhamento alterar o e-mail depois, a assinatura pode quebrar. Isso nem sempre significa que a mensagem é maliciosa, mas pode afetar como os provedores de caixa de entrada a tratam.

Para provedores transacionais, o objetivo usual é assinar todo o correio enviado do domínio ou subdomínio relevante e manter o comportamento de assinatura consistente em todos os tipos de mensagem. Redefinições de senha e recibos não devem ser tratados como casos especiais, a menos que sua arquitetura exija isso.

Configurando o DMARC para Proteger Seu Domínio

DMARC é onde a autenticação se torna política. Ele informa aos servidores receptores como lidar com mensagens que falham no SPF ou DKIM, e também permite que você receba relatórios sobre e-mails enviados com seu domínio.

Um registro DMARC também é publicado no DNS como um registro TXT, geralmente sob _dmarc.seudominio.com. Ele inclui um valor de política que pode começar em modo de monitoramento e depois passar para a aplicação. As opções de política comuns são:

• nenhum — monitorar o tráfego e coletar relatórios sem bloquear e-mails.
• quarentena — sugerir que e-mails que falham devem ser tratados com suspeita, muitas vezes entregues como spam.
• rejeitar — solicitar que e-mails que falham sejam bloqueados imediatamente.

O DMARC também depende de alinhamento. SPF ou DKIM podem passar tecnicamente, mas se o domínio autenticado não se alinha com o domínio visível de From, o DMARC ainda pode falhar. É por isso que remetentes de terceiros e subdomínios precisam de uma configuração cuidadosa. Uma mensagem de billing@seudominio.com deve ser autenticada de uma forma que se conecte de volta a seudominio.com, e não a algum domínio de envio não relacionado.

A maioria das equipes começa com uma política de monitoramento para que possam ver como os e-mails estão se comportando antes de tomar uma ação. Isso é sensato. Relatórios ajudam você a descobrir ferramentas esquecidas, plataformas antigas que ainda estão enviando e-mails e erros de configuração que, de outra forma, permaneceriam ocultos. Uma vez que você esteja confiante de que os e-mails legítimos estão autenticando corretamente, você pode passar para quarentena ou rejeitar.

Os relatórios DMARC podem parecer densos no início, mas são extremamente úteis. Eles mostram quem está enviando e-mails para seu domínio, se SPF e DKIM estão passando e onde o alinhamento está falhando. Se você está tentando melhorar a saúde geral da sua configuração de remetente, este é um dos lugares mais claros para olhar.

Erros Comuns na Configuração de DKIM SPF DMARC

Mesmo uma configuração bem-intencionada pode dar errado de maneiras pequenas, mas prejudiciais. Os erros mais comuns geralmente não são dramáticos. Eles são os erros de configuração silenciosos que persistem até que a entregabilidade comece a cair.

• Publicar múltiplos registros SPF para o mesmo domínio em vez de um registro consolidado.
• Esquecer de incluir um serviço de envio que está ativamente sendo usado para e-mails transacionais.
• Usar o seletor DKIM errado ou copiar a chave pública para o nome DNS errado.
• Permitir que a assinatura DKIM seja desativada em alguns tipos de mensagens, mas não em outros.
• Definir uma política DMARC antes de verificar se todos os e-mails legítimos estão alinhados corretamente.
• Mudar de fornecedores sem atualizar referências SPF, DKIM e DMARC em toda a pilha.

Erros de alinhamento merecem atenção especial. É fácil acreditar que a autenticação está “funcionando” porque uma ferramenta de teste diz que SPF passou ou DKIM passou. Mas o DMARC está verificando se esses passes estão alinhados com o domínio do From. É aí que muitas configurações falham na vida real.

Outro problema comum aparece quando as equipes adicionam ferramentas de encaminhamento, roteamento ou processamento de mensagens que alteram cabeçalhos. Às vezes, o e-mail ainda chega, mas os resultados da autenticação mudam. Se você notar uma mudança repentina na colocação na caixa de entrada, vale a pena verificar se algo no caminho de entrega está reescrevendo ou retransmitindo a mensagem.

E sim, erros de DNS acontecem mais frequentemente do que as pessoas admitem. Uma aspa faltando, um seletor copiado com o rótulo errado ou uma declaração de inclusão desatualizada podem ser suficientes para quebrar a autenticação. A abordagem mais segura é verificar cada alteração após sua publicação, em vez de assumir que o painel reflete a realidade instantaneamente.

Testando e Verificando Sua Configuração de Autenticação

Uma vez que os registros estão no lugar, o teste é onde a teoria encontra a caixa de entrada. Envie uma mensagem transacional real e inspecione os cabeçalhos da mensagem. Você quer ver resultados claros de aprovação para SPF, DKIM e DMARC, junto com os domínios que foram avaliados.

A maioria dos provedores de caixa de entrada inclui detalhes de autenticação na fonte da mensagem bruta. Procure por campos que indiquem se o SPF passou, se o DKIM produziu uma assinatura válida e se o DMARC passou na verificação de alinhamento. Se um deles falhar, o cabeçalho geralmente dá uma pista sobre o porquê.

Também é útil testar a partir de mais de um provedor de caixa de entrada, pois diferentes sistemas podem apresentar os resultados de autenticação de maneiras diferentes. Uma mensagem que parece boa em uma caixa de entrada pode revelar um problema em outra. Isso não é incomum, apenas irritante.

Ao verificar e-mails transacionais especificamente, teste as mensagens que mais importam: redefinições de senha, confirmações de inscrição, avisos de cobrança e alertas. Não confie apenas em um simples “e-mail de teste” do seu provedor, pois o sistema real pode usar cabeçalhos diferentes, roteamento diferente ou uma identidade de remetente diferente.

Se você não tiver certeza se sua configuração está se mantendo ao longo do tempo, uma revisão periódica de cabeçalhos e registros DNS vale o esforço. Você não precisa complicar demais; apenas precisa de um hábito repetível. Para verificações práticas, as ferramentas e métodos abordados em ferramentas de teste de entregabilidade de e-mail podem ajudá-lo a confirmar onde a mensagem está realmente aterrissando e como está sendo avaliada.

Melhores Práticas para Manter a Autenticação de E-mail ao Longo do Tempo

A autenticação não é um projeto único. É uma tarefa de manutenção. Domínios mudam de mãos, provedores são trocados, novos produtos começam a enviar e-mails e sistemas antigos permanecem por mais tempo do que qualquer um espera. Se você não revisar o SPF, DKIM e DMARC periodicamente, a deriva eventualmente se instalará.

Uma boa rotina de manutenção inclui alguns hábitos simples:

• Revise os registros DNS após qualquer alteração de fornecedor ou infraestrutura.
• Audite cada sistema que envia e-mails do seu domínio ou subdomínio.
• Verifique os relatórios DMARC para fontes desconhecidas ou falhas de alinhamento.
• Verifique se as chaves DKIM ainda estão ativas e se os seletores correspondem à configuração de envio.
• Confirme se o SPF não se tornou um registro longo e frágil cheio de inclusões desatualizadas.

Também é prudente documentar quem possui cada registro e por que ele existe. Assim, quando alguém perguntar por que um determinado serviço aparece no SPF, você não precisa reverter a história da memória e de tickets antigos.

Quando um novo fornecedor de e-mail é introduzido, trate a autenticação como parte da integração, não como um pensamento posterior. Pergunte como o provedor lida com o alinhamento SPF, DKIM e DMARC. Confirme se eles assinam e-mails para o seu domínio, se precisam de um seletor personalizado e se seus endereços de envio correspondem aos seus objetivos de política.

Por fim, fique de olho na experiência do usuário. Se as redefinições de senha começarem a falhar ou os recibos se tornarem pouco confiáveis, não assuma que o problema é conteúdo ou design. Verifique primeiro a trilha de autenticação. Em e-mails transacionais, o menor registro DNS pode ter o maior efeito prático.

Para equipes que desejam um manual mais amplo sobre reputação e colocação na caixa de entrada, a orientação em melhores práticas de entregabilidade de e-mail também pode ser útil, especialmente quando a autenticação é apenas uma parte de um quadro maior de entregabilidade.

Feito corretamente, a configuração de DKIM SPF DMARC para e-mails transacionais cria uma base sólida. Isso informa aos provedores de caixa de correio que seu e-mail é legítimo, ajuda a proteger os usuários contra falsificações e dá à sua própria equipe um caminho mais limpo para solução de problemas. O retorno é simples: entrega mais confiável para as mensagens que as pessoas realmente precisam.