Defaults.Exposed › Correções › Guides

O Outlook a Rejeitar o Seu Email: 550 5.7.515, 550 5.7.509 e compauth=fail, Explicados e Corrigidos (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Dois sistemas diferentes da Microsoft rejeitam correio. O Outlook.com de consumidor devolve remetentes de alto volume que falham a autenticação (550 5.7.515, aplicado desde maio de 2025); o Exchange Online devolve correio que falha a sua própria política DMARC de reject (550 5.7.509). Dos 10.205.070 domínios que autorizam spf.protection.outlook.com, 85,0% têm SPF estrito mas só 21,7% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios.

A maioria dos problemas de “o Outlook está a rejeitar o meu email” não são rejeições nenhumas — é correio a cair silenciosamente em Lixo com compauth=fail nos cabeçalhos. Este guia descodifica os códigos da Microsoft, mostra-lhe como ler o cabeçalho Authentication-Results, e percorre a correção por ordem: confirme o SPF, ative o DKIM para o seu domínio personalizado, publique e aplique o DMARC, volte a testar.

Que erro da Microsoft tem realmente?

A Microsoft gere duas superfícies de receção separadas, e rejeitam por razões diferentes. Faça corresponder primeiro o seu sintoma — o diagnóstico errado desperdiça um dia.

A redação exata do NDR muda; verifique as frases que citar contra uma devolução real antes de confiar nelas.

O que significa o 550 5.7.515?

É o requisito do Outlook.com/Hotmail de consumidor, não um erro de conta empresarial Microsoft 365. Desde maio de 2025, remetentes de mais de 5000 mensagens por dia para endereços Outlook de consumidor têm de passar o SPF, passar o DKIM, e publicar um registo DMARC (pelo menos p=none) alinhado com o domínio From. Falhe esse patamar e o Outlook de consumidor rejeita com uma redação como:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Duas coisas que isto não é: não é um mandato de 2026 (se o seu correio começou a ser devolvido agora, foi o seu volume ou o seu DNS que mudou, não a regra), e não tem a ver com as definições do tenant M365 do destinatário. A correção é a escada de autenticação abaixo — e os dias de campanha ocasionais que ultrapassam 5000/dia contam.

O que significa o 550 5.7.509?

Este vem do Exchange Online Protection em contas empresariais, e significa que a sua própria política DMARC está a ser honrada:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Leia isto com atenção — a Microsoft não está a ser difícil. O seu domínio publica p=reject, esta mensagem falhou o DMARC, e o recetor fez exatamente o que você pediu. Se o correio devolvido é legítimo, alguma origem de envio (uma ferramenta de newsletter, um CRM, um dispositivo de digitalização para email) não está autenticada de forma alinhada. Não enfraqueça a política; dê a essa origem SPF ou DKIM alinhado — veja corrigir o DMARC e de p=none a p=reject.

Porque é que o Outlook deposita o meu correio em spam com compauth=fail em vez de o devolver?

A maior parte da dor de entregabilidade da Microsoft nunca produz uma devolução. A mensagem é aceite, pontuada, e arquivada em Lixo — a única evidência é o cabeçalho Authentication-Results. Na caixa de correio do destinatário (ou na sua própria caixa de teste outlook.com), abra a mensagem, escolha View message source, e encontre a linha:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

O compauth é o veredito de autenticação composta da Microsoft: mesmo quando um domínio não publica registo DMARC nenhum, a Microsoft aplica verificações implícitas, semelhantes ao DMARC. Valores comummente vistos:

• compauth=fail reason=000 — a mensagem falhou a autenticação explícita: a política DMARC do seu domínio é quarantine/reject e a mensagem falhou-a.
• compauth=fail reason=001 — a mensagem falhou a autenticação implícita: o seu domínio não publica registos de autenticação (ou não publica suficientes), e a mensagem não parecia vir de si. A clássica assinatura de “nunca configurámos DKIM/DMARC”.
• compauth=fail reason=6xx — variantes de falha de autenticação implícita; 601 significa especificamente que o domínio remetente é um dos domínios aceites da própria organização (falsificação intra-organizacional, de si para si).

A lição: na Microsoft, leia o cabeçalho, não só o NDR. Os veredictos spf=, dkim= e dmarc= nessa mesma linha dizem-lhe exatamente qual verificação corrigir.

Como se corrigem as rejeições e o depósito em spam no Outlook?

1. Execute primeiro a verificação gratuita. Classifica o seu SPF, DKIM e DMARC de uma vez e mostra qual verificação está a falhar antes de tocar no DNS.
2. Confirme o SPF — normalmente já está bem no Microsoft 365. O registo padrão é v=spf1 include:spf.protection.outlook.com -all, e a configuração do M365 põe-no lá: 85,0% dos 10.205.070 domínios que autorizam spf.protection.outlook.com já terminam em -all estrito (dados a 2026-06-29). Uma salvaguarda: os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From — portanto uma ferramenta de newsletter pode passar o SPF no seu domínio de devolução sem fazer nada pelo seu alinhamento. É por isso que os passos 3 e 4 importam mais.
3. Ative o DKIM para o seu domínio personalizado — dois CNAMEs de seletor. O M365 assina com uma predefinição onmicrosoft.com não alinhada até ativar a assinatura de domínio personalizado: publique os CNAMEs selector1._domainkey e selector2._domainkey a apontar para as chaves do seu tenant, depois ative a assinatura no portal do Defender. Caminho completo: configurar o DKIM no Microsoft 365. Se o DKIM mostrar “pass” mas o DMARC continuar a falhar, está na armadilha da assinatura predefinida.
4. Publique o DMARC, depois aplique-o. Comece com v=DMARC1; p=none; rua=mailto:... para obter relatórios, corrija todas as origens legítimas que revelar, depois avance para p=quarantine e p=reject — o caminho faseado está em corrigir o DMARC. É o passo que a maioria das empresas com Microsoft salta: só 21,7% dos domínios remetentes do M365 aplicam o DMARC.
5. Volte a testar lendo o cabeçalho. Envie para uma caixa de correio outlook.com de consumidor, abra a origem da mensagem, e confirme spf=pass, dkim=pass, dmarc=pass e compauth=pass.
6. Remetentes de alto volume: cumpra o patamar do Outlook de consumidor. Acima de 5000/dia também precisa de um From/reply-to válido e monitorizado, anulação de subscrição funcional, e listas limpas — a autenticação limpa o 5.7.515; a taxa de reclamação mantém-no fora dos bloqueios de IP S3140/S3150. Se já está bloqueado por IP, corrigir SPF/DKIM/DMARC não levanta o bloqueio: peça a remoção da lista através do suporte de remetentes da Microsoft, e trate a autenticação como a razão pela qual não voltará a acontecer.

Porque é que tantos domínios do Microsoft 365 ainda falham?

Porque a predefinição faz o primeiro passo por si e mais nada. Entre os 10.205.070 domínios que autorizam spf.protection.outlook.com, 85,0% têm SPF estrito — o registo que o M365 lhes dá na configuração — mas só 21,7% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios. O M365 dá-lhe SPF estrito por defeito, depois a maioria das contas para por aí — exatamente a população que o compauth foi construído para apanhar (ainda que à frente dos 10,59% de aplicação de DMARC em todos os domínios classificados). Comparação completa de fornecedores: a nossa tabela do SPF mais forte por fornecedor de email.

Perguntas frequentes

O 550 5.7.515 é um erro do Microsoft 365? Não. Vem do Outlook.com/Hotmail de consumidor e visa remetentes de >5000 mensagens/dia, aplicado desde maio de 2025. As rejeições do Exchange Online empresarial usam códigos diferentes — mais comummente 550 5.7.509 (a sua política DMARC de reject) ou 5.7.511 (remetente banido).

Recebemos 550 5.7.509 mas o correio era legítimo — devemos abandonar o p=reject? Não — a sua política apanhou uma origem não autenticada, o que significa que está a funcionar. Encontre a origem no cabeçalho ou nos seus relatórios DMARC e dê-lhe DKIM alinhado (ou SPF alinhado). Enfraquecer para p=none reabre a falsificação de domínio exato para toda a gente.

O compauth=fail significa que alguém nos está a falsificar? Não necessariamente. reason=001 normalmente significa que o seu próprio correio não consegue provar que é seu — sem DKIM alinhado, sem DMARC. Só 21,7% dos 10.205.070 domínios remetentes do M365 aplicam o DMARC (dados a 2026-06-29), portanto a Microsoft aplica verificações implícitas a todos os outros, e o correio legítimo não autenticado falha-as também.

Envio menos de 5000 emails por dia — posso ignorar isto? Vai escapar ao 550 5.7.515, mas não à pasta de Lixo: o compauth aplica-se a qualquer volume. O Gmail faz a mesma jogada — veja o guia do Gmail 550 5.7.26. As correções são gratuitas; a barreira é a falta de conhecimento, não o custo.

Envie o relatório ao proprietário

Se corrige email para outra pessoa — um cliente, o seu patrão, a empresa cujas faturas estavam a ser devolvidas — termine o trabalho com prova. Volte a executar a verificação gratuita depois de o DNS assentar e reencaminhe o relatório classificado. Mostra SPF, DKIM e DMARC a ficarem verdes em linguagem simples que o dono do negócio consegue ler, e é o artefacto de que vão precisar da próxima vez que a renovação do seguro cibernético ou um questionário de segurança de cliente perguntar se o email está autenticado. Corrigido é bom; comprovadamente corrigido é o que lhe paga a si e os cobre a eles.

Verifique o seu domínio gratuitamente

Veja qual verificação a Microsoft está a reprovar-lhe — SPF, DKIM, DMARC — em privado e só para o proprietário.

Verifique o seu domínio → · Corrigir o DMARC → · DKIM passa mas o DMARC falha → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.