Desde 5 de novembro de 2026 que os servidores de correio eletrónico de consumo da Microsoft (Outlook.com, Hotmail, Live e MSN) estão a rejeitar parte das mensagens legítimas que recebem, devolvendo aos remetentes erros relacionados com a autenticação SPF, DKIM e DMARC. O problema atinge sobretudo domínios sem registo DMARC publicado, incluindo pequenos remetentes que nunca estiveram abrangidos pelas regras para envios em massa, mas há também relatos de rejeições a domínios com toda a autenticação configurada corretamente. Um moderador do fórum de suporte da Microsoft reconheceu a falha e afirmou que esta foi “classificada como uma degradação de serviço”, estando a causa ainda sob investigação.
Resposta rápida: Desde 5 de novembro, mensagens enviadas para endereços @outlook.com, @hotmail.com, @live.com e @msn.com estão a ser devolvidas com o erro 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) ou com falhas de validação SPF (550 5.7.23). A Microsoft classificou o caso como degradação de serviço e está a investigar. Se envia email a partir de um domínio próprio, confirme que tem SPF e DKIM a passar e publique um registo DMARC (no mínimo p=none): na maioria dos relatos, isso resolve as rejeições. Se apenas recebe num endereço pessoal da Microsoft, não há nada a corrigir do seu lado; a correção cabe ao remetente ou à Microsoft.
O que está a acontecer
Os primeiros relatos surgiram na quinta-feira, 5 de novembro, em fóruns de administradores, na lista de operadores de correio mailop e no fórum Microsoft Q&A. Desde essa data, administradores e serviços de email veem devoluções vindas dos servidores que gerem as caixas de correio de consumo da Microsoft, ou seja, endereços terminados em @outlook.com, @hotmail.com, @live.com e @msn.com (e versões nacionais como @hotmail.co.uk). As caixas empresariais do Microsoft 365 (Exchange Online) não parecem estar afetadas enquanto destinatárias.
A mensagem de erro mais comum é nova e não consta da documentação pública da Microsoft. O texto “Message lacks SPF/DKIM/DMARC Auth Records” não aparece na página de resolução de problemas do postmaster, na referência de NDR do Exchange Online, nos artigos de suporte do Outlook.com nem no guia de autenticação de email da empresa. Ao contrário de uma devolução 5.7.515, que lista os resultados de SPF, DKIM e DMARC, esta apenas diz que faltam registos, o que dificulta o diagnóstico.
Um segundo padrão de erro também foi registado: um utilizador com conta empresarial do Microsoft 365 descreveu falhas súbitas de entrega para endereços Outlook.com e Hotmail com o erro “550 5.7.23 The message was rejected because of Sender Policy Framework violation”, acompanhado do mesmo código de diagnóstico AS9031519.
| Data (2026) | Acontecimento |
|---|---|
| 5 de novembro | Primeiras rejeições 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records nos servidores *.olc.protection.outlook.com |
| 6 de novembro | A devolução passa a incluir o sufixo (AS9031519); abrem-se threads no Microsoft Q&A e na lista mailop; fornecedores começam a aconselhar clientes a publicar DMARC |
| 7 e 8 de novembro | Investigadores de entregabilidade reproduzem a rejeição removendo o registo DMARC de domínios de baixo volume; a Microsoft não publica qualquer aviso |
| 9 de novembro | Moderador da Microsoft confirma no Q&A uma incidência no Exchange, classificada como degradação de serviço, com investigação em curso |
A regra de 2025 e o que se observa agora
A Microsoft tem, de facto, uma política publicada de autenticação obrigatória, mas dirigida a grandes remetentes. A 2 de abril de 2025, a equipa do Defender for Office 365 anunciou novos requisitos para envios em massa: domínios que enviem mais de 5.000 mensagens por dia para caixas de consumo do Outlook.com têm de passar SPF, passar DKIM e publicar um registo DMARC com pelo menos p=none alinhado com SPF ou DKIM. O anúncio original previa que, após 5 de maio de 2025, o Outlook começasse a encaminhar mensagens de domínios de alto volume não conformes para a pasta de Lixo, dando aos remetentes oportunidade de resolver os problemas pendentes. Uma atualização posterior alterou essa medida para rejeição direta, e a aplicação começou a 5 de maio de 2025 com o erro 550 5.7.515 Access denied.
O que se observa desde 5 de novembro é diferente em três aspetos: o código de erro, o alcance e a ausência de aviso prévio. Desde 5 de novembro de 2026, Outlook.com, Hotmail, Live e MSN estão a rejeitar parte do correio enviado a partir de domínios que não publicam registo DMARC, independentemente do volume. A EasyDMARC reproduziu o comportamento num teste controlado: enviou a partir de um domínio alojado no Zoho Mail com SPF a passar e alinhado, DKIM a passar e alinhado, e sem registo DMARC, e a mensagem para um endereço live.com foi devolvida. Outro investigador chegou ao mesmo resultado: a 7 de novembro, apagou o registo DMARC de vários domínios de baixo volume e enviou mensagens de teste; o Outlook.com rejeitou-as com o erro 550 5.7.1, enquanto um domínio empresarial no Microsoft 365 aceitou a mesma mensagem.
| Regra anunciada (maio de 2025) | Comportamento observado (novembro de 2026) | |
|---|---|---|
| Remetentes abrangidos | Mais de 5.000 mensagens/dia | Qualquer volume, incluindo mensagens isoladas |
| Código de devolução | 550 5.7.515 Access denied | 550 5.7.1 ... (AS9031519) ou 550 5.7.23 |
| Informação no erro | Resultados individuais de SPF, DKIM e DMARC | Apenas indica que faltam registos |
| Consistência | Determinística | Intermitente |
| Aviso prévio | Cerca de um mês | Nenhum |
Nem todos os casos se explicam pela falta de DMARC
A hipótese dominante entre especialistas é que a Microsoft passou a exigir, de forma silenciosa, um registo DMARC a todos os domínios remetentes. Mas essa explicação não cobre todos os relatos. No thread do Microsoft Q&A há também relatos de domínios com SPF, DKIM e DMARC em vigor há anos, com spf=pass, dkim=pass e dmarc=pass nos cabeçalhos das mensagens, cujo correio continua a ser rejeitado de vez em quando. É precisamente este conjunto de casos que levou a Microsoft a tratar a situação como avaria e não como mudança de política.
Até ao fim de semana a empresa não tinha dito nada. A 8 de novembro de 2026, a Microsoft não tinha publicado nada sobre o assunto; a EasyDMARC verificou o blogue do Defender for Office 365, as páginas de suporte a remetentes do Outlook.com e a lista de problemas conhecidos do Outlook.com. A posição mudou a 9 de novembro. Um moderador da Microsoft confirmou no mesmo thread do Q&A que existe uma incidência em curso no serviço Exchange com mensagens para endereços Outlook.com, Hotmail e Live; o aviso está classificado como degradação de serviço e a Microsoft continua a investigar a causa raiz. Segundo o The Register, a empresa afirmou que as equipas de engenharia estão a analisar telemetria do serviço e dados fornecidos por clientes para identificar a origem do problema. Um blogue técnico alemão associa a incidência ao identificador EX1540236 no centro de administração do Microsoft 365, informação que não conseguimos confirmar de forma independente.
O que fazer se envia email a partir de um domínio próprio
Independentemente de a causa final ser uma avaria ou uma nova regra, a recomendação prática é a mesma e coincide com o que o Google e o Yahoo já exigem desde 2024. Embora alguns clientes insistam que as suas configurações de DMARC, SPF e DKIM estão conformes, muitos mais relataram que, depois de as ajustarem às preferências da Microsoft, o email voltou a fluir.
- Procure o código na devolução. Antes de alterar seja o que for, confirme se a mensagem de erro contém
AS9031519ou o textolacks SPF/DKIM/DMARC Auth Records. Se a sua infraestrutura regista devoluções, filtre por estes termos por domínio remetente para perceber a dimensão do problema. - Verifique o SPF. O registo TXT do domínio deve incluir todos os servidores e serviços que enviam em seu nome (por exemplo,
include:spf.protection.outlook.compara o Microsoft 365) e terminar com-allou~all. Evite ultrapassar as 10 consultas DNS. - Ative o DKIM. As mensagens devem ser assinadas com uma chave publicada no DNS do seu domínio, e o domínio de assinatura (
d=) deve coincidir com o domínio do campo De. - Publique um registo DMARC. É o passo que mais relatos apontam como decisivo. Crie um registo TXT em
_dmarc.oseudominio.ptcom, no mínimo,v=DMARC1; p=none; rua=mailto:[email protected]. O Microsoft 365 não cria automaticamente registos DMARC para domínios personalizados, pelo que muitas organizações assumem erradamente que já o têm. - Confirme o alinhamento. Envie uma mensagem de teste para um endereço Outlook.com e leia o cabeçalho
Authentication-Results: deve mostrarspf=pass,dkim=passedmarc=passcom os domínios alinhados. - Se tudo passa e as devoluções continuam, guarde a devolução completa (com o identificador do servidor e a hora UTC) e abra um pedido junto da Microsoft ou do seu fornecedor de email. Nesse cenário, o problema está do lado da Microsoft.
E se apenas recebe num endereço pessoal da Microsoft?
Para quem usa uma conta gratuita @hotmail.com ou @outlook.com, o impacto é silencioso: as mensagens não chegam à caixa de entrada nem ao Lixo, e só o remetente recebe a devolução. Se outras pessoas não conseguem enviar para o seu endereço pessoal @outlook.com, a solução não está nas suas definições; uma resposta no Q&A explica que não é possível adicionar registos SPF, DKIM ou DMARC a um endereço pessoal e que é o remetente rejeitado, ou o seu fornecedor de email, que tem de autenticar o domínio de origem. A lista de remetentes seguros também não ajuda, porque a rejeição ocorre na ligação SMTP, antes de qualquer filtragem na caixa de correio. Se depende deste tipo de conta para receber faturas, orçamentos ou comunicações de serviços públicos, vale a pena confirmar com os remetentes habituais se têm devoluções desde 5 de novembro.
Porque é que isto importa em Portugal
Os endereços Hotmail e Outlook.com continuam a ser dos mais usados por particulares em Portugal, o que significa que qualquer PME, clínica, escola ou associação que envie email a clientes a partir de um domínio próprio pode estar, neste momento, a perder mensagens sem se aperceber. O episódio mostra também que a autenticação de email deixou de ser uma preocupação exclusiva de quem faz marketing em massa: uma simples resposta a um pedido de orçamento pode ser rejeitada se o domínio não publicar DMARC.
Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), SPF, DKIM e DMARC fazem parte das medidas básicas de higiene de segurança das comunicações que terão de demonstrar perante o CNCS. O CERT.PT recomenda há anos a adoção destes mecanismos como barreira contra o spoofing de domínios, e este incidente é um bom pretexto para verificar se estão de facto implementados e alinhados. Há ainda uma dimensão de RGPD: se comunicações com dados pessoais (confirmações de consulta, faturas, respostas a pedidos de titulares) não chegam ao destinatário e ninguém monitoriza as devoluções, a organização pode falhar prazos legais ou obrigações de informação sem o saber. Monitorizar os relatórios DMARC e as devoluções SMTP é, por isso, uma medida de segurança e também de conformidade.
Perguntas frequentes
O que significa o erro AS9031519 do Outlook.com?
É o código de diagnóstico que acompanha a devolução 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records, emitida desde 5 de novembro de 2026 pelos servidores de consumo da Microsoft (Outlook.com, Hotmail, Live, MSN). Indica que o servidor considerou a mensagem não autenticada, na maioria dos casos por o domínio remetente não ter registo DMARC publicado.
A Microsoft mudou as regras ou é uma avaria?
A 9 de novembro, um moderador da Microsoft confirmou no fórum Q&A uma incidência no Exchange classificada como degradação de serviço, ainda sob investigação. A regra publicada em 2025 só exige SPF, DKIM e DMARC a domínios com mais de 5.000 mensagens por dia; o comportamento atual atinge qualquer volume e não foi anunciado.
Tenho SPF e DKIM a passar. Porque é que o Hotmail rejeita o meu email?
Testes independentes mostram que, sem registo DMARC, o Outlook.com rejeita a mensagem mesmo com SPF e DKIM a passar e alinhados. Publique um registo TXT em _dmarc.oseudominio.pt com v=DMARC1; p=none; rua=mailto:.... Se já tem DMARC e as devoluções continuam, guarde a devolução completa e contacte a Microsoft ou o seu fornecedor.
Uso uma conta pessoal @hotmail.com. Posso corrigir isto do meu lado?
Não. Os registos SPF, DKIM e DMARC pertencem ao domínio de quem envia, e a rejeição acontece antes de a mensagem chegar à sua caixa, pelo que a lista de remetentes seguros não ajuda. Avise os remetentes habituais para verificarem a autenticação do domínio deles ou aguarde a resolução da incidência pela Microsoft.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft (Defender for Office 365 Blog), pela Microsoft (suporte Outlook.com), pelo fórum Microsoft Q&A, pela EasyDMARC e pelo The Register.

