DMarkBlogInfo

Thomas A. Johnson, fundador da MailRoute, mostrou que desde 5 de novembro o Outlook.com recusa parte dos e-mails de domínios sem registro DMARC, inclusive de remetentes pequenos, e que a correção começa por um único registro no DNS.

Se o seu sistema manda e-mail para endereços @hotmail.com ou @outlook.com, separe cinco minutos hoje para checar uma coisa. Desde 5 de novembro, o serviço de e-mail de consumidor da Microsoft (Outlook.com, Hotmail, Live e MSN) passou a recusar parte das mensagens que chegam de domínios sem registro DMARC, e até agora a Microsoft não publicou nada sobre isso.

Quem identificou o padrão foi a MailRoute, empresa americana de segurança de e-mail. Eles viram os bounces nos próprios logs de saída no dia 5 e publicaram o relato no dia 6. O que mais me chamou atenção é que isso atinge remetente pequeno. Não se trata da regra de envio em massa que a Microsoft já tinha anunciado. Uma resposta isolada de um atendente ou um e-mail de recuperação de senha de um sistema interno pode voltar.

A correção é um registro TXT. Só que publicar o registro nem sempre basta, e é nessa parte que eu quero me aprofundar: o que o DMARC compara de fato, onde a configuração costuma quebrar e como descobrir se você já está perdendo mensagem.

Como o bounce aparece

O remetente recebe um retorno como este, com um identificador entre parênteses que muda a cada mensagem:

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

Segundo a MailRoute, no primeiro dia o mesmo erro chegava sem o código entre parênteses:

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

A mensagem dá a impressão de que SPF, DKIM e DMARC estão todos ausentes, mas normalmente não estão. A maioria dos domínios recusados que a MailRoute analisou tinha SPF funcionando, e muitos tinham DKIM também. O que faltava era o registro DMARC, que é o mecanismo que liga os outros dois ao endereço exibido no campo De.

O que muda em relação à regra de maio de 2025

A Microsoft já tinha uma regra publicada. Desde maio de 2025, domínios que mandam mais de 5.000 mensagens por dia para o Outlook.com precisam passar em SPF, DKIM e DMARC, ou recebem 550 5.7.515 Access denied. Como essa regra mirava marketing e disparo em massa, a maioria das empresas pequenas concluiu, com razão, que não se aplicava a elas.

O comportamento novo é outra coisa:

	Regra de maio de 2025	Comportamento desde 5 de novembro
Quem é atingido	Domínios com mais de 5.000 mensagens por dia	Qualquer domínio sem DMARC, em qualquer volume
Anúncio	Publicado pela Microsoft, com prazo	Nenhum, até 6 de novembro
Código	`550 5.7.515`	`550 5.7.1`
O que o bounce informa	O resultado de SPF, DKIM e DMARC, separadamente	Só que os registros estão ausentes

Por que é tão fácil não perceber

Esse é o ponto mais perigoso do relato. A Microsoft não recusa todo o tráfego do domínio, só uma parte. Uma mensagem para um endereço Hotmail passa, a seguinte para o mesmo endereço volta, e um reenvio pode dar certo.

Pega o caso da redefinição de senha. O usuário com conta Hotmail pede o link e ele não chega. Pede de novo e dessa vez chega. Para ele foi lentidão, para o suporte não aconteceu nada, e o bounce da primeira tentativa foi parar numa caixa noreply que ninguém abre. Multiplica isso por todo e-mail que o sistema dispara e você tem uma parte do tráfego sumindo sem nenhum alerta.

[COMPLETAR: experiência minha com e-mail transacional que não chegava ou com bounce que ninguém olhava]

No Brasil o impacto tende a ser maior, porque muita gente ainda usa conta Hotmail ou Outlook como e-mail pessoal principal.

O que o DMARC compara de verdade

Para entender por que o registro sozinho às vezes não resolve, vale olhar o que cada mecanismo verifica. Uma mensagem carrega três domínios diferentes:

Domínio	Onde fica	Quem verifica
Envelope (MAIL FROM)	Comando SMTP, aparece no cabeçalho `Return-Path`	SPF
Assinatura (`d=`)	Cabeçalho `DKIM-Signature`	DKIM
Remetente visível	Cabeçalho `From`	DMARC

SPF e DKIM, isoladamente, só dizem se um domínio autorizou aquele envio. Nenhum dos dois olha para o From que o usuário vê na caixa de entrada. O DMARC preenche essa lacuna: ele passa quando SPF ou DKIM passam para um domínio alinhado com o From. Basta um dos dois.

Por padrão, o alinhamento é relaxado. Basta o domínio organizacional ser o mesmo, então um envelope em bounces.empresa.com.br alinha com um From em empresa.com.br. No modo estrito (aspf=s e adkim=s), os domínios precisam ser idênticos. O domínio organizacional é calculado com a Public Suffix List, por isso, para empresa.com.br, ele é o próprio empresa.com.br, e não com.br.

O cabeçalho Authentication-Results de uma mensagem recebida mostra o resultado de cada verificação. Este é um exemplo ilustrativo de um caso comum:

Authentication-Results: mx.provedor-destino.com;
       spf=pass smtp.mailfrom=bounces.plataforma-envio.com;
       dkim=pass header.d=plataforma-envio.com;
       dmarc=fail header.from=empresa.com.br

SPF passou e DKIM passou, mas os dois para o domínio da plataforma de envio. Nenhum deles alinha com empresa.com.br, então o DMARC falha. É o tipo de configuração que parece correta no painel e continua perdendo mensagem.

Checando seu domínio em um minuto

Três consultas com dig mostram o estado dos registros:

# DMARC: saída vazia é exatamente o caso que o Outlook.com está recusando
dig +short TXT _dmarc.empresa.com.br

# SPF: deve existir um único registro começando com v=spf1
dig +short TXT empresa.com.br

# DKIM: depende do seletor usado pelo seu provedor
dig +short TXT selector1._domainkey.empresa.com.br   # Microsoft 365 usa selector1 e selector2
dig +short TXT google._domainkey.empresa.com.br      # seletor padrão do Google Workspace

Se você cuida de vários domínios (o institucional, o de cada produto, o de marketing), um script com dnspython faz a varredura de uma vez:

import dns.resolver  # pip install dnspython


def buscar_txt(nome):
    try:
        respostas = dns.resolver.resolve(nome, "TXT")
    except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer):
        return []
    return [b"".join(r.strings).decode() for r in respostas]


def verificar(dominio):
    dmarc = [t for t in buscar_txt(f"_dmarc.{dominio}") if t.lower().startswith("v=dmarc1")]
    spf = [t for t in buscar_txt(dominio) if t.lower().startswith("v=spf1")]

    print(f"\n{dominio}")
    print(f"  DMARC: {dmarc[0] if dmarc else 'AUSENTE (exposto à recusa do Outlook.com)'}")

    if not spf:
        print("  SPF:   ausente")
    elif len(spf) > 1:
        print(f"  SPF:   {len(spf)} registros (erro permanente, mantenha só um)")
    else:
        print(f"  SPF:   {spf[0]}")


for dominio in ["empresa.com.br", "produto.com.br"]:
    verificar(dominio)

Dois limites desse script. Ele não testa alinhamento, porque isso depende de quem envia a mensagem e só se confirma no cabeçalho de um e-mail real. E ele não considera que um subdomínio sem registro próprio herda o DMARC do domínio organizacional, assunto da próxima seção.

O registro mínimo e o que vale acrescentar

A correção que a MailRoute recomenda é um registro TXT com nome _dmarc e valor v=DMARC1; p=none. A política p=none declara que o domínio usa DMARC e pede relatórios, sem instruir ninguém a rejeitar ou colocar mensagens em quarentena. O jeito como Gmail, Yahoo e outros provedores tratam seu e-mail continua igual.

Eu colocaria o endereço de relatórios desde o primeiro dia. Sem o rua, você publica a política mas não recebe nenhum dado sobre quem está enviando em nome do seu domínio. No formato de arquivo de zona:

_dmarc.empresa.com.br.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@empresa.com.br"

As tags que mais aparecem:

Tag	O que faz
`v`	Versão, sempre `DMARC1` e sempre a primeira tag
`p`	Política para o domínio: `none`, `quarantine` ou `reject`
`sp`	Política para subdomínios; se omitida, vale a mesma de `p`
`rua`	Endereço que recebe os relatórios agregados, em XML
`ruf`	Endereço para relatórios de falha individuais; poucos provedores enviam
`adkim` / `aspf`	Modo de alinhamento de DKIM e SPF: `r` (relaxado, padrão) ou `s` (estrito)
`pct`	Percentual das mensagens com falha em que a política é aplicada

Dois detalhes que costumam pegar quem publica pela primeira vez:

Subdomínios herdam. Se a mensagem sai de notificacoes.empresa.com.br e não existe _dmarc.notificacoes.empresa.com.br, o receptor consulta o registro do domínio organizacional e aplica o sp, ou o p se não houver sp. Um registro na raiz cobre os subdomínios.
Relatório para outro domínio precisa de autorização. Se o rua aponta para um domínio diferente do seu (um serviço de análise, por exemplo), esse domínio precisa publicar um registro autorizando o recebimento, senão os provedores não enviam.

; publicado pelo domínio que RECEBE os relatórios de empresa.com.br
empresa.com.br._report._dmarc.relatorios-dmarc.com.  3600  IN  TXT  "v=DMARC1"

Onde a configuração costuma quebrar

Publicado o registro, o que resta é garantir que cada sistema que envia em nome do domínio passe em SPF ou DKIM alinhado. Os pontos mais comuns de falha:

Microsoft 365 sem DKIM do próprio domínio. É o exemplo que a MailRoute cita. Por padrão, o 365 assina com o domínio onmicrosoft.com até alguém ativar o DKIM para o domínio da empresa, e essa assinatura não conta para o DMARC.
Plataforma de envio com domínio próprio. Serviços como Amazon SES e SendGrid usam um domínio deles no envelope e na assinatura até você configurar a autenticação do seu domínio (MAIL FROM personalizado e DKIM com CNAMEs no seu DNS). Sem isso, o cenário é o do Authentication-Results mostrado acima.
Sistema legado mandando direto do servidor. Uma aplicação PHP usando mail() numa hospedagem compartilhada costuma sair com o envelope do usuário do servidor, não do seu domínio. Dá para forçar o envelope com o parâmetro -f, mas o DKIM vai depender do que a hospedagem oferece.
SPF com mais de 10 consultas DNS. Cada include, a, mx e redirect conta. Passou de 10, o resultado é permerror, e o SPF deixa de valer para o DMARC.
Dois registros SPF. Comum quando alguém adiciona um provedor novo criando outro TXT em vez de editar o existente. Também resulta em permerror.
Encaminhamento. Quando a mensagem é reencaminhada, o SPF quebra, porque o servidor que entrega passa a ser outro. O DKIM sobrevive se o conteúdo não for alterado, então, entre os dois, é o DKIM alinhado que segura melhor.

No caso do mail(), o quinto parâmetro define o envelope:

<?php
$cabecalhos = "From: Empresa <noreply@empresa.com.br>\r\n";

// -f define o MAIL FROM (envelope), que é o domínio verificado pelo SPF
mail($para, $assunto, $corpo, $cabecalhos, '-f noreply@empresa.com.br');

Procurando os bounces que já aconteceram

Como a recusa é intermitente, vale procurar retroativamente. Se você opera o próprio Postfix, o log mostra cada recusa:

# syslog tradicional
grep -i "lacks SPF/DKIM/DMARC" /var/log/mail.log

# distros com journald
journalctl -t postfix/smtp --since "2026-11-05" | grep -i "lacks SPF/DKIM/DMARC"

Se o envio passa por uma plataforma, o caminho é o relatório ou o webhook de bounces, filtrando pelo texto lacks SPF/DKIM/DMARC Auth Records a partir de 5 de novembro. Cruzar esses endereços com a base de usuários mostra quem pode não ter recebido uma confirmação de cadastro ou uma cobrança e merece um reenvio depois da correção.

De p=none até p=reject

A MailRoute enxerga nisso o mesmo roteiro que os grandes provedores de caixa postal vêm seguindo: a exigência começa pelo remetente em massa, é anunciada com prazo e depois vira regra para todo mundo, sem aviso. Johnson resume assim:

"DMARC em p=none virou o piso, e não mais uma boa prática." (Thomas A. Johnson, MailRoute)

O lado bom é que o registro que destrava a entrega no Outlook.com hoje é o primeiro passo para p=reject, a política que manda os provedores recusarem mensagens que falsificam o seu domínio. Boa parte do phishing e dos golpes de comprometimento de e-mail corporativo começa justamente por essa falsificação. O caminho que eu seguiria:

Publicar p=none com rua e acompanhar os relatórios por algumas semanas. Ferramentas open source como o parsedmarc transformam o XML em algo legível.
Corrigir cada fonte legítima que aparece falhando: CRM, ERP, plataforma de marketing, formulário do site.
Subir para p=quarantine, se quiser com pct baixo no início.
Chegar a p=reject quando os relatórios mostrarem só tráfego legítimo passando.

Checklist de diagnóstico

dig +short TXT _dmarc.seudominio retorna algo começando com v=DMARC1?
Existe um único registro SPF, com menos de 10 consultas DNS?
O DKIM está ativo com o seu domínio, e não com o do provedor (onmicrosoft.com, domínio da plataforma de envio)?
Você listou todos os sistemas que enviam em nome do domínio, incluindo os legados e os de terceiros?
O cabeçalho Authentication-Results de uma mensagem real de cada sistema mostra dmarc=pass?
Os logs ou webhooks de bounce desde 5 de novembro têm ocorrências de lacks SPF/DKIM/DMARC?
Alguém lê a caixa que recebe bounces e relatórios DMARC?

Fonte: Outlook.com Is Quietly Rejecting Email From Domains Without DMARC (Hacker News)

Chega de ordem de serviço no papel.

Seu e-mail pode estar voltando do Hotmail sem você saber, e o motivo é a falta de DMARC