Autenticação de e-mail: SPF, DKIM e DMARC

A autenticação de e-mail é a prova de identidade das suas mensagens: a forma como você demonstra a Gmail, Outlook ou Yahoo que o correio que diz vir do seu domínio vem de verdade de você. Durante anos foi uma boa prática recomendável; hoje é um requisito de entrada. Sem SPF, DKIM e DMARC bem configurados e alinhados, o seu correio não compete em igualdade de condições, e desde o fim de 2025 ele nem sequer se adia com um erro temporário: é rejeitado de plano. Esta página explica o que cada peça faz, onde está a falha que afeta quase todos — o alinhamento — e como levamos você até uma autenticação completa sem que um único correio legítimo fique pelo caminho.

O que cada registro de autenticação prova?

Três registros formam o núcleo, e cada um responde uma pergunta distinta. O SPF (Sender Policy Framework) declara, no seu DNS, quais servidores e IPs estão autorizados a enviar correio em nome do seu domínio; o receptor o consulta como uma lista de convidados. O DKIM (DomainKeys Identified Mail) adiciona a cada mensagem uma assinatura criptográfica que o receptor verifica com uma chave pública publicada no seu DNS, demonstrando que o correio saiu do seu domínio e não se alterou pelo caminho. E o DMARC (Domain-based Message Authentication) amarra os dois anteriores: define o que o receptor deve fazer se as verificações falham e, sobretudo, exige que estejam alinhadas com o domínio que o destinatário vê. Por cima dos três, o BIMI permite mostrar o seu logo verificado na caixa quando todo o resto está em ordem.

Por que um registro nunca basta?

É tentador pensar que com o SPF você já está coberto, mas cada registro tapa um vão que os outros deixam. O SPF autoriza servidores, mas não protege o conteúdo nem sobrevive bem aos reencaminhamentos. O DKIM garante integridade e origem, mas por si só não diz ao receptor o que fazer quando algo não bate. O DMARC põe as regras e exige alinhamento, mas não pode funcionar se não houver SPF ou DKIM para validar por baixo. Só juntos contam uma história completa: este correio vem de quem diz, não foi tocado, e aqui está a política para quando alguém tentar falsificá-lo. Por isso as grandes caixas pedem os três aos remetentes de volume, e por isso configurar um e esquecer os demais deixa uma porta que os filtros detectam logo.

SPF em detalhe: o limite das dez consultas

O SPF parece simples e esconde uma armadilha que derruba muitas configurações: o limite de dez consultas DNS. Cada «include» que você adiciona — o seu ESP, o seu CRM, a sua passarela de faturamento — consome consultas, e ao passar de dez o registro deixa de ser avaliado e começa a falhar, ainda que à primeira vista pareça correto. A solução passa por manter o registro limpo: consolidar fontes, eliminar as que você já não usa e, quando faz falta, achatar o registro para que caiba sob o limite. Também importa como você o fecha: um «-all» rejeita de forma explícita o não autorizado, enquanto um «~all» o marca como suspeito sem bloqueá-lo. Revisar o SPF vai além de conferir que ele existe: é preciso ver que avalia bem, contar as suas consultas e olhar como fecha. É um dos pontos onde uma ferramenta sem critério dá a você um «verde» enganoso.

DKIM em detalhe: chaves, seletores e rotação

O DKIM tem mais peças móveis do que parece. Cada fonte assina com um «seletor» — um nome que aponta para a sua chave pública no seu DNS —, o que permite que distintos serviços assinem com o seu domínio sem se atropelar. A força da chave importa: 2048 bits é hoje o padrão sadio, e as chaves de 1024, ainda frequentes, se consideram fracas. E as chaves não são para sempre: convém rotacioná-las com certa regularidade, o que exige publicar a nova antes de retirar a velha para não cortar a assinatura. A falha mais cara, já vimos, é assinar com o domínio do provedor em vez do seu, que quebra o alinhamento sem quebrar a assinatura. Gerir o DKIM bem é levar o controle de que seletor cada fonte usa, com que chave e a partir de que domínio, algo que em uma operação com muitos serviços se desordena com facilidade.

O que o servidor receptor de fato verifica?

Entender a verificação ajuda a entender as falhas. Quando o seu correio chega, o receptor olha três coisas quase ao mesmo tempo. Verifica o SPF contra o domínio do envelope — o return-path —, conferindo se o IP que conecta está autorizado. Verifica a assinatura DKIM com a sua chave pública, confirmando que a mensagem é íntegra e procede do seu domínio. E aplica o DMARC: confere que ao menos uma das duas anteriores tenha passado e, além disso, que esteja alinhada com o domínio visível no campo «De». Se o DMARC passa, o correio segue o seu caminho com a sua reputação por trás; se falha, o receptor faz o que a sua política indicar. Esse cruzamento ocorre em milissegundos e decide o destino de cada mensagem.

O alinhamento, onde quase todos falham

Se há um conceito que separa uma autenticação que funciona de uma que só parece, é o alinhamento. Não basta que SPF ou DKIM «passem»: o domínio que passa tem que coincidir com o que o destinatário vê no «De». O caso clássico é o de um provedor externo — a sua plataforma de marketing, o seu CRM — que assina DKIM com o próprio domínio ou cujo return-path é dele: as verificações passam, mas contra o domínio do provedor em vez do seu, então o DMARC as trata como falha. O resultado é um correio que parece autenticado e ainda assim vai ao spam. A solução é configurar cada fonte para que assine com o seu domínio e use um return-path seu, e escolher bem entre alinhamento relaxado — que admite subdomínios — e estrito. É o ajuste que mais correios resgata, e o que mais se ignora. No Brasil isso tem um peso extra: o CAPEM, o código de autorregulação avalizado pelo CGI.br, exige que o envio se faça a partir de um domínio próprio, justo o que o alinhamento garante a nível técnico.

Alinhamento relaxado frente a estrito

O DMARC permite escolher quão exigente é o alinhamento, e a decisão tem consequências práticas. Em modo relaxado — o habitual —, basta que o domínio que passa SPF ou DKIM compartilhe o domínio organizacional com o «De»; assim, um correio enviado de um subdomínio como envios.seudominio.com segue alinhado com seudominio.com. Em modo estrito, os domínios devem coincidir de forma exata, e qualquer diferença de subdomínio quebra o alinhamento. O estrito protege melhor frente a certos abusos, mas é muito mais frágil com as arquiteturas que usam subdomínios, que são justo as recomendáveis. Escolher o modo correto por registro e por fonte é parte do trabalho fino: estrito demais e você bloqueia correio legítimo; relaxado demais e deixa margem ao abuso. A maioria das operações funciona melhor em relaxado, com uma arquitetura de subdomínios bem pensada por baixo.

Remetentes de terceiros: o ponto fraco

Quase nenhuma empresa envia todo o seu correio de um único lugar, e aí está o risco. A plataforma de marketing, o CRM, o sistema de tíquetes, a passarela de faturamento, a ferramenta de assinaturas: cada uma manda correio com o seu domínio, e cada uma tem que se autenticar e se alinhar por separado. É habitual que uma delas — a que um departamento configurou sem avisar ninguém — assine com o domínio do provedor ou não figure no SPF, e se torne o fluxo que quebra o seu DMARC. Por isso o inventário de fontes é o primeiro passo de qualquer projeto sério: você não pode alinhar o que não sabe que existe. Cada terceiro que envia em seu nome é uma peça que é preciso configurar com o seu domínio, não com o dele, e vigiar cada vez que muda. E não é só técnica: que o envio saia de um domínio próprio é também o que o CAPEM espera de um remetente correto no Brasil.

As armadilhas que impedem passar

Alguns erros se repetem em quase todas as configurações que revisamos. O duplo registro SPF, que provoca um erro de validação e derruba a autenticação inteira. O SPF que supera as dez consultas DNS permitidas e deixa de ser avaliado corretamente. As chaves DKIM de 1024 bits, hoje fracas, quando o padrão sadio são 2048. A assinatura DKIM feita a partir do domínio do ESP em vez do seu, que quebra o alinhamento sem quebrar a assinatura. O «include» de SPF que faz o correio passar com o domínio de um terceiro. E o mais difundido de todos: deixar o DMARC em p=none «temporariamente» e esquecê-lo ali durante anos, monitorando sem nunca proteger. Nenhum é difícil de corrigir; o difícil é detectá-los sem ler os relatórios.

# SPF: está dentro do limite de 10 consultas?
$ dig +short TXT exemplo.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net include:mktomail.com ~all"
# 11 consultas entre os includes — acima do limite, o SPF devolve permerror

# DKIM: o seletor está vivo e a chave é de 2048 bits?
$ dig +short TXT sel1._domainkey.exemplo.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkq..."   # 2048 bits, resolve

# DMARC: aplica, ou está parado em p=none?
$ dig +short TXT _dmarc.exemplo.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
# p=none: só monitora — um falsificador ainda passa como o seu domínio

Como o DMARC passa da monitoração ao enforcement?

O DMARC se implanta por etapas, e cada uma tem a sua função. Você começa em p=none, que não bloqueia nada e só observa: você recolhe relatórios para ver quem envia com o seu domínio, legítimo ou não. Quando autenticou todas as suas fontes reais, sobe para p=quarantine, que manda ao spam o que falhe, e por fim para p=reject, que o rejeita de plano com um erro 550 e fecha a porta à falsificação. A opção pct= permite aplicar a política só a uma porcentagem do tráfego para testar sem risco, e rua e ruf definem aonde chegam os relatórios. A regra de ouro é não pular etapas: cada salto se dá quando os dados confirmam que nenhum correio legítimo ficará de fora, não antes.

Ler os relatórios agregados

Os relatórios RUA são o mapa que torna segura a subida para rejeição, embora cheguem em um XML que não é pensado para se ler a olho. Neles aparece cada fonte que envia com o seu domínio, quantas mensagens manda e se passam SPF e DKIM alinhados. Essa visibilidade destapa duas coisas muito valiosas: as fontes legítimas que você tinha esquecido — aquele servidor que alguém configurou anos atrás, a ferramenta nova de um departamento — e as fontes maliciosas que tentam se passar por você. Interpretar esses relatórios é o que converte o DMARC de uma casinha marcada em uma defesa real: diz a você exatamente o que autenticar antes de endurecer a política, de modo que o salto para rejeição não deixe de fora o seu próprio faturamento nem os seus alertas.

ARC e os reencaminhamentos

Há um cenário que quebra o SPF sem que você faça nada errado: o reencaminhamento. Quando uma lista de correio ou uma caixa reencaminha a sua mensagem, o IP que a entrega muda, e o seu SPF — que autorizava o original — deixa de bater. O DKIM costuma sobreviver ao reencaminhamento porque viaja dentro da mensagem, razão a mais para se apoiar nele. Para os casos em que um intermediário modifica o correio, existe o ARC (Authenticated Received Chain), que preserva o resultado de autenticação original ao longo da cadeia de reencaminhamentos, de modo que o receptor final possa confiar nele. Nem todos os fluxos o precisam, mas conhecer como as suas mensagens se comportam ao serem reencaminhadas evita diagnósticos errados: uma «falha» de SPF após um reencaminhamento raramente é um problema seu para corrigir; muitas vezes é o funcionamento esperado, que DKIM e ARC compensam.

BIMI e o logo verificado

O BIMI é a recompensa visível de fazer bem tudo o anterior: mostra o logotipo verificado da sua marca junto aos seus correios na caixa de entrada. É uma cereja mais do que um ponto de partida, porque só se ativa quando o seu DMARC está em quarentena ou rejeição e todas as suas fontes legítimas estão autenticadas e alinhadas. Exige publicar um logo em formato SVG e, nos principais provedores, um certificado de marca verificada (VMC). A sua cobertura já alcança a maioria dos usuários de correio, e para uma marca com volume comercial o reconhecimento na caixa justifica o investimento. Mas a ordem importa: o BIMI sem uma autenticação sólida por baixo simplesmente não aparece, então nunca é o primeiro.

Autenticação defensiva para os domínios que você não usa

Há uma parte da autenticação ligada a proteger o que você não envia. Cada domínio e subdomínio que você possui mas não usa para enviar é uma oportunidade para um falsificador, que pode mandar correio em seu nome sem que ninguém note. A defesa é publicar nesses domínios um SPF que não autorize ninguém e uma política DMARC em rejeição, de modo que qualquer tentativa de usá-los se bloqueie. É uma medida barata e de alto retorno que quase ninguém aplica, e que fecha uma via de phishing contra a sua marca e os seus clientes. Revisar o inventário completo de domínios, não só o principal, é parte de fazer a autenticação bem.

O que muda a grande volume e com várias marcas?

Quando você cresce, a autenticação deixa de ser um único jogo de registros e se torna uma arquitetura. Os remetentes de volume separam os seus fluxos em subdomínios dedicados — um para marketing, outro para transacional, outro por marca ou por país —, cada um com o seu SPF, o seu DKIM e a sua política de DMARC, herdada ou própria. Essa separação não é burocracia: isola a reputação, de modo que um problema nas campanhas não arraste a entrega das faturas, e permite governar a autenticação sem que uma mudança em um fluxo quebre outro. Para uma empresa com várias marcas ou vários domínios, o desenho dessa hierarquia — o que pende de quê, que política aplica a cada nível — pesa tanto quanto os registros em si. Fazê-lo bem desde o começo poupa uma reorganização dolorosa mais adiante, quando o volume já não perdoa os experimentos.

Autenticação, conformidade e proteção de dados

A autenticação saiu do terreno da entregabilidade para entrar também no da conformidade e da segurança. Marcos de segurança de pagamentos como o PCI DSS, na sua versão mais recente, incorporam requisitos de autenticação de correio para as organizações que lidam com dados de cartões. No mercado lusófono, soma-se a isso a camada de proteção de dados e de autorregulação: a LGPD no Brasil, fiscalizada pela ANPD, e o RGPD em Portugal e na Europa fazem da proteção contra o phishing — que um DMARC em rejeição bloqueia — uma obrigação de cuidado com os dados das pessoas, e o CAPEM exige o envio a partir de um domínio próprio, que é exatamente o que uma autenticação alinhada garante. A tendência é clara: o que começou como uma boa prática de marketing é cada vez mais uma obrigação de segurança, porque um domínio sem DMARC em rejeição é uma ferramenta de phishing esperando para ser usada contra os seus clientes. Plantear a autenticação também como uma medida de segurança e de conformidade, além de entrega, ajuda a justificar o projeto diante de quem controla o orçamento e eleva a conversa acima do marketing.

O que mudou, e por que urge

A autenticação deixou de ser opcional em muito pouco tempo. Desde fevereiro de 2024, Gmail e Yahoo exigem SPF, DKIM e DMARC aos remetentes em massa; desde 5 de maio de 2025, a Microsoft pede o mesmo a quem envia mais de cinco mil correios diários a Outlook, Hotmail ou Live. E no fim de 2025 o Gmail deu o passo mais duro: passou de adiar o correio não conforme com erros temporários a rejeitá-lo de forma permanente, sem período de carência. A isso se soma um dado que surpreende os remetentes pequenos: a falta de autenticação pode afundar a colocação na caixa de forma drástica mesmo a baixo volume, porque os filtros usam os mesmos sinais para todos. Reunimos esses requisitos, lado a lado e com fontes, na nossa página de referências e dados.

Quatro mitos que deixam domínios expostos

Quatro crenças mantêm muitos domínios meio autenticados. A primeira, «sou pequeno, isto não é comigo»: os filtros não perguntam o seu tamanho, e a falta de autenticação penaliza você igual. A segunda, «p=reject é perigoso»: é, se for feito às pressas, mas com a rota gradual e os relatórios é a meta segura e desejável. A terceira, «com o SPF já está»: o SPF sozinho deixa metade do trabalho por fazer e nem sequer cobre o alinhamento. E a quarta, «configura-se uma vez e pronto»: cada fonte nova, cada troca de provedor e cada rotação de chaves pede revisar que tudo segue alinhado. Desmontar esses mitos costuma ser o primeiro passo de um projeto de autenticação, porque a crença errada é o que mantém o buraco aberto.

MTA-STS e TLS-RPT: proteger o caminho além da identidade

SPF, DKIM e DMARC provam quem envia, mas há uma segunda família de registros que protege como a mensagem viaja, e convém não esquecê-la. O MTA-STS (SMTP MTA Strict Transport Security) instrui os servidores que entregam o seu correio a exigir uma conexão cifrada com TLS e um certificado válido antes de entregar, fechando a porta a um atacante que tente rebaixar a conexão para texto plano e ler ou alterar a mensagem em trânsito. O seu complemento, o TLS-RPT, faz com que os receptores enviem relatórios de quando uma entrega cifrada falhou, de modo que você veja um problema de transporte em vez de descobri-lo por acaso. Completam a autenticação de identidade em vez de a substituir: uma protege contra a falsificação do remetente, a outra contra a interceptação no caminho. Para domínios que tratam dados sensíveis — e sob a LGPD ou o RGPD muitos tratam —, exigir o cifrado em trânsito deixa de ser opcional e passa a ser parte do cuidado esperado. Publicá-los e ler os seus relatórios é um passo que poucos dão e que fecha um flanco real.

O alcance lusófono: Brasil, Portugal e África

Um programa de autenticação que serve a um público lusófono cruza várias jurisdições, e o desenho tem que contar com isso. No Brasil, além das regras dos grandes provedores, o CAPEM marca o tom da autorregulação e a LGPD, fiscalizada pela ANPD, o do tratamento de dados; em Portugal e no resto da Europa manda o RGPD; e Angola e Moçambique têm as suas próprias leis de proteção de dados que vão amadurecendo. A autenticação em si — SPF, DKIM, DMARC alinhados — é a mesma em todos os lados, porque os filtros de Gmail, Outlook e Yahoo não mudam de país; o que muda é a moldura legal e de autorregulação por baixo, e onde os dados podem viver. Para uma marca que envia a esses mercados a partir de um único domínio, o sensato é uma autenticação técnica unificada e impecável, com a camada de conformidade desenhada para a jurisdição mais exigente de cada fluxo. Pensá-lo assim evita ter que refazer a arquitetura quando o envio cresce de um país para vários.

Como o implementamos

O nosso método segue um arco provado que evita o erro de endurecer às cegas. Começamos por um inventário completo: documentamos cada sistema que envia com o seu domínio, incluído aquele servidor esquecido que ninguém lembra de ter configurado. Publicamos um SPF limpo, abaixo do limite de consultas, e configuramos o DKIM com chaves fortes e alinhamento correto para cada fonte. Ativamos o DMARC em monitoração e analisamos os relatórios para separar o legítimo do malicioso. Autenticamos as fontes legítimas que faltam e, só então, subimos a política para quarentena e para rejeição, validando em cada passo. Se o seu correio cai por um código concreto durante o processo, nós o lemos em contexto, porque um 421 e um 550 contam histórias distintas e pedem respostas distintas. O resultado é uma autenticação que cumpre hoje e se sustenta amanhã.

Onde as ferramentas se detêm e onde começamos?

Há boas ferramentas que publicam registros e leem relatórios, e nós as usamos. Mas uma ferramenta diz a você que algo falha; não decide por você quando é seguro subir para rejeição, não interpreta um relatório RUA com centenas de fontes em contexto, nem reconhece que aquele IP que aparece assinando é a passarela legítima do seu departamento financeiro. A parte difícil da autenticação é o critério, mais do que publicar um registro: saber que fonte é real, que risco você assume em cada passo e quando apertar sem quebrar nada. Essa é a parte que nós pomos, e a razão pela qual um projeto de autenticação raramente é «colar um TXT» e muito mais frequentemente «pôr ordem em anos de envios sem governo».

Como medimos o progresso até a rejeição

Subir até o p=reject sem números é caminhar no escuro, então deixamos o progresso medido em cada etapa. A partir dos relatórios RUA acompanhamos quantas mensagens passam DMARC alinhado frente ao total, fonte por fonte, e essa porcentagem é a bússola: enquanto houver fluxo legítimo que ainda falha, não se endurece a política. Vemos também aparecer e desaparecer as fontes — a ferramenta nova que um departamento ligou, o servidor antigo que finalmente se aposentou — e quanto tráfego malicioso tenta usar o seu domínio, que é precisamente o que a rejeição vai bloquear. Quando a fração de correio legítimo alinhado se aproxima da totalidade e se mantém estável por um período, o salto para quarentena e depois para rejeição deixa de ser um risco e passa a ser uma formalidade respaldada por dados. Esse acompanhamento é o que separa uma subida tranquila de uma que deixa de fora, por pressa, a fatura ou o alerta de que o seu negócio depende.

Por que com uma consultoria independente

Na autenticação, o viés do provedor se cola fácil: o seu ESP dirá para você assinar com o domínio dele porque lhe simplifica a vida, não porque convém a você. Nós não revendemos plataformas nem certificados, então a recomendação aponta para o seu alinhamento e a sua proteção, não para a comodidade de um terceiro. Trabalhamos na camada técnica do correio todos os dias, em fusos horários da Europa, América do Norte e América Latina, e a autenticação encaixa com o resto do que fazemos: quando uma falha de alinhamento é na verdade um sintoma de um problema maior de entrega, nós a vemos, e a abordamos com uma auditoria de entregabilidade ou com gestão contínua em vez de tratar só o sintoma visível.

O ponto de partida é uma foto honesta e gratuita: a auditoria de 25 pontos revisa a sua autenticação — presença, validade e, sobretudo, alinhamento —, diz a você o que falha e traça o caminho até deixar você em rejeição sem sobressaltos. É a forma de começar com dados em vez de com suposições.