Desde março de 2024, vários locatários do Microsoft 365 relatam devoluções ao tentar entregar mensagens para destinatários @aol.com e @yahoo.com. Este guia detalhado explica por que o problema ocorre e traz um roteiro prático – do conceito ao passo a passo – para restaurar a entregabilidade dos seus e‑mails, aumentar a segurança do domínio e evitar reincidências.
Visão geral do problema
O comportamento típico começa com um retorno automático contendo o assunto “Your message couldn’t be delivered” e códigos do tipo 550‑5.7.1. O erro surge mesmo quando:
- O volume de mensagens é baixo ou você envia a apenas um contato;
- Os e‑mails anteriores, enviados meses antes, eram entregues normalmente;
- Outros provedores (Gmail, Hotmail, domínios corporativos) continuam aceitando suas mensagens.
A falha aponta para recusas no servidor de recebimento da Verizon Media (proprietária do Yahoo e do AOL), que passa a negar a conexão se o domínio do remetente não cumprir todos os requisitos de autenticação.
Por que isso está acontecendo?
Em fevereiro de 2024, o Yahoo/AOL passou a seguir o cronograma do Google e exige que todo remetente possua registros válidos de SPF, DKIM e DMARC. Embora o comunicado oficial falasse apenas em “remetentes de alto volume”, na prática os filtros se aplicam a qualquer domínio personalizado que utilize servidores de saída da Microsoft. Assim:
- O Exchange Online tenta entregar a mensagem;
- O servidor de recebimento do Yahoo/AOL verifica os três mecanismos de autenticação;
- Se algum deles falhar ou estiver ausente, a conexão é recusada e você recebe a notificação de falha.
Esse comportamento se estende a provedores norte‑americanos menores (Comcast, Cox, Spectrum, etc.) e deve se tornar norma para qualquer grande ESP (Email Service Provider) nos próximos meses.
Entendendo SPF, DKIM e DMARC
SPF informa quais servidores estão autorizados a enviar mensagens em nome do seu domínio.
DKIM assina criptograficamente cada e‑mail; o destinatário pode verificar a assinatura com a chave publicada no DNS.
DMARC agrega SPF e DKIM, descreve a política que o provedor deve seguir quando algo falhar e fornece relatórios (rua/ruf) para que você monitore.
Sem esses registros, qualquer provedor moderno enxergará seus e‑mails como “não confiáveis” – e, diante de políticas de tolerância zero, a rejeição é imediata.
Guia passo a passo para correção
O procedimento a seguir foi testado com dezenas de domínios lusófonos – do .com ao .gov.br – e serve tanto para empresas quanto para profissionais autônomos.
| Passo | O que fazer | Onde configurar |
|---|---|---|
| SPF | Verifique se já existe um registro TXT para a raíz do domínio contendo v=spf1.• Se existir, confirme que inclui include:spf.protection.outlook.com e termina em ~all ou -all.• Se não existir, crie: TXT @ "v=spf1 include:spf.protection.outlook.com ~all" | Zona DNS do provedor (GoDaddy, Cloudflare, Registro.br, etc.) |
| DKIM | No Centro de Administração do Microsoft 365 → Defesa/Email → Políticas de autenticação, ative DKIM. Serão gerados dois registros CNAME:selector1.domainkey.<seu‑domínio> → selector1‑<domínio‑onmicrosoft>...dkim.protection.outlook.comselector2.domainkey.<seu‑domínio> → selector2‑<domínio‑onmicrosoft>...dkim.protection.outlook.com | Zona DNS |
| DMARC | Crie ou ajuste um TXT em _dmarc.<seu‑domínio> com, no mínimo:v=DMARC1; p=none; rua=mailto:postmaster@<seu‑domínio>Depois de algumas semanas de monitoramento dos relatórios, altere p=none para quarantine ou reject para ganhar proteção total. | Zona DNS |
| Testes | Use ferramentas como MXToolbox (Find Problems) ou Microsoft Remote Connectivity Analyzer para confirmar que tudo está publicado e válido. | — |
| Propagação | Aguarde até 48 h. Depois disso, reenvie as mensagens que haviam falhado. | — |
Importante:
• Não copie registros de exemplos que mencionemmandrillapp.com,sendgrid.netou similares, a menos que você realmente utilize esses serviços.
• O mesmo roteiro corrige problemas semelhantes com provedores como Comcast, BT, Orange ou Terra.
Tabela de erros SMTP mais comuns
| Código | Mensagem (resumida) | Significado prático |
|---|---|---|
| 550‑5.7.1 | Connection refused or blocked | Falha de autenticação SPF/DKIM/DMARC ou reputação negativa |
| 554 Message not allowed | Policy violation | Conteúdo, anexo ou assunto considerado arriscado |
| 421 4.7.0 | Temporary deferral | Fila sobrecarregada ou domínio em supervisão; tente mais tarde |
Benefícios adicionais do trio SPF + DKIM + DMARC
- Entregabilidade global melhorada – provedores como Gmail, Proton e Zoho usam os mesmos critérios;
- Proteção contra spoofing – reduz a chance de seus clientes receberem fraudes “em nome” do seu domínio;
- Relatórios granulares – via DMARC, você descobre quem está tentando abusar da sua marca;
- Nota mais alta em ferramentas de análise – tests como Mail‑Tester e GlockApps, refletindo positivamente no score geral;
- Alinhamento com frameworks de segurança – ISO 27001, SOC 2, LGPD e GDPR exigem práticas robustas de e‑mail.
Quando você não precisa alterar nada
Se você envia mensagens apenas de <nome>@<tenant>.onmicrosoft.com – ou seja, não usa domínio próprio – a Microsoft já administra SPF, DKIM e DMARC por você. Nesse cenário, a falha provavelmente decorre de:
- Anexos suspeitos bloqueados por antivírus;
- Palavras‑chave de spam no assunto ou no corpo;
- Envio de campanhas em massa sem tempo de resfriamento adequado.
Nestas situações, revise o conteúdo, reduza o volume ou fraccione os envios.
Ferramentas de diagnóstico recomendadas
Embora haja dezenas de opções, abaixo estão as que costumam dar o melhor retorno em português:
- MXToolbox – Verificações pontuais e monitoramento contínuo de blacklists;
- Microsoft Remote Connectivity Analyzer – Testes dirigidos especificamente ao Exchange Online;
- Nslookup/DiG (linha de comando) – Permitem confirmar em segundos se o DNS já propagou;
- Relatórios RUA/RUF de DMARC – Fornecidos por provedores como Postmark, dmarcian e Valimail.
Perguntas frequentes (FAQ)
Quanto tempo leva para os novos registros entrarem em vigor?
Normalmente poucas horas, mas servidores de cache podem levar até 48 h. Use comandos nslookup -type=TXT domínio.com para checar periodicamente.
Posso usar -all em vez de ~all no SPF?
Sim, desde que você tenha total certeza de que apenas o Microsoft 365 envia e‑mails pelo seu domínio. Caso possua sistemas de ERP, SaaS ou gateways externos, comece com ~all (soft fail) e, depois de testar, mude para -all (hard fail).
Tenho múltiplos domínios no mesmo tenant. Preciso repetir tudo?
SPF precisa de um único registro por domínio. DKIM e DMARC devem ser publicados individualmente para cada domínio que envia mensagens.
E se eu usar subdomínios, como mail.dominio.com?
Os princípios são os mesmos: publique SPF, ative DKIM e crie DMARC apontando para o subdomínio. O alinhamento entre “De:” e “Return‑Path” decide qual domínio o provedor vai validar.
DMARC com política “reject” não é arriscado?
Configurar p=reject sem monitoramento prévio pode bloquear envios legítimos. Por isso comece com p=none, analise relatórios e só aí avance para quarantine ou reject.
Conclusão
O endurecimento das políticas de autenticação por parte do Yahoo/AOL pegou muitos administradores de surpresa, mas tem um objetivo claro: proteger usuários finais e elevar o padrão de segurança do ecossistema de e‑mail. Ao implementar corretamente SPF, DKIM e DMARC você não só resolve as devoluções atuais, como também:
- Garante melhor reputação junto a qualquer grande provedor;
- Cria uma barreira técnica contra fraudes que usam seu domínio;
- Alinha‑se às melhores práticas do setor e atende a requisitos de compliance.
Adote o procedimento descrito, monitore por algumas semanas e, sempre que possível, automatize os relatórios. Assim você transforma um episódio pontual de falha em um salto duradouro de confiabilidade.
Recursos úteis em português:
* Documentação oficial – “Autenticação de E‑mail no Microsoft 365” (Microsoft Learn)
* MXToolbox – verificações de SPF, DKIM e DMARC
* Série “SPF, DKIM e DMARC para iniciantes” – canal Jonathan Edwards (YouTube)