Entregabilidade de email em 2026 — os padrões, o warmup, o feedback loop.

§1 · Definição

O que entregabilidade de email realmente é.

Entregabilidade é a taxa com que suas mensagens enviadas chegam à caixa de entrada principal do destinatário — distinta de entrega (a mensagem foi aceita pelo servidor de email do destinatário) e de envio (você entregou ao pipeline de envio). Uma mensagem pode ser enviada com sucesso, entregue ao servidor de email do destinatário e terminar no spam — isso é sucesso de entrega e falha de entregabilidade. Os números com que as pessoas se importam — taxa de abertura, taxa de clique, conversão — dependem de entregabilidade, não de entrega.

Provedores de caixa de entrada — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, os principais provedores regionais — cada um roda um pipeline de pontuação em múltiplos estágios contra cada mensagem que chega. Os estágios são aproximadamente os mesmos entre os provedores, com diferenças de peso:

1. Checagens em tempo de conexão. DNS reverso, sanidade de HELO/EHLO, suporte a TLS, listagem do IP em RBLs (Spamhaus, SpamCop, etc).
2. Checagens de autenticação. SPF pass/fail (RFC 7208), validação de assinatura DKIM (RFC 6376), alinhamento DMARC (RFC 7489). Todos os três precisam passar limpos para a pontuação mais branda lá na frente.
3. Pontuação de conteúdo. Densidade de palavras-chave de spam, reputação dos links, proporção imagem/texto, se o From-name combina com o From-address.
4. Lookup de reputação. O registro interno do provedor sobre seu IP de envio e seu From-domain — taxa histórica de bounce, taxa de reclamação, engajamento em envios anteriores.
5. Sinal de engajamento. O destinatário (ou destinatários da mesma coorte) abriu ou clicou em mensagens similares suas anteriormente? Engajamento recente é o sinal positivo individual mais forte.
6. Disposição. Caixa de entrada, aba Promoções (Gmail), pasta de spam ou rejeitar. A disposição alimenta a reputação de volta.

As cinco seções abaixo tratam dos estágios 2 (autenticação) e 4 (reputação). O estágio 1 é majoritariamente trabalho do relay de envio; os estágios 3 e 5 são decisões de conteúdo + audiência fora do escopo de um guia de entregabilidade. O estágio 6 é o output. Para um remetente comercial típico, acertar os estágios 2 e 4 leva você de 60–80% de inboxing para 95%+.

Este guia é escrito para operadores auto-hospedados porque é você que ajusta os botões. Em SaaS a plataforma abstrai a maior parte disso; em auto-hospedado você é dono do registro SPF, do par de chaves DKIM, da política DMARC, do cronograma de IP warmup. A boa notícia: os padrões são públicos e estáveis. A má: não tem atalho.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) é uma lista pública de endereços IP autorizados a enviar email em nome do seu domínio. Você publica como um único registro TXT no seu domínio de envio. Quando um provedor de caixa de entrada recebe uma mensagem dizendo ser de @suaempresa.com, ele faz lookup do registro SPF em suaempresa.com e pergunta: essa mensagem veio de um dos IPs listados? Se sim, SPF passa. Se não, SPF falha.

A sintaxe

v=spf1 include:amazonses.com ~all

Lê-se: "SPF versão 1, autorize qualquer coisa que o Amazon SES autorize, soft-fail qualquer outra coisa". O ~all no final é a cláusula catch-all. ~all = soft-fail (marca suspeito mas aceita), -all = hard-fail (rejeita), ?all = neutro (sem opinião). Use ~all até o DMARC estar saudável, depois aperte para -all.

Múltiplos remetentes (ex.: Google Workspace para saída + SES para marketing + Mailgun para transacional) encadeiam com múltiplos mecanismos include::

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

O limite de 10 DNS lookups. RFC 7208 §4.6.4 limita a resolução SPF a 10 DNS lookups no total. Cada include: conta como um. Falha comum: encadear 5+ fornecedores e estourar o limite, depois do que o SPF resolve para permerror e é tratado como falha. Audite com dig TXT suaempresa.com + um SPF flattener se estiver perto do limite.

SPF no AcelleMail

O model SendingDomain do AcelleMail expõe getSpf() em app/Model/SendingDomain.php:154, que lê a configuração global spf_record e renderiza o valor do registro TXT. O método verifySpf(string $ipOrHostname) na linha 363 envelopa a biblioteca Mika56\SPFCheck — consulta o DNS ao vivo em runtime e afirma RESULT_PASS. A superfície de verificação na UI admin mostra verde quando o registro está presente e autoriza o IP de envio, vermelho caso contrário.

Dica prática: o SPF só autentica o envelope sender (o MAIL FROM em nível SMTP), não o cabeçalho From visível. Essa distinção é o que o alinhamento DMARC corrige — veja §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) anexa uma assinatura criptográfica a cada mensagem de saída. O servidor receptor busca sua chave pública num registro TXT no DNS, verifica a assinatura contra cabeçalhos específicos da mensagem e o corpo, e aceita a mensagem como autêntica se a matemática funciona. SPF diz "esse IP tem permissão para enviar por nós"; DKIM diz "esse corpo e cabeçalho From não foram adulterados desde que assinamos".

O mecanismo

1. Você gera um par de chaves RSA (mínimo 1024 bits, 2048 bits recomendado para novos setups).
2. A chave pública vai para o DNS como registro TXT em {selector}._domainkey.{seudominio}. O selector é uma string arbitrária (ex. k1, mail, 20251208) que você escolhe para permitir rotacionar chaves sem quebrar mensagens em trânsito.
3. A chave privada fica no seu servidor de envio. O MTA (ou relay de envio) assina cada mensagem de saída com ela, adicionando um cabeçalho DKIM-Signature.
4. O servidor de email do destinatário lê os valores d= (domínio) e s= (selector) do cabeçalho da assinatura, faz lookup de {s}._domainkey.{d}, busca a chave pública e verifica.

DKIM no AcelleMail

SendingDomain::generateDkimKeys() em app/Model/SendingDomain.php:221 gera um par de chaves RSA de 1024 bits via os bindings OpenSSL do PHP, guarda a metade privada em dkim_private e a metade pública em dkim_public. O selector é lido de dkim_selector no model, com fallback para a configuração global dkim_selector. O valor do registro DNS renderiza via $this->getDomain()->getDkimDnsRecord() (linha 270) e é mostrado ao operador com um botão de copiar ao lado de "o valor a publicar".

O padrão de geração de chave (de generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verificação: $this->getDomain()->verifyDkim() consulta o DNS em {selector}._domainkey.{domain} e compara a chave pública publicada com o valor armazenado localmente. O método verify() completo no model orquestra checagens de identidade + DKIM + SPF + DMARC em uma única chamada (linha 300).

DKIM gerenciado pelo fornecedor

Se você envia pelo Amazon SES, SendGrid, Mailgun ou qualquer outro fornecedor que assina do lado deles, você publica o selector + chave pública do fornecedor em vez de gerar a sua. A capacidade SignsDkimOnServer no nível do driver do AcelleMail (veja app/SendingServers/Capabilities/SignsDkimOnServer.php) marca drivers que cuidam de DKIM remotamente; a UI então mostra os registros CNAME do fornecedor para publicar em vez de gerar um par de chaves local. O SES usa três CNAMEs que delegam _domainkey para amazonses.com — configure uma vez e o SES rotaciona a chave subjacente para você.

§4 · DMARC

DMARC — alinhamento, política e relatórios.

DMARC (RFC 7489) fica em cima do SPF e do DKIM. Faz três coisas que SPF e DKIM individualmente não fazem:

1. Alinhamento. Exige que o domínio do envelope validado por SPF ou o domínio de assinatura DKIM combine com o domínio do cabeçalho From visível. Sem alinhamento, SPF e DKIM podem passar para um domínio diferente do que o destinatário vê — o gap que phishing explora.
2. Política. Diz aos servidores receptores o que fazer quando o alinhamento falha: none (não faça nada, só relate), quarantine (entregue no spam), reject (recuse a mensagem no SMTP).
3. Relatórios. Relatórios agregados (RUA — relatórios XML diários de todos os envios do seu domínio) e relatórios forenses (RUF — relatórios individuais por falha) enviados para os endereços que você especificar. Os relatórios dão visibilidade sobre quem está mandando email se dizendo você.

A sintaxe

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Lê-se: "DMARC versão 1, ponha em quarentena mensagens que falham o alinhamento, envie relatórios agregados para dmarc@suaempresa.com, aplique a política a 100% das mensagens falhando, exija alinhamento estrito tanto para SPF quanto para DKIM".

O rollout padrão

1. Dia 0: publique p=none com rua= apontando para uma caixa monitorada. Aceite relatórios por 7–14 dias. Isso é só observação — nenhuma mensagem é rejeitada.
2. Dia 14: revise os relatórios. Identifique remetentes legítimos (seu próprio SES, os IPs de envio do seu CRM, provedores transacionais) e traga todos para o alinhamento SPF + DKIM.
3. Dia 30: aperte para p=quarantine; pct=10. Email desalinhado vai para o spam de 10% dos destinatários. Observe os relatórios por duas semanas.
4. Dia 45: escale para pct=50, depois pct=100 ao longo de 2–4 semanas.
5. Dia 60–90: aperte para p=reject. Agora email desalinhado faz bounce no SMTP — phishers usando seu domínio veem hard rejects.

Não pule o rollout. Ir direto de nenhum DMARC para p=reject é a causa mais comum de desastre auto-infligido de entregabilidade: um remetente transacional esquecido (seu CRM, sua ferramenta de suporte, seu sistema de billing) começa a bouncear hard no momento em que p=reject propaga.

Mandatos dos provedores de caixa de entrada

Desde fevereiro de 2024, Gmail e Yahoo exigem DMARC para qualquer remetente que envia > 5.000 mensagens por dia para seus domínios, além de SPF ou DKIM alinhado, mais List-Unsubscribe de um clique (RFC 8058). O Microsoft 365 está alinhado com o mesmo padrão neste momento. A barra para "envio comercial" se moveu permanentemente — DMARC não é mais opcional para qualquer lista acima de ~1.000 contatos. Configure cedo, mesmo que sua lista ainda seja pequena.

§5 · BIMI

BIMI — o bônus do logo da marca.

BIMI (Brand Indicators for Message Identification) exibe o logo da sua marca ao lado das suas mensagens na caixa de entrada do destinatário. Gmail, Yahoo, Apple Mail e Fastmail suportam desde 2025. É um recurso adjacente a entregabilidade — não autenticação propriamente — mas exige DMARC em p=quarantine ou p=reject como pré-requisito, e é por isso que ele vive neste guia.

Passos de setup (depois que o DMARC estiver em quarantine ou mais estrito):

1. Crie uma versão SVG do seu logo seguindo a spec BIMI SVG Tiny PS — quadrada, sem texto fora da marca, paths simples.
2. Hospede o SVG em uma URL HTTPS acessível publicamente.
3. Opcionalmente, obtenha um Verified Mark Certificate (VMC) de uma CA — exigido pelo Gmail para exibir o badge com o check azul, ~$1.500/ano. Common Mark Certificates (CMC) são uma alternativa mais barata para marcas não registradas.
4. Publique o registro BIMI: default._bimi.suaempresa.com TXT "v=BIMI1; l=https://seucdn/logo.svg; a=https://seucdn/vmc.pem"

O impacto do BIMI em entregabilidade é indireto mas mensurável: logos de marca na caixa de entrada elevam taxas de abertura em 5–20% em estudos de caso publicados (dados do piloto do Yahoo Mail, relatório BIMI do Mailchimp). Também é uma forte função forçante — você não consegue ativar BIMI sem antes endurecer o DMARC, então os times usam isso como cenoura para uma faxina de autenticação.

§6 · Reputação

Reputação — o que os provedores de caixa de entrada realmente pontuam.

Autenticação é binária — um registro ou resolve e alinha, ou não. Reputação é contínua: uma pontuação de 0 a 100 mantida por cada provedor de caixa de entrada, contra seu IP de envio e seu From-domain independentemente. As duas pontuações se combinam na decisão de roteamento (inbox vs Promoções vs spam vs reject).

Os sinais

Onde ler sua pontuação de reputação

• Google Postmaster Tools (postmaster.google.com) — reputação de IP e domínio pela visão do Gmail, mais conformidade de autenticação, taxa de criptografia, taxa de spam. Grátis.
• Microsoft SNDS (postmaster.live.com/snds/) — dados em nível de IP do Outlook.com, classificações de reputação do remetente. Grátis, exige cadastro.
• Yahoo Sender Hub — mais novo, cadastro via página Yahoo Postmaster. Estatísticas agregadas por domínio.
• Dashboards de provedor — o Reputation Dashboard do Amazon SES expõe taxas de bounce + reclamação com thresholds. SparkPost, Mailgun, SendGrid todos têm dashboards similares.

Cheque pelo menos um por semana. Os indicadores líderes (tendência da taxa de spam, queda da reputação do IP) aparecem dias antes dos efeitos a jusante (taxa de abertura caindo) — quando você nota uma campanha sub-performando, o problema de reputação já tem duas semanas.

§7 · IP warmup

IP warmup — o cronograma de 6 semanas.

Um IP de envio novo começa com reputação zero. Provedores de caixa de entrada fazem throttle de volumes altos vindos de IPs novos por design — é a defesa principal contra snowshoe spammers subindo instâncias na nuvem e disparando. Warmup é a prática de aumentar gradualmente o volume de envio ao longo de 4–6 semanas, ficando dentro dos limites por dia e por hora de throttle, construindo reputação organicamente.

Você só faz isso uma vez por IP. A maioria dos times nunca faz porque os IPs compartilhados do Amazon SES, SendGrid e Mailgun vêm pré-aquecidos. Os casos em que warmup importa: IP dedicado no SES (tipicamente > 1M envios/mês justifica um), MTA Postal auto-hospedado em uma instância de nuvem nova, migração de um ESP para outro com mudança de domínio.

O cronograma

Cronograma baseado nas recomendações de warmup publicadas por SparkPost / Postmark / SES, consolidadas em uma tabela semanal única. Rampa mais devagar do que isso se você ver a taxa de reclamação subindo; rampa mais rápido só se você tiver luz-verde de reputação confirmada pelo provedor em cada passo.

Rastreamento de warmup no AcelleMail

O model SendingServer do AcelleMail tem estado de warmup de primeira classe. warmup_enabled, warmup_strategy_id e warmup_started_at vivem na tabela sending_servers; isWarmupEnabled() em app/Model/SendingServer.php:333 controla decisões em tempo de envio. A tabela companheira SendingServerWarmupLog registra cada envio durante a janela de warmup com data, status e um payload meta serializado — veja app/Model/SendingServerWarmupLog.php.

O padrão: atribua uma WarmupStrategy (uma linha que define a curva de volume por dia) a um servidor de envio, vire warmup_enabled = true, configure warmup_started_at = now(). O SendingServerWarmupUsage do pipeline de envio rastreia a contagem do dia e recusa despachar além do teto diário da estratégia. Quando o teto de dia-N da estratégia excede seu volume diário completo, o servidor se forma e o modo warmup auto-desativa.

As classes DynamicRateTracker e InMemoryRateTracker (app/Library/) cuidam de rate limiting por minuto / por hora no nível SMTP — mesmo fora do warmup, o AcelleMail impõe os tetos de taxa publicados pelo relay para que um surto de fila não tropece em throttling do lado do provedor.

§8 · Bounces + reclamações

Bounces, reclamações e o feedback loop.

Hard vs soft bounces

Um hard bounce é uma falha permanente — tipicamente um código SMTP 5xx: o endereço não existe, o domínio não resolve, a caixa do destinatário está desativada permanentemente. O model BounceLog do AcelleMail define as constantes HARD e SOFT em app/Model/BounceLog.php:33; um hard bounce suprime o endereço imediatamente. Um soft bounce é transitório — um código 4xx: caixa cheia, servidor temporariamente indisponível, mensagem muito grande. Soft bounces tentam de novo num cronograma de backoff; endereços que dão soft bounce repetidamente entre envios são eventualmente rebaixados para hard.

O mapa de classificação para notificações de bounce do AWS SES (a fonte que a documentação de BounceLog.php:32 do AcelleMail cita): tipos de bounce incluem Permanent (hard) com sub-tipos General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (soft) com sub-tipos General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; mais Undetermined (tratar como soft, retry).

Reclamações

Uma reclamação é um destinatário clicando em "denunciar como spam" no seu cliente de email. Reclamações chegam via Feedback Loops (FBLs) — um canal de notificação por provedor onde os ISPs encaminham para você as mensagens reportadas como abusivas. O FeedbackLoopHandler do AcelleMail em app/Model/FeedbackLoopHandler.php processa mensagens FBL de entrada via IMAP/POP e parseia os cabeçalhos do Abuse Reporting Format (ARF, RFC 5965) para extrair o message ID original e o tipo de feedback.

Tipos de feedback ARF que o AcelleMail trata (por FeedbackLoopHandler::FEEDBACK_TYPES na linha 35):

• abuse — destinatário marcou explicitamente como spam. Suprima imediatamente.
• fraud — destinatário marcou como phishing. Suprima + logue para revisão de segurança.
• virus — antivírus do destinatário sinalizou um payload. Suprima + audite o conteúdo.
• other — reclamação genérica. Suprima.
• not-spam — relatório explícito "isso não é spam" (raro). Excluído da supressão — veja EXCLUDED_FEEDBACK_TYPES.

Principais provedores de caixa de entrada participantes de FBLs: AOL, Yahoo, Microsoft (via JMRP), Comcast, BlueTie. O Gmail não roda um FBL público — entrega o feedback "marcado como spam" pelo dashboard do Postmaster Tools e por relatórios DMARC agregados.

Regras de supressão

1. Hard bounce → suprima permanentemente. Nunca tente de novo; o endereço está morto.
2. Reclamação → suprima permanentemente. O destinatário pediu ativamente para parar. Reenvio é ilegal na maioria das jurisdições e queima reputação.
3. Soft bounce ×3 em 30 dias → rebaixe para hard, suprima. Soft bounces persistentes são caixa cheia ou problemas de conectividade persistentes — trate como morto.
4. Descadastramento → suprima para marketing, não para transacional. Recibos de pedido e password resets continuam; campanhas param.
5. Acerto em spam-trap → escalone para investigação. Puxe toda a fonte de aquisição daquele assinante. A lista foi provavelmente contaminada com endereços comprados ou raspados.

§9 · Higiene de lista

Higiene de lista — a disciplina que mantém a reputação alta.

Autenticação é setup único. Reputação é disciplina operacional. Os sete hábitos que movem o ponteiro:

1. Duplo opt-in para todas as inscrições de marketing. Um clique de confirmação antes que o endereço entre na lista ativa. Elimina typos, endereços de papel (info@, sales@) e endereços coletados. Adiciona 10–20% de fricção à inscrição; subtrai 50–80% do risco de bounce/reclamação.
2. Descadastramento em um clique (RFC 8058). Cabeçalho List-Unsubscribe apontando para uma URL de um clique. Exigido por Gmail e Yahoo para remetentes > 5K/dia para seus domínios desde fevereiro de 2024. Torne o unsub mais fácil do que a reclamação — destinatários que iam clicar em "spam" clicam em "descadastrar".
3. Reengajamento antes da supressão. Assinantes que não abriram em 90 dias recebem uma campanha "queremos continuar sendo relevantes". Abriu → mantém. Não abriu → vai para uma fila de sunset. Sem abrir após 180 dias → suprima.
4. Auto-supressão de bounces. Processe o webhook de bounce em minutos; remova da lista de envio ativa antes da próxima campanha. BounceLog::record() do AcelleMail e handlers de bounce-webhook estilo vbrandsync fazem isso automaticamente.
5. Não importe listas compradas. Nunca. Listas compradas vêm semeadas com spam traps. Um acerto em trap e seu domínio entra para o Spamhaus por 30+ dias. A matemática nunca fecha — listas compradas são um sumidouro permanente de reputação.
6. Segmente por engajamento. Envie campanhas para os 50% engajados o dobro de vezes, para os 50% frios metade. Eleva a taxa de abertura geral, derruba a taxa de reclamação e dá aos provedores um sinal forte de "esse remetente é relevante".
7. Limite a cadência de automações. Uma série de boas-vindas + carrinho abandonado + pós-compra + aniversário + reengajamento pode produzir 8 mensagens em uma única semana. Limite o total de mensagens de automação a uma a cada 48 horas por destinatário, com exceções duras para transacional (recibos, password resets).

§10 · Ferramentas do AcelleMail

As ferramentas de entregabilidade do AcelleMail — o que o código-fonte entrega.

Puxado diretamente da árvore do código-fonte em app/Model/ e app/Library/. Cada entrada é um model real, interface de capacidade ou classe de biblioteca — não marketing.

§11 · Troubleshooting

Problemas comuns de entregabilidade e correções.

§12 · FAQ

FAQ de entregabilidade de email.

Cabeça do cluster

Para onde ir em seguida.

Domínios autenticados. Bounces rastreados. Reputação nível caixa de entrada.

O AcelleMail entrega verificação SPF/DKIM/DMARC, processamento de feedback-loop ARF, máquina de estado de IP warmup e rate limiting por servidor na caixa. Cada afirmação neste guia mapeia para uma classe em app/Model/ ou app/Library/ do AcelleMail na árvore do código-fonte.