Conta de envio de e-mail suspensa: o que fazer nas primeiras 24 horas

O app parou de mandar e-mail e ninguém avisou. Você descobre quando um cliente reclama que o código de login não chegou, abre o painel do provedor e encontra a conta suspensa. Senha, cobrança, confirmação de pedido: tudo parado ao mesmo tempo.

Isso acontece em todos os grandes provedores, e quase sempre tem uma causa que dá para encontrar e corrigir. Este guia explica por que os provedores suspendem, traz um plano hora a hora para as primeiras 24 horas e mostra como evitar que aconteça de novo. Vale para qualquer serviço de envio.

Por que os provedores suspendem contas#

Quem recebe o seu e-mail (Gmail, Outlook, Yahoo) julga o remetente pelo histórico. Num provedor de envio, muitos clientes dividem a mesma estrutura, então um cliente que manda spam prejudica a entrega de todos. Por isso os provedores medem duas taxas o tempo todo:

• Devolução (bounce): e-mails que voltaram porque o endereço não existe. Taxa alta indica lista velha, comprada ou cheia de endereços digitados por robôs.
• Reclamação: pessoas que clicaram em "marcar como spam". É o sinal que os grandes provedores mais levam a sério.

As réguas de fora são públicas. O Google pede que remetentes mantenham a taxa de spam no Postmaster Tools abaixo de 0,3%, com a recomendação de ficar abaixo de 0,1%, e exige descadastro em um clique para quem manda mais de 5 mil mensagens por dia para contas do Gmail (diretrizes do Google). A Microsoft passou a exigir SPF, DKIM e DMARC de quem envia mais de 5 mil por dia para o Outlook, a partir de 05/05/2025; quem não cumpre vai para o lixo eletrônico e depois é recusado com o código 550 5.7.515 (anúncio da Microsoft).

Os provedores de envio pausam bem antes dessas réguas, para proteger os outros clientes. Alguns publicam os números (verificado em 20/10/2026):

Saber a régua do seu provedor antes do problema é metade da prevenção.

Quatro casos reais e o que cada um ensina#

Relatos públicos de quem passou por isso, resumidos. Não são para apontar culpados: em todos, o provedor protegia a própria estrutura, e o cliente tinha um ponto cego.

1. Cadastros falsos num SaaS com vários clientes. Um SaaS de atendimento teve a conta inteira suspensa duas vezes em uma semana: pessoas mal-intencionadas criaram contas fingindo ser empresas legítimas e usaram o sistema de tickets para mandar e-mails de golpe. Todos os clientes legítimos ficaram sem e-mail, e o dono só percebeu quando o app parou de enviar (relato no r/SaaS). Lição: se usuários do seu produto disparam e-mails, o abuso deles vira o seu.
2. Formulário de contato usado por robôs. Uma agência com cerca de 50 sites num mesmo SendGrid via a conta toda suspensa sempre que uma chave vazava ou um formulário de contato era bombardeado com spam, e precisava trocar todas as chaves para reativar (relato no r/SendGrid). Lição: um formulário sem proteção e uma conta única para tudo transformam um problema pequeno num apagão geral.
3. A primeira newsletter. Uma loja que usava o Mailgun havia meses sem problema mandou a primeira campanha, cerca de 150 e-mails, acima do limite do plano grátis. A conta foi marcada quase na hora e encerrada de vez, mesmo depois do upgrade (relato no r/webdev). Lição: a primeira campanha grande é o momento de maior risco. Avise o provedor e comece pequeno.
4. Suspensão logo depois de pagar. Um usuário da Brevo pagou um plano e, 40 minutos depois, teve a conta suspensa por 2% de devolução e 3% de descadastro na primeira campanha (comentário no r/DigitalMarketing). Lição: as réguas de campanha valem desde o primeiro envio, e 2% de devolução numa lista importada é fácil de atingir.

O plano das primeiras 24 horas#

Hora 0 a 1: confirme e contenha#

• Leia o aviso inteiro, no e-mail e no painel. Anote o que foi suspenso (a conta, um domínio, só o marketing?) e o motivo citado.
• Pare tudo que é marketing. Campanhas agendadas, sequências e importações em andamento. Elas pioram as taxas enquanto você investiga.
• Troque as chaves de API se houver qualquer sinal de vazamento: pico de envio que você não reconhece, destinatários de domínios que você nunca usou, envio de madrugada. Crie chaves novas, uma por sistema, e apague as antigas.
• Avise o seu time e, se preciso, os seus clientes. "O envio de e-mails está com instabilidade, estamos resolvendo" evita chamados duplicados.

Hora 1 a 4: encontre a causa, com números#

O pedido de revisão só anda com dados. Levante:

• Taxa de devolução definitiva das últimas 24 horas: devoluções definitivas divididas pelos enviados. Separe por campanha, por origem da lista e por domínio de destino.
• Taxa de reclamação dos últimos 7 dias, pela mesma divisão.
• De onde vieram os endereços problemáticos: importação recente, formulário, cadastro, API de um cliente seu.
• O que mudou nos últimos dias: lista nova, campanha nova, deploy que mexeu no cadastro, cliente novo no seu SaaS.

Os eventos do provedor (webhooks ou a exportação do log) trazem tudo isso. Se os endereços que devolveram têm cara de robô (letras aleatórias, domínios descartáveis, cadastros em sequência), a causa está no formulário.

Hora 4 a 12: limpe a lista#

• Remova quem devolveu de forma definitiva e quem reclamou. Esses nunca mais recebem.
• Tire do marketing quem se descadastrou, mas mantenha o transacional (senha, cobrança) para essas pessoas.
• Separe contatos sem nenhuma abertura ou clique há mais de 12 meses. Antes de voltar a mandar para eles, peça a reconfirmação.
• Apague os cadastros criados por robôs e bloqueie a origem.
• Exporte a lista de supressão e guarde uma cópia. Ela é sua e vale ouro se você trocar de provedor.

Hora 12 a 24: peça a revisão com números#

Um bom pedido responde, em poucas linhas, o que aconteceu, por que e o que mudou. Modelo:

Nossa conta foi suspensa em 20/10 às 9h. A causa foi uma importação de 3.200 contatos antigos na campanha de outubro: a devolução definitiva chegou a 6,1% nas últimas 24 horas (196 de 3.200). Já fizemos: removemos os 196 endereços e todos os contatos sem abertura há 12 meses (1.140), pausamos as campanhas e trocamos as chaves de API. Daqui para frente: listas importadas passam por reconfirmação e o formulário ganhou captcha e confirmação dupla. Pedimos a reativação do transacional (login, senha e cobrança, cerca de 400 por dia) e voltamos ao marketing só depois de 7 dias limpos.

Pedir de volta primeiro só o transacional, com volume menor, costuma ser mais fácil de aprovar do que pedir tudo de uma vez.

Proteja formulários e cadastros contra robôs#

A maior parte das suspensões que não envolvem lista comprada começa num formulário aberto.

• Captcha no cadastro, no "esqueci a senha" e no contato. Turnstile, hCaptcha e reCAPTCHA têm opções invisíveis que não incomodam pessoas reais.
• Campo isca (honeypot): um campo escondido por CSS. Pessoas não preenchem; robôs preenchem. Descartar esses envios custa uma linha de código.
• Limite de tentativas por IP e por endereço de e-mail. Exemplo em Node com Express:

import rateLimit from "express-rate-limit";

app.post("/cadastro", rateLimit({ windowMs: 15 * 60 * 1000, limit: 5 }), cadastrar);

• Confirmação dupla: o primeiro e-mail é só o link de confirmação. Boas-vindas, newsletter e sequências esperam a pessoa clicar.
• Nunca mande "uma cópia para você" no formulário de contato. Esse recurso deixa qualquer robô mandar texto livre para qualquer endereço usando o seu domínio.
• Em SaaS com vários clientes: limite convites e envios de contas novas nos primeiros dias, não coloque texto digitado pelo usuário (nome da empresa, assunto do ticket) em e-mails para terceiros sem limite de tamanho e sem filtrar links, e confira o domínio de quem se cadastra.

Não dependa de um único provedor#

Mesmo fazendo tudo certo, ter um plano B reduz uma suspensão de "dias sem e-mail" para "minutos para trocar uma variável de ambiente".

• Uma camada de envio no seu código: uma função enviarEmail() que chama o provedor. Trocar de provedor vira mudar uma configuração.
• Um segundo provedor com o domínio já verificado, recebendo uma parte pequena do tráfego (por exemplo, um fluxo de baixo volume) para manter a reputação aquecida.
• Transacional e marketing separados, por fluxo, por chave ou até por provedor. Um problema na newsletter não pode derrubar o login.
• Uma chave por sistema ou por cliente, para que uma chave vazada seja trocada sem parar as outras.
• Eventos guardados no seu banco, pelos webhooks. Se o provedor sair do ar ou a conta for suspensa, o histórico e a supressão continuam com você.

Exemplo de política transparente: as pausas do Couryo#

Vale ler a política de qualquer provedor antes de assinar. Como exemplo de regra pública, esta é a do Couryo, publicada na política de uso aceitável e de pausas:

• A descida é gradual. Primeiro o limite diário cai pela metade e tudo continua saindo. Depois, só o marketing para, e senha, login e cobrança continuam saindo com limite reduzido. A pausa total fica para taxas muito altas ou fraude evidente.
• Toda pausa vem com o motivo, os números e o que corrigir, no painel, por e-mail e na resposta da API.
• Revisão: o botão Pedir revisão dispara uma checagem automática na hora, com os números da conta; se a dúvida continuar, uma pessoa responde em até 1 dia útil.
• Pausa por projeto primeiro: numa conta com vários projetos, só o projeto que passou da linha é afetado (limites e níveis).
• Chave suspeita é pausada sozinha, sem parar a conta, e você reativa com um clique depois de conferir (chaves pausadas).

Use estas perguntas para avaliar qualquer provedor: os números são públicos? Existe etapa antes do corte total? O transacional crítico continua saindo durante a pausa? Quem revisa, e em quanto tempo?

Perguntas frequentes#

Quanto tempo leva para reativar uma conta suspensa?#

Depende do provedor e da causa, e poucos publicam um prazo. Um pedido com a causa, os números e a correção anda mais rápido do que um "por favor, reativem". Na Brevo, a primeira suspensão de campanha pode ser reativada pelo próprio painel, seguindo as instruções da Central de entregabilidade (Brevo); no Couryo, a revisão automática responde na hora e uma pessoa em até 1 dia útil. Fraude ou reincidência podem levar ao encerramento. Enquanto espera, use um segundo provedor para o transacional crítico.

Posso criar outra conta no mesmo provedor para continuar enviando?#

Não faça isso. Dividir envios entre contas para fugir de uma pausa costuma ser vetado nos termos de uso (a política do Couryo também não permite), e o domínio, o cartão e o IP ligam a conta nova à antiga. O risco é perder as duas.

Qual taxa de devolução é aceitável?#

Quanto menor, melhor. As réguas publicadas vão de 2% (Brevo, em campanhas) a 10% (Postmark). Se a sua passa de 2%, ela já está acima da régua mais rígida da tabela, e a lista precisa de limpeza antes do próximo envio. Confirmação dupla no cadastro é o que mais ajuda a ficar abaixo disso.

Uma única reclamação de spam pode suspender a conta?#

Uma só raramente basta para passar da taxa, mas pode disparar uma revisão em conta nova ou com pouco volume, porque a taxa é calculada sobre poucos envios. Por isso o descadastro em um clique visível é a melhor defesa: quem quer sair clica em "descadastrar" em vez de "spam".

Trocar de provedor resolve o problema?#

Só se a causa estava no provedor. Se a causa é a lista ou um formulário aberto, o problema vai junto para o provedor novo, e a suspensão se repete. Corrija a causa primeiro e leve a lista de supressão na mudança. O guia Alternativas ao SendGrid compara as regras de pausa de seis serviços.