DKIM aprovado, devolução mesmo assim? A nova rejeição misteriosa do Outlook

30 de junho de 2025

Há relatos de que o Outlook está devolvendo e-mails autenticados, e o motivo é um certo mistério. Esta é a nossa opinião depois de analisar os logs, relatórios e de muito conversar com os nossos colegas do setor.

Em março de 2025, a Microsoft anunciou novos requisitos de remetente para as caixas de entrada do Outlook, Hotmail e Live.com. Isso está alinhado com os novos requisitos de remetente que vimos o Gmail e o Yahoo lançarem em 2024. Abordamos as alterações da Microsoft imediatamente em nosso blog, e as tornamos o foco do segundo episódio do Deliverability Academy. Como veteranos em entregabilidade, estávamos preparados para alguns problemas de adaptação e esperávamos que alguns remetentes pudessem começar a ver rejeições devido a requisitos de autenticação mais rígidos, mas esse erro pareceu inesperado para os remetentes. Aqui está a nossa opinião.

Nas últimas semanas, um número crescente de clientes do Mailgun (e colegas do setor em outros ESPs) encontrou mensagens de devolução como esta:

550 5.7.515 Acesso negado, o domínio de envio DOMAIN.TLD não atende ao nível de autenticação exigido. O domínio do remetente no endereço 5322.From não atende aos requisitos de autenticação definidos para o remetente.

Esses erros geralmente mostram:

• SPF = Aprovado
• DKIM = Falha (mas falsamente!)
• DMARC = Aprovado

Resumindo: o DKIM parece ser aprovado em um lugar (como no Gmail ou nos seus relatórios DMARC), mas falha na Microsoft. E quando falha, o Outlook bloqueia a mensagem, mesmo que atenda à política DMARC padrão de p=none.

Ainda não temos uma resposta completa, mas eis o que descobrimos até agora, tanto pelos nossos próprios dados quanto pela colaboração do setor:

Algumas mensagens são devolvidas; outras não, mesmo com cabeçalhos e conteúdo idênticos. Domínios que antes não eram afetados podem começar a falhar de repente.

Se você estiver vendo erros 550 5.7.515, comece confirmando sua configuração de autenticação

• SPF: deve incluir IPs do Mailgun e permanecer abaixo do limite de 10 pesquisas.
• DKIM: verifique se o seu registro TXT do DKIM está publicado corretamente no DNS (de preferência como um valor de linha única) e corresponde ao seletor usado pelo Mailgun para assinatura.
• DMARC: política válida (p=none/quarantine/reject) alinhada com SPF ou DKIM.

As mensagens são aprovadas DKIM no Gmail e no Yahoo, mas falham na Microsoft. A nossa teoria de trabalho é que a Microsoft está aplicando verificações adicionais antes da entrega (quebrando o DKIM) ou interpretando o alinhamento de forma mais rígida do que o DMARC exige.

Como corrigir: verifique o alinhamento

• A Microsoft pode estar exigindo um alinhamento rígido, mesmo que DMARC permita um alinhamento flexível.
• Se você estiver vendo devoluções persistentes, entre em contato com nossa equipe de suporte para explorar a assinatura direta com seu domínio raiz (ex., example.com). Embora o Mailgun geralmente use um subdomínio para DKIM, o alinhamento rígido com o domínio de origem (From) pode melhorar a entregabilidade para a Microsoft.

E-mails com esses fatores parecem ter maior probabilidade de rejeição:

• Caracteres não ASCII (como acentos ou emojis)
• Cabeçalhos com codificação MIME (Subject ou From)

Chaves DKIM mais antigas, especialmente aquelas alternadas pela última vez antes de março de 2025, parecem mais vulneráveis. Chaves mais novas apresentam menos falhas.

Como corrigir: considere a alternância de chaves DKIM

Mesmo as chaves mais fortes têm um prazo de validade. Se uma chave DKIM for exposta, isso pode abrir as portas para falsificação (spoofing), spam e ataques de repetição (replay) que se aproveitam da sua boa reputação. Isso é uma má notícia para sua marca e para qualquer outra pessoa que faça envios a partir do mesmo IP.

Para reduzir o risco, uma das práticas recomendadas é alternar suas chaves DKIM a cada 6–12 meses. Se você estiver usando o Automatic Sender Security do Mailgun, parabéns! Nós cuidamos disso para você. Mas, se você gerencia seu próprio DNS ou usa um domínio de envio personalizado, cabe a você programar as atualizações regulares de chaves.

• Considere alternar quaisquer chaves DKIM com mais de 6 a 12 meses.
• Aguarde a propagação do DNS e, em seguida, teste novamente.

Se uma assinatura DKIM fizer referência a cabeçalhos que estão ausentes na mensagem real (ex., MessageID:), isso pode invalidar a assinatura.

Como corrigir: observe os cabeçalhos que você pode acessar

Você não conseguirá ver os cabeçalhos completos de uma mensagem que a Microsoft rejeita, mas ainda poderá obter pistas em outros lugares. Analise os cabeçalhos de uma mensagem entregue com sucesso de um provedor diferente para identificar possíveis problemas de cabeçalho ou codificação, como:

• Caracteres não ASCII (como emojis ou acentos) em Subject ou From
• Codificação MIME que pode ser interpretada de forma diferente pelo Outlook
• Quais cabeçalhos foram assinados via DKIM vs. quais foram realmente incluídos na mensagem
• Diferenças no alinhamento da assinatura DKIM (ex., subdomínio vs. domínio raiz)

Cerca de 1,8% das devoluções relacionadas à Microsoft em nossos dados de maio a junho de 2025 decorrem de problemas de autenticação – principalmente do Hotmail. Remetentes de alto volume podem estar mais expostos, seja devido à complexidade da mensagem ou apenas à escala.

Como corrigir: certifique-se de estar monitorando sua autenticação

Use relatórios DMARC como Red Sift ou ferramentas semelhantes para ver onde as falhas estão ocorrendo e quais IPs/domínios são afetados, e analise detalhadamente as diretrizes do remetente. O Gmail e o Yahoo têm limites muito específicos, mas a abordagem da Microsoft nos lembra que os provedores de caixas de entrada estão analisando diversos fatores comportamentais, não apenas técnicos.

Como a alternância regular de chaves é uma das práticas recomendadas, faça uma rápida revisão nas suas. Se você alternar manualmente e a sua chave atual for anterior a maio de 2025, talvez seja hora de uma atualização. Até mesmo chaves válidas podem ser rejeitadas se a Microsoft estiver filtrando com base na adesão às práticas recomendadas; uma chave nova pode ajudar a reduzir essas falhas falsas.

A Microsoft pode estar aplicando uma lógica de alinhamento mais rígida do que o DMARC exige, e nem sempre de maneiras previsíveis. Mesmo que você esteja assinando com seu domínio raiz e usando um subdomínio em seu endereço From: (ou vice-versa), as rejeições ainda podem ocorrer.

É uma boa ideia verificar o alinhamento, mas não presuma que o mais simples seja o melhor. Se você não tiver certeza de que sua configuração atual de DKIM é rígida ou flexível, ou se quiser explorar alguns ajustes, nossa equipe de suporte pode ajudar a analisar a configuração do seu domínio.

Evite emojis, caracteres acentuados ou codificação MIME desnecessariamente complexa em seus campos From: ou Subject:. Se estiver solucionando problemas de rejeições, faça testes com uma mensagem simplificada para descartar surpresas relacionadas à codificação.

Use relatórios DMARC agregados (por meio de ferramentas como Red Sift) para ficar de olho em problemas de alinhamento, remetentes não autorizados e mudanças nas tendências de devolução — especialmente em domínios Outlook, Hotmail e Live.

O Mailgun já assina mensagens duplamente para muitos clientes, geralmente usando tanto um domínio da plataforma quanto o subdomínio do cliente. Teoricamente, isso deve atender ao padrão mais alto de autenticação. Contudo, com base nos comentários do setor e no que vimos, a Microsoft pode estar avaliando apenas uma das assinaturas (e nem sempre a que é aprovada no alinhamento).

Estamos pesquisando ativamente se a Microsoft está aplicando incorretamente a lógica de avaliação de DKIM em mensagens com assinatura dupla e, em caso afirmativo, quais padrões ou configurações aumentam o risco.

Como deve ser a estrutura do meu domínio?

Evite configurações de subdomínio desnecessariamente complexas (ex., send13.mailgun.example.com), a menos que sejam essenciais para a sua configuração. Subdomínios excessivamente específicos ou inconsistentes podem aumentar a chance de confusão no alinhamento ou problemas na resolução de DNS.

O que meus clientes precisam saber?

Se você é um ESP ou agência trabalhando em nome de remetentes, ajude seus clientes a:

• Entender o alinhamento de DKIM
• Evitar conteúdo e cabeçalhos arriscados
• Revisar o DNS e alternar as chaves regularmente

Não estamos apenas observando, estamos trabalhando:

• Monitoramento contínuo: estamos rastreando as tendências de devolução em todo o tráfego destinado à Microsoft.
• Colaboração do setor: estamos conversando com outros ESPs e provedores para reunir percepções e pressionar a Microsoft por transparência.
• Suporte ao cliente: estamos ajudando a nossa base de usuários a auditar suas configurações e a fazer testes.
• Encaminhamento: estamos compilando dados para apresentar à Microsoft e pressionando por clareza sobre essas falsas falhas de DKIM.

Infelizmente, ainda não há uma solução alternativa garantida. Mas aqui está o que parece ajudar a reduzir as taxas de devolução:

• Chaves DKIM recém-alternadas
• Cabeçalhos mais simples apenas com caracteres ASCII
• Menos campos com codificação MIME em From: e Subject:

Estamos monitorando de perto tudo o que foi mencionado acima para determinar quais mudanças fazem a diferença de forma consistente.

Esse problema não se limita ao Mailgun, ou mesmo aos ESPs em geral. Trata-se de um problema mais amplo decorrente dos comportamentos de filtragem em evolução da Microsoft. Estamos acompanhando a situação bem de perto com o restante do setor e continuaremos a compartilhar o que aprendermos.

Se você for cliente do Mailgun e precisar de ajuda para solucionar erros 550 5.7.515, entre em contato com nossa equipe de suporte com o máximo de detalhes possível: domínios afetados, mensagens de devolução e cabeçalhos completos.

Atualizaremos este post à medida que a situação evoluir. Fique de olho e mantenha a sua autenticação.