SPF, DKIM e DMARC: o que são e como configurá-los no seu domínio

SPF, DKIM e DMARC são três registos que se publicam no DNS do seu domínio. Em conjunto, dizem aos servidores de destino quem pode enviar email em seu nome, provam que a mensagem não foi alterada pelo caminho e definem o que fazer quando algo não bate certo. Sem eles, qualquer pessoa consegue enviar uma fatura falsa com o endereço da sua empresa no campo "De", e os seus emails legítimos têm mais probabilidade de acabar no spam. Explicamos o que faz cada um, como se configuram pela ordem certa e como diagnosticar as falhas mais comuns.

TL;DR

• SPF autoriza os servidores que podem enviar pelo seu domínio. DKIM assina cada mensagem com uma chave criptográfica. DMARC liga os dois ao endereço que o destinatário vê e define a política para falhas.
• O DMARC só passa se o SPF ou o DKIM passarem alinhados com o domínio do campo "De". Ter o SPF a passar não chega.
• Configure por esta ordem: SPF, depois DKIM, depois DMARC em p=none com relatórios. Só avance para quarantine ou reject depois de ler os relatórios.
• Desde fevereiro de 2024, quem envia mais de 5.000 mensagens por dia para contas Gmail tem de ter os três publicados.
• É uma alteração no DNS e no fornecedor de email, não uma instalação num computador. O trabalho a sério está em inventariar todos os serviços que enviam em seu nome.

Índice

• Porque é que o email precisa de autenticação
• O que faz cada protocolo
• Alinhamento: porque o DMARC falha com o SPF a passar
• Como configurar, passo a passo
• Microsoft 365, reencaminhamento e gateways
• Como diagnosticar uma falha
• Gmail e grandes remetentes: deixou de ser opcional
• O que o DMARC não garante
• A nossa perspetiva
• Quando faz sentido pedir ajuda
• Perguntas frequentes
• Fontes

Porque é que o email precisa de autenticação

O protocolo de email foi desenhado numa época em que ninguém pensava em fraude. O endereço no campo "De" é texto livre: o servidor que envia escreve o que quiser. É por isso que o spoofing (falsificar o remetente) continua a ser a base de tantos esquemas de phishing e de fraude de pagamentos.

O SPF nasceu no início dos anos 2000, no IETF, e chegou a chamar-se "Sender Permitted From" antes de assumir o nome atual, como conta a nota técnica do NIST sobre mecanismos de autenticação de email. O DKIM e o DMARC vieram depois, para resolver o que o SPF sozinho não resolve. A agência federal alemã de cibersegurança trata os três como um conjunto, sob o termo "Email Authentication", nas suas diretrizes técnicas TR-03182. Em Portugal, o Centro Nacional de Cibersegurança dedicou ao tema a sua Recomendação Técnica 01/2020, sobre a proteção de domínios contra utilização abusiva.

A ideia central é simples: estes protocolos funcionam como um sistema, não como três caixas independentes. Uma empresa que só publica SPF continua exposta à falsificação do campo "De". Uma empresa que publica um DMARC rigoroso sem SPF e DKIM bem afinados arrisca-se a ver os próprios emails rejeitados.

O que faz cada protocolo

SPF: quem pode enviar

O SPF (Sender Policy Framework) é um registo TXT que lista os servidores e serviços autorizados a enviar email pelo seu domínio. O servidor de destino compara o IP de quem está a entregar a mensagem com essa lista.

Há um detalhe que gera confusão: o SPF verifica o domínio do envelope (o "MAIL FROM" ou Return-Path, invisível para o utilizador), não o endereço que aparece no campo "De". Um atacante pode passar no SPF com um domínio próprio e, mesmo assim, mostrar o seu endereço ao destinatário.

DKIM: a assinatura da mensagem

O DKIM (DomainKeys Identified Mail) acrescenta uma assinatura digital ao cabeçalho de cada mensagem. O servidor de envio assina com uma chave privada. O destinatário vai buscar a chave pública ao DNS, a um registo identificado por um "selector", e confirma que o conteúdo assinado não foi alterado. O domínio responsável pela assinatura é o valor d= do cabeçalho DKIM.

Ao contrário do SPF, o DKIM sobrevive ao reencaminhamento, desde que ninguém altere o corpo ou os cabeçalhos assinados.

DMARC: a política e os relatórios

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é um registo TXT publicado em _dmarc.seudominio.pt. Faz três coisas: liga o SPF e o DKIM ao domínio visível no campo "De", diz ao destinatário o que fazer com as mensagens que falham e pede relatórios sobre quem está a enviar em seu nome. A especificação atual é o RFC 9989, publicado em maio de 2026, que substitui o RFC 7489 de 2015.

Alinhamento: porque o DMARC falha com o SPF a passar

É o ponto que mais surpreende em implementações reais. Segundo o RFC 9989, para o DMARC passar é preciso que pelo menos um dos mecanismos passe e esteja alinhado com o domínio do campo "De".

Um exemplo comum: a sua newsletter sai por uma plataforma de marketing. O campo "De" mostra noticias@empresa.pt, mas o envelope usa um domínio técnico da plataforma e a assinatura DKIM tem d=plataforma.com. O SPF passa (para o domínio da plataforma), o DKIM passa (para o domínio da plataforma) e o DMARC falha, porque nenhum dos dois corresponde a empresa.pt.

Há dois modos de alinhamento:

• Relaxed (o predefinido): basta pertencer ao mesmo domínio organizacional. mail.empresa.pt alinha com empresa.pt.
• Strict: os domínios têm de ser idênticos.

A solução passa quase sempre por configurar o DKIM com o seu próprio domínio em cada serviço que envia em seu nome, em vez de depender da assinatura técnica do fornecedor.

Como configurar, passo a passo

A configuração faz-se no painel DNS do seu domínio (no registador ou no fornecedor de alojamento) e na consola do serviço de email. Não se instala nada nos computadores.

1. Faça o inventário de quem envia em seu nome. Caixas de correio, newsletters, CRM, faturação, helpdesk, formulários do site, impressoras e scanners que enviam por email. É o passo que mais se salta e o que mais problemas causa depois.
2. Publique um único registo SPF. Junte todos os serviços num só TXT. Um exemplo genérico: v=spf1 include:servico-de-email.exemplo include:plataforma-newsletter.exemplo -all. Use o valor de include que cada fornecedor indica na sua documentação. Dois registos SPF no mesmo domínio invalidam-se mutuamente.
3. Ative o DKIM em cada serviço. No fornecedor de email e em cada plataforma de envio, ative a assinatura com o seu domínio e publique os registos do selector que o fornecedor indicar.
4. Publique o DMARC em modo de observação. Por exemplo: v=DMARC1; p=none; rua=mailto:dmarc@empresa.pt. A política none não bloqueia nada: serve para recolher relatórios agregados.
5. Teste com mensagens reais. Envie a partir de cada serviço para uma conta Gmail e outra Outlook e leia os cabeçalhos Authentication-Results.
6. Leia os relatórios durante algumas semanas. Vão aparecer remetentes legítimos esquecidos. Corrija-os até todos passarem alinhados.
7. Endureça a política aos poucos. Passe para p=quarantine (as falhas vão para o spam) e, quando estiver confiante, para p=reject. As três políticas possíveis estão definidas no RFC 9989.

Quanto tempo demora? Os registos propagam-se conforme o TTL definido no DNS, normalmente em minutos ou poucas horas. O que demora é o inventário e a fase de observação. As orientações do Google para remetentes não fixam um prazo universal, e o esforço depende do número de domínios, subdomínios e serviços externos.

Microsoft 365, reencaminhamento e gateways

Em ambientes Microsoft 365 há duas armadilhas recorrentes.

Reencaminhamento. Quando uma mensagem é reencaminhada, o IP de origem muda e o SPF tende a falhar. Se, além disso, um intermediário altera o corpo (um gateway de segurança que reescreve links ou acrescenta um rodapé), o DKIM também falha. Resultado: uma mensagem legítima chumba no DMARC.

Serviços intermédios. Para estes casos, a Microsoft recomenda configurar selos ARC fidedignos para os serviços legítimos que modificam as mensagens antes da entrega. O ARC preserva os resultados de autenticação originais ao longo da cadeia. Usá-lo não é sinal de configuração incompleta: é controlo de risco.

Por isso, antes de passar a p=reject, teste os fluxos reais da empresa. Uma política rigorosa protege contra o phishing, mas também bloqueia mensagens legítimas se o caminho alterar o IP, os cabeçalhos ou o corpo. Se está a mudar de fornecedor de email, o nosso guia de migração para o Microsoft 365 em PME mostra onde encaixar esta configuração no plano.

Como diagnosticar uma falha

Abra a mensagem, veja o código-fonte ou os cabeçalhos completos e procure a linha Authentication-Results. A página de resolução de problemas da Microsoft organiza os sintomas assim:

A ordem que a Microsoft sugere é lógica: corrigir o SPF, depois o DKIM, confirmar o alinhamento DMARC e só então tratar dos reencaminhamentos e gateways.

O limite de 10 consultas DNS merece atenção especial. Cada include pode desencadear outras consultas, e as empresas com vários fornecedores (email, CRM, marketing, faturação) ultrapassam-no sem dar por isso. Vale também a pena rever os include de serviços que já não usa: são consultas desperdiçadas e portas que ficam abertas.

Gmail e grandes remetentes: deixou de ser opcional

Durante anos, estes protocolos foram uma boa prática. Para quem envia em volume, passaram a ser requisito. Desde 1 de fevereiro de 2024, segundo as diretrizes do Gmail para remetentes, quem envia mais de 5.000 mensagens por dia para contas Gmail tem de:

• configurar o SPF e o DKIM;
• publicar o DMARC (a política pode ser none);
• manter o DNS direto e o reverso válidos para os IP de envio;
• usar TLS na transmissão;
• manter a taxa de spam reportada no Postmaster Tools abaixo de 0,30%;
• nas mensagens de marketing e de subscrição, permitir o cancelamento com um só clique.

Estas regras aplicam-se ao volume dirigido a contas Gmail, não a todos os destinatários. Mas, mesmo abaixo desse limiar, o Google recomenda aos administradores que configurem sempre os três, tanto contra o spoofing como para evitar que as mensagens legítimas sejam marcadas como spam. Na prática, uma PME que envia faturas, propostas e uma newsletter mensal deve olhar para todo o ecossistema de envio, e não apenas para as caixas de correio.

O que o DMARC não garante

Há duas expectativas erradas que convém desfazer:

• Não garante a chegada à caixa de entrada. O DMARC comunica quem está autorizado a usar o domínio e o que fazer com as falhas. A reputação, o conteúdo, o volume e o comportamento do remetente continuam a pesar na entrega.
• Não prova que a mensagem é segura. O RFC 9989 é claro: um DMARC positivo significa que o uso do domínio foi validado, não que o conteúdo é benigno. Um atacante com o seu próprio domínio bem configurado passa no DMARC. A filtragem antispam e a atenção dos utilizadores continuam a ser necessárias, sobretudo perante domínios parecidos com o seu.

A nossa perspetiva

Quando uma empresa nos contacta porque "os emails vão para o spam" ou porque um cliente recebeu uma fatura falsa em seu nome, raramente o problema é só um registo em falta. Quase sempre há um serviço que alguém ativou há dois anos, um formulário do site que envia por um servidor esquecido ou dois registos SPF publicados por pessoas diferentes.

Por isso, não começamos pelo DNS. Começamos por perceber como a empresa trabalha: quem envia o quê, a partir de onde, e o que não pode falhar. Só depois publicamos os registos, e fazemo-lo aos poucos, com os relatórios lidos e expectativas claras sobre o que cada fase protege. Saltar diretamente para p=reject parece mais seguro, mas é muitas vezes a forma mais rápida de bloquear as próprias faturas.

Também dizemos com franqueza o que estes protocolos não fazem. Protegem o seu domínio de ser usado por terceiros, mas não substituem uma boa configuração da caixa de correio, a autenticação multifator nem a formação da equipa. É esta visão de conjunto que separa uma correção pontual de uma solução que se mantém.

— Luis

Quando faz sentido pedir ajuda

Se tem um único domínio e usa apenas uma caixa de correio, a configuração base está ao alcance de quem tem acesso ao DNS. Quando há vários serviços a enviar, subdomínios, gateways de segurança ou uma migração em curso, o risco de bloquear email legítimo sobe bastante.

Na TechLead tratamos de Microsoft 365 e segurança de email para empresas e profissionais: levantamento dos fluxos de envio, publicação de SPF, DKIM e DMARC, testes com mensagens reais, leitura dos relatórios e passagem gradual para uma política rigorosa. Cada caso começa com uma análise do contexto antes de qualquer proposta. Se quer perceber em que ponto está o seu domínio, fale connosco.

Perguntas frequentes

Preciso dos três protocolos ou basta o SPF?

Precisa dos três. O SPF verifica apenas o domínio do envelope, que o destinatário não vê, por isso não impede a falsificação do campo "De". É o DMARC que liga a autenticação ao endereço visível, e o DMARC depende de o SPF ou o DKIM passarem alinhados.

Configurar o DMARC pode bloquear os meus emails?

Com p=none, não: essa política apenas recolhe relatórios. O risco aparece com quarantine ou reject se ainda houver serviços legítimos por autenticar. É por isso que se começa em modo de observação e só se endurece a política depois de ler os relatórios.

Quanto tempo demora a propagação dos registos?

Depende do TTL configurado no DNS, normalmente de minutos a algumas horas. A parte longa do projeto é a observação: algumas semanas de relatórios para garantir que todos os remetentes legítimos passam antes de aplicar uma política rigorosa.

Como sei se o meu domínio já tem SPF, DKIM e DMARC?

Envie um email para uma conta Gmail ou Outlook, abra os cabeçalhos completos e procure a linha Authentication-Results. Vai ver o resultado de cada protocolo (pass, fail, none). Um none indica que o registo ou a assinatura não existem.

Posso ter mais do que um registo SPF?

Não. Dois registos SPF no mesmo domínio produzem um erro permanente (permerror) e anulam a verificação. Todos os serviços autorizados têm de estar num único registo TXT, sem ultrapassar as 10 consultas DNS.

Fontes

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7489: DMARC (versão anterior)
• NIST Technical Note 1945: Email Authentication Mechanisms
• BSI TR-03182: Email Authentication
• CNCS: Recomendação Técnica 01/2020
• Microsoft Learn: resolução de problemas de autenticação de email no Microsoft 365
• Microsoft Learn: configurar selos ARC fidedignos
• Google: diretrizes para remetentes de email
• Google Workspace: prevenir spoofing e spam com DMARC

Recomendações

• Microsoft 365 e Segurança de Email
• Migração Microsoft 365 para PME: Plano e Email

Written using BabyLoveGrowth's AI