Segurança de email para PMEs: SPF, DKIM, DMARC e anti-phishing 2026

1O problema: spoofing e Business Email Compromise

Por padrão, o protocolo SMTP de email não tem autenticação nativa. Qualquer servidor no mundo pode escrever um email dizendo "De: [email protected]" — e a mensagem chega ao destinatário parecendo legítima. Isso é spoofing.

O uso clássico desse vetor é o Business Email Compromise (BEC): o atacante envia uma mensagem fingindo ser o CEO ou um fornecedor para induzir um colaborador a transferir dinheiro, alterar dados bancários ou compartilhar informação sensível. Variantes comuns no Brasil em 2026:

• "Mudei o PIX, anota o novo aí" — vindo de domínio parecido (typo squatting) ou do próprio domínio se não tiver proteção
• "Preciso de uma transferência urgente" — assinado como CEO
• "Boleto da fatura, anexo" — boleto com código de barras adulterado
• "Atualize o cadastro bancário do fornecedor" — pedindo trocar conta destino

SPF, DKIM e DMARC são três protocolos DNS que, juntos, impedem essas mensagens de chegarem ao destinatário como se fossem do seu domínio. Nenhum dos três sozinho resolve. Os três juntos resolvem.

2Configurar SPF

SPF (Sender Policy Framework) é o primeiro protocolo a implementar — é simples, bloqueia muito spam imediatamente e é pré-requisito para os outros dois.

O que é

Um registro TXT no DNS do seu domínio que lista quais servidores estão autorizados a enviar email em seu nome. Quando um servidor destinatário recebe uma mensagem alegando vir do seu domínio, ele consulta o SPF do seu DNS. Se o servidor que enviou não está na lista, o destinatário marca como suspeita.

Como configurar em Microsoft 365

Microsoft 365 já cria automaticamente o registro SPF padrão quando você adiciona um domínio customizado. O registro típico é:

v=spf1 include:spf.protection.outlook.com -all

Se a empresa envia email também por outros sistemas (ferramenta de marketing, CRM, sistema de chamados), cada um precisa ser declarado:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:mailgun.org -all

3Habilitar DKIM

DKIM (DomainKeys Identified Mail) é o segundo protocolo. Ele adiciona uma assinatura criptográfica em cada mensagem enviada, calculada com uma chave privada que só o seu servidor de email possui. O servidor destinatário consulta a chave pública no DNS e valida a assinatura.

Por que DKIM importa

SPF pode quebrar quando uma mensagem é encaminhada (forwarding) — o servidor que reencaminha não está no SPF original. DKIM resolve isso: a assinatura criptográfica acompanha a mensagem mesmo após reencaminhamento.

Como ativar em Microsoft 365

No Microsoft 365, DKIM não vem ativo por padrão em domínios customizados. Precisa ser habilitado manualmente:

1. Acesse security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → DKIM
2. Selecione o domínio
3. Microsoft mostra 2 registros CNAME que precisam ser criados no DNS do domínio
4. Crie os CNAMEs no seu DNS (Cloudflare, Registro.br, GoDaddy, AWS Route 53, etc)
5. Volte ao Defender e clique "Enable" — Microsoft valida que os CNAMEs estão publicados e ativa a assinatura

4Publicar política DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) é o terceiro e último protocolo. Ele combina SPF e DKIM e adiciona duas coisas críticas:

1. Política: você instrui servidores destinatários sobre o que fazer com mensagens que falham na autenticação (none = só monitorar, quarantine = mandar para spam, reject = rejeitar)
2. Relatórios: você recebe relatórios diários sobre tentativas de envio em seu nome — incluindo tentativas legítimas que falharam (ajuste config) e atacantes tentando spoofing

Estrutura do registro DMARC

Registro TXT em _dmarc.suaempresa.com.br:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r

Onde:

• p=none — política inicial. Servidores destinatários reportam falhas mas não bloqueiam ninguém. Fique aqui pelo menos 30-90 dias antes de avançar.
• p=quarantine — manda mensagens que falham para spam. Bom segundo passo após análise de relatórios.
• p=reject — rejeita mensagens que falham. Política final, oferece proteção máxima.
• rua=... — onde os servidores destinatários enviam relatórios agregados (aggregate reports, formato XML).
• pct=100 — aplica a política a 100% das mensagens. Use pct=10 ou pct=25 em transição gradual.
• aspf=r / adkim=r — alinhamento "relaxed" (subdomínios são tratados como mesmo organizational domain). Use s (strict) se quiser controle subdomain-by-subdomain.

5Monitorar relatórios DMARC

Em p=none, você começa a receber relatórios diários XML dos servidores destinatários (Google, Microsoft, Apple, etc) na caixa que configurou no rua. Cada relatório lista:

• Quantas mensagens chegaram alegando vir do seu domínio
• Quais IPs as enviaram
• Resultado SPF e DKIM de cada
• Volume agregado por dia

Ler XML de DMARC manualmente é tedioso. Use uma das ferramentas:

• DMARC Analyzer / DMARCian / Postmark DMARC Monitoring / EasyDMARC — SaaS gratuitos ou freemium que parseiam o XML e mostram em dashboard
• Microsoft Defender for Office 365 (Plan 2) — inclui visualização de DMARC reports nativa
• Google Postmaster Tools — Google oferece estatísticas DMARC para domínios que enviam para Gmail

Acompanhe por 30-90 dias em p=none. Identifique sistemas legítimos da empresa que estão falhando autenticação (ajuste SPF/DKIM para cobri-los). Identifique IPs maliciosos tentando spoofing (boa hora para reportar abuse e ajustar). Quando os relatórios mostrarem >95% de mensagens passando autenticação, avance para p=quarantine. Após mais 30-60 dias, p=reject.

6Atender requisitos Google e Microsoft 2026

Desde fevereiro de 2024, Google e Yahoo passaram a exigir SPF + DKIM + DMARC para remetentes que enviam mais de 5.000 mensagens por dia a contas Gmail/Yahoo. Para volumes menores, a política recomendada já é a mesma.

Em 2026, a tendência é endurecer ainda mais:

• Google sinaliza que DMARC com alinhamento explícito (não só p=none) será requisito futuro
• Microsoft 365 já recomenda DMARC p=reject para domínios em produção
• PCI DSS v4.0 (versão atualmente em vigor) inclui DMARC como controle obrigatório para organizações que processam cartão

Checklist conformidade 2026

• ✅ SPF publicado com -all (hardfail)
• ✅ DKIM habilitado com chave de 2048 bits
• ✅ DMARC publicado com política mínima p=quarantine, idealmente p=reject
• ✅ Caixa rua= sendo monitorada (manual ou via ferramenta)
• ✅ Domínio listado em Google Postmaster Tools para visibilidade de reputação
• ✅ Revisão trimestral de relatórios DMARC + ajuste de SPF para novos sistemas

Perguntas frequentes sobre SPF, DKIM e DMARC

Para que servem SPF, DKIM e DMARC?

São três protocolos de autenticação de email que trabalham juntos para impedir que atacantes falsifiquem o domínio da sua empresa em mensagens fraudulentas. SPF declara quais servidores podem enviar email no seu nome. DKIM assina criptograficamente cada mensagem. DMARC amarra os dois e diz aos servidores destinatários o que fazer com mensagens que falham na autenticação.

Em que ordem implementar?

Sempre nesta ordem: primeiro SPF (mais simples e bloqueia muito spam imediatamente), depois DKIM, depois DMARC. DKIM e SPF precisam estar autenticando mensagens por pelo menos 48 horas antes de ativar DMARC. Comece DMARC em modo p=none (apenas monitora), avance para p=quarantine após 30-90 dias de observação, depois p=reject.

O que muda em 2026 com requisitos Google e Microsoft?

Desde fevereiro de 2024, o Google exige que remetentes que enviam mais de 5.000 mensagens por dia a contas Gmail tenham SPF, DKIM e DMARC configurados. Em 2026, a tendência é exigir DMARC com alinhamento explícito. PMEs que ignoram esses protocolos veem suas mensagens caindo em spam mesmo quando legítimas, e ficam expostas a spoofing por terceiros.

O que é Business Email Compromise (BEC)?

BEC é uma categoria de fraude onde o atacante se passa por executivo ou fornecedor legítimo via email para induzir colaborador a transferir dinheiro, alterar dados bancários ou enviar informações sensíveis. Categoria de maior prejuízo financeiro entre crimes cibernéticos para PMEs. SPF/DKIM/DMARC reduzem drasticamente a superfície de BEC quando o atacante tenta usar o seu domínio.

Meu provedor de email já fez SPF/DKIM/DMARC. Preciso me preocupar?

Depende. Em Microsoft 365, SPF padrão é configurado, mas DKIM precisa ser ativado manualmente por domínio customizado e DMARC nunca vem ativo por padrão. Em Google Workspace, é similar. A configuração padrão do provedor cobre o básico, mas DMARC com política enforcement (p=quarantine ou p=reject) raramente está em vigor. Verifique com uma checagem DNS pública.

Este conteúdo tem caráter educativo e não constitui parecer técnico ou jurídico vinculante. Para avaliação específica do ambiente Microsoft 365 da sua empresa, consulte um profissional qualificado. AKADNYX é membro do Microsoft AI Cloud Partner Program (Partner ID 1290730) e atua como Cloud Solution Provider (CSP) com acesso administrativo delegado (GDAP) aos tenants de clientes contratantes. Este artigo não é endossado pela Microsoft Corporation. Microsoft, Microsoft 365, Entra, Defender e Intune são marcas registradas da Microsoft Corporation.