Executando verificação de segurança...
-3
LDM
3 min de leitura ·

Pitch: Construí um checker de inbox placement em 4 horas antes de uma entrevista — virou meu produto

Meu amigo saiu da entrevista às 9:03 da manhã. A minha era às 13:00.

Ele me mandou mensagem assim que saiu: "Cara. Eles me grelharam em inbox placement. SPF, DKIM e DMARC foi só o aquecimento. Eles queriam código."

Eu tinha 3 horas e 57 minutos.

O contexto

A vaga era numa empresa de outreach B2B. Tinha aplicado uma semana antes com um currículo que dizia "infraestrutura de email" sem se comprometer com especificidades. Achei que ia improvisar a parte técnica — eu já entreguei sistemas de cold outreach por anos, conheço a teoria.

A entrevista do meu amigo foi às 8h (horário dele). A minha às 13h (meu horário). Mesma banca, mesmo gerente de contratação, quase certeza o mesmo roteiro.

O resumo dele em três pontos:

  • Explicar como detectar se um email caiu na caixa de entrada, spam ou na aba Promoções do Gmail — sem acesso à caixa do destinatário.
  • Desenhar um sistema para medir entregabilidade em 10 provedores em tempo real.
  • Bônus: mostrar código. Qualquer código. Eles respeitam mais um hack do que slides.

Teoria eu tinha. Código não.

A maratona de 4 horas

Abri Claude Code às 9:11 com café e prazo.

Plano:

  1. Subir uma rede pequena de seed mailboxes — contas burner no Gmail, Outlook, Yandex, Mail.ru, ProtonMail.
  2. Construir um fetcher IMAP que faz polling em cada seed e classifica onde o email caiu (inbox / spam / aba de categoria).
  3. Empacotar numa CLI que recebe um endereço "from", manda mensagem de teste pra cada seed e imprime um relatório de placement.

Claude Code escreveu o scaffold em uns 20 minutos. NestJS + BullMQ pra fila, IMAP via imapflow, lógica de classificação baseada no header X-Gm-Labels do Gmail e nomes de pasta dos outros provedores.

O tempo real foi gasto em edge cases:

  • "Focused" vs "Other" do Outlook — nenhum é spam, mas recrutadores confundem direto.
  • Yandex retorna nomes de pasta em russo. Precisei de fallbacks hardcoded.
  • Alguns provedores limitam polling IMAP agressivamente. Tive que adicionar retries com jitter.

Ao meio-dia tinha uma CLI funcionando.

Mandei teste do meu Gmail pessoal pra todas as 5 seeds, esperei 90 segundos:gmail.com
→ INBOX
outlook.com → JUNK
yandex.ru → INBOX
mail.ru → INBOX
proton.me → INBOX

O Outlook comendo um envio limpo do Gmail foi uma surpresa útil — exatamente o tipo de coisa que você ia querer uma ferramenta pegar antes de mandar 10.000 emails.

Screenshot do output, push pro GitHub privado, almoço.

A entrevista

A primeira pergunta técnica foi quase palavra por palavra o que meu amigo avisou. Respondi a teoria e disse: "Na verdade construí uma implementação de referência hoje de manhã. Posso compartilhar tela?"

O hiring manager pausou dois segundos. "Por favor."

Rodei um teste ao vivo no próprio domínio de marketing deles. Três provedores limpos, dois em spam. Passamos os 20 minutos seguintes debugando o porquê — alinhamento de DMARC quebrado no subdomínio no-reply.

Não me vendi como o candidato que sabia deliverability. Me vendi como o candidato que conseguia entregar uma ferramenta de deliverability entre café da manhã e almoço.

Oferta chegou 3 dias depois. Recusei por motivos não relacionados, mas isso é outro post.

O que continuou depois

Continuei mexendo na CLI depois da entrevista. Virou um serviço completo de inbox placement — multi-tenant, hospedado, com tier grátis pra checks pontuais.

Se quiser rodar o mesmo teste no seu domínio de envio, está aqui: https://check.live-direct-marketing.online

Cola um from-address, recebe breakdown por provedor em uns 60 segundos. Sem cadastro pra checks individuais.

Feedback técnico, sugestões de melhoria e críticas são bem-vindos.

Fonte: https://check.live-direct-marketing.online

Carregando publicação patrocinada...
2
Oletros

Meus 2 cents,

Para quem nao conhece o assunto, uma "traducao" do post:

1 - Eh um post que trata de ferramentas de envio de email, em especial email marketing, e de tecnicas para saber a saude da "entrega" dos emails enviados

2 - SPF, DKIM e DMARC (simplificando) sao registros usados no DNS do dominio que envia os emails para indicar a responsabilidade pelo sistema.

3 - "empresa de outreach B2B": empresa de email marketing e prospeccao

4 - "...Explicar como detectar se um email caiu na caixa de entrada, spam ou na aba Promoções do Gmail — sem acesso à caixa do destinatário.."

Aqui cabe uma explicacao mais detalhada, pois pode dar a impressao que as empresas realmente "sabem" onde caiu o email: quem envia nao tem como saber, o protocolo SMTP nao implementa isso.

O que as empresas fazem: criam emails de controle em diversos provedores (GMAIL, outlook/MS, uol, etc) e quando fazem o envio de um email-mkt, tambem enviam para estes emails de controle - assim podem acompanhar o provavel destino final do email (p.ex. caixa de spam).

Entretanto este acompanhamento eh um tanto impreciso, uma vez que diversos fatores podem interferir no recebimento do email em um destinatario, ainda que pertencendo ao mesmo dominio de controle.

Alguns provedores (p.ex. MS/outlook) possuem ferramentas de reputacao onde voce pode checar a reputacao do seu dominio e/ou range de IPs, alem de existirem ferramentas abertas com listas de blacklist e semelhantes (p.ex. RBL - uma que eu gosto eh a b.barracudacentral.org)

4.1 - Este controle geralmente eh feito via IMAP de forma automatizada - entao um script faz o "fetch" (baixa) o email e ve em que caixa ficou e avisa no sistema e alimenta as metricas

5 - "...alinhamento de DMARC quebrado no subdomínio no-reply..."

Eh a checagem de headers do email como "From/Return-Path" contra os dados de DMARC, SPF e DKIM: se um destes falha, os sistemas de anti-spam do SMTP de destino podem classificar o email como spam de forma automatica.

Para quem quer uma checagem basica da situacao do seu dominio, uma opcao eh:

6 - Um projeto interessante na area de anti-spam eh o SPF-BL (e nacional !!!)

2
LDM
  • Autor
    Autor

Oletros, obrigado pela tradução e principalmente pela correção no ponto 4 — você está absolutamente certo e eu deveria ter sido mais preciso.

Quem envia não tem como saber o destino final num mailbox que ele não controla. O método que descrevi funciona porque os seeds são caixas sob meu controle — então tecnicamente é "sem acesso à caixa do destinatário real", mas COM acesso às caixas de controle. A diferença é importante e eu nivelei errado no texto.

Sobre os outros pontos:

  • SPF-BL eu não conhecia, valeu pela indicação. Vou olhar com calma — interessante que seja brasileiro.
  • b.barracudacentral.org está na minha lista de RBLs que consulto, junto com Spamhaus ZEN e SORBS. Para Microsoft especificamente o SNDS (Smart Network Data Services) também ajuda a entender a reputação do IP.
  • Sobre imprecisão do seed-based monitoring: 100% verdade. Mesmo com 50-100 seeds bem distribuídos, os resultados são estatísticos, não determinísticos. Provedores como Gmail aplicam personalização por destinatário (histórico, engajamento), então o que cai no inbox do seed pode cair no spam do destinatário real. Isso não invalida a métrica, mas exige interpretar como "probabilidade de inbox" e não "garantia".

A coisa que me incomoda no espaço hoje é exatamente o que você apontou — empresas vendendo "monitoramento de entregabilidade" como se fosse determinístico. É probabilístico, sempre foi.

1
Oletros

Meus 2 cents,

Obrigado pela resposta gentil - minha ideia era menos criticar e mais "traduzir" as ideias para pessoas que nao conhecam sobre o assunto tenham uma base/entendimento melhor sobre como isso funciona por debaixo do "capô".

Na epoca que trabalhei como sysadmin para algumas empresas de email-mkt interagia com muita frequencia com a Spamhaus/SORBS/SNDS e ficava louco tentando entender as regras que algumas destas listas implementavam (noves fora as "taxas de liberacao rapida") - mesmo usando opt-in era frequente ter dores de cabeca.

Ja usei muito a SPF-BL (tendo participado ativamente na epoca em que ela foi lancada, ja tem uns bons 10 anos) - mas acabei "desistindo" de brigar com spam/anti-spam e optei por usar o google workspace / gmail como provedor dos meus dominios.

Valeu !

2
LDM
  • Autor
    Autor

Concordo 100% sobre o caráter probabilístico — e é exatamente por isso que a abordagem em produção não pode depender de uma única caixa.

O que fazemos:

  1. Escala em vez de seed único. Cada teste roda contra ~100 caixas Gmail e ~100 Outlook em paralelo, distribuídas em diferentes contas, IPs de coleta e perfis de engajamento. O resultado não é "caiu em INBOX" ou "caiu em SPAM" — é uma distribuição. Medianas e percentis dizem muito mais que um caso isolado. Se 87 de 100 Gmails entregaram em INBOX, isso é um sinal estatisticamente útil; se 50/50, é um sinal completamente diferente.

  2. Monitoramento temporal, não snapshot. O check inicial roda imediatamente, mas o sistema repete a verificação em intervalos configuráveis — tipicamente 1h, 6h, 12h, 24h. Provedores movem mensagens entre pastas post-delivery (especialmente Gmail e Outlook), e um email que entrou em INBOX às 10:00 pode estar em SPAM às 16:00 se o engajamento global do remetente cair. Sem essa dimensão temporal você só vê a foto, não o filme.

  3. Distribuição por tipo de conta. As 100 caixas Gmail não são iguais — algumas têm histórico de engajamento ativo, outras são "frias". Isso permite estimar o efeito do reputation score do remetente, não só do conteúdo do email.

Honestamente, não conheço outro método que dê um sinal mais confiável dentro das limitações que o SMTP impõe. Tudo o que esteja em cima disso (predição "100% inbox", garantias determinísticas) é vendor marketing, não engenharia.

Se você tiver tempo, gostaria muito de ouvir sua opinião sobre se há algum ângulo que estamos ignorando — especialmente porque sua experiência com SPF-BL e Spamhaus dá uma perspectiva que poucos têm.

PS — sobre em quais provedores focar: mantemos uma análise pública baseada em dados DNS do OpenINTEL (top-1M Tranco, arquivada desde 2016): https://check.live-direct-marketing.online/email-stats/

O que os dados mostram: a cauda é enorme, mas ~5-7 plataformas concentram a maioria do tráfego B2B — Google Workspace, Microsoft 365, Yandex/Mail.ru em mercados CIS, mais alguns ESPs corporativos. Cobrir esses bem vale mais que tentar cobrir 200 superficialmente.

1
Oletros

Meus 2 cents,

Novamente, obrigado pela resposta.

Se você tiver tempo, gostaria muito de ouvir sua opinião sobre se há algum ângulo que estamos ignorando — especialmente porque sua experiência com SPF-BL e Spamhaus dá uma perspectiva que poucos têm.

Nao acredito que eu possa agregar nada a tua solucao, que ja esta bem estabelecida. Na epoca que trabalhei com email-mkt (anos 2000-2010), o apice da tecnologia era email html com pixel de tracking para controlar entrega e leitura, o que hoje praticamente nao faz mais sentido.

Os conhecimentos que tenho sobre DNS/SPF/RBL/etc voce ja domina de cor e salteado - mas meu ego agradece, devidamente afagado.

Quanto ao SPF-BL nao tem muito segredo: eh uma rede P2P onde os participantes rodam um client no servidor SMTP (p.ex. postfix) que analisa 2 coisas: se o dominio do remetente ja esta em blacklist (uma RBL normal) e se o SPF dele esta coerente. Em casos onde o SPF esteja incorreto ou que os participantes deem flag como spam, esta denuncia eh propagada para os demais participantes da rede e com um TTL - ou seja, uma RBL que ao inves de ser centralizada pode ser compartilhada e ajustada conforme necessario por cada participante. Mas estou tocando de memoria, depois que migrei para gmail, nao tenho mais usado ativamente (uns 5 anos).

Enfim, ficam meus votos de,

Saude e Sucesso !