Compauth=fail no Microsoft 365: entenda a autenticação composta e corrija os reason codes

⚡TL;DR

• compauth é o veredito de autenticação composta do Microsoft 365: combina SPF, DKIM, DMARC e sinais internos (reputação, histórico, PTR), e não é um padrão RFC
• O campo aparece como compauth=<pass|softpass|fail|none> reason=<código> no cabeçalho Authentication-Results; o reason indica por quê
• compauth=fail não bloqueia automaticamente uma mensagem no caso geral: a Microsoft aplica uma avaliação holística (SCL, CAT, SFTY) antes de decidir entre caixa de entrada, lixo eletrônico ou quarentena. Ressalva: desde 2023, uma falha DMARC explícita contra p=reject pode ser rejeitada no gateway (NDR 550 5.7.509) quando o MX aponta diretamente para o Microsoft 365
• A correção duradoura passa quase sempre pelo alinhamento de SPF + DKIM + DMARC no domínio do From:
• Os códigos 604, 605 e 703 citados por algumas ferramentas de terceiros não estão documentados pela Microsoft: não baseie um diagnóstico neles

Você inspeciona os cabeçalhos de uma mensagem no Microsoft 365 e se depara com compauth=fail reason=001. A mensagem vem de um remetente conhecido, o SPF parece correto e, mesmo assim, ela cai no lixo eletrônico ou na quarentena. O campo compauth é um dos mais mal compreendidos do Exchange Online, porque não corresponde a nenhum protocolo padrão: é um mecanismo proprietário da Microsoft.

Este guia é uma referência completa. Ele explica o que é a autenticação composta, como o Microsoft 365 calcula esse veredito a partir de SPF, DKIM, DMARC e sinais internos, a diferença essencial entre autenticação implícita e explícita, e depois fornece a tabela completa dos reason codes verificada na documentação oficial da Microsoft. Por fim, você encontrará um plano de diagnóstico e correção organizado por família de códigos.

Ele se destina aos administradores de Microsoft 365 e Exchange Online cujas mensagens legítimas são marcadas como falsificação ou colocadas em quarentena, bem como aos responsáveis por entregabilidade que precisam ler e interpretar um cabeçalho de autenticação da Microsoft.

O que é a autenticação composta (compauth) do Microsoft 365?

A autenticação composta é um veredito proprietário da Microsoft. Ao contrário de SPF (RFC 7208), DKIM (RFC 6376) e DMARC (RFC 7489), o compauth não é definido por nenhum padrão. É uma camada de avaliação que o Microsoft 365 adiciona sobre esses três protocolos para produzir um julgamento global sobre a autenticidade de um remetente.

Na prática, o Exchange Online Protection (EOP) não se limita a repassar os resultados de SPF, DKIM e DMARC. Ele os agrega a sinais adicionais: a reputação do endereço IP de envio, o histórico das mensagens já recebidas dessa infraestrutura, o registro PTR (DNS reverso) do IP e padrões comportamentais derivados da análise em massa do tráfego da Microsoft. O resultado dessa agregação é registrado no campo compauth do cabeçalho Authentication-Results.

A unidade básica da avaliação é o domínio do From: visível para o destinatário, ou seja, o endereço do cabeçalho 5322.From (também chamado de domínio P2). É esse domínio que a Microsoft procura proteger contra falsificação, e é sobre ele que recaem o alinhamento e o veredito composto. Essa precisão não é trivial: uma mensagem pode perfeitamente passar no SPF do domínio do envelope (5321.MailFrom) e ainda assim falhar na autenticação composta, porque esse domínio de envelope não corresponde ao domínio exibido no From:. O usuário final nunca vê o envelope, apenas o From:; logicamente, portanto, é sobre esse endereço que se baseia a proteção contra falsificação.

Por que a Microsoft criou essa camada adicional em vez de se limitar ao DMARC? Porque a adoção do DMARC ainda é parcial. Uma parcela importante dos domínios legítimos não tem nenhuma política DMARC, ou publica um p=none que não fornece qualquer instrução de aplicação. Sem um sinal composto, a Microsoft teria de confiar cegamente nesses domínios (e deixar passar a falsificação) ou penalizá-los sistematicamente (e bloquear correio legítimo). A autenticação composta é a resposta a esse dilema: ela permite avaliar um remetente mesmo quando os protocolos padrão não fornecem um veredito claro, apoiando-se em sinais observáveis do lado da Microsoft.

O campo aparece tipicamente nesta forma em um cabeçalho:

Authentication-Results: spf=pass (sender IP is 40.107.0.1)
 smtp.mailfrom=captaindns.com; dkim=pass (signature was verified)
 header.d=captaindns.com; dmarc=pass action=none
 header.from=captaindns.com; compauth=pass reason=100

A sintaxe geral é compauth=<resultado> reason=<código>. O resultado assume um de quatro valores, e o código de três dígitos especifica a razão exata do veredito.

compauth=pass / softpass / fail / none: o que significa cada valor?

O resultado composto não se limita a sucesso ou falha. A Microsoft distingue quatro estados, cada um com um significado preciso.

Valor	Significado
pass	A mensagem passou na autenticação composta, por via explícita (SPF/DKIM/DMARC alinhados) ou implícita (sinais internos suficientes).
softpass	A mensagem passou parcialmente na autenticação implícita. Os sinais são positivos, mas fracos (alinhamento por PTR ou por sub-rede, por exemplo).
fail	A mensagem falhou na autenticação composta, explícita ou implícita. Não é um veredito de bloqueio, mas um fator de risco.
none	A mensagem não foi avaliada para a autenticação composta, ou a contornou (roteamento específico, mensagem já processada anteriormente).

A distinção entre fail e none é importante. fail sinaliza uma falha ativa de autenticação: a Microsoft avaliou a mensagem e concluiu que não podia garantir a identidade do remetente. none sinaliza a ausência de avaliação, muitas vezes causada por um roteamento complexo ou por uma mensagem que já passou por outro gateway.

Autenticação implícita vs explícita: a chave para entender o compauth

Esta é a distinção mais importante de todo o artigo. O Microsoft 365 avalia a autenticação de uma mensagem por duas vias, e o reason code indica qual delas foi usada.

A autenticação explícita baseia-se nos registros DNS publicados pelo domínio remetente: SPF, DKIM e a política DMARC. É a autenticação padrão. Se o domínio publica um DMARC estrito (p=quarantine ou p=reject) e a mensagem se alinha corretamente, o veredito é explícito.

A autenticação implícita é uma extensão própria da Microsoft. Quando um domínio não publica DMARC, ou publica uma política permissiva (p=none, SPF em ~all ou ?all), a Microsoft não pode se apoiar em uma intenção declarada. Ela então aplica seus próprios sinais para decidir: reputação do IP, histórico de envio, alinhamento por PTR, MX do domínio. Essa via permite que uma mensagem legítima sem DMARC passe (por exemplo, o reason 109), mas também expõe a uma falha implícita (reason 001 ou 6xx) quando os sinais são insuficientes.

Esse mecanismo explica duas situações que costumam confundir os administradores. Uma mensagem de um domínio sem nenhuma autenticação pode obter compauth=pass se o seu IP tiver excelente reputação e um histórico limpo (autenticação implícita bem-sucedida). Por outro lado, uma mensagem de um domínio com DMARC estrito, mas mal alinhado, obtém compauth=fail reason=000 (autenticação explícita falhada), mesmo que o IP de envio seja, de resto, bem reputado.

A via explícita tem sempre prioridade. Se o domínio publica um DMARC utilizável, a Microsoft aplica sua política antes de recorrer aos sinais implícitos. É por isso que publicar um DMARC corretamente alinhado é a alavanca de controle mais poderosa de que um remetente dispõe sobre seu veredito composto.

Onde encontrar compauth=fail nos seus cabeçalhos?

O veredito composto é lido no cabeçalho Authentication-Results, mas a análise completa exige cruzar vários cabeçalhos da Microsoft.

O cabeçalho Authentication-Results reúne os vereditos de SPF, DKIM, DMARC e compauth. É o ponto de partida. Mas, para entender o impacto real de um compauth=fail, também é preciso ler o cabeçalho X-Forefront-Antispam-Report, que contém os campos de decisão do EOP.

No X-Forefront-Antispam-Report, vários campos são úteis:

Campo	Função
CAT	Categoria do veredito do EOP (SPM para spam, PHSH para phishing, SPOOF para falsificação, BULK, etc.).
SFV	Veredito do filtro (por exemplo, SKS para regra de transporte, SPM para spam).
SCL	Spam Confidence Level, de -1 a 9. Quanto maior o valor, mais a mensagem é considerada indesejada.
SFTY	Indicador de segurança, em especial 9.x para mensagens do tipo falsificação ou phishing: 9.19 falsificação de domínio, 9.20 falsificação de usuário, 9.25 aviso de segurança de "primeiro contato".

Veja um exemplo de cabeçalho real, comentado, em que a autenticação composta falha:

Authentication-Results: spf=none (sender IP is 203.0.113.20)
 smtp.mailfrom=marketing.captaindns.com; dkim=none (message not signed)
 header.d=none; dmarc=none action=none header.from=captaindns.com;
 compauth=fail reason=001
X-Forefront-Antispam-Report: CIP:203.0.113.20; CTRY:US;
 CAT:SPOOF; SFV:SPM; SCL:5; SFTY:9.19

Aqui, o domínio não publica SPF utilizável, nem DKIM, nem DMARC: a autenticação explícita é impossível e a implícita falha (reason=001). O EOP classifica a mensagem em CAT:SPOOF com um SCL:5 e um indicador SFTY:9.19, o que a destina ao lixo eletrônico. É o cruzamento de compauth=fail com esses campos de decisão que determina o destino real da mensagem.

Ainda é preciso saber onde recuperar esses cabeçalhos. No Outlook na Web, abra a mensagem, depois o menu de opções e "Exibir detalhes da mensagem" para copiar a origem bruta. No cliente Outlook para desktop, abra a mensagem em sua própria janela, depois Arquivo e Propriedades: o campo "Cabeçalhos da Internet" contém tudo. Do lado do administrador, o rastreamento de mensagens (message trace) do centro de administração do Exchange permite recuperar o veredito do EOP de uma mensagem entregue sem sequer acessar a caixa do destinatário. Para um diagnóstico em escala, os relatórios agregados DMARC (RUA) cruzam as fontes de envio que falham e complementam de forma útil a leitura de um cabeçalho individual.

Para extrair e ler esses cabeçalhos sem erro, copie a origem completa da mensagem e passe-a por um analisador dedicado. O tema da leitura de cabeçalhos está detalhado no nosso guia Como ler os cabeçalhos de um email.

A tabela completa dos reason codes compauth

Esta é a referência central do artigo. A tabela abaixo foi verificada na documentação oficial da Microsoft (página "Anti-spam message headers" do Microsoft Learn, atualizada em 8 de outubro de 2025). Cada linha apresenta o código, o resultado composto associado, o significado exato segundo a Microsoft, a causa típica e a resolução.

Código	compauth	Significado (Microsoft)	Causa típica	Resolução
000	fail	Falha de autenticação explícita. O DMARC falha com uma política p=quarantine ou p=reject. Desde 2023, um p=reject honrado por padrão pode causar uma rejeição no gateway (NDR 550 5.7.509), e não apenas uma classificação em Lixo Eletrônico.	O domínio publica um DMARC estrito, mas a mensagem não se alinha (SPF/DKIM quebram o alinhamento, muitas vezes em encaminhamento ou fonte não autorizada).	Alinhar SPF e DKIM no From:; autorizar a fonte de envio; configurar um ARC sealer confiável em caso de encaminhamento.
001	fail	Falha de autenticação implícita. Sem registros de autenticação publicados, ou política fraca.	O domínio não tem (ou tem pouca) autenticação: SPF em ~all/?all, ou DMARC em p=none. A Microsoft fica sem sinal.	Publicar SPF + DKIM + DMARC alinhados; endurecer progressivamente para ~all e depois -all.
002	fail	Uma política do tenant proíbe explicitamente esse par remetente/domínio.	Entrada manual de administrador (Tenant Allow/Block List, bloqueio de falsificação).	Verificar e remover a entrada de bloqueio se o remetente for legítimo.
010	fail	O DMARC falha com p=reject/p=quarantine, e o domínio remetente é um domínio aceito da sua organização.	Falsificação intraorganização: um serviço de terceiros envia "em nome do" seu próprio domínio sem estar autorizado.	Autorizar a fonte em SPF/DKIM ou via Tenant Allow/Block List.
1xx	pass	A mensagem passou na autenticação explícita ou implícita.	Sucesso.	Nenhuma ação.
100	pass	O SPF passou ou o DKIM passou, e MAIL FROM e From estão alinhados.	Sucesso nominal.	Nenhuma ação.
101	pass	A mensagem está assinada com DKIM pelo domínio do From:.	Sucesso DKIM alinhado.	Nenhuma ação.
102	pass	MAIL FROM e From alinhados, e o SPF passou.	Sucesso SPF alinhado.	Nenhuma ação.
103	pass	O From: está alinhado com o PTR (DNS reverso) do IP de origem.	Sucesso via PTR.	Nenhuma ação.
104	pass	O PTR do IP de origem está alinhado com o domínio do From:.	Sucesso via PTR.	Nenhuma ação.
108	pass	O DKIM falhou por causa de uma modificação do corpo por um salto legítimo anterior.	Tolerado (ambiente on-premises, por exemplo).	Monitorar as modificações em trânsito; considerar ARC.
109	pass	Sem DMARC, mas a mensagem passaria na avaliação mesmo assim.	Tolerado.	Publicar DMARC para formalizar a intenção.
111	pass	Apesar de um temperror ou permerror de DMARC, o SPF ou o DKIM está alinhado com o From:.	Tolerado apesar de um erro de DNS.	Corrigir o registro DMARC.
112	pass	Um timeout de DNS impediu a recuperação do DMARC.	Erro de DNS transitório.	Verificar a resolução DNS do domínio.
115	pass	A mensagem vem de uma organização Microsoft 365 em que o From: é um domínio aceito.	Tolerado (Microsoft 365 para Microsoft 365).	Nenhuma ação.
116	pass	O MX do From: está alinhado com o PTR do IP de conexão.	Tolerado.	Nenhuma ação.
130	pass	O resultado ARC de um ARC sealer confiável substituiu uma falha de DMARC.	Encaminhamento via um serviço ARC confiável.	Configurar ARC sealers confiáveis.
2xx	softpass	A mensagem passou parcialmente na autenticação implícita.	Sinais parciais.	Reforçar SPF/DKIM/DMARC.
201	softpass	O PTR do From: está alinhado com a sub-rede do PTR do IP de conexão.	Alinhamento fraco (sub-rede).	Reforçar a autenticação.
202	softpass	O From: está alinhado com o domínio do PTR do IP de conexão.	Alinhamento fraco (PTR).	Reforçar a autenticação.
3xx	none	A mensagem não foi verificada quanto à autenticação composta.	Não avaliado.	Nenhuma.
4xx	none	A mensagem contornou a autenticação composta.	Contornamento.	Nenhuma.
501	(n/a)	DMARC não aplicado: NDR (relatório de não entrega) válido, contato previamente estabelecido.	Tolerância de NDR.	Nenhuma ação.
502	(n/a)	DMARC não aplicado: NDR válido para uma mensagem enviada por esta organização.	Tolerância de NDR.	Nenhuma ação.
6xx	fail	Falha de autenticação de email implícita.	Falha implícita.	Publicar e alinhar SPF, DKIM, DMARC.
601	fail	O domínio remetente é um domínio aceito da sua organização (envio para si mesmo / falsificação intraorganização).	Aplicação ou serviço interno ou de terceiros enviando "como você" sem autenticação.	Autorizar a fonte (SPF/DKIM, relay autenticado, Tenant Allow/Block List).
7xx	pass	A mensagem passou na autenticação implícita.	Sucesso implícito.	Nenhuma ação.
701-704	pass	DMARC não aplicado graças a um histórico de mensagens legítimas dessa infraestrutura.	Reputação e histórico.	Nenhuma ação.
9xx	none	A mensagem contornou a autenticação composta.	Contornamento.	Nenhuma.
905	none	DMARC não aplicado por causa de um roteamento complexo (on-premises ou serviço de terceiros antes do Microsoft 365).	Roteamento híbrido.	Configurar ARC ou um relay autenticado.

Quadro de exatidão: os códigos 604, 605 e 703

Algumas ferramentas de terceiros (entre elas analisadores DMARC comerciais) citam os códigos 604, 605 e 703 como reason codes compauth distintos. Esses códigos não aparecem na documentação oficial atual da Microsoft. Na família 6xx, a Microsoft documenta apenas o código 601. Na família 7xx, a documentação cobre o intervalo 701-704 sem isolar 703 com um significado próprio. Nenhum 604 ou 605 é definido.

Por isso, não inventamos nenhum significado para eles. Se você encontrar um desses códigos, trate-o de acordo com sua família: um 6xx é uma falha implícita (a corrigir como um 601), um 7xx é um sucesso implícito. Não baseie um diagnóstico em uma definição sem fonte.

Códigos de falha: 000, 001, 002, 010 e 6xx/601

São os códigos que levam um administrador a ler este artigo. Eles se dividem em duas lógicas.

Os códigos 000 e 010 correspondem à falha explícita: o domínio publica um DMARC estrito, mas a mensagem não se alinha. O 010 é o caso particular em que o domínio em falha é um domínio aceito da sua própria organização. O 000, por sua vez, diz respeito a qualquer domínio externo com DMARC estrito mal alinhado.

Os códigos 001, 6xx e 601 correspondem à falha implícita: a Microsoft não pôde se apoiar em uma política declarada e seus sinais internos não foram suficientes. O 601 é o subcaso do domínio aceito da organização. O 002, por fim, é um caso à parte: não reflete uma falha técnica, mas uma decisão de administrador (uma entrada de bloqueio manual).

Códigos de sucesso (1xx, 7xx) e softpass (2xx)

A família 1xx reúne os sucessos, sejam eles explícitos (100, 101, 102) ou tolerados apesar de uma fraqueza (108, 109, 111, 112). O 130 merece atenção especial: indica que um ARC sealer confiável permitiu recuperar uma mensagem que teria falhado no DMARC por causa de um encaminhamento.

A família 7xx reúne os sucessos implícitos baseados na reputação e no histórico. A família 2xx (softpass) sinaliza um sucesso fraco: o alinhamento se apoia em sinais tênues como o PTR ou a sub-rede. Um softpass não é uma falha, mas é melhor reforçá-lo publicando uma autenticação explícita.

Códigos none / bypass (3xx, 4xx, 9xx, 905) e NDR (501/502)

As famílias 3xx, 4xx e 9xx correspondem a mensagens não avaliadas ou que contornaram a autenticação composta. O 905 é o mais instrutivo: sinaliza um roteamento complexo (passagem por um servidor on-premises ou um serviço de terceiros antes do Microsoft 365) que impede a aplicação normal do DMARC. A resposta a um 905 é, em geral, a implementação de ARC ou de um relay autenticado.

Os códigos 501 e 502 dizem respeito aos NDR (relatórios de não entrega) legítimos: a Microsoft não aplica DMARC a eles, pois respondem a um contato previamente estabelecido.

Diagnóstico e resolução por família de códigos

A tabela fornece a visão geral. Esta seção aprofunda os casos mais frequentes e o passo a passo concreto.

reason=000: um DMARC estrito quebrado pelo alinhamento

O reason=000 significa que o domínio remetente publica um DMARC em p=quarantine ou p=reject, mas que a mensagem não respeita o alinhamento DMARC. O alinhamento DMARC exige que o SPF ou o DKIM passe e que o domínio verificado corresponda ao domínio do From:. Atenção: desde meados de agosto de 2023, quando o destinatário aponta seu MX diretamente para o Microsoft 365, um reason=000 diante de um p=reject não se limita mais a rebaixar a mensagem, podendo causar uma rejeição no nível do gateway (NDR 550 5.7.509). O que está em jogo na correção, portanto, deixa de ser apenas a caixa de entrada contra o Lixo Eletrônico e passa a ser a própria entrega.

A causa mais frequente é o encaminhamento de email. Quando uma mensagem é reencaminhada, o IP de envio muda (o IP do servidor de encaminhamento substitui o IP de origem), o que quebra o alinhamento SPF. Se o DKIM não estiver presente ou se o corpo for modificado em trânsito, o DKIM também falha, e o DMARC falha por completo.

A segunda causa é o envio a partir de uma fonte não autorizada: um provedor de email marketing que não foi declarado no SPF nem configurado para assinar com DKIM no seu domínio.

A resolução depende do caso. Para uma fonte de envio legítima, autorize-a: adicione seu mecanismo include: ao SPF e configure a assinatura DKIM alinhada com seu domínio. Para o encaminhamento, a única resposta robusta é o ARC: o servidor de encaminhamento deve aplicar uma assinatura ARC, e o destinatário Microsoft 365 deve reconhecer esse sealer como confiável (o que então produz um reason=130).

Vejamos um exemplo concreto de encaminhamento que produz um reason=000. Uma mensagem sai de compta@captaindns.com, devidamente assinada com DKIM com d=captaindns.com e enviada a partir de um IP autorizado pelo SPF do domínio. Tudo está alinhado na origem. O destinatário configurou um redirecionamento automático para uma caixa hospedada no Microsoft 365. O servidor de redirecionamento reencaminha a mensagem a partir de seu próprio IP, que não está no SPF de captaindns.com: o SPF falha do lado da Microsoft. Se o servidor de redirecionamento, além disso, adicionou um aviso de "mensagem encaminhada" ao corpo, o hash DKIM deixa de corresponder e o DKIM também falha. O From: continuou compta@captaindns.com com um DMARC estrito: o DMARC falha por completo e a Microsoft registra compauth=fail reason=000. A mensagem, no entanto, é perfeitamente legítima. Somente o ARC, ao preservar os resultados de autenticação de origem ao longo de toda a cadeia, permite recuperar esse caso sem flexibilizar a política do domínio remetente.

reason=001: autenticação ausente ou fraca demais

O reason=001 é a falha implícita por excelência. O domínio não dá à Microsoft elementos para decidir: sem DMARC utilizável, SPF em ~all ou ?all, sem DKIM alinhado. A Microsoft tenta uma autenticação implícita, mas os sinais (reputação do IP, histórico) não bastam para concluir positivamente.

A resolução é estrutural. Publique os três pilares da autenticação de email. Um SPF correto que declare todas as suas fontes de envio, assinaturas DKIM alinhadas com seu domínio e um registro DMARC. Comece o DMARC em p=none corretamente alinhado para observar sem bloquear, depois endureça para p=quarantine quando suas fontes estiverem sob controle. No SPF, faça o mecanismo final evoluir de ~all para -all quando tiver certeza da exaustividade das suas fontes.

Uma nuance importante: um domínio em p=none ou um SPF em ~all não está "quebrado", está apenas permissivo. A Microsoft interpreta essa permissividade como uma ausência de intenção clara e passa para a autenticação implícita. O reason=001, portanto, não é a punição de um erro de sintaxe, mas a constatação de que o domínio não dá à Microsoft elementos para concluir positivamente pela via padrão. É exatamente por isso que reforçar as políticas faz o código desaparecer: você desloca a avaliação da via implícita (incerta) para a via explícita (determinística).

reason=010 e reason=601: a falsificação intraorganização

Esses dois códigos compartilham uma característica: o domínio remetente é um domínio aceito da sua própria organização Microsoft 365. Em outras palavras, uma mensagem afirma vir do seu domínio, mas a Microsoft não consegue confirmar que ela foi de fato enviada por uma fonte autorizada. O 010 corresponde à parte explícita (DMARC estrito em falha), o 601 à parte implícita.

É um cenário extremamente comum na prática: uma impressora de rede, uma aplicação corporativa, um CRM, uma ferramenta de faturamento ou um provedor de marketing envia emails "em nome do" seu domínio sem ter sido declarado no seu SPF nem configurado em DKIM. A Microsoft interpreta isso como uma possível falsificação interna. Esse mecanismo está ligado ao aviso "via" que o Microsoft 365 às vezes exibe; nós o detalhamos no nosso artigo sobre a falsificação intraorganização e o aviso da Microsoft.

A resolução consiste em autorizar explicitamente a fonte legítima. Três opções, por ordem de preferência: adicionar a fonte ao seu registro SPF e configurá-la para assinar com DKIM no seu domínio; encaminhar seus envios por um relay SMTP autenticado do seu tenant; em último recurso, criar uma entrada na Tenant Allow/Block List. Evite depender de forma duradoura da lista de permissões: é uma correção provisória, não uma autenticação.

reason=002: um bloqueio manual pela política do tenant

O reason=002 não traduz nenhuma falha técnica. Sinaliza que um administrador bloqueou explicitamente esse par remetente/domínio, geralmente via Tenant Allow/Block List ou uma regra anti-falsificação. Se o remetente for legítimo, a resolução é simples: remover a entrada de bloqueio. Antes disso, verifique por que o bloqueio foi colocado, para não reabrir uma porta fechada por um bom motivo.

reason=130: um ARC sealer substituiu legitimamente a falha de DMARC

O reason=130 é um sucesso, não um problema. Indica que uma mensagem teria falhado no DMARC (tipicamente por causa de um encaminhamento), mas que um ARC sealer confiável preservou os resultados de autenticação de origem, o que a Microsoft aceitou. É exatamente o comportamento desejado para o encaminhamento legítimo. Se você vê esse código, sua cadeia ARC está funcionando. O funcionamento do ARC está detalhado no nosso guia O que é o ARC (Authenticated Received Chain).

Compauth=fail significa que meu email está bloqueado?

Não no caso geral, mas com uma ressalva importante desde 2023. A documentação da Microsoft permanece explícita quanto ao princípio: um compauth=fail não causa, por si só, uma rejeição nem uma colocação em quarentena automática. O veredito composto é um fator entre outros na avaliação holística do EOP. Isso vale em especial para uma falha implícita (reason=001) e para os domínios sem DMARC estrito: a mensagem é então avaliada de forma global e cai com frequência no lixo eletrônico, não é rejeitada.

A ressalva diz respeito à falha explícita diante de uma política DMARC estrita. Desde meados de agosto de 2023, quando o domínio destinatário aponta seu MX diretamente para o Microsoft 365, o Exchange Online Protection honra por padrão a política DMARC publicada pelo domínio remetente. Uma falha de DMARC contra p=reject causa então uma rejeição no nível do gateway (com um relatório de não entrega, NDR), e p=quarantine uma colocação em quarentena, em vez do antigo comportamento que classificava tudo em Lixo Eletrônico. Essa mudança vem da configuração anti-phishing "Honrar a política DMARC quando a mensagem é detectada como falsificação", ativa por padrão, com ações configuráveis distintas para p=quarantine e para p=reject. Na prática, uma falha explícita do tipo reason=000 contra um p=reject pode agora ser rejeitada no gateway, e não apenas classificada em Lixo Eletrônico. O NDR retornado assume a forma: 550 5.7.509: Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject.

Uma ressalva dentro da ressalva: essa rejeição por padrão se aplica quando o MX do destinatário aponta diretamente para o Microsoft 365. Se o MX aponta para um gateway de terceiros colocado à frente do Microsoft 365, o EOP só honra a política DMARC se a "filtragem aprimorada para conectores" (Enhanced Filtering for Connectors) estiver ativada, pois ele precisa conseguir recuperar o IP de envio real por trás do relay.

Depois de estabelecer o veredito composto, o EOP combina essa informação com outros sinais para decidir o destino da mensagem: o SCL (Spam Confidence Level), a categoria CAT, o indicador de segurança SFTY, a reputação do IP, o conteúdo da mensagem e as políticas anti-spam e anti-phishing configuradas no tenant. Uma mensagem pode perfeitamente obter compauth=fail e chegar mesmo assim à caixa de entrada se os demais sinais forem tranquilizadores.

Por outro lado, é quando o compauth=fail se combina com uma categoria desfavorável que a mensagem é rebaixada. Um CAT:SPOOF acompanhado de um SFTY:9.x orienta a mensagem para o lixo eletrônico ou a quarentena, muitas vezes com um banner de aviso de falsificação. É, portanto, o contexto global, e não apenas o compauth, que determina a entrega.

Na prática, vários caminhos de decisão coexistem. Um compauth=fail reason=001 vindo de um IP com boa reputação, sem conteúdo suspeito, pode cair na caixa de entrada com um simples SCL baixo. O mesmo reason=001 vindo de um IP novo ou pouco reputado, com links ou anexos suspeitos, herda um SCL alto e uma categoria SPM ou PHSH, e vai para o lixo eletrônico. Por fim, um compauth=fail com CAT:SPOOF e SFTY:9.19 (falsificação de domínio) aciona a proteção anti-falsificação e pode levar diretamente à quarentena. O mesmo valor compauth=fail produz, portanto, três desfechos diferentes conforme o ambiente de sinais que o cerca.

Essa lógica tem uma consequência prática. Corrigir um compauth=fail não se resume a fazer desaparecer um sinalizador: trata-se de reduzir o risco global percebido pela Microsoft. Alinhar SPF, DKIM e DMARC eleva o veredito composto rumo a pass, mas também melhora a reputação da sua infraestrutura ao longo do tempo, o que age sobre o conjunto dos sinais. Se suas mensagens vão para o lixo eletrônico apesar de uma autenticação correta, nosso guia Por que seus emails vão para o spam cobre as outras alavancas de entregabilidade.

Plano de ação recomendado para corrigir um compauth=fail

Veja o passo a passo, do diagnóstico à verificação, aplicável qualquer que seja o reason code.

Diagnóstico e correção da autenticação composta, do reason code à verificação

1. Abra a origem completa da mensagem e anote o valor exato de compauth=fail reason=<código> no cabeçalho Authentication-Results. Anote também CAT, SCL e SFTY no X-Forefront-Antispam-Report. O reason code orienta todo o diagnóstico.

2. Verifique se todas as suas fontes de envio constam do registro SPF e se o alinhamento MAIL FROM/From é respeitado. Acompanhe o número de consultas DNS (limite de 10) que provoca um permerror.

3. Certifique-se de que suas mensagens estão assinadas com DKIM e de que o domínio de assinatura (header.d=) corresponde ao domínio do From:. Sem alinhamento DKIM, o DMARC não pode passar por essa via.

4. Verifique a presença e a coerência do registro DMARC. Confira o alinhamento e a política (p=). Uma política estrita mal alinhada provoca um reason=000; uma política ausente ou em p=none favorece um reason=001.

5. Se a falha vem de um encaminhamento, implemente o ARC. O servidor de encaminhamento deve selar a mensagem, e o Microsoft 365 deve reconhecer o sealer como confiável para produzir um reason=130.

6. Para um reason=010 ou 601, autorize a fonte interna: adição ao SPF e assinatura DKIM alinhada, relay SMTP autenticado, ou em último recurso a Tenant Allow/Block List.

7. Após a correção, envie uma mensagem de teste e inspecione o cabeçalho de novo. O veredito deve subir rumo a compauth=pass (reason 100 ou 130 conforme o caso).

Para as etapas de SPF e DKIM, duas ferramentas aceleram o diagnóstico: o verificador SPF confirma o alinhamento e conta as consultas DNS, e o verificador DKIM valida a publicação e a sintaxe da sua chave. As causas detalhadas de uma falha de assinatura estão cobertas no nosso guia DKIM fail: causas e correções, e os erros de SPF em SPF permerror: diagnóstico e resolução e SPF: consultas DNS em excesso.

As novas exigências da Microsoft para remetentes de alto volume

O compauth do Exchange Online Protection diz respeito ao correio recebido pelas organizações Microsoft 365. Em paralelo, a Microsoft elevou o nível para o correio que entra nas suas caixas consumidor Outlook. Esses dois mecanismos são distintos, mas convergem para a mesma exigência: autenticar o correio.

Desde 5 de maio de 2025, todo remetente de mais de 5.000 mensagens por dia para caixas consumidor @outlook.com, @hotmail.com e @live.com deve publicar os três pilares SPF, DKIM e DMARC, com uma política DMARC de no mínimo p=none alinhada com SPF ou com DKIM. Esse limiar retoma a lógica já imposta pelo Gmail e pelo Yahoo em fevereiro de 2024.

Segundo a Microsoft, as mensagens não conformes são primeiro encaminhadas ao Lixo Eletrônico e, depois de uma fase inicial de filtragem, são rejeitadas (não entregues). A rejeição associada assume a forma: 550 5.7.515 Access denied, sending domain [domínio] does not meet the required authentication level.

Um ponto essencial para evitar qualquer confusão com o restante deste artigo: essas exigências visam as caixas consumidor Outlook, Hotmail e Live, e fazem parte de um mecanismo distinto do compauth do Exchange Online Protection do lado corporativo do Microsoft 365. Os próprios códigos SMTP diferem: 5.7.515 sinaliza uma falha de autenticação do lado consumidor de alto volume, enquanto 5.7.509 corresponde a uma rejeição DMARC honrada pelo EOP do lado corporativo (ver acima). Não confunda os dois.

A boa notícia é que a conformidade também resolve o problema de fundo tratado neste guia. Publicar SPF, DKIM e DMARC alinhados para vencer essa barreira elimina por construção as causas de um reason=001 (falha implícita): a avaliação da Microsoft passa então da via implícita (incerta) para a via explícita (determinística). A trajetória é clara: a Microsoft honra o DMARC por padrão do lado do EOP em 2023, depois impõe a autenticação aos grandes remetentes do Outlook em 2025, na esteira do Gmail e do Yahoo. A autenticação de email não é mais opcional.

FAQ

O que é a autenticação composta (compauth) da Microsoft?

É um veredito proprietário do Microsoft 365 que agrega os resultados de SPF, DKIM e DMARC com sinais internos: reputação do IP de envio, histórico das mensagens, registro PTR e padrões comportamentais. O resultado é registrado no campo compauth do cabeçalho Authentication-Results. Não é um padrão RFC, mas uma camada de avaliação própria do Exchange Online Protection.

O que significa compauth=fail em um cabeçalho Authentication-Results?

O veredito compauth=fail indica que o Microsoft 365 não conseguiu confirmar a autenticidade do remetente, por via explícita (SPF/DKIM/DMARC alinhados) ou implícita (sinais internos). O reason que vem em seguida especifica por quê. Não é um veredito de bloqueio em si, mas um fator de risco na avaliação global da mensagem.

Um compauth=fail sempre bloqueia meu email?

Não. A Microsoft aplica uma avaliação holística: o veredito composto é combinado com o SCL, a categoria CAT, o indicador SFTY e a reputação do IP antes de qualquer decisão. Uma mensagem em compauth=fail pode chegar à caixa de entrada se os demais sinais forem favoráveis. Ela acaba no lixo eletrônico ou na quarentena sobretudo quando acompanhada de um CAT:SPOOF e de um SFTY:9.x.

O que significa reason=000?

O reason=000 é uma falha de autenticação explícita: o domínio remetente publica um DMARC estrito (p=quarantine ou p=reject), mas a mensagem não respeita o alinhamento DMARC. A causa mais frequente é o encaminhamento de email, que quebra o alinhamento SPF, ou um envio a partir de uma fonte não declarada. A correção passa pelo alinhamento SPF/DKIM ou pela implementação de ARC para o encaminhamento.

O que significa reason=001?

O reason=001 é uma falha de autenticação implícita: o domínio não publica autenticação utilizável (sem DMARC, SPF em ~all ou ?all, sem DKIM alinhado), e os sinais internos da Microsoft não bastam para concluir. A resolução consiste em publicar SPF, DKIM e DMARC corretamente alinhados e depois endurecer progressivamente as políticas.

O que significam reason=010 e reason=601?

Os dois códigos sinalizam que o domínio remetente é um domínio aceito da sua própria organização: um serviço ou uma aplicação envia "em nome do" seu domínio sem estar autorizado. O 010 é a parte explícita (DMARC estrito em falha), o 601 a parte implícita. A resolução consiste em autorizar a fonte legítima via SPF/DKIM, um relay autenticado ou a Tenant Allow/Block List.

Qual a diferença entre compauth=pass, softpass, fail e none?

pass significa que a autenticação composta passou, explícita ou implicitamente. softpass é um sucesso parcial da autenticação implícita, baseado em sinais fracos (PTR, sub-rede). fail é uma falha de autenticação, fator de risco mas não bloqueio automático. none significa que a mensagem não foi avaliada ou contornou a autenticação composta.

O compauth fail é diferente de uma falha de SPF, DKIM ou DMARC?

Sim. SPF, DKIM e DMARC são protocolos padronizados com vereditos independentes. O compauth é um veredito composto próprio da Microsoft, que agrega esses três resultados com sinais internos. Uma mensagem pode ter dmarc=fail mas compauth=pass (por exemplo, via um ARC sealer confiável, reason 130), ou o inverso conforme os sinais implícitos.

Por que um email legítimo obtém compauth=fail?

As causas mais frequentes são o encaminhamento de email (que quebra o alinhamento SPF e muitas vezes o DKIM), uma fonte de envio não declarada no SPF, um domínio sem DMARC nem DKIM alinhado, ou um serviço interno enviando em nome do seu domínio sem autorização. A autenticidade real da mensagem não está em questão: é a incapacidade da Microsoft de prová-la tecnicamente que produz a falha.

A Microsoft realmente rejeita os emails em p=reject agora?

Sim, em um caso específico. Desde meados de agosto de 2023, quando o destinatário aponta seu MX diretamente para o Microsoft 365, o Exchange Online Protection honra por padrão a política DMARC publicada pelo remetente. Uma falha de DMARC contra p=reject provoca então uma rejeição no gateway (NDR 550 5.7.509), e p=quarantine uma colocação em quarentena. Para uma falha implícita (reason=001) ou um domínio sem DMARC estrito, a mensagem continua sendo avaliada de forma global e vai, na maioria das vezes, para o Lixo Eletrônico, sem ser rejeitada. Se o MX passa por um gateway de terceiros, esse comportamento pressupõe que a "filtragem aprimorada para conectores" esteja ativada.

As exigências de alto volume do Outlook se aplicam a mim?

Aplicam-se se você envia mais de 5.000 mensagens por dia para caixas consumidor @outlook.com, @hotmail.com ou @live.com. Desde 5 de maio de 2025, esses envios exigem SPF, DKIM e DMARC publicados, com uma política DMARC de no mínimo p=none alinhada com SPF ou DKIM. As mensagens não conformes são filtradas para o Lixo Eletrônico e depois rejeitadas (NDR 550 5.7.515). Esse dispositivo visa as caixas consumidor e continua distinto do compauth do Exchange Online Protection do lado corporativo do Microsoft 365.

Os reason codes 604, 605 e 703 existem mesmo?

Eles são citados por algumas ferramentas de terceiros, mas não estão documentados pela Microsoft. A documentação oficial só descreve, na família 6xx, o código 601, e cobre o intervalo 701-704 sem isolar 703; nenhum 604 ou 605 consta dela. Se você encontrar um desses códigos, trate-o de acordo com sua família (6xx = falha implícita, 7xx = sucesso implícito) sem se apoiar em uma definição sem fonte.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os arquivos JSON ou CSV abaixo.

• Baixar os reason codes (CSV)
• Baixar os reason codes (JSON)

📖 Glossário

• Authentication-Results: cabeçalho (RFC 7001/8601) adicionado pelo servidor de recepção, que registra os vereditos de SPF, DKIM, DMARC e, no caso da Microsoft, compauth.
• Autenticação composta (compauth): veredito proprietário do Microsoft 365 que agrega SPF, DKIM, DMARC e sinais internos.
• Autenticação explícita: avaliação baseada nos registros DNS publicados (SPF, DKIM, política DMARC).
• Autenticação implícita: avaliação baseada nos sinais internos da Microsoft (reputação, histórico, PTR) na ausência de uma política utilizável.
• Alinhamento: correspondência entre o domínio verificado pelo SPF (5321.MailFrom) ou pelo DKIM e o domínio visível do From: (5322.From).
• Reason code: código de três dígitos que especifica a razão do veredito composto.
• ARC sealer: serviço que aplica uma assinatura ARC (RFC 8617) preservando os resultados de autenticação durante um encaminhamento.
• SCL / SFTY / CAT: campos de decisão do Exchange Online Protection (nível de spam, indicador de segurança, categoria do veredito).

Fontes

• Microsoft Learn: Anti-spam message headers in EOP (doc atualizada em 8 de outubro de 2025)
• Microsoft Learn: Email authentication in Microsoft 365
• Microsoft Learn: Use DMARC to validate email
• Microsoft Tech Community: Announcing new DMARC policy handling defaults for enhanced email security (2023)
• Microsoft Tech Community: Strengthening Email Ecosystem: Outlook's new requirements for high-volume senders (2025)
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8617: The Authenticated Received Chain (ARC) Protocol