Voltar pro blog json-p.org

PilarEntregabilidade de email Publicado8 de outubro de 2026 AutorElton

Aquecimento de domínio de email: como fazer sem queimar o remetente

Aquecimento de domínio de email: por que domínio autenticado ainda cai no spam, a rampa de volume que funciona e como monitorar sem queimar o remetente.

Você fez a lição de casa. SPF com um registro só, DKIM assinando com o seu domínio, DMARC publicado, e no "Mostrar original" do Gmail aparece tudo PASS. Aí comprou um domínio novo pro lançamento (ou criou o subdomínio de envio separado, como manda o figurino), importou os 18 mil leads do último lançamento e disparou o "carrinho aberto" no domingo às 20h.

Segunda de manhã: abertura de 4%, suporte lotado de aluno dizendo que o acesso não chegou, gente mandando print da pasta de spam. E você olhando o cabeçalho, que continua todo verde, sem entender o que deu errado.

O que deu errado é que autenticação e reputação são coisas diferentes. No post sobre SPF, DKIM e DMARC eu deixei o aquecimento de domínio pra depois. Chegou a hora. SPF, DKIM e DMARC provam quem está mandando. Não dizem nada sobre se esse alguém merece confiança. E um domínio que nasceu semana passada e solta 18 mil emails num domingo à noite parece exatamente o que um spammer faz.

A resposta curta: o que é aquecimento de domínio de email

Aquecimento de domínio de email é construir histórico de envio antes de precisar dele. Gmail, Outlook e companhia decidem entre caixa de entrada e spam olhando o passado do remetente: quanto ele costuma mandar, com que regularidade, quanta gente reclama, quanto volta como bounce e quanta gente interage. Domínio novo não tem passado, então começa sob suspeita. O processo: volume baixo no começo, primeiro pra quem mais engaja, subindo aos poucos num ritmo constante, olhando os sinais todo dia e freando quando pioram. Leva semanas, não dias: a documentação do Amazon SES fala em duas a seis semanas pra construir reputação positiva, dependendo do provedor de caixa postal, e o aquecimento automático de IP dedicado do próprio SES roda em 45 dias. Não existe atalho que não passe por mandar email que as pessoas querem receber.

Autenticação prova quem você é, reputação diz se dá pra confiar

Pensa em autenticação como o crachá e em reputação como a ficha. O crachá (SPF, DKIM, DMARC alinhado) é o que permite ao Gmail pendurar a ficha no seu nome e não no de outro. Por isso autenticação vem antes: sem DKIM alinhado com o domínio do From, não tem nem em quem acumular reputação de domínio. Mas crachá válido com ficha vazia continua sendo ficha vazia.

Essa ficha fica presa a mais de um identificador. Os principais são o domínio (o que assina o DKIM e aparece no From) e o IP de onde o email sai. Dá pra ver isso nos próprios erros do Gmail: a mensagem de limitação por volume suspeito (código 421 4.7.28) tem variantes que citam o IP, a faixa de IPs, o domínio do DKIM ou do SPF, e até o domínio dos links dentro do email. Cada um desses carrega histórico próprio.

IP compartilhado ou dedicado muda o que você aquece

Aqui é onde a maioria dos tutoriais mistura tudo. Depende de por onde o seu email sai:

Pro infoprodutor isso tem consequência direta. Quem manda 30 mil na semana do lançamento e passa as três seguintes quase calado é o pior perfil pra IP dedicado: o pico pede IP próprio, o silêncio derruba ele. Pra esse padrão, IP compartilhado de provedor sério com domínio bem aquecido costuma ser mais seguro.

O que "queimar o remetente" quer dizer, em número

Queimar é ensinar o filtro do provedor que o seu email é indesejado. São três sinais, e só dois deles têm número público.

Reclamação de spam. É o clique em "denunciar spam". O Gmail pede, na diretriz de remetentes, taxa de spam abaixo de 0,1% e que você nunca chegue a 0,3%. Traduzindo: 0,3% são 3 denúncias a cada mil emails. Numa lista de 10 mil, 30 pessoas irritadas te colocam na linha vermelha. O provedor de envio também vigia isso do lado dele: o Amazon SES coloca a conta em revisão a partir de 0,1% de reclamação e pode pausar o envio a partir de 0,5%.

Bounce. O hard bounce é o endereço que não existe mais. Lista de lançamento de dois anos atrás está cheia deles, e endereço abandonado há muito tempo pode ter virado armadilha de spam (spam trap), que existe pra pegar quem manda pra lista velha. O SES pede bounce abaixo de 2%, abre revisão a partir de 5% e pode pausar a partir de 10%.

Engajamento. Ninguém abre, clica, responde ou tira da pasta de spam. Não existe número público pra isso, e quem te der um limiar exato está inventando. Mas é o motivo de lista fria ser tão destrutiva: mesmo sem reclamação, o silêncio ensina o filtro.

A consequência vem em degraus. O primeiro é silencioso: o email cai em spam ou promoções e você só percebe pela abertura despencando. Depois o Gmail passa a adiar a entrega, e aparece no log do provedor algo nessa linha (trecho):

421-4.7.28 Gmail has detected an unusual rate of unsolicited mail
originating from your DKIM domain [mail.seudominio.com.br].
To protect our users from spam, mail ... has been temporarily
rate limited.

Esse 421 é temporário, o servidor tenta de novo mais tarde. Ele é o aviso. Se você ignora e continua empurrando volume, o próximo degrau é rejeição e caixa de entrada perdida por semanas. Reputação queima num domingo e leva semanas pra reconstruir.

A rampa de volume na prática

O próprio Google resume a regra em três frases na diretriz de remetentes: comece com volume baixo pra usuários engajados e aumente devagar; mande num ritmo constante, sem rajadas; evite picos repentinos se você não tem histórico de volume alto. O resto é execução.

Um exemplo de rampa pra chegar a 20 mil por dia, começando com 100:

dias    volume/dia   quem recebe
1-3        100       compradores dos últimos 30 dias
4-6        200       + quem clicou nos últimos 30 dias
7-9        400       idem, mais fundo no segmento
10-12      800       + clicou entre 30 e 60 dias
13-15    1.500       + clicou entre 60 e 90 dias
16-18    3.000       idem
19-21    6.000       + interagiu nos últimos 6 meses
22-24   12.000       idem
25+     20.000       lista ativa inteira (sem os mortos)

Isso dá umas quatro semanas, e é ilustração, não regra de provedor. A documentação do SendGrid, por exemplo, sugere começar com até 50 no primeiro dia e dobrar a cada dia de envio. O que importa não é o número exato de cada degrau, e sim três coisas: no máximo dobrar, nunca pular degrau e só subir quando os sinais do degrau atual estiverem limpos.

Essa última parte é a que todo mundo pula. A decisão de subir ou segurar cabe numa função de dez linhas rodando num cron, lendo as métricas que o seu provedor de envio já te entrega (bounce, reclamação via feedback loop, adiamentos 4xx por destino):

// m = métricas das últimas 48h vindas do provedor de envio
function proximoVolume(atual, m, alvo) {
  if (m.reclamacao >= 0.003 || m.bounce >= 0.05 || m.adiados4xx >= 0.05) {
    return Math.max(100, Math.floor(atual.volume / 2)); // freia forte
  }
  if (m.reclamacao >= 0.001 || m.bounce >= 0.02 || m.adiados4xx >= 0.01) {
    return atual.volume;                                 // segura o degrau
  }
  if (atual.diasNoDegrau < 3) return atual.volume;      // degrau mínimo
  return Math.min(atual.volume * 2, alvo);               // sobe
}

Os limites de reclamação e bounce saem das diretrizes que citei acima. Os de adiamento 4xx (1% segura, 5% freia) são número meu, de operação, não regra publicada por ninguém: ajuste pro seu caso, mas tenha algum. Eu automatizei essa mesma lógica (degrau, freio e segmento por engajamento) no mailforge, a infraestrutura de envio que estou construindo, mas nada aqui depende dela. Uma planilha, uma consulta no banco e um cron fazem o mesmo trabalho.

Quem recebe primeiro

A ordem da lista importa tanto quanto o volume. Nos primeiros degraus você quer quem tem mais chance de clicar e não denunciar, porque esse comportamento vira histórico: quem comprou recentemente, quem clicou recentemente, e só depois o resto. A documentação do SES diz o mesmo: no aquecimento, mande pros usuários mais ativos pra manter a reclamação baixa. E quem não abre nem clica há vários meses a AWS sugere considerar remover. Faça esse corte antes da rampa, não no meio dela.

Se a sua base está num Postgres, o segmento do primeiro degrau é uma consulta:

SELECT email
FROM contatos
WHERE descadastrado = false
  AND hard_bounce = false
  AND (ultima_compra >= now() - interval '30 days'
       OR ultimo_clique >= now() - interval '30 days')
ORDER BY greatest(ultima_compra, ultimo_clique) DESC
LIMIT 100;

Repara que o critério é clique e compra, não abertura. Abertura virou métrica poluída desde que o Apple Mail passou a pré-carregar as imagens do email (a Proteção de Privacidade do Mail), o que dispara o pixel sem ninguém ter lido nada. Clique, resposta e compra são sinais que um humano produziu.

Um detalhe a favor do infoprodutor: email transacional (compra aprovada, acesso à área de membros) é o mais engajado que existe, porque a pessoa está esperando por ele. O próprio fluxo de vendas aquece o subdomínio transacional. Quem precisa de rampa cuidadosa é o subdomínio de marketing, o do disparo de lançamento.

Como monitorar durante o aquecimento

Google Postmaster Tools, e o que mudou nele

O Postmaster Tools é o painel do Google pro remetente: você verifica o domínio com um registro TXT e passa a ver taxa de spam, autenticação, erros de entrega, feedback loop e o painel de conformidade (Compliance status), que cruza o seu envio com as exigências de remetente do Gmail.

Atenção a um ponto que muito tutorial ainda não atualizou: o Google anunciou a aposentadoria dos painéis de reputação de domínio e de IP (aquele "alta, média, baixa, ruim") na versão 2 do Postmaster, com o argumento de que reputação é difícil de transformar em ação e demora a refletir mudança de comportamento. Se o guia que você segue manda acompanhar a "reputação do domínio" ali, essa tela pode nem existir mais na sua conta. O número que importa agora é a taxa de spam, com os mesmos 0,1% e 0,3%.

E o painel só mostra dado quando o volume diário pro Gmail é grande o bastante (o Google não publica o mínimo). Nos primeiros degraus ele vai ficar vazio, e isso é normal. Nessa fase quem te dá sinal é o provedor de envio e o relatório de DMARC.

Microsoft SNDS e JMRP, só se o IP for seu

O SNDS é o painel da Microsoft pra Outlook.com e Hotmail, e o JMRP é o feedback loop de reclamações de lá. Os dois são centrados em IP: você pede acesso pras faixas que controla. Só fazem sentido com IP dedicado; em IP compartilhado quem acompanha é o provedor. A Microsoft mexeu no portal e no formato do JMRP em 2026, então confira o endereço atual antes de confiar em link velho. E desde maio de 2025 ela exige SPF e DKIM passando e DMARC publicado (pelo menos p=none, alinhado) de quem manda mais de 5 mil emails por dia pro Outlook.com, que é o volume de um dia de lançamento.

Relatório agregado de DMARC: o que mostra e o que não mostra

Se você seguiu o post anterior, o seu registro DMARC tem um rua= e você recebe todo dia um XML de cada provedor grande. Um registro típico, mascarado:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>mail.seudominio.com.br</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mail.seudominio.com.br</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.provedor-de-envio.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Lendo: 412 mensagens saíram do IP 203.0.113.25 com o seu domínio no From. O SPF passou, mas pro domínio de bounce do provedor, então não alinhou (por isso o fail em policy_evaluated). O DKIM passou e alinhou com o seu domínio, e isso basta pro DMARC passar. É o quadro normal de quem usa provedor de envio.

Durante o aquecimento esse XML serve pra três coisas:

O que ele não mostra: se caiu na caixa de entrada ou no spam. DMARC pass só quer dizer que autenticou. Relatório todo verde com abertura no chão é o retrato do domínio autenticado sem reputação, o cenário do começo deste post.

Domínio novo do zero ou migração de provedor

São dois aquecimentos diferentes, e tratar um como o outro é erro caro.

Domínio novo. Zero histórico, e domínio recém-registrado já é por si um sinal que filtro de spam olha com desconfiança, porque domínio descartável é ferramenta clássica de spammer. Registre e configure o DNS com folga, e rode a rampa inteira antes do lançamento. Se o lançamento é daqui a 15 dias e o domínio é de ontem, a conta não fecha (mais sobre isso abaixo).

Migração de provedor. O domínio já tem ficha, e a parte presa ao domínio vai com você. O que não vai é a parte presa à infraestrutura: o IP novo (dedicado, ou o pool compartilhado do provedor novo, com a reputação que ele tiver) e a assinatura DKIM com seletor novo. Então migração é rampa de divisão de tráfego, não de volume total: o volume do dia continua o mesmo, muda a fatia que passa pelo provedor novo. Comece com uns 10%, sempre os segmentos mais engajados, e aumente a fatia em degraus ao longo de algumas semanas enquanto o antigo carrega o resto. É o raciocínio do aquecimento automático do SES, que divide o envio entre IPs já aquecidos e os novos. Mantenha o DKIM e o include de SPF do provedor antigo até o fim; tirar antes quebra a autenticação do que ainda sai por lá.

E se você está migrando justamente porque cai no spam: a reputação presa ao domínio vai junto. Trocar de provedor não lava domínio queimado. Arrume a causa (lista, frequência, conteúdo) antes de mudar de casa.

O que dá errado

Fechando

Autenticação dá um nome ao seu email; aquecimento dá histórico a esse nome. Pouco volume, pra quem quer receber, subindo devagar e num ritmo constante, olhando bounce, reclamação e adiamento todo dia e freando sem dó quando piora. Começa semanas antes do lançamento, não na véspera. É chato e é lento, e é a diferença entre o email de acesso cair na caixa de entrada ou no suporte lotado de segunda de manhã.

Fontes primárias consultadas em 08/10/2026: diretrizes de remetente do Gmail (taxa de spam, ritmo de volume, IP compartilhado), aviso de descontinuação da interface antiga do Postmaster Tools, códigos de erro SMTP do Gmail, aquecimento de IP dedicado no Amazon SES, FAQ de revisão de envio do Amazon SES (limites de bounce e reclamação) e guia de warmup do SendGrid. Mudanças de 2026 no SNDS/JMRP checadas em fontes de terceiros; confira no portal da Microsoft.