O SPF valida o envelope. O DKIM valida a assinatura. Nenhum dos dois olha para o endereço que o Outlook mostra — é aí que entra a fraude. O DMARC é a única camada que vê a falha dos outros dois: cruza os resultados com o domínio do From. A sequência no Microsoft 365: SPF, DKIM, TXT _dmarc em observação e subida até p=reject pelos relatórios RUA.

💡 TL;DR

SPF com -all, DKIM no portal, o TXT _dmarc em p=none 30 dias a recolher rua, depois p=quarantine e p=reject.

O que o DMARC fecha

Dois remetentes: o do envelope (5321.MailFrom), alvo do SPF, e o do campo From (5322.From). SPF e DKIM não exigem que os domínios coincidam: o atacante assina no dele e escreve [email protected] no From — e passam ambos.

O DMARC é o alinhamento: passa se SPF ou DKIM validaram um domínio alinhado ao From. A política é pública — qualquer receptor a aplica — e corta a fraude BEC fora do Microsoft 365.

A sequência na ordem certa

1. SPF primeiro. É a camada mais barata — uma linha TXT: o Microsoft 365 deu o registo base, e falta-lhe a regra de fecho da lista. Sem SPF, o alinhamento via SPF nunca passa.

2. DKIM em seguida. Publica os dois CNAMEs e activa o DKIM no portal depois da propagação, até aparecer Signing DKIM signatures. A assinatura cobre From, Subject e corpo e viaja com a mensagem — sobrevive ao reencaminhamento, onde o SPF falha. Os dois antes do DMARC: cada um alimenta um alinhamento.

3. DMARC em p=none, 30 dias. O p=none não muda a entrega: o receptor filtra como sempre e manda-te relatórios. A espera constrói o inventário de quem envia em nome do domínio. Saltar a fase é subir a política sobre mapa em branco.

4. p=quarantine, depois p=reject. Limpo o inventário, muda para quarantine e controla a fatia exposta com pct (tag legado mas aceita) — começa reduzido, sobe até 100 e termina em p=reject — o receptor nega a falha no SMTP. Corriges emissores esquecidos com o impacto pequeno: o reject chega quando os relatórios deixam de mostrar legítimos sem alinhamento.

ℹ Nota de gestão: não há portal nem cmdlets para o TXT _dmarc de domínios personalizados — é tu quem o escreve na zona DNS. O *.onmicrosoft.com inicial (SPF e DKIM nativos) leva o TXT no admin center.

Os registos DNS

O SPF fecha a lista autorizada, com TTL folgado:

contoso.pt. 3600 IN TXT v=spf1 include:spf.protection.outlook.com -all

O ~all — aceitar e marcar — é só para testes. Um domínio leva um só registo SPF: dois devolvem permerror. O DKIM vem em dois CNAMEs: selector1._domainkey e selector2._domainkey, os valores exactos no portal:

selector1._domainkey.contoso.pt. 3600 IN CNAME SELECTOR1-DOMINIO._domainkey.TENANT.X-v1.dkim.mail.microsoft
selector2._domainkey.contoso.pt. 3600 IN CNAME SELECTOR2-DOMINIO._domainkey.TENANT.X-v1.dkim.mail.microsoft

Depois da propagação o portal activa a assinatura. Em domínio fora da lista, crias a configuração com New-DkimSigningConfig -KeySize 2048, e o Rotate DKIM keys troca as chaves em serviço. O TXT vai no host _dmarc: primeira linha em observação, segunda no destino:

_dmarc.contoso.pt. 3600 IN TXT v=DMARC1; p=none; pct=100; rua=mailto:dmarc-reports@contoso.pt
_dmarc.contoso.pt. 3600 IN TXT v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@contoso.pt

As tags vêm do DMARCbis, a revisão de Maio de 2026 que substituiu o RFC 7489: p o domínio, sp os subdomínios, rua os relatórios agregados e ruf os de falha. pct e ri ficaram de fora — são legado, ainda aceites e a Microsoft documentou-os, com np (para subdomínios inexistentes) e t (teste) a entrarem no lugar.

Relatórios RUA e RUF

Aponta o rua para uma caixa partilhada dedicada (dmarc-reports@) ou para um serviço externo que descodifica o XML. A tag ri pede 86400 segundos por omissão: um relatório por receptor por dia, anexo XML gzip.

A leitura: cada record agrega uma origem — o source_ip, a conta de mensagens, os resultados dkim e spf alinhados ou não contra o header_from. Origem volumosa em falha de alinhamento é fornecedor a corrigir antes de subir. Volume baixo sem assinatura é spoof.

O ruf é o relatório forense, quase em tempo real — mas o Microsoft 365 não os envia. Na prática, o RUA conta.

As armadilhas

Fornecedores que enviam no teu nome. Marketing, ERP e plataforma de bilhetes autenticam-se nos domínios deles — incluindo tenants *.onmicrosoft.com do fornecedor. Passam SPF e DKIM lá — sem alinhamento com o teu From. A receita: um subdomínio por fornecedor (marketing.contoso.pt), com SPF e DKIM próprios — e o raiz fica limpo. Subdomínios sem email são cobertos pela política do pai.

O reencaminhamento. Cada salto de forwarding muda o IP de origem, e quem altera a mensagem parte a assinatura DKIM. Mensagem reencaminhada falha SPF e sobrevive pelo DKIM — por isto o DMARC apoia-se nos dois. Serviços interpostos que mexem na mensagem registam-se como ARC sealer de confiança. O reencaminhamento externo automático é outro tema: o Exchange Online bloqueia-o por defeito (o 550 5.7.520 que tratei num artigo).

Os 10 lookups. Cada include e redireccionamento gasta consultas DNS, e o limite é 10. O spf.protection.outlook.com é o caso leve: o alvo é só um bloco de endereços IP, sem includes, um lookup em baixo. São os fornecedores terceiros é que multiplicam — conta os lookups a cada um e manda o excedente aos subdomínios.

O subject não está coberto. A DMARC autentica o domínio do From, não o assunto nem o corpo. O atacante com domínio próprio — contoso-facturas.pt — autentica-o e passa com o subject que quiser. Para esse ângulo: anti-phishing do Defender e treino do utilizador.

SPF, DKIM e DMARC em comparação

Camada O que valida Quando falha O que reporta
SPF O IP de envio contra o TXT do domínio do envelope (5321.MailFrom) Reencaminhamento e emissores fora do registo O Authentication-Results
DKIM Assinatura de cabeçalhos e corpo contra a chave pública no d= Alterações em trânsito, chaves mal publicadas O Authentication-Results
DMARC O alinhamento do SPF ou do DKIM com o 5322.From que o Outlook mostra Nenhum mecanismo passa com alinhamento Relatórios rua diários e ruf facultativos

Cenário: o CEO falsificado

O domínio do cliente recebe From [email protected]: assunto Transferência urgente e o pedido por IBAN estrangeiro. O servidor do imitador não está no SPF nem assina: SPF falha, DKIM não existe, DMARC fecha. Em p=none o receptor não recusa pelo teu DMARC. Em p=quarantine, pasta de lixo. Em p=reject morre em geral na negociação SMTP — se o receptor também for M365, o peso final é da política anti-phishing do tenant receptor. O mesmo TXT protege o banco e o contabilista externo — a política é pública por isto. Assegura a identidade, não o canal: o transporte fica para o MTA-STS e o DANE, que tratei noutro artigo.

Fontes Oficiais

Artigos Relacionados