Entregabilidade de email para classificados adultos: por que o código de verificação nunca chega
A falha para a qual ninguém recebe um alerta
Um novo usuário se cadastra, digita um endereço de email e espera o código de seis dígitos que permite concluir a verificação de idade. Ele não chega no minuto em que deveria. Talvez caia na pasta de spam dez minutos depois, muito depois de o usuário ter desistido e fechado a aba. Talvez o servidor de email destinatário o rejeite diretamente no momento do envio, com uma mensagem de devolução que passa despercebida em um registro que ninguém está observando. De qualquer forma, nada na experiência diz ao operador que algo deu errado. O funil de cadastro simplesmente mostra mais um visitante que digitou um endereço de email e nunca voltou, indistinguível de alguém que apenas mudou de ideia.
Essa ambiguidade é o verdadeiro problema, mais do que qualquer causa técnica isolada. A maioria dos sites monitora se um email foi enviado, uma marca verde em um painel, não se ele realmente chegou diante de uma pessoa. São dois eventos diferentes, e o intervalo entre eles é exatamente onde um problema de entregabilidade se esconde por meses. Um operador que nunca teve uma queda de hospedagem ou um bloqueio de processador de pagamento ainda pode estar perdendo uma parcela real de novos cadastros por causa de um problema de email que não tem como perceber, porque não há incidente, não há chamado de suporte, não há painel ficando vermelho.
Esse é um tipo de risco de fornecedor diferente daquele que fecha uma conta de hospedagem com um aviso citando uma cláusula que ninguém releu desde a assinatura. Um host suspenso é barulhento: o site sai do ar, e o operador descobre em minutos porque os clientes avisam e o painel também mostra. Um problema de entregabilidade é silencioso por natureza. A conta de envio continua aberta, a fatura mensal continua chegando, e o único sintoma visível é um funil de cadastro que perde pessoas na última etapa por motivos que, do lado do operador, parecem abandono comum e não uma falha técnica corrigível.
A causa de fundo continua sendo o mesmo tipo de atrito de categoria que aparece com hosts, bancos e processadores de pagamento. Provedores de caixa de entrada e serviços de envio de email pontuam essa categoria como mais arriscada do que a maioria, alguns explicitamente e pelo nome, e um domínio novo sem histórico de envio começa cada mensagem com uma desvantagem que não tem nada a ver com o que a mensagem realmente diz.
Por que essa categoria é filtrada com mais rigor que a maioria
Filtros de spam e provedores de serviço de email não tratam todos os setores da mesma forma, e vale a pena ler as diferenças antes de se cadastrar do que depois que uma conta é sinalizada. A política publicada pelo SendGrid sobre conteúdo proibido lista, como itens separados, "pornografia ou conteúdo sexualmente explícito" e, distintamente, "serviços de acompanhantes, busca de noivas ou cônjuges por correspondência, agências matrimoniais internacionais e serviços similares". Essa segunda categoria não trata do que o email contém. Ela nomeia o próprio negócio como motivo de exclusão, o que significa que um código de verificação em texto simples enviado por um diretório de acompanhantes pode ficar fora da política só pela categoria, independentemente de quão discreta seja a mensagem.
A política de uso aceitável do Mailgun traça a linha em outro lugar completamente diferente. Sua seção de conteúdo proibido se limita a material que constitui ou promove exploração infantil, zoofilia ou atos não consensuais, sem uma cláusula separada nomeando negócios adultos ou serviços de acompanhantes como categoria. É uma restrição bem mais estreita que a do SendGrid, voltada para o que é ilegal em vez de para qual setor está enviando. Dois grandes provedores generalistas, acessíveis pelo mesmo tipo de formulário de cadastro, traçam a linha em pontos realmente diferentes, e um operador que escolhe um sem ler além da página de preços não tem como saber de que lado dessa linha a conta dele está até que uma revisão a sinalize.
Essa é a mesma lacuna de verificação prévia que pega operadores de surpresa com uma cláusula de rescisão de hospedagem ou CDN que nunca leram, uma camada mais abaixo na pilha. A pergunta a fazer antes de escolher um provedor de email não é se ele tecnicamente permite enviar email para esse tipo de negócio em geral. É se a política escrita do provedor nomeia especificamente a categoria do negócio, por escrito, antes que o primeiro código de verificação seja enviado, não depois que uma revisão de abuso o descobre.
Um domínio de envio novo agrava isso além do que o provedor permite. Filtros pesam muito o histórico e o padrão de volume de um domínio, e um domínio que apareceu recentemente e começou imediatamente a enviar códigos automáticos em volume se parece, para um filtro sem outro sinal, com o padrão de uma conta criada para um propósito estreito e abandonada assim que sinalizada. Isso não é um julgamento sobre o negócio; é uma correspondência de padrão que qualquer domínio novíssimo dispara, classificados adultos ou não, e que só desaparece com o tempo e um comportamento de envio consistente.
O piso técnico que todo provedor de caixa de entrada já exige
Mesmo um provedor cuja política aceita a conta sem ressalvas não consegue, sozinho, fazer um email chegar à caixa de entrada. Desde 1º de fevereiro de 2024, o Google exige de todo remetente que envia email para endereços do Gmail, independentemente do volume, atender a uma base documentada: no mínimo, SPF ou DKIM configurados corretamente no domínio de envio. O SPF lista quais servidores estão autorizados a enviar em nome do domínio; o DKIM assina cada mensagem para que o servidor destinatário possa confirmar que ela não foi alterada em trânsito. Remetentes que chegam a 5.000 mensagens por dia para endereços do Gmail especificamente enfrentam uma barra mais alta: SPF e DKIM juntos, mais DMARC publicado no domínio, no mínimo em modo de monitoramento. Um site de classificados que envia códigos de verificação de idade, redefinições de senha e recibos de pagamento em escala real cruza essa marca de 5.000 mensagens rapidamente, já que cada uma delas conta para o total.
As próprias diretrizes publicadas pelo Google fixam um número exato acima da autenticação: remetentes de qualquer tamanho devem manter a taxa de reclamações relatada pelo Postmaster Tools do Google abaixo de 0,30 por cento, e as mesmas diretrizes recomendam ficar abaixo de 0,10 por cento como uma margem de segurança real, em vez de tratar 0,30 por cento como uma meta confortável para se aproximar. O descumprimento se traduz em duas falhas distintas e documentadas separadamente, não em uma penalidade vaga. Emails que falham em SPF, DKIM ou DMARC podem ser marcados como spam ou rejeitados diretamente com o erro SMTP 5.7.26. Remetentes que excedem a cota de envio permitida pelo Google esbarram em uma parede diferente, um erro de limitação de taxa 4.7.28. Nenhum dos dois anuncia "este setor não é bem-vindo aqui". Ambos parecem, do painel de um desenvolvedor, uma falha técnica comum, e é exatamente por isso que tendem a ser notados semanas depois em vez de corrigidos no dia em que começam.
O Yahoo, cuja infraestrutura também atende endereços da AOL, publica independentemente o mesmo tipo de exigência: SPF e DKIM juntos, uma política DMARC de pelo menos p=none que precisa passar na verificação, e o mesmo teto de 0,30 por cento na taxa de reclamações, em vigor no mesmo cronograma desde fevereiro de 2024. Um operador que resolve isso para o Gmail e presume que Yahoo e AOL vão acompanhar geralmente acerta na mecânica, já que os dois provedores convergiram para números quase idênticos, mas os dois sistemas continuam medindo e aplicando as regras separadamente, então um domínio em conformidade com um não está automaticamente em conformidade com o outro.
Uma exigência desse conjunto é escrita de forma deliberadamente estreita. O cancelamento de inscrição em um clique, usando o cabeçalho List-Unsubscribe, se aplica especificamente a mensagens de marketing e mensagens de assinatura, nas próprias palavras do Google. Um código de verificação ou um recibo de pagamento não é nenhum dos dois, então não é isso que essa linha em particular tem como alvo. As exigências de autenticação e reputação acima dela, SPF, DKIM, DMARC e o teto de reclamações, não são limitadas dessa forma: elas se aplicam a toda mensagem que um domínio envia, transacional incluída.
O erro que arrasta junto o email importante
A forma mais comum de um operador prejudicar seus próprios emails de verificação é enviar email de marketing do mesmo domínio que envia os códigos de verificação e os recibos de pagamento. A reputação é rastreada principalmente no nível do domínio e subdomínio de envio, o que explica por que separar os fluxos ajuda, mas o isolamento entre subdomínios não é absoluto: um pico de reclamações em um subdomínio ainda pode se refletir no domínio pai, especialmente se os dois fluxos compartilharem a mesma identidade de assinatura DKIM nos bastidores. Um email promocional anunciando um novo recurso ou uma oferta sazonal, enviado para uma lista já desatualizada, produz exatamente o tipo de pico de reclamações que pode derrubar a reputação de um domínio compartilhado, e parte desse dano atinge o código de verificação que um usuário recém-cadastrado está esperando agora mesmo, uma mensagem que não tem nada a ver com o envio de marketing que causou o problema.
É também aqui que a disciplina operacional construída em torno da verificação de idade se entrelaça com um problema de entrega de email puramente técnico, de uma forma fácil de não perceber. Um fluxo de verificação que depende de um código chegar a uma caixa de entrada só é tão confiável quanto a reputação do domínio de envio no dia em que esse código sai, e reputação é um recurso compartilhado entre todos os tipos de mensagem que usam infraestrutura relacionada, a menos que o operador os mantenha deliberadamente separados.
A solução é estrutural, não uma configuração para alternar depois que um pico de reclamações já aconteceu. Envie o email transacional, códigos de verificação, confirmações de pagamento, redefinições de senha, de um subdomínio dedicado usado para mais nada, por exemplo mail.exemplo.com em vez do domínio puro ou de um subdomínio de marketing compartilhado, e assine-o com sua própria chave DKIM em vez de uma reutilizada em todos os fluxos. Envie conteúdo de marketing ou newsletters de um subdomínio totalmente separado, como news.exemplo.com, com seus próprios registros de autenticação e sua própria reputação, capaz de absorver uma semana ruim de reclamações sem arrastar junto o email que precisa chegar. Os dois fluxos podem passar pela mesma conta no provedor, mas precisam parecer, e estar assinados, como remetentes claramente distintos aos olhos do servidor de email destinatário.
O que realmente verificar nesta semana
Comece consultando a política de uso aceitável de qualquer serviço que esteja enviando atualmente o email transacional do site, e descubra, por escrito, se ela nomeia especificamente a categoria do negócio, da mesma forma que a verificação anterior sobre contratos de hospedagem e CDN funcionou para fornecedores de infraestrutura. Um provedor cuja política já exclui a categoria pelo nome não é um provedor sobre o qual construir um fluxo de verificação, por mais confiável que tenha sido até agora, porque uma revisão de conta pode encerrar essa confiabilidade sem nenhum aviso prévio.
Verifique se SPF, DKIM e DMARC estão realmente publicados e passando na verificação no domínio que envia agora os emails de verificação e recibo, em vez de presumir que estão corretos porque alguém os configurou uma vez, anos atrás. Um registro DNS que estava correto quando foi escrito pode ficar desatualizado após uma migração de provedor, e um domínio sem autenticação começa toda mensagem com uma chance real de rejeição sob as regras que Google e Yahoo aplicam desde fevereiro de 2024, independentemente do que a mensagem diga.
Separe email transacional e de marketing em subdomínios distintos com chaves de assinatura distintas, se ainda não estiverem, e trate isso como trabalho de infraestrutura, não como uma decisão da equipe de marketing, já que errar aqui custa uma verificação de identidade falha, não uma venda perdida.
Acompanhe a taxa real de reclamações pelos próprios relatórios do provedor ou pelo Postmaster Tools do Google em um cronograma fixo, e trate qualquer aproximação de 0,10 por cento como o ponto para investigar, não 0,30 por cento, já que 0,30 por cento está mais perto do ponto em que o email começa a ser rejeitado do que do ponto em que um problema começa. E, periodicamente, envie um cadastro de teste real para um endereço pessoal do Gmail e um do Yahoo, e cronometre quanto tempo o código leva para chegar e onde ele chega, porque um painel relatando um envio bem-sucedido está relatando o que saiu do servidor, não o que um usuário realmente viu.
