Como configurar SPF, DKIM e DMARC para e-mail corporativo

Configurar SPF, DKIM e DMARC é hoje uma das primeiras tarefas de qualquer empresa que usa e-mail corporativo com domínio próprio. Sem esses três registros no DNS, as mensagens da empresa correm o risco de cair no spam ou de nem chegar ao destinatário. Além disso, qualquer pessoa consegue enviar e-mails fingindo ser o seu domínio.

O tema deixou de ser assunto exclusivo de especialistas. Gmail, Yahoo e Outlook passaram a exigir autenticação de e-mail, e mesmo assim apenas 52,1% dos domínios mais visitados do mundo tinham uma política DMARC válida no início de 2026, segundo o relatório anual da EasyDMARC.

Neste guia, explicamos em linguagem simples o que cada protocolo faz, mostramos a configuração passo a passo para Google Workspace, Microsoft 365 e servidor próprio, contamos o que mudou no padrão DMARC em 2026 e reunimos os erros mais comuns com as respectivas soluções.

Por que o e-mail corporativo precisa de autenticação em 2026?

O que Gmail, Yahoo e Outlook fazem com mensagens sem SPF, DKIM e DMARC

Os grandes provedores endureceram as regras em etapas. Google e Yahoo começaram a aplicar exigências obrigatórias em fevereiro de 2024, e a Microsoft seguiu o mesmo caminho em maio de 2025. Hoje o quadro é este:

• Todos os remetentes. O Google exige pelo menos SPF ou DKIM, e o Yahoo exige os dois, mesmo para quem envia poucas mensagens por dia.
• Remetentes em massa, a partir de cerca de 5 mil e-mails por dia. Precisam de SPF, DKIM e DMARC ao mesmo tempo, taxa de reclamações abaixo de 0,3% e descadastro em um clique.
• Desde maio de 2025, mensagens em massa de domínios fora das regras são recusadas com o código de erro 550 5.7.515.

Na prática, um domínio sem autenticação perde entregabilidade. A mensagem pode ir para o spam ou ser recusada ainda na conexão SMTP e voltar ao remetente como erro.

Por que empresas brasileiras são alvo frequente de falsificação de remetente

O Brasil aparece de forma constante nas estatísticas de fraude digital. Dados da Kaspersky apresentados em 2025 apontaram 553 milhões de ataques de phishing no país em um período de doze meses, e levantamentos de mercado baseados nos números da mesma empresa colocam o Brasil como responsável por cerca de 62% do phishing registrado na América Latina.

O próprio governo federal reconhece o problema. Na Recomendação 17/2023, o CTIR Gov solicita aos órgãos da Administração Pública Federal e orienta as demais instituições a implementar SPF, DKIM e DMARC para proteger o e-mail organizacional contra spoofing, spam e phishing.

Há também o contexto da LGPD. A lei pede medidas técnicas de segurança adequadas para proteger dados pessoais, e a autenticação de e-mail é uma dessas camadas: ela dificulta golpes que usam o nome da empresa para enganar clientes e colaboradores.

Como SPF, DKIM e DMARC dividem o trabalho de verificar um e-mail?

Os três protocolos funcionam como verificações independentes. Cada um responde a uma pergunta diferente sobre a mensagem, e só a combinação deles dá ao servidor destinatário um quadro completo.

SPF: a lista de servidores autorizados a enviar pelo domínio

O SPF (Sender Policy Framework) funciona como a lista de convidados na portaria de um prédio. É um registro TXT publicado no DNS do domínio com os servidores e endereços IP que podem enviar mensagens em nome dele.

Quando um e-mail chega, o servidor destinatário compara o IP de origem com essa lista. Um detalhe importante: o SPF verifica o endereço técnico do envelope da mensagem (Return-Path), que o usuário comum normalmente nem vê.

DKIM: a assinatura que prova que a mensagem não foi alterada

O DKIM (DomainKeys Identified Mail) é parecido com um lacre em um envelope. O servidor de envio guarda uma chave privada e usa essa chave para assinar cada mensagem. A chave pública correspondente fica no DNS, em um registro com nome no formato seletor._domainkey.seudominio.

O destinatário busca a chave pública e confere a assinatura. Se alguém alterar o texto ou os cabeçalhos no caminho, a verificação falha. O seletor permite ter várias chaves no mesmo domínio, por exemplo uma para o e-mail corporativo e outra para a plataforma de marketing.

DMARC: o alinhamento com o remetente que o destinatário vê

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é o elo entre os dois. Ele verifica se o domínio aprovado no SPF ou no DKIM coincide com o domínio do campo “De” que aparece para o destinatário. Essa coincidência se chama alinhamento, e basta um dos dois protocolos passar com alinhamento para o DMARC aprovar a mensagem.

Além disso, o DMARC define o que fazer com as falhas por meio de três políticas:

• none: apenas monitorar e receber relatórios;
• quarantine: enviar mensagens suspeitas para o spam;
• reject: recusar a mensagem.

Os destinatários também enviam relatórios agregados ao dono do domínio, que mostram quem está enviando e-mails em nome dele.

O que levantar antes de alterar os registros DNS?

O erro mais caro nessa configuração é publicar uma política rígida sem saber quem envia e-mails em nome da empresa. Antes de mexer no DNS, vale fazer um inventário dos remetentes:

• serviço principal de e-mail corporativo (Google Workspace, Microsoft 365 ou servidor próprio);
• ERP, sistema financeiro ou plataforma de cobrança que envia boletos, notas fiscais e lembretes de pagamento;
• ferramentas de e-mail marketing e CRM;
• formulários do site, sistemas de atendimento e notificações automáticas de aplicativos.

Depois, confirme onde está a zona DNS do domínio. Para domínios .br que usam o DNS do Registro.br, é preciso ativar o modo avançado; segundo a Locaweb, a mudança leva de 2 a 5 horas antes de permitir a inclusão de registros TXT. Se a infraestrutura já roda na nuvem, a zona também pode ficar na Hospedagem de DNS da Serverspace, gratuita e gerenciada no mesmo painel dos servidores.

Uma dica prática: reduza o TTL dos registros para cerca de 300 segundos um dia antes das alterações. Assim, correções eventuais se propagam mais rápido.

Como configurar SPF, DKIM e DMARC na prática, passo a passo?

Nos exemplos a seguir usamos o domínio fictício example.com.br. Substitua pelos dados reais da sua empresa e dos seus serviços de envio.

Passo 1. Como criar um registro SPF sem estourar o limite de 10 consultas

Um registro SPF típico para uma empresa que usa Google Workspace e mais um servidor próprio fica assim:

Para o Microsoft 365, o trecho correspondente é include:spf.protection.outlook.com. Na criação do registro SPF, quatro regras evitam a maioria dos problemas:

• Um único registro por domínio. Dois registros que começam com v=spf1 geram erro permanente (PermError), e o SPF deixa de funcionar. Cada novo serviço entra no mesmo registro.
• Limite de 10 consultas DNS. Os mecanismos include, a, mx, ptr, exists e o modificador redirect contam no limite; ip4, ip6 e all não contam. Cada include pode esconder outros includes internos, por isso o total cresce rápido.
• Limite de 2 consultas vazias. Um include que aponta para um domínio sem resposta também gera PermError.
• Final ~all ou -all. Com ~all (softfail), servidores fora da lista são marcados como suspeitos; com -all (fail), o destinatário é orientado a recusar. Começar com ~all e passar para -all depois de confirmar o inventário é o caminho mais seguro.

Passo 2. Como configurar DKIM no Google Workspace, no Microsoft 365 e em servidor próprio

Google Workspace

1. No Admin console, abra Apps → Google Workspace → Gmail → Autenticar e-mail.
2. Gere um novo registro com chave de 2048 bits.
3. Publique no DNS o registro TXT com nome google._domainkey.
4. Volte ao console e clique em Iniciar autenticação.

O Google não ativa o DKIM automaticamente para domínio próprio, e esquecer esse último clique é uma das falhas mais comuns na prática.

Microsoft 365

• Publique dois registros CNAME, selector1._domainkey e selector2._domainkey, com os valores exibidos no portal Microsoft Defender.
• Ative o DKIM para o domínio nas configurações de autenticação de e-mail.
• Mantenha os dois registros sempre publicados. A Microsoft alterna entre eles na rotação de chaves, e com apenas o selector1 o DKIM para de funcionar na primeira troca.

Atenção a uma armadilha: sem DKIM configurado no domínio próprio, o Microsoft 365 assina as mensagens com o domínio onmicrosoft.com. A assinatura é válida, porém não está alinhada com o domínio da empresa, e o DMARC reprova a mensagem.

Servidor próprio

Em servidores com Postfix, o DKIM costuma ser configurado com o OpenDKIM. O par de chaves é gerado com um comando como:

opendkim-genkey -b 2048 -s mail2026 -d example.com.br

A chave pública vai para o DNS em um registro TXT com nome mail2026._domainkey, e a chave privada fica no servidor com acesso restrito (permissão 600). Use sempre 2048 bits: é o tamanho recomendado pela RFC 8301, e o Yahoo recusa assinaturas com chaves antigas de 512 bits.

Passo 3. Como publicar a política DMARC começando pelo monitoramento

O registro DMARC inicial fica assim:

O que significa cada parte:

• p: política principal. Começamos com none, apenas monitoramento.
• rua: endereço que recebe os relatórios agregados em XML. Use uma caixa dedicada ou um serviço de análise, porque o volume cresce rápido.
• sp: política opcional para subdomínios existentes.
• np: política para subdomínios que não existem. Com np=reject, ninguém consegue enviar golpes a partir de endereços inventados, como financeiro.example.com.br.
• adkim e aspf: modo de alinhamento, relaxado (r, padrão) ou estrito (s).

Passo 4. Como conferir se as três verificações passaram

A forma mais simples de testar é enviar uma mensagem para uma conta do Gmail, abrir o menu da mensagem e escolher Mostrar original. No cabeçalho Authentication-Results devem aparecer spf=pass, dkim=pass e dmarc=pass, e o domínio indicado no DKIM (parâmetro d=) deve ser o da empresa.

Pelo terminal, os registros publicados podem ser consultados assim:

Se o resultado vier vazio logo após a alteração, aguarde a propagação do DNS e repita a consulta.

O que mudou no DMARC em 2026 com o novo padrão RFC 9989?

Em 19 de maio de 2026, a IETF publicou a nova versão do DMARC, conhecida durante anos como DMARCbis, em três documentos: RFC 9989 (protocolo), RFC 9990 (relatórios agregados) e RFC 9991 (relatórios de falha). Eles substituem a RFC 7489, de 2015, e colocam o DMARC oficialmente na trilha de padrões da IETF.

Para quem já usa DMARC, nada quebra: os registros continuam começando com v=DMARC1. As mudanças práticas são estas:

• Nova tag np, que define a política para subdomínios inexistentes e fecha uma brecha antiga de falsificação.
• Nova tag t, um modo de teste. Com t=y, o destinatário aplica a política um degrau abaixo da publicada: quarantine passa a valer como none.
• Tags removidas: pct, rf e ri. Os destinatários devem ignorá-las, mas vale retirá-las para manter o registro limpo.
• Nova forma de identificar o domínio da organização, feita por consulta direta ao DNS em vez da lista pública de sufixos (Public Suffix List).

A retirada da tag pct tem uma explicação prática. Segundo dados da DMARCeye do primeiro trimestre de 2026, cerca de 94% dos domínios com política quarantine já tinham a tag ignorada pelos destinatários, que aplicavam a política integral desde o primeiro dia.

Como sair do p=none e chegar ao p=reject sem bloquear e-mails legítimos?

A política none serve para aprender, e seu papel acaba quando o inventário de remetentes está completo. Mantê-la por anos sem análise passa a ser visto pelos provedores como sinal negativo de confiança. Uma rota segura para a política DMARC tem quatro etapas:

1. Monitoramento (p=none). Durante algumas semanas, analise os relatórios, identifique todos os serviços que enviam em nome do domínio e corrija os que falham no SPF ou no DKIM.
2. Quarentena em teste (p=quarantine; t=y). Os destinatários ainda tratam as falhas como none, e você confere nos relatórios se nada legítimo seria afetado.
3. Quarentena real (p=quarantine). Mensagens reprovadas vão para o spam. Acompanhe reclamações da equipe e dos clientes.
4. Rejeição (p=reject). Mensagens falsificadas passam a ser recusadas.

Depois de chegar ao reject, crie uma regra interna simples: qualquer serviço novo, como uma plataforma de marketing ou um ERP, precisa ter SPF e DKIM configurados antes de enviar o primeiro e-mail. Caso contrário, mensagens legítimas serão recusadas.

Em quais situações a autenticação de e-mail resolve problemas reais?

Pequena empresa no Google Workspace ou no Microsoft 365

É o cenário mais comum. Três registros no DNS e um clique no painel do provedor resolvem a maior parte dos casos de e-mail indo para spam e impedem que golpistas usem o domínio da empresa.

ERP que envia boletos, cobranças e notas fiscais

Faturas e lembretes de pagamento costumam ser enviados pelo ERP com o domínio da empresa no campo “De”, porém a partir dos servidores do fornecedor. Se esse serviço não estiver no SPF e não tiver DKIM próprio, os boletos caem no spam, e a empresa só percebe quando os pagamentos atrasam.

Plataformas de e-mail marketing com domínio próprio

Plataformas de envio em massa oferecem autenticação de domínio personalizado. Sem essa etapa, a assinatura DKIM sai com o domínio da plataforma, o alinhamento quebra e as campanhas perdem entregabilidade.

Servidor de e-mail próprio em VPS

Empresas que precisam de controle total sobre a caixa postal, regras de arquivamento ou integrações próprias montam um servidor de e-mail em VPS com Postfix, Dovecot e OpenDKIM. Nesse caso, além dos três registros, é preciso IP fixo com boa reputação, registro PTR (DNS reverso) e porta 25 liberada para a comunicação entre servidores.

No Brasil, a porta 25 foi bloqueada para envio a partir de conexões domésticas em 2013, por isso servidores de e-mail ficam em data center. Um servidor VPS da Serverspace no data center de São Paulo atende a esse cenário com baixa latência para usuários brasileiros. Para comparar modelos de e-mail antes de decidir, vale ler nosso artigo sobre hospedagem de e-mail ou servidor de e-mail corporativo.

Domínios que não enviam e-mail

Domínios de campanhas, marcas registradas e endereços antigos também podem ser usados por golpistas. A proteção é simples: SPF com v=spf1 -all e DMARC com p=reject, que declaram que nenhuma mensagem legítima sai desse domínio.

O que SPF, DKIM e DMARC não conseguem impedir?

Os ganhos da autenticação de e-mail são claros:

• proteção da marca contra falsificação do domínio exato da empresa;
• melhor entregabilidade nos grandes provedores;
• visibilidade sobre quem envia mensagens em nome do domínio, graças aos relatórios.

Os protocolos também têm limites que precisam ficar claros para a equipe:

• Caixa invadida. Em setembro de 2026, o governo federal alertou para mensagens enviadas a partir de caixas .gov.br comprometidas que passavam nas verificações de SPF, DKIM e DMARC. Se o invasor usa uma conta real, a autenticação confirma apenas que o e-mail saiu do servidor correto.
• Domínios parecidos. Um golpista pode registrar exemplo-br.com e enviar mensagens autenticadas desse endereço. Os protocolos protegem somente o seu domínio exato.
• O SPF costuma falhar quando a mensagem é reencaminhada, porque o IP do servidor intermediário não está na lista. O DKIM sobrevive se o conteúdo não for alterado, por isso é arriscado depender apenas do SPF.

Por isso, a autenticação funciona melhor ao lado de autenticação multifator nas contas, filtros de e-mail e treinamento da equipe contra phishing.

Quais erros mais quebram a autenticação e como corrigi-los?

A maior parte dos problemas nasce de pequenos detalhes no DNS ou de um serviço esquecido no inventário. Reunimos os casos mais frequentes na tabela abaixo.

Antes de publicar qualquer alteração, confira o registro em um validador de SPF, DKIM e DMARC. Um espaço a mais ou uma aspa fora do lugar bastam para invalidar a configuração inteira.

Conclusão: por onde começar ainda esta semana

SPF indica quem pode enviar, DKIM prova que a mensagem não foi alterada e DMARC liga os dois ao remetente que o destinatário vê. Sem os três, o e-mail corporativo perde entregabilidade e fica exposto a golpes com o nome da empresa.

Para começar, siga esta ordem:

1. Liste todos os serviços que enviam e-mails em nome do domínio.
2. Publique um único registro SPF com todos eles, dentro do limite de 10 consultas.
3. Ative o DKIM com chave de 2048 bits no provedor principal e em cada serviço extra.
4. Publique o DMARC com p=none e np=reject e avance até o reject com base nos relatórios.

Se a empresa pretende manter o próprio servidor de e-mail ou centralizar DNS e infraestrutura em um só lugar, a Serverspace oferece VPS no Brasil e hospedagem de DNS gratuita no mesmo painel, o que simplifica a configuração dos três registros