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

> Seu provedor de e-mail suspendeu a conta? Veja por que acontece, o plano das primeiras 24 horas e como evitar que se repita.

Fonte: https://couryo.com/blog/conta-de-email-suspensa · Publicado em 2026-10-20

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](https://support.google.com/a/answer/81126)). 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](https://techcommunity.microsoft.com/blog/outlook/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)).

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):

| Provedor | Devolução | Reclamação | O que acontece |
|---|---|---|---|
| [Resend](https://resend.com/docs/knowledge-base/account-quotas-and-limits) | abaixo de 4% | abaixo de 0,08% | acima, pode haver pausa temporária até a taxa baixar |
| [Postmark](https://postmarkapp.com/support/article/1111-does-postmark-have-a-daily-send-limit) | abaixo de 10% | abaixo de 0,1% | acima, a conta é pausada e as mensagens ficam na fila |
| [Brevo](https://help.brevo.com/hc/en-us/articles/360017299259) | definitiva acima de 2% (campanhas) | acima de 0,2% (campanhas) | a campanha e a conta podem ser suspensas; descadastro acima de 1% também conta |
| [Mailgun](https://documentation.mailgun.com/docs/mailgun/api-reference/lower-bounce-rate) | não publica os números | não publica os números | o domínio é desativado temporariamente; o suporte reativa depois da correção |

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](https://www.reddit.com/r/SaaS/comments/1x9ql91/resend_suspended_our_entire_saas_email_service/)). **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](https://www.reddit.com/r/SendGrid/comments/1ug37tn/looking_for_replacement/)). **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](https://www.reddit.com/r/webdev/comments/1u9g7cl/mailgun_alternative/)). **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](https://www.reddit.com/r/DigitalMarketing/comments/1d5umi8/best_email_marketing_or_any_experience_with_brevo/mk59ex4/)). **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:

```js title="Limite de 5 cadastros por IP a cada 15 minutos"
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](https://couryo.com/uso-aceitavel):

| Medida | Limite reduzido | Marketing pausado | Pausa total |
|---|---|---|---|
| Devolução definitiva (24 horas, com pelo menos 50 enviados) | acima de 2% | acima de 3% | acima de 10% |
| Reclamação (7 dias, com pelo menos 200 enviados) | acima de 0,03% | acima de 0,05% | acima de 0,5% |

- **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](https://couryo.com/docs/limits.md#pausa-por-projeto-primeiro)).
- **Chave suspeita é pausada sozinha**, sem parar a conta, e você reativa com um clique depois de conferir ([chaves pausadas](https://couryo.com/docs/limits.md#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](https://help.brevo.com/hc/en-us/articles/360017299259)); 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](https://couryo.com/uso-aceitavel) 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](https://couryo.com/blog/alternativas-ao-sendgrid) compara as regras de pausa de seis serviços.