Início › Guias

Como configurar SPF, DKIM e DMARC: registros, armadilhas e testes

Publicado em 2026-11-03 ／ Atualizado em 2026-11-03 ／ Por Yuki Nakazawa

Uma configuração de SPF, DKIM e DMARC deixou de ser opcional para quem envia e-mails do próprio domínio. Faça nesta ordem: publique um único registro SPF, ative a assinatura DKIM com uma chave de 2048 bits e depois publique um registro DMARC que comece em p=none com relatórios ativados. Aproveite para garantir que o endereço IP que envia seus e-mails tenha DNS reverso (PTR) correspondente.

Este guia serve para quem envia por hospedagem compartilhada, VPS próprio, Google Workspace, Microsoft 365 ou um serviço de e-mail em massa. Ele traz registros que você pode adaptar, os erros que mais quebram a autenticação e como confirmar que tudo funciona a partir do cabeçalho de uma mensagem real.

As informações abaixo foram conferidas nos RFCs e nas páginas oficiais do Google, do Yahoo e da Microsoft em novembro de 2026. Os requisitos dos provedores de e-mail mudam, então considere as páginas deles como a palavra final.

O que SPF, DKIM e DMARC comprovam e em que ordem configurar

O SPF (Sender Policy Framework) permite que um domínio liste, no DNS, quais servidores podem enviar e-mails em seu nome. O servidor de destino olha o remetente do envelope (o endereço SMTP MAIL FROM, que depois aparece como Return-Path), busca o registro SPF desse domínio e verifica se o endereço IP que está se conectando consta da lista. Sozinho, o SPF não diz nada sobre o endereço From que o leitor vê.

O DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada mensagem. O sistema de envio assina com uma chave privada, e os destinatários verificam a assinatura com uma chave pública publicada no DNS. Uma assinatura válida comprova que o domínio signatário (o valor d=) assumiu a responsabilidade pela mensagem e que os cabeçalhos assinados e o corpo não foram alterados no caminho.

O DMARC (Domain-based Message Authentication, Reporting and Conformance) liga os dois ao domínio From visível. Uma mensagem só passa no DMARC quando o SPF ou o DKIM passa e o domínio autenticado está alinhado com o domínio From. O registro DMARC também informa aos destinatários o que você quer que seja feito com as falhas (nada, quarentena ou rejeição) e para onde enviar os relatórios agregados, que é como você descobre fontes de envio que tinha esquecido.

Ordem de configuração

1. Liste todos os sistemas que enviam e-mails em nome do seu domínio: seu próprio servidor, Google Workspace ou Microsoft 365, serviços de newsletter e de e-mail transacional, formulários do site, ferramentas de faturamento e de help desk.
2. Publique um único registro SPF que cubra todos eles.
3. Ative o DKIM em cada sistema de envio e publique a chave pública correspondente.
4. Publique o DMARC com p=none e um endereço de relatórios rua. O Google sugere esperar 48 horas depois de configurar SPF e DKIM antes de adicionar o DMARC.
5. Leia os relatórios, corrija as fontes que falham, passe para p=quarantine e, por fim, para p=reject.

Configuração do SPF: um registro, dez consultas

O SPF é um registro TXT no próprio domínio. Veja um domínio que envia do próprio servidor por IPv4 e IPv6 e também usa o Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

Na maioria dos painéis de DNS, você deixa o campo de host vazio (ou digita @), escolhe TXT e cola o valor a partir de v=spf1. Peças comuns:

Armadilhas do SPF

• Um registro SPF por nome. O RFC 7208 proíbe vários registros SPF para o mesmo domínio; os destinatários retornam permerror e o SPF falha para tudo. Ao adicionar um serviço, edite o registro existente e acrescente o include: dele em vez de criar um segundo registro v=spf1.
• O limite de 10 consultas. Os mecanismos include, a, mx, ptr e exists e o modificador redirect disparam consultas DNS, e o total em toda a avaliação, incluindo as consultas dentro de includes aninhados, não pode passar de 10. Ultrapassar resulta em permerror. ip4:, ip6: e all não custam nada. O RFC 7208 também diz que os destinatários devem parar após duas consultas sem resposta, então remova os includes de serviços que você não usa mais.
• ~all ou -all. -all significa que as fontes não listadas não estão autorizadas (fail); ~all significa que provavelmente não estão autorizadas (softfail). O Google recomenda ~all para domínios do Workspace; a Microsoft recomenda -all para domínios do Microsoft 365 que também usam DKIM e DMARC. Se você ainda não tem certeza de ter encontrado todos os remetentes, comece com ~all e deixe a aplicação a cargo do DMARC.
• Subdomínios precisam de registro próprio. O registro SPF de example.com não cobre news.example.com. Colocar um serviço de e-mail em massa em um subdomínio próprio também dá a ele uma cota separada de 10 consultas e mantém a reputação dele separada dos e-mails da equipe.
• Erros de sintaxe. A Microsoft lista os mais comuns: include= em vez de include:, um espaço depois dos dois-pontos e um ponto final depois do domínio incluído.

Para domínios que nunca enviam e-mails, publique v=spf1 -all para dificultar a falsificação.

Configuração do DKIM: chaves de 2048 bits e seletores

O DKIM tem duas metades: o sistema de envio assina com uma chave privada, e o DNS publica a chave pública correspondente. No Google Workspace, no Microsoft 365, na maioria dos painéis de hospedagem e na maioria dos serviços de e-mail, você gera a chave no console de administração e copia o valor DNS exibido.

Tamanho da chave e seletores

Use uma chave RSA de 2048 bits. O RFC 8301 define 1024 bits como mínimo e diz que os signatários devem usar pelo menos 2048 bits; ele também proíbe o rsa-sha1. A orientação do Google é a mesma: escolha 2048 bits se o seu provedor de DNS suportar e recorra a 1024 apenas se não suportar.

O seletor é um rótulo que identifica qual chave assinou a mensagem, de modo que um domínio pode ter várias chaves ao mesmo tempo, uma por serviço de envio ou uma por período de rotação. A chave pública fica em selector._domainkey.yourdomain. O Google Workspace usa google como seletor padrão. O Microsoft 365 usa dois registros CNAME, selector1._domainkey e selector2._domainkey, que apontam para chaves hospedadas pela Microsoft; copie os destinos exatos do portal do Defender ou do Get-DkimSigningConfig, porque o formato varia conforme o locatário (tenant).

Publicar uma chave pública longa

Uma chave pública de 2048 bits é maior que os 255 caracteres permitidos em uma única character-string do DNS; por isso, no formato de arquivo de zona, ela é escrita como várias strings entre aspas em um único registro TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Substitua as partes entre parênteses pela sua chave real. Os destinatários juntam as strings sem espaços entre elas, então você pode dividir em qualquer ponto da chave. Muitos painéis dividem valores longos automaticamente: cole primeiro o valor inteiro e só divida por conta própria se o painel recusar. Garanta que nada se perca na cópia; um p= vazio significa que a chave foi revogada.

Em um VPS próprio com Postfix ou um MTA semelhante, um milter de assinatura como o OpenDKIM pode criar o par de chaves, por exemplo opendkim-genkey -b 2048 -s selector1 -d example.com. Publique o conteúdo do arquivo de chave pública gerado como mostrado acima.

Confirme que as mensagens estão mesmo assinadas

Abra uma mensagem que você enviou e procure um cabeçalho DKIM-Signature:. A tag d= deve ser o seu domínio, e s= o seletor que você publicou. Muitos serviços de e-mail assinam com o próprio domínio por padrão; isso passa no DKIM, mas não se alinha com o seu domínio From e, portanto, não ajuda no DMARC. Ative a autenticação de domínio personalizado do serviço para que o d= passe a ser o seu domínio.

Configuração do DMARC: comece em p=none e depois aplique

O DMARC é um registro TXT em _dmarc sob o seu domínio. Comece no modo de monitoramento, que pede aos destinatários que não mudem a forma como tratam seus e-mails, e solicite relatórios agregados:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Os relatórios agregados são resumos legíveis por máquina que mostram quais endereços IP enviaram e-mails em nome do seu domínio e se passaram; o Google sugere uma caixa de correio ou um grupo dedicado para recebê-los. Quando os relatórios mostrarem que todas as fontes legítimas passam com alinhamento, endureça a política editando o mesmo registro, em vez de adicionar um segundo:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alinhamento, em termos simples

Para passar no DMARC, pelo menos um entre SPF e DKIM precisa passar para um domínio que corresponda ao domínio From. No modo relaxado, os domínios organizacionais precisam coincidir, então uma assinatura DKIM com d=example.com se alinha com e-mails de alerts@news.example.com. O modo estrito exige correspondência exata. Serviços de e-mail costumam usar o próprio domínio no Return-Path, então o SPF não se alinha mesmo quando passa; o DKIM alinhado é a forma prática de fazer essas mensagens passarem no DMARC.

Se quiser uma política diferente para os subdomínios, adicione sp=. Por exemplo, p=reject; sp=quarantine rejeita os e-mails com falha do domínio principal e apenas coloca em quarentena as falhas dos subdomínios.

Uma observação sobre o padrão atualizado

Em maio de 2026, o DMARC foi republicado como RFC 9989, que torna obsoleto o RFC 7489. Os registros existentes continuam funcionando e ainda começam com v=DMARC1. O novo padrão elimina a tag pct, que raramente era aplicada com precisão, exceto em 0 ou 100, e adiciona tags como t=y (modo de teste) e np (política para subdomínios inexistentes). Algumas páginas de ajuda de provedores ainda mostram pct, então a forma menos ambígua de implantar a aplicação é avançar pelos valores de p=.

DNS reverso (PTR) para o seu IP de envio

O DNS reverso associa um endereço IP de volta a um nome de host. O Google exige que todos os remetentes para contas pessoais do Gmail tenham um registro PTR cujo nome de host resolva de volta para o mesmo IP de envio, e o Yahoo exige DNS direto e reverso válidos para os IPs de envio e recomenda um registro PTR significativo, não genérico.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

O registro PTR não fica na zona do seu domínio. Quem controla é o dono do endereço IP; por isso, em um VPS, você o configura no painel do provedor (muitas vezes chamado de DNS reverso ou rDNS) e depois cria um registro A correspondente (AAAA para IPv6) no seu próprio DNS. Se você envia por IPv6, o endereço IPv6 precisa do mesmo tratamento. No Google Workspace, no Microsoft 365, em serviços de e-mail e na maioria das hospedagens compartilhadas, o provedor gerencia os IPs de envio e o DNS reverso deles por você.

Como verificar a configuração

Leia o Authentication-Results

Envie uma mensagem de teste para uma caixa de correio externa e veja os cabeçalhos completos. No Gmail, abra a mensagem e escolha Mostrar original. A ajuda do Google sobre DKIM recomenda enviar para outro usuário, e não para você mesmo. Procure um cabeçalho como este:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

O formato exato varia conforme o destinatário. O que importa é spf=pass, dkim=pass e dmarc=pass, com o seu próprio domínio em header.i ou header.d e em header.from. Se o SPF passa para o domínio de um serviço, mas o DKIM mostra outro domínio, o DMARC vai falhar: corrija primeiro o alinhamento do DKIM.

Consulte o DNS diretamente

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

No Windows, nslookup -type=TXT _dmarc.example.com faz o mesmo trabalho. Alterações de DNS podem levar algum tempo para se propagar; o Google diz que SPF e DKIM podem levar até 48 horas cada um para começar a funcionar. Verificadores on-line gratuitos também conseguem analisar seus registros e contar as consultas do SPF por você.

Se a autenticação passa e os e-mails ainda voltam ou caem no spam, verifique se o seu IP ou domínio de envio está listado em alguma DNSBL com o nosso verificador de blacklist, e veja e-mail não entregue por causa de uma blacklist para os próximos passos.

Requisitos para remetentes do Gmail, Yahoo e Outlook.com

Os grandes provedores de e-mail agora exigem autenticação. Em novembro de 2026, as páginas oficiais deles dizem o seguinte.

• Gmail (em vigor desde 1 de fevereiro de 2024): todos que enviam para contas pessoais do Gmail precisam de SPF ou DKIM, DNS direto e reverso correspondentes, conexão TLS e taxa de spam abaixo de 0,3% no Postmaster Tools. Quem envia mais de 5.000 mensagens por dia também precisa de SPF e DKIM, um registro DMARC (p=none é aceito), um domínio From alinhado com o SPF ou o DKIM e cancelamento de inscrição com um clique para e-mails de marketing. As chaves DKIM devem ter pelo menos 1024 bits, sendo 2048 o recomendado.
• Yahoo (aplicação a partir de fevereiro de 2024): todos os remetentes precisam de SPF ou DKIM, DNS direto e reverso válidos e taxa de spam abaixo de 0,3%. Remetentes em massa precisam de SPF e DKIM, uma política DMARC de pelo menos p=none que passe, alinhamento do From (o relaxado basta), cancelamento de inscrição com um clique funcionando e DNS direto e reverso válidos para os IPs de envio.
• Outlook.com (o serviço para consumidores por trás de outlook.com, hotmail.com e live.com): domínios que enviam mais de 5.000 e-mails por dia devem passar no SPF e no DKIM e publicar um DMARC de pelo menos p=none, alinhado com o SPF ou o DKIM. A Microsoft informou que, a partir de 5 de maio de 2025, as mensagens fora de conformidade seriam rejeitadas com o erro 550; 5.7.515.

Leia o texto completo nas diretrizes do Google para remetentes de e-mail, nas boas práticas para remetentes do Yahoo e no anúncio da Microsoft sobre o Outlook.com. Mesmo que você envie bem menos mensagens, configurar os três agora evita surpresas se o limite for reduzido no futuro. Para problemas específicos do Gmail, veja Gmail não entrega seus e-mails.

Erros comuns

• Um segundo registro SPF. Adicionar um novo registro v=spf1 para cada serviço invalida o SPF do domínio inteiro. Junte tudo em um só.
• Includes demais. Serviços antigos esquecidos no SPF consomem a cota de 10 consultas. Remova o que você não usa mais e mova os envios em massa para um subdomínio.
• Chave publicada, assinatura não ativada. No Google Workspace, você ainda precisa clicar em Iniciar autenticação depois que o registro DNS estiver no ar; outras plataformas têm uma opção parecida.
• O serviço assina com o próprio domínio. SPF e DKIM passam, o DMARC falha. Ative a assinatura com domínio personalizado.
• Pular direto para p=reject. Um formulário do site ou um sistema de faturamento esquecido para de entregar da noite para o dia. Comece em p=none e leia os relatórios.
• Estragos de copiar e colar. Aspas a mais dentro do valor, uma chave truncada ou um nome de host que vira _dmarc.example.com.example.com porque o painel acrescenta o domínio automaticamente. Um dig rápido detecta todos esses problemas.

Perguntas frequentes

Páginas oficiais consultadas

As informações deste artigo foram conferidas nas páginas oficiais abaixo na data da publicação. Políticas e procedimentos mudam sem aviso prévio; consulte as páginas oficiais antes de tomar qualquer decisão importante.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Guias relacionados

Todos os guias →