Por que o email cai no spam: o guia medido em 89 caixas reais

Capítulo 1

Por que o email cai no spam, e por que "entregue" não quer dizer entregue

Existe uma frase que aparece em todo painel de plataforma de email e que atrasa a solução do problema mais caro de quem escreve para uma lista: taxa de entrega de 99%.

Em 12 de agosto de 2026, as newsletters que eu opero mediram as duas pontas no mesmo dia. De um lado, o painel: 1.093 edições confirmadas nos últimos 30 dias, 1.952.853 envios, 1.942.396 entregues, 99,46% de taxa de entrega agregada, com 99,6% das edições individuais acima de 97%. Um quadro impecável.

Do outro lado, uma caixa de email de verdade, assinando as mesmas publicações, com um script conferindo em qual pasta cada edição foi parar. De 89 newsletters medidas, 80 tinham mensagem na janela. Dessas 80: 15 na caixa de entrada principal, 24 na aba Promoções, 31 na pasta de spam, 2 na lixeira e 8 em outros rótulos. Trinta e uma de oitenta, ou 38,8%, foram entregues direto para a pasta que ninguém abre.

Os dois números estão certos. Eles medem coisas diferentes, e a diferença entre os dois é o assunto deste guia inteiro.

O que "entregue" mede de verdade

Quando a sua plataforma marca uma mensagem como entregue, ela está registrando uma coisa específica: o servidor do destinatário aceitou receber. Foi um aperto de mão entre dois servidores, o de saída disse "tenho uma mensagem para este endereço" e o de chegada respondeu "pode mandar, recebi". Fim.

O que acontece depois é decisão do provedor, e a plataforma que enviou nunca fica sabendo. Gmail, Outlook e Yahoo recebem a mensagem, passam pelos próprios filtros e decidem sozinhos onde colocar: caixa principal, aba de promoções, pasta de spam ou, em casos extremos, lugar nenhum. Nenhuma dessas decisões volta para quem enviou. Não existe evento de "fui para o spam" chegando ao seu painel, porque o provedor não conta.

A taxa de entrega é, portanto, um número de sanidade, não um número de sucesso. Ela responde "o servidor recusou?" e é útil para pegar endereço morto e bloqueio explícito. Ela não responde a única pergunta que importa: a pessoa vê a mensagem?

Promoções não é spam, e a diferença importa

Uma confusão comum vale ser desfeita antes de seguir. Na medição acima, 24 newsletters caíram na aba Promoções do Gmail e 31 na pasta de spam. Só o segundo grupo era incêndio.

A aba Promoções é caixa de entrada. A mensagem chegou, foi classificada por assunto junto com outras mensagens comerciais, e continua a um clique do leitor. Abertura e clique acontecem normalmente lá, e uma parte enorme das newsletters do mundo vive nessa aba sem prejuízo nenhum. Tentar sair dela com truque de formatação costuma custar mais do que rende.

A pasta de spam é outra história. Ali a mensagem está fora do caminho do leitor, quase ninguém abre, e cada envio novo para lá afunda mais a reputação do seu domínio, porque a ausência de engajamento confirma para o filtro que ele acertou. Spam é uma espiral: quanto mais tempo você fica, mais difícil sair.

Os três motivos, em ordem de frequência

Quase toda queda para o spam se explica por uma combinação de três causas, e vale conhecer as três antes de mexer em qualquer coisa.

1. Autenticação. O provedor não consegue provar que a mensagem é sua. Sem SPF, DKIM e DMARC publicados e passando, você é um remetente anônimo pedindo confiança, e desde 2024 os grandes provedores pararam de dar essa confiança de graça para quem envia em volume. Os capítulos 2 a 5 cobrem os três registros um a um.

2. Reputação. O provedor sabe quem você é e não gosta do histórico. Lista velha com endereço morto, gente que nunca abre, reclamação de spam acumulada, envio para quem não pediu. Reputação é do domínio, se constrói devagar e se perde rápido. Os capítulos 7 e 8 mostram como medir a sua antes que o filtro meça por você.

3. Padrão de envio. O provedor não tem histórico suficiente e o que vê parece disparo em massa. Saltar de dezenas para milhares de destinatários em poucos dias é exatamente o desenho que o filtro aprendeu a reconhecer como lista comprada. Foi essa terceira causa que derrubou a nossa operação, e o capítulo 10 conta o caso inteiro com data, número e o caminho de volta.

As três se retroalimentam. Domínio sem autenticação começa com reputação neutra, o que faz o filtro olhar com mais rigor para o padrão de envio, o que aumenta a chance de cair no spam, o que derruba a reputação. É a razão de a ordem de resolução deste guia não é negociável: autenticação primeiro, sempre, porque é a única das três que se resolve em uma tarde e não depende de tempo.

Como você confere a sua situação hoje, sem ferramenta nenhuma

Antes de continuar, vale medir a sua própria situação, porque o resto do guia fica mais útil com o diagnóstico na mão.

Assine a sua própria newsletter em uma conta do Gmail que você não usa para trabalhar, uma que não tenha histórico de abrir os seus emails. Espere a próxima edição sair. Procure pela mensagem com o campo de busca, incluindo spam e lixeira. O lugar onde ela estiver é o seu número real de entrega, e ele quase nunca é o do painel.

Depois abra a mensagem, clique nos três pontos e em Mostrar original. As três primeiras linhas trazem o veredito de SPF, DKIM e DMARC, e é a checagem mais barata que existe do que o capítulo seguinte explica.

▸ Ao terminar este capítulo, você sabe por que “99% entregue” no painel não quer dizer que o email chegou, e onde ele cai de verdade.

Capítulo 2

Os três porteiros do email: SPF, DKIM e DMARC em uma frase cada

O email foi desenhado nos anos 1980 sem nenhuma noção de identidade. O protocolo original aceita que qualquer servidor diga "sou o banco central" e envie mensagens em nome dele. Não é falha de implementação, é o desenho: o remetente é um campo de texto livre, como o remetente escrito à mão no verso de um envelope.

SPF, DKIM e DMARC são três remendos criados décadas depois para responder três perguntas diferentes sobre esse envelope. Cada um resolve um pedaço, nenhum resolve sozinho, e é por causa dessa divisão de trabalho que existem três siglas em vez de uma.

SPF: quem pode enviar em meu nome

O SPF é uma lista de servidores autorizados, publicada no DNS do seu domínio. Ele responde: "esta mensagem saiu de um servidor que o dono do domínio autorizou?"

Na prática é um registro de texto que diz "quem pode enviar por mim é o servidor da plataforma X, o do serviço Y e mais ninguém". O provedor que recebe a mensagem olha de onde ela veio, compara com a lista e tem a primeira resposta. É o registro mais simples dos três e o mais fácil de quebrar sem perceber, como o capítulo 3 mostra.

DKIM: esta mensagem é mesmo a que eu escrevi

O DKIM é uma assinatura criptográfica em cada mensagem. Ele responde: "o conteúdo chegou como saiu, sem ninguém mexer no caminho?"

A plataforma de envio guarda uma chave privada e assina cada mensagem com ela. Você publica a chave pública no DNS. O provedor pega a assinatura, confere contra a chave pública e sabe duas coisas: que a mensagem passou por quem tem a chave, e que o conteúdo não foi alterado depois de assinado. É a prova mais forte dos três, e a que viaja junto da mensagem mesmo quando ela é encaminhada.

DMARC: o que fazer quando um dos dois falha

Os dois primeiros produzem um veredito, e nada mais. Sem o terceiro, o provedor recebe uma mensagem que falhou no SPF e fica sem instrução: entrega mesmo assim? Manda para o spam? Rejeita?

O DMARC é a sua instrução por escrito. Ele responde: "quando a checagem falhar, faça isto, e me avise". É uma política publicada no DNS, com três valores possíveis, do mais leve ao mais duro, mais um endereço para onde os relatórios diários são enviados.

O DMARC também traz a peça que faz os outros dois valerem alguma coisa, chamada alinhamento: não basta a mensagem passar no SPF de qualquer domínio, ela precisa passar no SPF do mesmo domínio que aparece no campo De. Sem alinhamento, um remetente mal intencionado podia passar no SPF do próprio domínio dele e escrever o seu no campo visível. O capítulo 5 abre esse ponto com calma, porque ele é a razão de o DMARC existir.

Por que agora e não antes

Os três registros existem há mais de quinze anos, e por quinze anos foram recomendação de manual, não obrigação. Em fevereiro de 2024 a régua mudou de uma vez: Gmail e Yahoo passaram a exigir os três de quem envia mais de 5.000 mensagens por dia, junto com descadastro em um clique e uma taxa de reclamação de spam abaixo de 0,3%. Em maio de 2025 a Microsoft seguiu com o Outlook, Hotmail e Live, e foi mais dura: mensagem de domínio de alto volume que não passa na autenticação é rejeitada na porta, com o erro 550 5.7.515 Access denied, sending domain does not meet the required authentication level.

A consequência prática é que os três deixaram de ser boa prática e viraram condição de entrada. E a boa notícia é que os três são configuração de DNS: uma tarde de trabalho, custo zero, e valem para sempre.

A ordem que economiza tempo

Configure nesta sequência, que é a do assistente de passos deste guia e a que menos gera retrabalho:

Primeiro o SPF, porque é o registro que a sua plataforma já entrega pronto e porque um erro nele derruba tudo. Depois o DKIM, que também sai pronto do painel da plataforma e só precisa ser colado no DNS. Por último o DMARC, em modo de observação, para você passar duas ou três semanas lendo quem envia em seu nome antes de bloquear qualquer coisa.

Inverter a ordem e começar pelo DMARC em modo duro é o erro clássico: você bloqueia o seu próprio email de nota fiscal, o formulário do site e o disparo da agência, tudo no mesmo dia, e descobre no telefonema do cliente.

▸ Ao terminar este capítulo, você sabe quais são os três porteiros (SPF, DKIM e DMARC) e qual deles a sua newsletter ainda não passou.

Capítulo 3

SPF: o registro que diz quem pode enviar pelo seu domínio

O SPF é um registro TXT publicado na raiz do seu domínio. Ele começa sempre com v=spf1, lista os autorizados e termina com uma instrução sobre todo o resto. O da Alquimia da Mente, lido no DNS público em 12 de agosto de 2026, é este:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

Traduzido: quem pode enviar em nome deste domínio são os servidores do Google Workspace, os do SendGrid e os do Mailchimp. Qualquer outro servidor que tentar deve ser tratado como suspeito.

As quatro terminações, e o que cada uma manda o provedor fazer

A última instrução do registro é a mais importante, e a que mais gente erra. São quatro possibilidades:

-all (falha dura). Servidor fora da lista deve ser rejeitado. É a mais rigorosa e a que os manuais de segurança recomendam. Ela só é segura quando você tem certeza absoluta de que a lista está completa, porque qualquer serviço esquecido para de entregar do dia para a noite.

~all (falha branda). Servidor fora da lista deve ser aceito e marcado como suspeito. É a recomendação da maioria das plataformas de envio, e a escolha certa para quase todo mundo: protege contra falsificação sem derrubar o sistema no dia em que você esquecer de acrescentar um serviço novo.

?all (neutro). O registro existe e não afirma nada. Equivale a não ter SPF, com o custo extra de dar a impressão de que tem.

+all (autoriza o mundo). Diz ao provedor que qualquer servidor do planeta pode enviar em seu nome. Aparece em tutorial ruim e em copiar e colar apressado, e é pior que não ter registro nenhum.

O limite de dez que quebra domínio antigo em silêncio

Esta é a armadilha que mais derruba domínio de quem já tem alguns anos de operação, e ela é invisível até o dia em que aparece.

A especificação do SPF impõe um limite de dez buscas de DNS por verificação. Cada include, cada a, cada mx, cada exists e cada redirect no seu registro gasta uma dessas dez. E a conta não é só do seu registro: o include de uma plataforma pode conter outros include dentro dele, e todos contam.

Ao passar de dez, a verificação não fica pior aos poucos. Ela devolve erro permanente, e o provedor trata a sua mensagem como se o SPF tivesse falhado, mesmo com o servidor certo enviando. O sintoma clássico é o mais confuso possível: nada mudou no seu envio, e do nada as mensagens começam a ser marcadas.

A causa quase sempre é acúmulo. A empresa contratou uma ferramenta de disparo em 2021, trocou por outra em 2023, testou uma terceira em 2024, e os três include continuam no registro. Limpar serviço que não se usa mais é a manutenção mais barata de entregabilidade que existe.

O verificador do capítulo 5 conta essas buscas para você e mostra quantas de dez o seu domínio está gastando.

Um domínio, um SPF, sem exceção

Segundo erro comum, e ele acontece por boa fé. A empresa contrata um serviço novo, o suporte manda "publique este registro SPF", e a pessoa publica um segundo registro TXT ao lado do que já existia.

A especificação é clara: mais de um registro v=spf1 no mesmo domínio é erro permanente, e o provedor invalida os dois. Ou seja, tentar autorizar dois serviços com dois registros desautoriza os dois.

O jeito certo é somar: pegar o include do serviço novo e acrescentar ao registro que já existe, deixando um só. Se a soma dos include estourar as dez buscas, é hora de cortar serviço morto antes de acrescentar mais um.

O que o SPF não protege

Vale saber onde ele para, porque é a razão de os outros dois existirem.

O SPF valida o remetente do envelope, que é o endereço técnico usado na conversa entre servidores. Ele não valida o campo De que a pessoa vê na tela. Um remetente malicioso pode passar no SPF do próprio domínio dele e escrever o seu nome no campo visível, e a mensagem passa. Quem fecha essa porta é o alinhamento do DMARC, no capítulo 5.

E o SPF quebra quando a mensagem é encaminhada. O servidor que encaminha passa a ser o remetente, e ele não está na sua lista. É um dos motivos de o DKIM existir, porque a assinatura dele sobrevive ao encaminhamento.

Como publicar, em quatro passos

Pegue no painel da sua plataforma de envio o include que ela indica. Entre no painel de DNS de onde o seu domínio está hospedado. Procure se já existe um TXT começando com v=spf1: se existe, edite e acrescente o include novo antes do all; se não existe, crie um TXT na raiz com v=spf1 include:oquevocecopiou ~all. Salve e espere: a propagação leva de minutos a algumas horas.

Depois confira no verificador do capítulo 5, que lê o registro publicado e conta as buscas.

▸ Ao terminar este capítulo, você sabe o que o seu SPF precisa declarar e quantas das dez buscas ele já gasta.

Capítulo 4

DKIM: a assinatura que prova que a mensagem chegou inteira

Se o SPF é a lista de quem pode entrar, o DKIM é o lacre no envelope. Ele resolve um problema que o SPF não toca: garantir que o conteúdo que saiu é exatamente o que chegou, e que quem enviou tinha a chave para provar.

O mecanismo é criptografia de chave pública, o mesmo princípio do cadeado do seu navegador. Existe um par de chaves. A privada fica com a plataforma de envio e nunca sai de lá. A pública você publica no DNS. Cada mensagem que sai leva um cabeçalho a mais, invisível para o leitor, com uma assinatura calculada a partir do conteúdo e da chave privada.

Do outro lado, o provedor faz o caminho inverso: busca a chave pública no seu DNS, confere a assinatura contra o conteúdo recebido e chega a duas conclusões. Que a mensagem passou por quem tem a chave privada, e que nem uma vírgula foi alterada depois da assinatura. Se alguém interceptar e mudar qualquer coisa, a conta não fecha e a checagem falha.

O seletor, e por que ele existe

A chave pública não fica solta no domínio. Ela mora em um endereço com nome próprio, no formato seletor._domainkey.seudominio.com. O seletor é um rótulo escolhido por quem assina.

Existe por dois motivos práticos. Primeiro, para permitir mais de um serviço assinando o mesmo domínio: a plataforma de newsletter usa um seletor, o email da empresa usa outro, o sistema de nota fiscal usa um terceiro, e cada um tem a própria chave sem atrapalhar os demais. Ver três ou quatro seletores em um domínio maduro é sinal de saúde, não de bagunça.

Segundo, para permitir troca de chave sem interrupção. Quando a plataforma precisa rotacionar a chave, ela publica um seletor novo, começa a assinar com ele e só depois aposenta o antigo. Nenhuma mensagem fica sem assinatura no meio da troca.

Na prática, o seletor mais comum é default, e cada plataforma tem os seus. O verificador do capítulo 5 varre os 24 seletores mais usados pelas plataformas de envio, e é honesto sobre o limite: não achar nenhum não prova que o domínio não assina, prova que o seletor está fora da lista. Só o painel da sua plataforma, ou o Mostrar original de uma mensagem recebida, dá a resposta definitiva.

Como configurar, e por que costuma ser o mais fácil dos três

O DKIM parece o mais técnico dos três e é o que dá menos trabalho, porque você nunca toca na criptografia.

O painel da plataforma gera o par de chaves e mostra o que publicar. Costuma ser um ou dois registros CNAME, que apontam para o servidor da plataforma, ou um TXT com a chave inteira. Você copia, cola no DNS, salva e clica em verificar no painel. Alguns minutos depois a plataforma confirma, e a partir dali toda mensagem sai assinada.

Dois detalhes que evitam suporte. Registros DKIM são longos e o painel de DNS às vezes quebra em pedaços na hora de salvar, o que é normal e funciona, desde que ninguém acrescente espaço no meio. E alguns painéis acrescentam o domínio ao final do que você colou, criando seletor._domainkey.seudominio.com.seudominio.com, que é a causa número um de DKIM publicado e não encontrado.

O erro que só aparece na mensagem encaminhada

Uma vantagem do DKIM que vale entender, porque ela explica um sintoma confuso.

Quando alguém encaminha a sua mensagem, ou quando ela passa por uma lista de discussão, o servidor que reenvia vira o remetente técnico. O SPF quebra na hora, porque esse servidor não está na sua lista de autorizados. A assinatura do DKIM, no entanto, viaja junto do conteúdo e continua válida, desde que ninguém tenha mexido no corpo da mensagem.

É por causa dessa diferença que o DMARC aceita um dos dois passando, e não os dois. Mensagem encaminhada costuma chegar com SPF falhando e DKIM passando, e continua legítima.

O reverso também acontece e é o caso que confunde: algumas listas de discussão acrescentam uma linha de rodapé ou um prefixo no assunto. Qualquer alteração no que foi assinado invalida a assinatura, e aí caem os dois. Não é problema do seu domínio, é comportamento conhecido de lista de discussão, e o relatório de DMARC vai mostrar exatamente esses casos.

Quando a plataforma assina pelo domínio dela

Se você ainda não configurou domínio de envio próprio, a sua plataforma assina com o domínio dela. A mensagem sai autenticada, o que é melhor que nada, e é exatamente o que a maior parte das newsletters novas faz.

O que você não tem nesse arranjo: reputação própria, alinhamento do DMARC com o domínio que aparece no campo De, e independência de plataforma. É um degrau intermediário aceitável no começo, e um teto baixo quando a lista cresce.

Chave de 1024 ou de 2048 bits

Se a plataforma perguntar, escolha 2048. Chaves de 1024 bits ainda funcionam e são aceitas, mas são consideradas fracas há anos e alguns provedores já dão menos peso a elas. O único motivo histórico para preferir 1024 era limitação de painel de DNS antigo que não aceitava valor longo, o que praticamente não existe mais.

O que o DKIM entrega além da entrega

Um benefício menos óbvio, e talvez o mais valioso a longo prazo: a reputação construída pelo DKIM é do seu domínio, não da plataforma.

Quando as suas mensagens saem assinadas com a chave do seu domínio, o histórico de bom comportamento se acumula no seu nome. No dia em que você trocar de plataforma de envio, essa reputação vai junto. Já quem envia pelo domínio compartilhado da plataforma, sem assinatura própria, está pegando emprestada a reputação de um endereço que milhares de outros remetentes também usam, e recomeça do zero a cada troca.

É a mesma lógica de construir audiência em domínio próprio em vez de em rede social alheia, aplicada à camada de infraestrutura. O capítulo 6 desdobra a decisão inteira.

▸ Ao terminar este capítulo, você sabe o que a assinatura DKIM prova e qual seletor a sua plataforma usa.

Capítulo 5

DMARC: a política que decide o que o provedor faz quando falha

Os dois capítulos anteriores produziram vereditos. O DMARC é o que transforma veredito em ação, e é o registro que amarra os outros dois em um sistema que funciona.

Ele vive em um endereço próprio, _dmarc.seudominio.com, e o registro mínimo é curto:

v=DMARC1; p=none; rua=mailto:voce@seudominio.com

Três informações: a versão, a política e para onde mandar os relatórios.

Alinhamento, a peça que faz o resto valer

Antes da política, o conceito que dá sentido ao DMARC.

O email tem dois remetentes. O do envelope, usado na conversa entre servidores, que o SPF valida. E o do cabeçalho De, que é o que aparece na tela do leitor. Nada no protocolo original obriga os dois a serem o mesmo domínio, e é exatamente essa folga que a falsificação explora: passar no SPF de um domínio descartável e escrever o seu no campo visível.

O DMARC exige alinhamento: o domínio do campo De precisa bater com o domínio validado pelo SPF ou com o domínio que assinou no DKIM. Basta um dos dois alinhar. Sem alinhamento, o DMARC falha mesmo que SPF e DKIM tenham passado, porque passaram para outro domínio.

É a razão de "configurei tudo e continua falhando" ser quase sempre um problema de alinhamento, não de configuração dos registros.

As três políticas, e a escada entre elas

p=none, só observa. A mensagem que falha passa mesmo assim, e você recebe o relatório. Não bloqueia nada, e é exatamente por não bloquear nada que é a porta de entrada certa.

p=quarantine, quarentena. A mensagem que falha vai para a pasta de spam do destinatário.

p=reject, rejeita na porta. A mensagem que falha nem chega a ser entregue.

A escada correta é subir devagar. Fique de duas a três semanas em p=none lendo os relatórios, que mostram todos os serviços enviando em seu nome. Quase sempre aparecem dois ou três que você tinha esquecido: o sistema de emissão de nota, o formulário do site, a ferramenta de suporte. Autentique cada um. Só quando a lista estiver limpa suba para quarantine, deixe mais duas semanas, e então vá para reject.

Pular a escada é o erro caro. Publicar p=reject no primeiro dia bloqueia todo serviço legítimo ainda não autenticado, e o sintoma chega como cliente reclamando que não recebe a fatura.

As tags que valem conhecer

rua=mailto: é para onde vão os relatórios agregados, um por dia por provedor. Sem essa tag você aplica uma política sem nunca ver quem ela bloqueia, que é dirigir de olhos fechados.

pct= aplica a política a uma fração das mensagens. pct=50 com p=quarantine manda metade das que falham para o spam e deixa a outra metade passar. É útil como transição e ruim como estado final, porque deixa a porta entreaberta para sempre.

sp= define política própria para subdomínios. Sem ela, o subdomínio herda a política do domínio pai, o que costuma ser o desejado.

fo=1 pede relatório detalhado sempre que qualquer uma das checagens falha, o que ajuda no diagnóstico da fase inicial.

Lendo o relatório que chega

Os relatórios agregados chegam como anexo XML compactado, um por provedor por dia, e são ilegíveis a olho nu de propósito: eles foram feitos para máquina. Duas saídas.

A barata: abrir o XML e procurar as linhas com <result>fail</result>, olhando o endereço IP e a contagem ao lado. Cada bloco é um servidor que enviou em seu nome, com quantas mensagens e se passou.

A confortável: usar um serviço gratuito que recebe os relatórios no lugar do seu email e mostra em painel. Você troca o rua= pelo endereço que ele fornece. É o que a Alquimia faz, e é a razão de o registro dela ter dois destinos no rua, o painel e o email próprio.

Na primeira semana, espere susto. O relatório mostra tentativas de envio em seu nome vindas de lugares que você nunca viu, e a maioria é lixo automático da internet, não invasão. O que importa é reconhecer os seus e autenticar cada um.

▸ Ao terminar este capítulo, você tem o resultado do verificador na tela: SPF, DKIM e DMARC em verde, amarelo ou vermelho.

Capítulo 6

Email profissional e domínio próprio: o remetente que muda o jogo

Chega o capítulo da decisão que separa quem resolve entregabilidade de vez de quem vive apagando incêndio: de qual domínio você envia.

A resposta curta é que enviar em volume por gmail.com, hotmail.com ou yahoo.com deixou de ser uma opção ruim e passou a ser uma opção impossível. Não é conselho de estilo, é bloqueio técnico.

Por que o remetente gratuito parou de funcionar

Os próprios provedores publicaram políticas de DMARC com p=reject nos domínios deles. Traduzindo: o Gmail instruiu o mundo a rejeitar mensagem em massa que chegue com @gmail.com no campo De sem ter saído dos servidores do Gmail.

Ou seja, pôr @gmail.com como remetente de um disparo pela sua plataforma de envio produz o pior resultado possível: a mensagem falha no DMARC do domínio do Google, e o provedor do destinatário cumpre a instrução do Google, não a sua. Você não tem como autenticar um domínio que não é seu.

O que o domínio próprio compra

Reputação sua, que se acumula. Cada envio bom constrói histórico no seu nome. Em domínio compartilhado da plataforma, o histórico é do endereço coletivo, dividido com todos os outros remetentes.

Reputação portátil. Trocar de plataforma sem trocar de domínio preserva o histórico inteiro. É o mesmo raciocínio de construir no que é seu, aplicado à infraestrutura.

Autenticação possível. Só no seu domínio você publica SPF, DKIM e DMARC. Sem domínio próprio, os três capítulos anteriores são inaplicáveis.

Confiança de quem lê. O remetente é a primeira coisa que aparece na lista de mensagens, antes do assunto.

Domínio ou subdomínio de envio

Uma escolha que vale entender, porque separa problema de problema.

Enviar pelo domínio raiz, voce@suamarca.com, é o caminho mais simples e junta a reputação do seu email pessoal com a do seu envio em massa. Enviar por um subdomínio dedicado, como news.suamarca.com, isola as duas: um problema de reputação no envio em massa não contamina o email que você usa para falar com cliente e fornecedor.

A recomendação prática: quem envia até alguns milhares por edição resolve bem no domínio raiz e não precisa complicar. Quem envia dezenas de milhares, ou manda tipos muito diferentes de mensagem, ganha em separar. E a decisão de subdomínio é bem mais barata de tomar agora do que depois, porque trocar o remetente de uma lista viva custa caro, como o próximo bloco mostra.

Você já tem lista em remetente gratuito: o que fazer

O caso mais comum de quem chega neste guia depois de já ter começado errado, e ele tem saída.

Não troque tudo de uma vez. Registre o domínio, configure os três registros do capítulo 2 ao 5, e prepare a plataforma com o remetente novo antes de mandar qualquer coisa por ele.

Avise antes. Duas ou três edições ainda pelo remetente antigo, cada uma dizendo em uma linha que o remetente muda e pedindo para a pessoa marcar como contato conhecido. Parece pouco e é a diferença entre a primeira edição no domínio novo chegar na caixa ou no spam.

Comece pequeno. Primeira edição no domínio novo apenas para quem abriu nos últimos 30 dias, que é o grupo com maior chance de abrir e ensinar o filtro que você é bem-vindo. Depois vá abrindo em degraus, como o capítulo 10 detalha.

Aceite a queda temporária. As primeiras semanas rendem menos, e o número volta. Quem desiste no meio e retorna ao remetente antigo paga o custo duas vezes.

O que checar antes de escolher a plataforma

Três perguntas que separam plataforma que resolve entregabilidade de plataforma que empurra o problema.

Ela oferece domínio de envio próprio, e em qual plano? É o recurso que faz tudo neste capítulo funcionar. Quando ele fica fora do plano de entrada, você está adiando o problema, não resolvendo.

Ela mostra bounce, reclamação de spam e descadastro por envio? Sem esses três números por edição, você não consegue rodar a rotina do capítulo 11.

Ela deixa segmentar por comportamento e enviar só para o segmento? É o freio de mão do capítulo 8, e sem ele não existe recuperação controlada.

O custo de trocar depois

Vale ser honesto sobre o preço da migração, porque ele é o argumento mais forte a favor de começar certo.

Trocar o domínio de envio de uma lista que já funciona significa recomeçar a reputação do zero. O domínio novo não tem histórico, e todo o cuidado do capítulo 10, crescimento capado e envio gradual, precisa ser refeito. Na prática, são de quatro a oito semanas de envio reduzido antes de voltar ao volume normal.

Some ao prazo o trabalho de trocar o remetente em toda automação, refazer os registros e avisar a lista de que o remetente muda. Nada dessa lista é difícil. Tudo nela é lento, e acontece enquanto o seu envio rende menos.

A parte que a plataforma resolve por você

O trabalho técnico dos capítulos 3, 4 e 5 tem um atalho legítimo: plataformas de newsletter com domínio de envio próprio entregam os registros prontos. Você aponta o domínio, o painel mostra exatamente o que colar no DNS, com o DKIM já gerado, e confere sozinho se está publicado.

É o que eu uso, e é onde ponho o link de indicação deste guia, porque é a única recomendação daqui que envolve pagar por alguma coisa. Quem quiser o passo a passo da plataforma em si, com telas e planos, tem o guia da beehiiv em português, e o recurso de domínio de envio mora no plano pago da plataforma. Uma observação honesta sobre a nossa própria operação: as minhas newsletters mais novas ainda enviam pelo domínio compartilhado da plataforma, e é justamente a parte da nossa infraestrutura que o incidente do capítulo 10 expôs.

▸ Ao terminar este capítulo, você decidiu se vai usar domínio próprio no remetente, e sabe o que o remetente próprio muda na entrega.

Capítulo 7

As quatro métricas com régua: bounce, spam, descadastro e abertura

Autenticação você resolve em uma tarde. Reputação é rotina, e rotina precisa de número com régua. Este capítulo dá as quatro métricas que importam, o que é normal em cada uma, e o que é incêndio.

1. Bounce: hard e soft

Hard bounce é a recusa definitiva: o endereço não existe. Digitação errada no cadastro, domínio que expirou, conta de trabalho de quem mudou de emprego. Sai da lista na hora, sem apelação.

Soft bounce é a recusa temporária: caixa cheia, servidor fora do ar, mensagem grande demais. Não sai na hora, sai depois de se repetir. A régua que a nossa operação usa é retirar depois de duas ocorrências em 30 dias.

Aqui mora uma armadilha que custou meses de análise errada na nossa operação, e ela vale mais que a régua. O contador de bounce do painel costuma ser vitalício, não é a lista de supressão. Quando fomos cortar por ele, o censo mostrou 2.013 endereços com hard bounce registrado na base inteira, e 1.540 deles continuavam recebendo e abrindo normalmente. Um bounce isolado de dois anos atrás, causado por instabilidade de servidor, tinha ficado no contador para sempre.

Cortar por contador vitalício apaga leitor vivo. A régua certa combina o bounce com uma janela e com sinal de engajamento, e é o que o capítulo 8 detalha.

2. Reclamação de spam, a métrica mais dura

É o número que mais rápido derruba um domínio, porque é o único em que a pessoa aponta o dedo para você.

O corte é público e o Gmail escreve com todas as letras: manter abaixo de 0,10% e nunca chegar a 0,30%. O Yahoo pede a mesma coisa, abaixo de 0,3%. A Microsoft não publica número, e este guia não inventa um no lugar dela.

Traduzindo para lista de verdade: 0,10% é uma reclamação a cada mil entregas. Uma lista de 10 mil tolera 10 reclamações por envio antes de acender a luz amarela, e 30 é zona vermelha. Números pequenos, e é de propósito: clicar em spam é um ato raro, então poucos casos já significam muito.

Para comparação com uma operação real, a nossa operação somou 184 reclamações em 1.942.396 entregas nos 30 dias medidos, ou 0,0095%, cerca de dez vezes abaixo do alvo do Gmail. E, mesmo com esse número, 31 das 80 newsletters medidas estavam na pasta de spam, o que mostra que taxa boa de reclamação não é garantia de nada sozinha.

Duas causas quase sempre explicam reclamação alta, e nenhuma é o conteúdo: a pessoa não lembra de ter assinado, ou não achou o link de descadastro. Sobre a primeira, o capítulo 8. Sobre a segunda, a solução é anticlimática: facilite o descadastro. Link visível, uma etapa, sem pedir senha. Quem sai clicando em descadastrar não faz mal a ninguém. Quem não acha o link clica em spam.

3. Descadastro, que é sinal e não derrota

O descadastro tem má fama e merece o contrário: ele é o mecanismo de escape que protege a sua taxa de reclamação.

Régua de tamanho: abaixo de 0,5% por envio é normal em lista construída com anúncio pago, e a nossa operação ficou em 0,227% nos 30 dias medidos. Acima de 1% em um envio isolado, procure o que mudou naquela edição. Acima de 2%, alguma coisa quebrou.

O que importa mais que o número é a tendência. Descadastro que sobe devagar por semanas costuma ser promessa desalinhada: a pessoa assinou esperando uma coisa e recebe outra.

Um envio foge da régua de propósito, e vale saber antes de tratar o vermelho como incêndio: o primeiro email da relação. Na nossa operação a boas-vindas descadastrou 1,851% contra 0,199% da edição regular, 9,3 vezes, e a leitura correta é otimista. Quem sai no primeiro email sai antes de custar entrega, antes de custar reputação e antes de virar endereço morto, que é exatamente a limpeza que o capítulo 8 faz a mão um ano depois. A régua própria desse envio está no guia do email de boas-vindas, com os primeiros 30 dias do assinante medidos.

Uma exigência técnica virou obrigação junto com a autenticação: descadastro em um clique, pelo cabeçalho List-Unsubscribe, é requisito de Gmail e Yahoo desde fevereiro de 2024, com prazo de dois dias para processar. Toda plataforma séria já manda o cabeçalho por padrão.

4. Abertura, o termômetro com defeito conhecido

A abertura é a métrica mais citada e a menos confiável, e vale saber por quê antes de tomar decisão com ela.

Ela é medida por uma imagem invisível de um pixel. Se a imagem carrega, conta abertura. O problema é que os provedores passaram a carregar imagens automaticamente por privacidade, antes de qualquer humano ver a mensagem. Resultado: parte das aberturas registradas nunca foi leitura, e a distorção é maior em quem tem mais leitores de iPhone.

O defeito não torna a abertura inútil, torna a métrica comparável só consigo mesma. Compare a sua abertura de hoje com a sua de três meses atrás, na mesma base, e a tendência diz alguma coisa. Compare com a média de mercado e você compara duas medições sujas de jeitos diferentes.

E a abertura amadurece: na nossa medição, edição com 3 dias de vida tem mediana de 6,1%, com 7 dias vai a 13,7%, e só com 10 ou mais chega aos 19,2% reais. Print tirado na manhã seguinte não mede nada.

Existem duas réguas mais honestas do que a abertura para saber se a edição foi lida: o clique entre quem abriu, e o voto no pé da edição, que só quem desceu até o fim consegue apertar. As duas estão medidas no guia de escrita para newsletter, com 910 edições da mesma rede na janela declarada.

▸ Ao terminar este capítulo, você tem as quatro métricas do seu último envio medidas contra a régua dos provedores.

Capítulo 8

Segmentação como instrumento: enxergar fantasma, zumbi e caixa morta

As métricas do capítulo anterior dizem que existe um problema. Segmento é a lente que mostra onde ele está, e é a diferença entre limpar lista com bisturi ou com machado.

A ideia é simples: em vez de tratar a base como um bloco, você cria grupos por comportamento, olha o tamanho de cada um e decide o que fazer com cada grupo. Toda plataforma decente monta o grupo com uma condição salva, e ele se atualiza sozinho.

Os quatro grupos que valem existir

Estes são os que a nossa operação mantém vivos em 40 publicações, com o nome que usamos internamente.

Hard bounce. Endereço com recusa definitiva registrada, cruzado com janela de tempo e com sinal de engajamento, pela razão do capítulo anterior. Sem o cruzamento, o grupo vira uma lista de gente viva.

Soft bounce. Duas ou mais recusas temporárias em 30 dias. Caixa cheia crônica quase sempre é conta abandonada.

Fantasma. Está na lista há tempo suficiente e nunca abriu nada, nem edição, nem email de boas-vindas, nem confirmação. Nunca é a palavra importante: quem nunca abriu nenhum email da sua marca provavelmente nunca vai abrir.

Zumbi. Já abriu, e esfriou. É o grupo mais valioso dos quatro, porque tem histórico de interesse. Zumbi não é caso de limpeza, é caso de campanha de reativação.

A distinção entre fantasma e zumbi parece sutil e não é. Na nossa base ela só ficou possível porque a plataforma separa "abriu edição" de "teve qualquer evento de email", que inclui automação de boas-vindas. Quem confunde os dois trata como morto quem só não abriu a última edição.

O nosso censo de 2 de agosto de 2026 mostrou os quatro grupos vivos em 40 publicações: 252 hard bounce, 842 soft bounce, 415 fantasmas e 1.102 zumbis.

Como montar os quatro grupos na prática

A parte que costuma travar é passar da ideia para a condição salva. As quatro condições abaixo são as que usamos aqui, escritas em linguagem comum para você traduzir para o painel da sua plataforma.

Hard bounce: tem pelo menos um bounce definitivo registrado nos últimos 30 dias e não abriu nada no mesmo período. A janela é o que impede o contador vitalício de condenar leitor vivo.

Soft bounce: duas ou mais recusas temporárias nos últimos 30 dias.

Fantasma: está na lista há mais de 90 dias e tem zero eventos de email, contando qualquer email, não apenas edição.

Zumbi: já teve abertura em algum momento e não abre há mais de 90 dias.

Duas armadilhas. A primeira é usar "não abriu a última edição" como sinal de morte, que condena metade da base por causa de um dia de viagem. A segunda é confundir "não abriu edição" com "não teve evento nenhum": a segunda condição é muito mais dura e é a que separa fantasma de zumbi.

Os quatro segmentos na beehiiv, condição por condição

Na plataforma que eu uso, o caminho é Audience, depois Segments, depois Create Segment, sempre do tipo Dynamic: o dinâmico se recalcula sozinho todo dia, enquanto o estático congela a foto do dia em que foi criado. Os prints abaixo são dos segmentos reais que rodam nas minhas 30 publicações, abertos no construtor: copie condição por condição. A beehiiv chama hard bounce de Bounced e soft bounce de Deferred, dentro de Subscriber data e Engagement. Repare que no painel não existe um campo com o nome soft bounce: o que você procura se chama Deferred, o email que bateu, foi adiado e vai tentar de novo. Soft bounce é o nome do conceito; Deferred é o nome do botão. Em outra ferramenta de envio o caminho tem outro nome: procure por segmentos ou grupos dinâmicos. Se a sua não recalcula o segmento sozinho, refaça a filtragem à mão antes de cada limpeza. As quatro principais estão lado a lado no comparador de plataformas.

Hard bounce (30d): teve Bounced registrado nos últimos 30 dias, e zero aberturas de edição nos últimos 90 dias, e status ativo. A segunda condição é a trava contra o contador vitalício: bounce isolado de quem continua abrindo não entra.

Soft bounce (30d): teve Deferred duas vezes ou mais nos últimos 30 dias, e zero aberturas e zero cliques nos últimos 90 dias, e status ativo. O clique entra como segundo sinal de vida, porque abertura sem registro acontece, como o capítulo 7 mostrou, e quem clica está vivo mesmo quando o pixel não carrega.

Fantasma (90d): nunca abriu email nenhum, contando edição, boas-vindas e automação (na beehiiv, a condição vive em Email data: Any email was not Opened), e entrou na lista há mais de 90 dias, e status ativo. A idade mínima protege o recém-chegado que ainda nem recebeu a segunda edição.

Zumbi (90d): já abriu algum email na vida (Any email was Opened), e zero aberturas de edição nos últimos 90 dias, e entrou há mais de 90 dias, e status ativo.

Três notas de quem já montou os quatro em dezenas de publicações. Nomeie com um prefixo comum e a janela no nome, como [LIMPEZA] Hard bounce (30d): a lista de segmentos é alfabética e o prefixo agrupa os quatro. Reclamação de spam não precisa de segmento, porque é o único evento que a plataforma já resolve sozinha, suprimindo e descadastrando o endereço na hora. E endereço com hard bounce confirmado já é filtrado automaticamente no momento do envio pela lista de supressão da plataforma: o segmento existe para você enxergar o tamanho do grupo e tirar os endereços da contagem de ativos, não para impedir o envio, que já está impedido.

O corte ingênuo contra o corte defensável

Aqui está o número mais útil deste capítulo, e ele veio de quase termos feito besteira.

Quando montamos a régua de limpeza pela primeira vez, a soma dos grupos de corte alcançava 6.145 pessoas em uma base de 39.010 ativos. Parecia uma faxina saudável de 15%.

Antes de executar, medimos endereço por endereço o que essas 6.145 pessoas realmente faziam. O resultado mudou a decisão inteira: 3.899 delas continuavam recebendo e abrindo, e 1.373 abriam mais de 20% das edições. Gente engajada dentro de um grupo chamado "para remover".

O corte de verdade defensável, o de quem não abre nada e não recebe nada, era de 81 pessoas. De 6.145 para 81, e o indicador de abertura geral nem se moveu.

A lição que ficou vale mais que a régua: conte antes de cortar, e olhe uma amostra na mão. Toda condição de limpeza parece óbvia até você abrir a lista e ver quem está lá dentro.

O que fazer com cada grupo

Hard bounce confirmado: remover. Não existe upside.

Soft bounce recorrente: suspender o envio por 30 dias e testar de novo com uma mensagem só. Voltou a abrir, volta para a base.

Fantasma: uma última tentativa em uma sequência curta de duas ou três mensagens, com assunto diferente do padrão. Quem não reagir sai. É o grupo que mais pesa contra você, porque lista com muita gente que nunca abre é o sinal mais claro de lista mal construída. Quando o fantasma vem em massa de campanha paga, a origem é anúncio mal segmentado, e quem trata da origem é o guia de tráfego pago pra newsletter.

Zumbi: campanha de reativação de verdade, com oferta ou conteúdo diferente. Nunca cortar sem tentar, porque essa pessoa já provou interesse uma vez.

O segmento que impede a queda

Um uso menos óbvio, e o que mais nos ajudou: segmento também serve para limitar quem recebe, não só para decidir quem sai.

Durante a recuperação do capítulo 10, cada edição saía apenas para um segmento de leitores liberados, montado pelo motor de cota, enquanto o resto da base esperava a vez em fila. O provedor via uma base pequena com engajamento alto, que é exatamente o oposto do que ele lê como disparo em massa.

Segmento deixa de ser relatório e vira freio de mão. É a peça de infraestrutura que separa quem sabe que a lista está ruim de quem consegue fazer alguma coisa a respeito.

▸ Ao terminar este capítulo, você tem os quatro segmentos de limpeza prontos para criar: hard bounce, soft bounce, fantasma e zumbi.

Capítulo 9

Cada provedor tem uma regra: Gmail, Outlook e Yahoo lado a lado

Até aqui o guia falou de "o provedor" no singular, por simplicidade. Na prática são três grandes com regras próprias, ferramentas próprias e temperamentos bem diferentes. Vale conhecer cada um, porque o mesmo envio pode ser bem tratado em um e recusado no outro.

Gmail, o que mais mede e o único que te mostra

O Gmail é o mais transparente dos três, e é onde mora a única ferramenta gratuita que mostra a sua reputação por dentro: o Google Postmaster Tools.

Você cadastra o domínio, prova a posse com um registro no DNS e passa a ver taxa de spam, reputação do domínio, autenticação e erros de entrega, com histórico. A nossa operação tem os 80 domínios cadastrados lá, e a taxa de spam do Postmaster virou o gatilho automático de alerta da operação.

A régua do Gmail, publicada por ele: quem envia mais de 5.000 mensagens por dia para contas Gmail precisa ter SPF, DKIM e DMARC, descadastro em um clique honrado em até dois dias, conexão segura e alinhamento de domínio no campo De. E a taxa de spam abaixo de 0,10%, sem nunca chegar a 0,30%.

Uma particularidade que confunde: o Gmail tem abas, e a de Promoções é caixa de entrada, como o capítulo 1 explicou. Perseguir a aba principal com truque de formatação costuma custar mais que rende.

Outlook, Hotmail e Live, o mais rigoroso na porta

A família Microsoft tem a fama de filtro agressivo e ela é merecida, com uma diferença de método: enquanto o Gmail classifica, a Microsoft rejeita.

Desde maio de 2025, domínio que envia mais de 5.000 mensagens por dia para Outlook, Hotmail ou Live e não passa em SPF, DKIM e DMARC alinhados recebe recusa na porta, com a mensagem 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Não é filtro de spam, é a conexão sendo negada.

A dureza tem um lado bom: você fica sabendo. A recusa volta como bounce e aparece no seu painel, ao contrário do silêncio da pasta de spam.

A ferramenta da casa é o SNDS, que mostra dados por endereço IP, e não por domínio. É útil para quem tem IP dedicado e pouco informativo para quem envia por plataforma compartilhada, que é o caso da maioria. A Microsoft também não publica corte numérico de taxa de reclamação, e este guia não cita nenhum: número sem fonte é chute com aparência de dado.

Yahoo, e a régua que mede só quem chegou

O Yahoo publicou as exigências junto com o Gmail em fevereiro de 2024, e a lista é praticamente a mesma: SPF e DKIM implementados, DMARC publicado com pelo menos p=none e passando, descadastro em um clique honrado em até dois dias, e taxa de spam abaixo de 0,3%.

Uma diferença que vale ler com atenção: o Yahoo diz explicitamente que a taxa é calculada sobre a mensagem entregue na caixa de entrada. Ou seja, o denominador exclui o que já foi para o spam. Uma taxa de reclamação aparentemente boa pode estar boa só porque pouca coisa chegou.

E os provedores brasileiros

Uma pergunta legítima de quem escreve em português: UOL, Terra, BOL e os provedores de hospedagem nacionais entram nessa conta?

Entram, com duas diferenças práticas. Eles somam uma fatia menor da base típica de newsletter brasileira, que é dominada por Gmail, e nenhum deles oferece ferramenta pública de reputação no nível do Postmaster Tools. Você não consegue ver a sua reputação com eles, apenas inferir pelo bounce e por conta de teste.

A boa notícia é que quase todos usam filtros de terceiros ou seguem a mesma cartilha dos grandes. Autenticação correta, lista limpa e crescimento sem degrau resolvem os três grandes e, junto, resolvem quase todo o resto. Não existe otimização específica que valha a pena para provedor nacional além da conta de teste, e ter um endereço de teste em um provedor brasileiro na sua rotina é o suficiente.

O que muda na prática

Três leituras que a nossa operação confirma.

A autenticação é a mesma para os três. Configurar uma vez resolve todos, e é a razão de ela vir antes de qualquer outra coisa.

A punição é diferente. A Microsoft nega na porta e devolve erro, o Gmail engole e classifica em silêncio, o Yahoo fica no meio. O Outlook parece o pior dos três e é, de certa forma, o mais honesto.

A medição é desigual. Só o Gmail te mostra a sua reputação por domínio de graça. É a razão de o capítulo 11 pôr o Postmaster no topo da rotina.

E vale a advertência sobre um assunto que sempre aparece nessa conversa: as listas de bloqueio públicas, as chamadas blacklists. Elas existem, e estar em uma delas atrapalha, mas elas são muito menos importantes do que a internet sugere para quem envia por plataforma. Se você não opera servidor próprio, a chance de o seu problema ser uma lista de bloqueio é pequena, e a de ser reputação de domínio é enorme. Perseguir blacklist antes de olhar reputação é procurar a chave debaixo do poste.

▸ Ao terminar este capítulo, você sabe o que Gmail, Outlook e Yahoo cobram de diferente, e para qual deles ajustar primeiro.

Capítulo 10

Quando a lista já queimou: o caminho de volta que a nossa operação andou

Este é o capítulo que nenhum guia de entregabilidade em português consegue escrever, porque exige ter queimado a própria lista e medido a volta. Nós queimamos, em agosto de 2026, e o registro está aqui inteiro.

O que aconteceu

Nós lançamos um bloco de newsletters novas e ligou uma máquina de recomendação cruzada entre elas: quem assinava uma via, logo depois de confirmar, uma lista de sugestões das outras. Em poucos dias, publicações que enviavam para dezenas de pessoas passaram a enviar para centenas.

O painel não acusou nada. As taxas de entrega seguiram entre 97% e 100% o tempo todo.

Em 11 de agosto, uma sonda que lê o rótulo real da mensagem em uma caixa do Gmail mostrou o tamanho do estrago: 28 newsletters com a edição inteira na pasta de spam. Na medição do dia seguinte, com a janela de 7 dias, eram 31 de 80.

A causa não foi conteúdo, e essa é a parte contraintuitiva. Foi padrão de crescimento. O leitor que chegava pela recomendação cruzada clicava por curiosidade, sem conhecer a marca, e quase nunca abria. O filtro do Gmail viu o desenho que ele mais reconhece: base que salta de tamanho, cheia de gente que não abre. Lista comprada tem exatamente essa assinatura, e o filtro não pergunta a origem.

A cura, em quatro peças

1. Cota de crescimento de 20% ao dia. Nenhuma publicação passou a aceitar mais leitores novos por dia que 20% da base já liberada. O provedor deixa de ver degrau e passa a ver curva composta, que é como uma lista orgânica cresce.

2. Envio limitado ao segmento liberado. Não bastava capar a entrada: a edição passou a sair apenas para quem já estava liberado, com o resto da base em fila. Foi a peça que o provedor efetivamente enxergou.

3. Fila ordenada por sinal. Quem entra primeiro não é quem chegou primeiro, e sim quem dá o sinal mais forte: leitor que veio pelo próprio conteúdo antes de quem veio por recomendação, e leitor que abre antes de quem nunca abriu.

4. Sonda diária com gate automático. Todo dia, às 21:30, um script confere em qual pasta a edição de cada publicação caiu. Sete medições limpas seguidas graduam a publicação, que sai do regime de cota. Uma única medição em spam revoga tudo e recomeça a contagem. Nenhuma decisão fica dependendo de alguém lembrar de olhar.

O estado da operação em 12 de agosto de 2026, sem retoque: 30 newsletters no regime, 28 ainda com o freio de spam armado, 139 leitores liberados e 2.050 na fila. A recuperação é lenta de propósito, e a fila grande é o preço da pressa anterior.

O que fazer se você está em spam agora

A ordem importa, e ela é a mesma que funcionou aqui.

Pare de enviar para quem não abre. Segmente a base e mande só para quem abriu nos últimos 30 ou 60 dias. Uma lista menor com engajamento alto reconstrói reputação; uma lista grande com engajamento baixo cava mais fundo.

O outro lado do mesmo conserto é a mensagem. Quem abre e clica manda pro provedor exatamente o sinal que reconstrói reputação, e o que faz abrir e clicar está medido no guia de copywriting para email, com 1.627 edições da mesma rede.

Autentique tudo, hoje. Os capítulos 3, 4 e 5 são pré-requisito, não paralelo.

Volte a crescer devagar. Cota de 20% ao dia é a régua que usamos e ela é conservadora de propósito. O erro clássico da recuperação é voltar ao volume normal assim que a primeira edição chega na caixa.

Meça na caixa, não no painel. Uma conta de teste que assina a sua própria newsletter, conferida a cada envio. Sem essa medição você está tratando um paciente sem termômetro.

Cadastre o domínio no Postmaster Tools. É onde você vê a curva de reputação subindo, e é o que diz se o trabalho está funcionando antes de a caixa mostrar.

Espere semanas, não dias. Reputação se perde em uma semana e se reconstrói em um mês ou dois, e não existe atalho pago para acelerar. Quem vende atalho está vendendo IP novo, que é trocar de domínio com outro nome e recomeçar o mesmo problema.

▸ Ao terminar este capítulo, você tem o diagnóstico da lista queimada: a causa provável, o capítulo que resolve e a ordem de ataque.

Capítulo 11

A rotina de quem não volta pro spam

Entregabilidade não é projeto com data de fim, é manutenção. A boa notícia é que a manutenção é curta: depois da autenticação feita, o trabalho recorrente cabe em minutos por semana.

A cada envio

Olhe três números na mesma tela: taxa de reclamação de spam, descadastros e bounces. Você já sabe as réguas do capítulo 7, e o que importa aqui é o desvio do seu próprio padrão, não o valor absoluto. Uma edição com o dobro do descadastro habitual tem alguma coisa a dizer sobre aquela edição.

Toda semana

Abra o Postmaster Tools. Dois minutos. A curva de reputação de domínio e a de taxa de spam contam a história antes de a caixa contar.

Confira onde a sua edição caiu. A conta de teste que assina a sua própria newsletter, conferida uma vez por semana, é o instrumento mais barato deste guia inteiro. Se você manda para mais de mil pessoas, vale ter três contas de teste: uma no Gmail, uma no Outlook e uma no Yahoo.

Todo mês

Rode a limpeza. Os quatro grupos do capítulo 8, com a régua cruzada, e o cuidado de contar antes de cortar.

Confira o SPF. Cinco segundos no verificador do capítulo 5, e serve para pegar o serviço que alguém acrescentou sem avisar e o limite de dez buscas chegando perto.

Leia um relatório de DMARC. Você não precisa ler todos. Um por mês, olhando se apareceu servidor novo enviando em seu nome, já cumpre o papel.

Uma vez por trimestre

Reveja quem envia em seu nome. Ferramenta contratada, plugin do site, sistema de nota fiscal. Serviço aposentado que continua no SPF é a causa silenciosa mais comum de problema futuro.

Suba um degrau no DMARC, se ainda não estiver em p=reject e os relatórios estiverem limpos.

A fronteira: email transacional é outro bicho

Vale marcar onde este guia acaba, porque a confusão gera decisão errada.

Email transacional é o disparado por uma ação da pessoa: confirmação de compra, recuperação de senha, recibo, aviso de entrega. Ele é um por vez, esperado, e tem abertura altíssima justamente por ser esperado.

Três coisas mudam. A autenticação é a mesma, e os capítulos 3, 4 e 5 valem inteiros. A régua é outra, porque taxa de reclamação em transacional é sempre próxima de zero e qualquer número acima disso indica problema sério. E o caminho de envio deve ser separado: use um subdomínio ou um serviço só para transacional, porque a mensagem que a pessoa está esperando não pode ficar refém da reputação da sua campanha de marketing.

Quem manda os dois tipos pelo mesmo domínio e pela mesma plataforma tem em separar o próximo passo natural depois de fechar tudo que este guia cobriu.

O que fazer no próximo mês

Se você leu até aqui e ainda não fez nada, a ordem é esta, e ela cabe em uma tarde mais um mês de paciência.

Hoje: rode o seu domínio no verificador do capítulo 5 e anote os três vereditos.

Esta semana: publique o que faltou, na ordem SPF, DKIM e DMARC em p=none. Assine a sua própria newsletter em uma conta limpa do Gmail.

Este mês: cadastre o domínio no Postmaster Tools, rode a primeira limpeza de lista com a régua cruzada do capítulo 8, e leia o primeiro relatório de DMARC.

Nos próximos três meses: suba o DMARC para quarantine e depois para reject, e faça da conferência semanal de caixa um hábito.

Nada aqui é difícil. Tudo aqui é chato, e é exatamente por ser chato que a maioria não faz. Quem faz entrega em caixa de entrada enquanto o concorrente escreve melhor e não é lido.

Se você chegou aqui pesquisando por que o seu email cai no spam, a resposta honesta é que quase sempre são as três causas do capítulo 1 juntas, e que as três têm conserto. A parte que dói é aceitar que a lista precisa encolher antes de voltar a crescer.

Entregabilidade é uma camada da operação, não a operação inteira: ela mora dentro do C1, a infra, a primeira das quatro camadas que a máquina empilha. Quem compra tráfego antes de a carta chegar na caixa paga por leitor que nunca vai ver a edição, e a ordem entre as quatro está no guia da metodologia dos 4Cs, o método em quatro camadas. Quem está montando a newsletter agora encontra o resto do caminho no guia da newsletter, o hub da categoria, e quem já entrega na caixa e quer transformar a lista em receita tem a conta do anúncio no guia de mídia kit e patrocínio.

E quem vai crescer a lista tem os motores medidos, um a um, no guia de captação de leads no orgânico, com o mix de origem medido na mesma rede. Leia os dois juntos: o capítulo 10 daqui é exatamente o preço de crescer rápido sem olhar para quem chega, porque base que salta de tamanho cheia de gente que não abre tem a mesma assinatura que o filtro aprendeu a chamar de lista comprada.

E quem transforma a lista em contrato, e não em anúncio, tem a caixa de entrada dentro do preço da venda. A proposta comercial é o email mais caro que você manda: um por vez, esperado do outro lado, e sem segunda chance. Quando ele para na pasta de spam, ninguém responde "não recebi"; o silêncio passa por desinteresse do cliente e a venda morre sem diagnóstico. O funil inteiro está no guia de venda de serviços pela newsletter, com o pipeline medido da operação.

▸ Ao terminar este capítulo, você decidiu a rotina semanal que mantém o domínio fora do spam, e a marcou no calendário.

Escrito por Henrique Carvalho, que opera 30 newsletters e aprendeu entregabilidade do jeito caro, vendo 31 delas caírem no spam no mesmo dia.

Capítulo 12

Perguntas frequentes sobre entregabilidade e caixa de entrada

Fontes e data de auditoria

Todo número deste guia foi medido em fonte própria ou lido na documentação oficial do provedor, com a janela declarada do lado. Nada aqui é estimativa de mercado.

Medição de caixa (12/08/2026). Rótulo real da mensagem em uma conta do Gmail que assina as nossas publicações, janela de 7 dias: 89 newsletters medidas, 80 com mensagem, 15 na caixa principal, 24 em Promoções, 31 em spam, 2 na lixeira e 8 em outros rótulos.

Painel de envio (30 dias até 12/08/2026). 1.093 edições confirmadas, 1.952.853 envios, 1.942.396 entregues, taxa de entrega agregada de 99,46%, 184 reclamações de spam (0,0095%) e 4.406 descadastros (0,227%).

Censo de lista (02/08/2026). 40 publicações com os grupos de limpeza vivos: 252 hard bounce, 842 soft bounce, 415 fantasmas e 1.102 zumbis.

Análise de corte (13/07/2026). 39.010 assinantes ativos na operação, 6.145 alcançados pela régua ingênua de limpeza, 3.899 deles ainda recebendo e abrindo, 1.373 abrindo mais de 20%, e 81 no corte defensável. Dos 2.013 com hard bounce registrado, 1.540 continuavam ativos.

Motor de cota (12/08/2026). 30 newsletters no regime de crescimento capado, 28 com o freio de spam armado, 139 leitores liberados e 2.050 na fila, com cota diária de 20%.

Régua dos provedores (lida em 12/08/2026). Requisitos de remetente em massa do Gmail, requisitos de remetente do Yahoo e o anúncio de requisitos para remetentes de alto volume do Outlook, cada um na documentação oficial do próprio provedor.