Outlook recusa e-mail sem DMARC: como corrigir

Desde 5 de novembro de 2026, e-mails enviados para contas do Outlook.com, Hotmail, Live e MSN começaram a voltar com um erro que pouca gente tinha visto: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519). O detalhe que confundiu muitos administradores é que SPF e DKIM estavam passando. O que faltava era um registro DMARC publicado no DNS do domínio remetente — e isso valeu até para quem manda poucas dezenas de mensagens por dia, bem longe da regra de grandes remetentes que a Microsoft anunciou em 2025.

A Microsoft não publicou nenhum comunicado sobre essa mudança até a noite de 8 de novembro. O que existe são relatos de administradores, testes reproduzidos por especialistas em entregabilidade e respostas no fórum oficial de suporte. Este post separa o que foi confirmado do que ainda é incerto, mostra como conferir o seu domínio com um script curto que rodamos aqui e explica qual registro publicar sem arriscar a entrega no Gmail e nas caixas corporativas.

O que mudou, segundo quem testou

O primeiro registro público é da MailRoute, que viu as recusas nos logs de saída em 5 de novembro. No dia 6, administradores compararam casos na lista Mailop e o assunto lotou uma pergunta no Microsoft Q&A, onde quem adicionou o registro DMARC relatou que as mesmas mensagens passaram a ser aceitas. No dia 7, Al Iverson, do Spam Resource, apagou o DMARC de domínios próprios e pequenos e reproduziu a recusa: a mensagem para um endereço outlook.com voltou com o 550, enquanto a mesma mensagem para uma empresa hospedada no Microsoft 365 foi aceita.

O teste mais detalhado até agora é o da DMARKOFF, uma empresa que vende monitoramento de DMARC (vale ter isso em mente ao ler). Em 7 e 8 de novembro, com SPF e DKIM passando e alinhados pelo Mailgun, eles encontraram o seguinte:

• Sem DMARC em lugar nenhum: as 16 caixas de Outlook.com e Hotmail recusaram a mensagem durante a conversa SMTP.
• DMARC só no domínio pai (o subdomínio de envio sem registro próprio): aceito, tanto com p=reject quanto com p=none.
• DMARC só no subdomínio: aceito também.
• Microsoft 365 corporativo: as cinco caixas aceitaram mesmo sem DMARC nenhum.
• Pasta de destino: o registro decidiu se a mensagem era aceita, não se ia para a caixa de entrada. Um dos subdomínios continuou caindo no spam com qualquer política.

Relatos no fórum da Microsoft falam em recusa intermitente — parte das mensagens do mesmo domínio passa, parte volta. No teste da DMARKOFF, com uma mensagem por caixa, foram 16 recusas em 16. Então “uma passou” não prova que o domínio está certo.

Como isso difere da regra de 2025

Desde 5 de maio de 2025, a Microsoft exige de quem envia mais de 5 mil mensagens por dia para as contas de consumidor SPF e DKIM passando e um DMARC de pelo menos p=none alinhado com o domínio do From. Essa regra foi anunciada no blog do Defender for Office 365 e tem o próprio código de erro, o 550 5.7.515, com página de ajuda oficial.

O que apareceu agora é outra coisa: código 5.7.1, identificador AS9031519, que não aparece na documentação pública, e nenhum limite de volume visível. Pode ser uma mudança deliberada, um teste ou algo que será desfeito. Ninguém fora da Microsoft sabe. A conclusão prática, porém, não depende da resposta: publicar um DMARC custa uma linha de DNS e protege contra as duas regras.

Quem precisa se mexer

Não é só quem tem servidor de e-mail próprio. Os casos mais comuns que vimos relatados são domínios que mandam e-mail por um serviço terceirizado que configurou SPF e DKIM e nunca falou de DMARC:

• o domínio da aplicação que envia redefinição de senha, nota fiscal ou alerta de cobrança;
• o domínio do sistema de chamados ou do CRM;
• o Microsoft 365 ou o Google Workspace de uma empresa pequena — o próprio Microsoft 365 não cria o registro DMARC sozinho, como relatou um administrador no fórum;
• a marca antiga que ainda dispara um boletim de vez em quando.

Se você mantém o formulário de contato de um site, vale lembrar que a confirmação para o cliente também é e-mail com o seu domínio no From — o mesmo cuidado que tratamos em formulário de contato que chega.

Confira o seu domínio em um minuto

O DMARC fica num registro TXT em _dmarc. seguido do domínio que aparece no From da mensagem. Se o subdomínio não tiver registro próprio, vale o do domínio organizacional (o “pai”), como define a RFC 7489. Com o dig instalado, a consulta é:

dig +short TXT _dmarc.seudominio.com.br

No Windows, o equivalente é Resolve-DnsName _dmarc.seudominio.com.br -Type TXT. Como o nosso computador de testes não tinha dig, escrevemos um script em Python sem dependências que consulta por DNS sobre HTTPS, olha o subdomínio e o domínio pai e acusa registro duplicado — que também quebra a autenticação:

import json, sys, urllib.request

def txt(nome):
    url = f"https://cloudflare-dns.com/dns-query?name={nome}&type=TXT"
    req = urllib.request.Request(url, headers={"accept": "application/dns-json"})
    dados = json.load(urllib.request.urlopen(req, timeout=10))
    return [r["data"].replace('" "', "").strip('"')
            for r in dados.get("Answer", []) if r["type"] == 16]

def organizacional(dominio):
    partes = dominio.split(".")
    n = 3 if len(partes) >= 3 and partes[-1] == "br" and len(partes[-2]) <= 3 else 2
    return ".".join(partes[-n:])

for dominio in sys.argv[1:]:
    org = organizacional(dominio)
    achou = None
    for d in dict.fromkeys([dominio, org]):
        regs = [r for r in txt("_dmarc." + d) if r.lower().startswith("v=dmarc1")]
        if len(regs) > 1:
            achou = f"ERRO: {len(regs)} registros em _dmarc.{d}"; break
        if regs:
            achou = f"ok  _dmarc.{d}: {regs[0]}"; break
    print(f"{dominio:28}", achou or "SEM DMARC")

A função organizacional é uma simplificação: ela trata .com.br, .net.br e parecidos, mas não conhece todos os sufixos públicos. Para um domínio fora desse padrão, confira o pai à mão. Rodando em 8 de novembro de 2026, a saída foi esta (o último nome não existe e entrou só para mostrar o caso negativo; cortamos o fim das linhas):

$ python3 checa_dmarc.py devbras.com clarus.devbras.com gmail.com loja-teste-sem-dmarc.com.br
devbras.com                  ok  _dmarc.devbras.com: v=DMARC1; p=quarantine; ...
clarus.devbras.com           ok  _dmarc.devbras.com: v=DMARC1; p=quarantine; ...
gmail.com                    ok  _dmarc.gmail.com: v=DMARC1; p=none; sp=quarantine; ...
loja-teste-sem-dmarc.com.br  SEM DMARC

Repare na segunda linha: o subdomínio do Clarus não tem registro próprio e herda o do domínio principal. Pelo teste da DMARKOFF, isso basta para o Outlook.com aceitar.

O registro mínimo que resolve

Se o resultado for “sem DMARC”, publique no domínio organizacional um TXT com nome _dmarc e este valor:

v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com.br

• p=none não manda ninguém rejeitar nada. Ele só declara que o domínio tem política e pede relatórios. Nos testes publicados, isso já parou a recusa.
• rua é o endereço que recebe os relatórios agregados (arquivos XML diários). Eles mostram quem está enviando e-mail em nome do domínio — inclusive aquele serviço de marketing que ninguém lembrava. Crie uma caixa separada ou use um serviço que leia esses XML.
• Publique um único registro. Dois TXT começando com v=DMARC1 no mesmo nome invalidam a política.

Para o DMARC passar de verdade, SPF ou DKIM precisam estar alinhados com o domínio do From. Na prática: o serviço que envia precisa assinar o DKIM com o seu domínio (não com o dele) ou usar um envelope de retorno no seu domínio coberto pelo SPF. A documentação da Microsoft sobre DMARC e a do Google para remetentes trazem o passo a passo de cada lado.

Depois de salvar, dê alguns minutos. Um resolvedor que guardou a resposta “não existe” pode mantê-la pelo tempo de cache negativo da zona — 15 minutos no teste da DMARKOFF.

Quando endurecer a política

Não suba direto para p=reject. Deixe p=none por algumas semanas, leia os relatórios e confirme que todo serviço legítimo aparece passando. Só então vá para p=quarantine e, depois, reject. Pular essa etapa é o jeito mais rápido de bloquear a sua própria nota fiscal ou o e-mail de cobrança. Se você está montando o próprio servidor, treine isso antes num domínio de laboratório, como descrevemos em e-mail próprio: laboratório antes de arriscar o domínio, e confira também o IP reverso e a reputação, tema de servidor de e-mail próprio: a entrega é a parte difícil.

Se você é quem está recebendo o erro

Quando é o seu Hotmail que deixa de receber mensagens de alguém, não há configuração na sua conta que resolva: a recusa acontece antes de a mensagem chegar à caixa, e lista de remetentes confiáveis não ajuda. O que dá para fazer é conferir o domínio do remetente com o script acima (ou com o verificador do MxToolbox) e mandar o resultado para a equipe de TI de quem envia. Se o domínio tiver DMARC válido e a recusa continuar, o caminho oficial é o formulário de suporte a remetentes do Outlook.com.

Em resumo

• O erro 550 5.7.1 … (AS9031519) vem das contas de consumidor da Microsoft, não do Microsoft 365, e aparece quando o domínio do From não tem DMARC nem no subdomínio nem no domínio pai.
• A mudança não foi anunciada; os fatos vêm de testes independentes de 5 a 8 de novembro de 2026 e podem mudar.
• Um TXT _dmarc com p=none e rua resolveu a recusa em todos os testes publicados. Não resolve spam: pasta de entrada continua dependendo de reputação.
• Endureça a política só depois de ler os relatórios.