Autenticação de e-mail explicada: por que o Gmail rejeita seu e-mail

Você escreveu um e-mail perfeitamente bom. Apertou enviar. Então recebeu uma notificação de bounce, ou pior, não ouviu nada porque a mensagem caiu silenciosamente no spam. Você não está sozinho. Esse é um dos problemas mais comuns no e-mail hoje, e tem uma causa específica: seu domínio não está autenticado.

Se você é um gerente de marketing, fundador ou qualquer pessoa que envia e-mail de um domínio próprio, esse artigo é pra você. Sem bombardeio de jargões. Só uma explicação clara do que mudou, por que seu e-mail está sendo rejeitado e como corrigir.

O que mudou

Por anos, autenticação de e-mail foi opcional. Dava pra enviar de qualquer domínio sem provar que você era o dono. Filtros de spam faziam o que podiam, mas o sistema era fundamentalmente quebrado. Qualquer um podia forjar um endereço From e fingir ser sua empresa.

Essa era acabou.

Google e Yahoo começaram a aplicar requisitos de autenticação em fevereiro de 2024. Se você envia mais de 5.000 mensagens por dia pra endereços Gmail ou Yahoo, seu domínio precisa ter SPF, DKIM e DMARC configurados corretamente. Ficou aquém e seu e-mail é rejeitado direto ou roteado pro spam.

A Microsoft seguiu em 2025, aplicando regras parecidas a Outlook.com, Hotmail e Live.com. O threshold é mais baixo e a aplicação é mais rígida do que muitos esperavam.

Isso não é um experimento temporário de política. É a nova linha de base. Todo grande provedor de e-mail agora trata e-mail não autenticado como suspeito por padrão. Se seus registros DNS não estão configurados, suas mensagens morrem na chegada.

SPF: a lista de convidados do seu domínio

SPF significa Sender Policy Framework. Pense nele como uma lista de convidados de um evento privado.

Seu domínio é o local. Todo servidor que envia e-mail em seu nome (seu provedor de e-mail, sua ferramenta de marketing, sua email API transacional) precisa estar nessa lista de convidados. SPF é como você publica essa lista.

Você cria um registro SPF no seu DNS. É um registro TXT que diz: "Esses endereços IP e serviços podem enviar e-mail como meu domínio." Quando o Gmail recebe uma mensagem alegando ser do seu domínio, ele checa o registro SPF. Se o servidor de envio está na lista, passa. Se não, falha.

Aqui vai como um registro SPF simples se parece:

v=spf1 include:spf.sendkit.dev include:_spf.google.com ~all

Esse registro diz: os servidores da Sendkit podem enviar por nós, o Google Workspace pode enviar por nós, e todo o resto deveria ser tratado como suspeito.

O ponto chave pra entender: SPF não criptografa nada. Não verifica o conteúdo do seu e-mail. Só responde uma pergunta: "Esse servidor tem permissão pra enviar por esse domínio?"

DKIM: o selo de cera na sua carta

DKIM significa DomainKeys Identified Mail. Se SPF é a lista de convidados, DKIM é um selo de cera numa carta.

Quando você envia um e-mail, seu serviço de e-mail anexa uma assinatura criptográfica invisível aos headers da mensagem. Essa assinatura é gerada usando uma chave privada que só seu serviço de envio possui. Uma chave pública correspondente é publicada nos seus registros DNS.

Quando o servidor receptor recebe sua mensagem, ele busca a chave pública, checa a assinatura e confirma duas coisas: a mensagem realmente veio de um remetente autorizado, e a mensagem não foi alterada em trânsito.

DKIM não impede alguém de ver seu e-mail. Ele prova que o e-mail é genuíno e intacto. Se alguém intercepta a mensagem e muda o conteúdo, a assinatura quebra e o servidor receptor sabe que algo está errado.

Você não precisa entender a criptografia. Você precisa entender que sem DKIM, servidores receptores não têm como verificar que seu e-mail é real. E em 2026, não verificado significa não confiável.

DMARC: a política que amarra tudo

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. É a camada de política que fica em cima de SPF e DKIM e diz aos servidores receptores o que fazer quando a autenticação falha.

Sem DMARC, um servidor receptor pode ver que seu e-mail falhou no SPF ou DKIM e dar de ombros. Talvez entregue a mensagem mesmo assim, talvez não. Não tem consistência. DMARC remove a ambiguidade.

Um registro DMARC se parece com isso:

v=DMARC1; p=reject; rua=mailto:[email protected]

O valor p= é sua política:

• p=none -- só monitora. Falhas são relatadas mas o e-mail ainda é entregue. Use enquanto você configura as coisas.
• p=quarantine -- mensagens que falham vão pro spam. Esse é o mínimo que Google e Yahoo exigem pra remetentes em massa.
• p=reject -- mensagens que falham são bloqueadas completamente. É onde você quer chegar.

DMARC também exige alinhamento. O domínio no header From precisa bater com o domínio usado nas checagens de SPF ou DKIM. Isso impede atacantes de passar no SPF com o próprio domínio enquanto fazem spoof do seu no campo From.

A parte rua= diz aos receptores pra onde enviar relatórios agregados. Esses relatórios mostram quem está enviando e-mail como seu domínio, se estão passando na autenticação e onde estão as falhas. São essenciais pra diagnosticar problemas.

Como checar se você está configurado corretamente

Você não precisa ser sysadmin pra verificar seus registros. Aqui vão as formas mais rápidas.

Usando comandos dig (se você tá confortável com terminal):

dig TXT seudominio.com +short        # Checar SPF
dig TXT _dmarc.seudominio.com +short # Checar DMARC
dig TXT selector._domainkey.seudominio.com +short # Checar DKIM

Pra DKIM, troque selector pelo seu selector DKIM real. Seu provedor de e-mail vai te dizer qual é.

Usando ferramentas online:

• MXToolbox -- checa SPF, DKIM, DMARC e registros MX
• Google Postmaster Tools -- mostra a reputação do seu domínio com o Gmail
• Mail Tester -- envie um e-mail de teste e receba uma pontuação de entregabilidade

Se qualquer uma dessas checagens voltar vazia ou com erros, sua autenticação está quebrada e você precisa consertar antes de enviar outra campanha.

Pra um passo a passo completo, leia nosso guia passo a passo pra configurar DMARC, DKIM e SPF.

Erros comuns que quebram a autenticação

Mesmo times que configuram autenticação frequentemente tropeçam nesses.

Muitos lookups SPF. SPF tem um limite rígido de 10 lookups de DNS. Cada include: no seu registro conta como um lookup, e includes aninhados também contam. Se você usa vários serviços de e-mail (marketing, transacional, CRM, helpdesk), pode passar desse limite sem perceber. Quando você excede 10 lookups, o SPF falha completamente, o que é pior do que não ter.

Deixar o DMARC em p=none pra sempre. Modo monitor foi feito pra ser temporário. É uma fase de diagnóstico onde você confirma que seu e-mail legítimo está passando na autenticação. Se você deixar em p=none por meses ou anos, os receptores sabem que você não leva aplicação a sério e tratam seu domínio de acordo. Migre pra p=quarantine quando seus relatórios estiverem limpos, depois pra p=reject.

Falta de alinhamento DKIM. DKIM tecnicamente pode passar mesmo quando o domínio assinante não bate com seu domínio From. Mas DMARC exige alinhamento. Se seu serviço de e-mail assina com bounce.terceiro.com em vez de seudominio.com, o DKIM passa mas o DMARC falha. Garanta que seu provedor suporte assinatura DKIM customizada com seu próprio domínio.

Esquecer subdomínios. Se você envia de mail.seudominio.com mas só configurou autenticação pra seudominio.com, mensagens do subdomínio podem falhar. DMARC tem uma tag sp= especificamente pra política de subdomínio. Não ignore.

Como a Sendkit lida com isso

Configuração de autenticação é uma daquelas coisas que não deveria exigir um fim de semana lendo RFCs.

Quando você adiciona um domínio de envio na Sendkit, a gente gera automaticamente os registros DNS exatos que você precisa: include de SPF, chaves DKIM e um registro DMARC recomendado. Você copia no seu provedor de DNS, clica em verificar, e pronto. Sem ficar adivinhando qual selector usar, sem gerar pares de chaves manualmente.

A Sendkit também monitora seu status de autenticação continuamente. Se um registro quebra porque alguém mudou seu DNS, a gente sinaliza no dashboard antes que afunde sua entregabilidade. Você pode enviar pela nossa email API ou SMTP relay, e os dois caminhos recebem o mesmo tratamento de autenticação.

Pro processo completo de configuração, confira a documentação da Sendkit.

Resumo

Autenticação de e-mail não é mais opcional. Gmail, Yahoo e Outlook vão rejeitar suas mensagens se SPF, DKIM e DMARC não estiverem configurados. A boa notícia é que configurar é uma tarefa única, e o retorno é imediato: melhor entrega na caixa de entrada, menos bounces e uma reputação de domínio que efetivamente trabalha a seu favor.

Se você não checou seus registros de autenticação recentemente, faça isso hoje. E se quiser melhorar sua entregabilidade de e-mail além da autenticação, comece pela higiene de lista e padrões de envio. Autenticação te coloca porta adentro. Todo o resto te mantém lá.