Outlook.com rejeita e-mails sem DMARC desde 5 de novembro e não avisou ninguém

Desde 5 de novembro de 2026, o serviço de e-mail do consumidor da Microsoft (Outlook.com, Hotmail, Live e MSN) passou a recusar parte das mensagens vindas de domínios que não publicam um registro DMARC. Quem reportou o padrão foi a MailRoute, empresa de segurança de e-mail, num post no próprio blog publicado em 6 de novembro. A Microsoft não emitiu nota, post de status ou aviso no Postmaster até a publicação do texto.

O detalhe que importa para quem opera infraestrutura: isso não é a regra de bulk sender que a Microsoft já tinha anunciado. É um comportamento novo, silencioso, que atinge domínios pequenos e volumes baixos de envio, inclusive respostas pontuais de um sistema interno ou de um único atendente.

Como é a rejeição na prática

O remetente recebe um bounce como este, com um código de servidor que varia por mensagem:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

No primeiro dia do novo comportamento, a mesma recusa chegava sem o código entre parênteses. Segundo a MailRoute, a maioria dos domínios afetados já tinha SPF funcionando, e boa parte também tinha DKIM. O que faltava era especificamente o registro DMARC, que é quem amarra SPF e DKIM ao domínio que aparece no campo "De" da mensagem.

Por que isso é diferente da regra de maio de 2025

A Microsoft já tinha uma política pública: desde maio de 2025, domínios que enviam mais de 5.000 mensagens por dia ao Outlook.com precisam passar em SPF, DKIM e DMARC, sob pena de um erro 550 5.7.515 Access denied. Essa regra mirava remetentes em massa e serviços de marketing, e a maioria das empresas pequenas corretamente assumiu que não se aplicava a elas.

O comportamento identificado agora difere em três pontos:

• Atinge remetentes pequenos: uma única resposta saída de um sistema interno pode ser recusada.
• Não foi anunciado: até 6 de novembro, não havia aviso de Postmaster, post de blog ou entrada em página de status da Microsoft sobre a mudança.
• O bounce não detalha o que falhou: diferente do erro 5.7.515, que lista os resultados de SPF, DKIM e DMARC separadamente, este só informa que os registros estão ausentes.

O jeito traiçoeiro: nem toda mensagem falha

O ponto mais perigoso do comportamento, segundo a MailRoute, é a inconsistência. A Microsoft recusa só parte do tráfego de um domínio exposto: uma mensagem para um endereço Hotmail passa, a próxima para o mesmo endereço falha, e um reenvio pode dar certo.

Vimos essas rejeições pela primeira vez em nossos próprios logs de saída em 5 de novembro.

Thomas A. Johnson, fundador e CEO da MailRouteWe first saw these bounces in our own outbound logs on November 5.

Essa intermitência é o que faz o problema passar despercebido: quem enviou vê um bounce cheio de sigla, assume falha pontual e segue em frente. Quem deveria receber nunca sabe que uma mensagem foi enviada. Para quem opera sistemas que falam com usuários de endereço pessoal (confirmação de cadastro, fatura, status de candidatura, lembrete de consulta), o custo é silencioso: nada trava visivelmente, mas uma fração do tráfego simplesmente some.

Como checar se seu domínio está exposto

A checagem leva segundos em qualquer terminal. Basta trocar example.com pelo domínio que você usa para enviar e-mail transacional ou corporativo:

dig +short TXT _dmarc.example.com

Uma linha que começa com v=DMARC1 indica que o domínio já tem registro. Saída vazia significa que não há DMARC publicado, e esse é exatamente o caso que a nova rejeição do Outlook.com está mirando.

O conserto é um registro DNS

A correção é um registro TXT publicado no provedor de DNS do domínio:

• Nome: _dmarc
• Valor: v=DMARC1; p=none

A política p=none é o ponto de partida seguro: ela declara que o domínio usa DMARC e pede relatórios aos servidores que recebem a mensagem, mas não instrui ninguém a rejeitar ou colocar em quarentena nada em caso de falha. Nada muda em como Gmail, Yahoo ou qualquer outro provedor trata o restante do tráfego do domínio.

Atenção ao alinhamento SPF/DKIM

Há uma condição que derruba quem publica o registro sem checar o resto: o DMARC só passa quando SPF ou DKIM passam alinhados ao domínio que aparece no campo "De" da mensagem. Se nenhum dos dois estiver alinhado, o registro DMARC sozinho não resolve a rejeição.

É aqui que boa parte das configurações corporativas falha sem o time perceber. A MailRoute cita o exemplo do Microsoft 365: por padrão, o serviço assina as mensagens com o domínio onmicrosoft.com da própria Microsoft até o DKIM ser ativado explicitamente para o domínio da empresa, e essa assinatura padrão não conta para o alinhamento do DMARC. Na prática, isso sugere que qualquer serviço terceirizado de envio de e-mail pode esconder a mesma armadilha: se ele assina as mensagens com um domínio próprio em vez do domínio da empresa contratante, o alinhamento DMARC falha até alguém ativar explicitamente a assinatura pelo domínio correto.

O que muda para quem opera infraestrutura no Brasil

Para startups e empresas brasileiras, o recorte prático é direto: qualquer sistema que mande e-mail para endereço pessoal de cliente, candidato ou usuário final (e no Brasil hotmail.com e outlook.com seguem muito usados por pessoa física) está sujeito a essa rejeição silenciosa se o domínio remetente não tiver DMARC.

Isso cobre casos comuns de stack de produto:

1. Confirmação de cadastro ou recuperação de senha disparada por um serviço de autenticação.
2. Notificação de cobrança ou fatura enviada por um sistema de billing.
3. Resposta automática de um formulário de contato ou de candidatura em RH.

A checagem com dig leva segundos e deveria entrar como item de rotina em qualquer auditoria de domínio, ao lado de SPF e certificado TLS. Quem já usa um relay de e-mail de terceiros que assina DKIM pelo próprio domínio (em vez de assinar por um domínio compartilhado do provedor) tende a resolver o problema só publicando o DMARC, já que o alinhamento já existe.

Para onde isso vai

A leitura da MailRoute é que esse é o padrão que todo grande provedor de caixa postal vem seguindo: a exigência começa pelos remetentes em massa, é anunciada com prazo, e depois vira linha de base para todo mundo, sem aviso. DMARC em p=none deixou de ser boa prática e virou piso mínimo para qualquer domínio que envia e-mail, não só para quem dispara newsletter em volume alto.

O mesmo registro que evita essa rejeição hoje também é o primeiro passo para p=reject, política que instrui provedores a recusar mensagens que forjam o domínio da empresa, uma defesa direta contra phishing e golpes de business email compromise que usam domínios corporativos como isca.

Fonte: Hacker News