Taxa de bounce: os limites que cada fornecedor publica

Não há dois fornecedores que concordem, e só o Amazon SES associa sanções concretas ao seu número.

O essencial A taxa de bounce é o número de bounces a dividir pelo número de emails enviados, multiplicado por 100. Enviam-se 1 000 e voltam 25: dá 2,5%. Quatro grandes fornecedores tomaram posição, e não estão de acordo. O Amazon SES pede que se mantenha a taxa abaixo de 2%, põe a conta em revisão aos 5% e pode suspender os envios aos 10%. O Klaviyo publica «abaixo de 1,0%», metade do valor do SES. O painel de sequências do HubSpot considera boa uma taxa abaixo de 3%. Para o Gmail, o Google não publica limite nenhum. O Mailchimp explica porquê no seu próprio centro de ajuda: "ISPs do not publicly release their limits." Ou seja, o «padrão da indústria de 2%» que toda a gente cita é o número de um fornecedor de cloud, não de um setor inteiro. O SES conta só os hard bounces e exclui, por escrito, a caixa cheia e os IP bloqueados. Na prática, 3% de caixas cheias e 3% de endereços mortos não são a mesma coisa, e só um deles ameaça a conta. Para o cold email, não existe nenhuma referência publicada, nem de um fornecedor de envio, nem de um organismo de normalização, nem de uma empresa de estudos.

Pegue no número de bounces, divida-o pelo número de emails enviados e multiplique por 100. A fórmula é essa, e é a última coisa simples desta página.

Antes dos números, um esclarecimento, porque o Google mistura as duas coisas a toda a hora. A analítica web tem uma métrica com o mesmo nome, que nada mais partilha com esta. O Google Analytics 4 define-a como "the percentage of sessions that were not engaged", e considera com envolvimento uma sessão que dura mais de 10 segundos, desencadeia um evento-chave ou chega a duas visualizações de página (ajuda do GA4, consultada a 29 de agosto de 2026). Num site, 42% é um dia normal. Num envio de email, 42% quer dizer que a lista nunca foi verificada e que o domínio está em apuros.

Agora a parte que ninguém faz como deve ser. Todos os artigos bem posicionados nesta pesquisa apresentam uma tabela de limites, e nenhum diz quem publicou os números que lá estão. Passei a manhã a ler as fontes primárias — o FAQ do Amazon SES sobre sanções, as faixas de entregabilidade do Klaviyo, a documentação de bounce do HubSpot, as regras de remetente do Google, o artigo do Mailchimp sobre bounces, a RFC 3463 e a referência de erros SMTP do Gmail — e copiei a formulação palavra por palavra. É isto que dizem, com a data em que consultei cada uma.

Antes de continuar, devo declarar um interesse. Dirijo a Enrow, que encontra e verifica emails profissionais, e tenho portanto interesse comercial em que este número lhe importe. Daqui até às duas últimas secções, tudo vem de documentos de terceiros, citados com o link ao lado.

Todos os limites de bounce publicados, numa tabela

Dois fornecedores, o Amazon SES e o Klaviyo, publicam um número preciso, e um é o dobro do outro. Um terceiro, o HubSpot, publica um valor mais folgado para as sequências e recusa-se a publicar um para o email de marketing. O Google não publica nada.

Três destas dez linhas dizem, de uma maneira ou de outra, «não há número». Não li mal. É a posição que dois dos maiores remetentes do mundo assumem por escrito, e explica por que razão a tabela arrumadinha de 2%/5% que circula nos resultados desta pesquisa tem uma única fonte real por trás.

O que o número do SES mede, ao certo

Quem cita os 5% herda a definição que vem com eles, e essa definição é mais estreita do que se costuma supor. O SES conta hard bounces para domínios que não foram verificados, e mais nada: "Temporary and intermittent failures such as 'mailbox full,' or bounces due to blocked IP addresses, don't count toward your bounce rate" (FAQ de bounce, Q3, consultado a 29 de agosto de 2026). Uma campanha que aparece a 4% no painel do seu fornecedor de envio pode estar bem abaixo de 1% pelas contas do SES. Ou pode não estar, e não há maneira de saber sem separar os códigos.

Há um segundo pormenor que quase ninguém menciona: quem está sujeito ao número do SES não o consegue reproduzir. A Amazon di-lo por escrito: "We don't calculate your bounce rate based on a fixed period of time… Instead, we look at a representative volume." E o próprio FAQ explica a seguir que a API de estatísticas de envio também não lho dá. A métrica que decide se a conta continua a enviar é calculada numa janela que a Amazon não revela, sobre um volume que a Amazon escolhe. Planeie em função do limiar que suspende a conta, não do valor que o painel mostra.

Já agora, mantenha as queixas numa coluna à parte. O Amazon SES pede uma taxa de queixas abaixo de 0,1%, põe a conta em revisão a partir de 0,1% e pode suspender os envios a partir de 0,5% (FAQ de queixas, Q5, consultado a 29 de agosto de 2026). O Klaviyo reparte a mesma métrica por três colunas da sua tabela de entregabilidade: saudável abaixo de 0,01%, a melhorar entre 0,01% e 0,05%, a precisar de atenção acima de 0,05%. Para os cancelamentos de subscrição, a faixa saudável fica abaixo de 0,3% por campanha. Métricas diferentes, cálculos diferentes, e, no entanto, há quem cite as duas no mesmo parágrafo como se fossem uma só.

Hard bounce e soft bounce

Um valor de 2,8% no HubSpot e outro de 2,8% no Amazon SES não medem a mesma coisa.

Um hard bounce é uma rejeição permanente: a caixa não existe, o domínio não consegue aceitar correio, ou o servidor recusa-o por motivos de política. Traz uma resposta SMTP da classe 5yz, que a RFC 3463 define como uma falha que dificilmente se resolve reenviando a mensagem tal como está. Um soft bounce é passageiro, traz uma resposta 4yz e costuma resolver-se numa segunda tentativa: caixa cheia, ritmo de envio excessivo, um servidor num mau dia.

A versão curta da tabela seguinte: de um lado, um endereço morto; do outro, um mau momento.

A versão longa é a que interessa, porque o seu fornecedor de envio lhe mostra uma categoria e o servidor de destino lhe mandou um código. Não é a mesma informação. Nove tipos de bounce cobrem quase todos os casos que surgem num envio real, e só quatro são falhas permanentes que entram na taxa que o Amazon SES aplica; os outros cinco são passageiros, excluídos ou não documentados.

Os códigos SMTP e as definições de sub-código foram retirados da RFC 3463 e da referência de erros SMTP do Gmail, ambas consultadas a 29 de agosto de 2026. O tratamento do SES vem do seu FAQ de bounce, consultado na mesma data.

E aqui está a divergência que vale a pena conhecer, porque muda o que o painel lhe está a dizer. O HubSpot lista seis motivos de hard bounce e «Mailbox full» é um deles. O Amazon SES dá o mesmo caso como exemplo do que não conta. É o mesmo bounce, para o mesmo destinatário, e um fornecedor classifica-o como permanente enquanto o outro o ignora. Nenhum dos dois está errado, mas 2,8% no HubSpot e 2,8% no SES continuam a não ser números comparáveis.

É nos soft bounces que se desfaz o folclore do «não faz mal, o servidor tenta outra vez». O Klaviyo suprime um endereço automaticamente ao fim de mais de 7 soft bounces consecutivos, contando só os dos últimos 2 anos. O Mailchimp prevê uma exceção deliberada no sentido contrário: "If a bounced address has recently engaged with your emails, we won't remove it from your audience right away." Dois fornecedores, o mesmo sinal, reflexos opostos. Num ponto estão de acordo: um soft bounce que se repete deixa de ser um contratempo passageiro e passa a ser uma caixa morta disfarçada.

Que taxa de bounce é boa?

Abaixo de 2% é o valor que o Amazon SES publica como boa prática, e é o único acompanhado de sanções concretas: revisão aos 5%, suspensão possível aos 10%, contando só hard bounces. O Klaviyo é mais exigente e fixa o limite abaixo de 1,0%. Em cold email, o objetivo prático é ficar abaixo de 1%, porque um envio a frio não tem um histórico de envolvimento que amorteça o impacto.

Este último valor é uma escolha minha; ninguém o publica como regra. Um envio a frio sai muitas vezes de um domínio jovem, sem histórico nenhum acumulado na conta, e aí as linhas mortas custam mais caro do que custariam numa newsletter com cinco anos de casa. O objetivo alcança-se sem proezas: é o resultado normal de uma lista verificada antes do envio. O método é aborrecido e está explicado em verificação de emails em massa: normalizar, tirar duplicados, passar cada linha por verificações SMTP reais, separar os resultados por estado em vez de os filtrar e voltar a verificar antes da campanha seguinte, sem confiar num ficheiro de março.

Valores de referência de bounce, por contexto de envio

As listas maiores têm menos bounces: entre 1 000 e 2 499 contactos, a taxa é de 3,18%, mais do dobro das maiores.

O maior conjunto de dados públicos sobre isto vem do GetResponse, que analisou mais de 4,4 mil milhões de mensagens enviadas pelos seus clientes em 2023, limitando-se às contas com pelo menos 500 contactos. A média que apresenta é 2,33%. E a conclusão mais útil contraria a intuição com que quase toda a gente aborda a limpeza de listas: as listas maiores têm menos bounces, não mais. O segmento acima de 100 000 contactos fica nos 1,51%, ao passo que as listas de 1 000 a 2 499 ficam nos 3,18%, mais do dobro.

Fonte: GetResponse Email Marketing Benchmarks, ano de dados 2023, página consultada a 29 de agosto de 2026. Trata-se apenas de email de marketing com consentimento: nada disto é prospeção a frio.

Os emails de boas-vindas, nos 3,98%, quase seis vezes o valor do RSS, são o dado mais revelador. É o envio que parte para um endereço no instante em que alguém o escreve num formulário, antes de qualquer verificação. É aí que as gralhas e os endereços descartáveis aparecem primeiro.

O setor de atividade pesa tanto como qualquer fator que esteja nas suas mãos, e do primeiro ao último a taxa quadruplica.

Mesma fonte, mesmo ano de dados, consultada na mesma data. Uma ressalva: o relatório apresenta três médias gerais diferentes, consoante a tabela que se abra (2,33% na tabela dos continentes e no FAQ, 2,79% na dos setores, 2,78% na dos países). São agregações diferentes do mesmo corpus, que o relatório não concilia. Indiquei de que tabela veio cada número, em vez de escolher o que me convinha.

Por país, o intervalo alarga-se ainda mais, e os resultados surpreendem um leitor europeu: Polónia 1,13%, Bélgica 1,75%, Austrália 1,77%, Canadá 2,26%, Espanha 2,48%, Estados Unidos 2,70%, França 2,71%, Grã-Bretanha 3,21%, Alemanha 3,89%, Israel 9,97%. E nada disto é estável. No mesmo relatório, a América do Norte caiu de 4,92% em 2022 para 2,68% em 2023. Um valor de referência é uma fotografia, não é uma constante.

Taxa de bounce em cold email: a referência que não existe

Não há média publicada de taxa de bounce para prospeção a frio. Fui procurá-la a 29 de agosto de 2026 e vim de mãos a abanar: o resultado mais bem posicionado para essa pergunta exata é uma publicação no LinkedIn que fala em cerca de 7,5%, sem dados, sem amostra e sem fonte nenhuma. Trate-o pelo que é, um número que alguém escreveu.

A taxa de bounce de uma lista fria decide-se a montante do envio: de onde vieram os endereços, há quanto tempo esperam no CRM e se cada um foi verificado antes de receber a primeira mensagem. Os limites publicados pelos fornecedores, mais acima, são as únicas referências fixas, portanto confronte os seus envios com eles: o «abaixo de 1,0%» do Klaviyo é a faixa saudável, e é aos 5% que o Amazon SES põe a conta em revisão.

O que um bounce lhe custa de verdade

Um hard bounce não é uma mensagem que não chegou. É uma marca no historial do seu domínio de envio, e essa marca dura mais do que a campanha que a produziu.

O HubSpot documenta a versão mais concreta disto, e vale a pena lê-la duas vezes. Um contacto que gere hard bounces em três ou mais contas HubSpot recebe o estado de bounce global e fica "dropped from future emails across all HubSpot accounts" — não na sua conta, em todas. O dano de reputação que os endereços maus provocam não fica confinado à conta que lhes escreveu. A lista suja de outra pessoa pode queimar um endereço antes mesmo de chegar a sua vez de lhe escrever, e a sua lista suja faz o mesmo aos outros.

No SES, o problema apresenta-se de outra maneira. Como a taxa de bounce é calculada sobre um volume representativo e não sobre uma janela fixa, não basta esperar que um mau envio caia no esquecimento. Não há nenhuma segunda-feira em que o contador volte a zero. Um mau número dilui-se devagar, à custa de envios bons, e entretanto a conta fica em revisão.

A assimetria é a parte que as equipas subestimam. Uma tarde a enviar para um ficheiro podre obriga a semanas de envios pequenos, cuidadosos e bem recebidos para recuperar. Já vi um domínio passar de uma reputação limpa para a pasta de spam entre o almoço e o fim do dia.

Porque é que os emails são devolvidos

Os bounces decidem-se na qualidade da lista, não no texto. Assuntos e horas de envio mexem com as taxas de abertura; nenhum deles muda o facto de a caixa existir ou não. Quatro causas explicam quase tudo o que vejo em ficheiros reais, e a primeira pesa mais do que as outras três juntas.

À cabeça vêm as linhas antigas. As pessoas mudam de empresa e os endereços morrem quando entregam o crachá, de maneira que qualquer ficheiro exportado há meses está a degradar-se enquanto espera no CRM. Não lhe consigo dar uma percentagem fiável de degradação: a fonte de estatísticas de emprego dos Estados Unidos que normalmente citaria devolveu-me um erro 403 a 29 de agosto de 2026, e não vou buscar o número a um blogue. A tendência, essa, não oferece dúvidas: uma exportação de há nove meses não é uma lista, é um arquivo.

Em segundo lugar vêm os endereços deduzidos a partir do formato da empresa. Alguém aplica nome.apelido@empresa.com a 400 linhas e envia sem mais verificações. Uma parte razoável está certa. Cada endereço errado gera um bounce, e não há maneira de distinguir os certos dos errados sem confirmar endereço a endereço. O método para deduzir com critério, e depois confirmar, está explicado no guia sobre como encontrar o email de alguém.

Depois vêm os catch-all, cujos bounces passam despercebidos até ser tarde demais. O SendGrid separa os dois mecanismos com precisão: um bounce síncrono acontece "when the remote inbox provider rejects the message during the initial delivery attempt", ao passo que um assíncrono acontece "when Twilio SendGrid accepts a message for delivery, but the inbox providers reports that message as a bounce" (documentação do SendGrid, consultada a 29 de agosto de 2026). Um domínio que aceita tudo diz que sim à porta e rejeita a mensagem no corredor, horas depois. É esse atraso que torna insegura uma linha catch-all por resolver; o mecanismo completo está explicado no artigo sobre o que é um email catch-all.

Por fim, a causa mais aborrecida de todas: dados sujos. Um espaço a mais no fim, .con no lugar de .com, nomes próprios na coluna do apelido, uma colagem que desalinhou o ficheiro inteiro, com tudo deslocado uma linha. Corrigir não custa nada. Enviar assim custa caro.

Como baixar a taxa de bounce

Verificar cada endereço antes de cada envio, apagar os hard bounces assim que aparecem, sem voltar a enviar, manter os catch-all fora do ficheiro enquanto ninguém os resolver e verificar outra vez tudo o que foi recolhido há mais de alguns meses: esta sequência elimina quase todas as causas de bounce. O resto é disciplina de volume: o Google classifica como remetente em massa quem passa das 5 000 mensagens por dia para contas Gmail, e esse é o único número publicado em que se pode basear um warm-up.

Dois hábitos valem mais do que todo o resto da lista.

O primeiro: agrupe o relatório de bounces por domínio de destino antes de o ler. Uma percentagem ao nível da campanha dilui na média a informação útil. Imagine um envio para 2 000 endereços que gera quatro hard bounces, todos na mesma empresa. Raramente é azar. Quase sempre quer dizer que o formato de endereço que aplicou àquela empresa está errado, o que põe sob suspeita todas as outras linhas que tem do mesmo domínio, tenham sido devolvidas ou não. Volte a pesquisar o domínio: quatro falhas permitem-lhe corrigir vinte linhas.

O segundo: confronte o seu relatório com os códigos da tabela acima antes de reagir. 452 4.2.2 e 550 5.1.1 caem na mesma coluna do painel, com a etiqueta «bounced», e querem dizer o contrário um do outro — um é uma pessoa com a caixa cheia, o outro é uma caixa que já não existe. Quem apaga o primeiro e volta a enviar para o segundo está a fazer tudo ao contrário. O HubSpot mostra isto como deve ser, na propriedade do motivo de hard bounce, e o procedimento de auditoria está descrito no artigo sobre a qualidade dos dados no HubSpot CRM. Se envia por sequências, os limiares que esse painel usa estão no guia das sequências do HubSpot.

As afirmações que circulam, confrontadas com a fonte

Oito afirmações dominam as páginas mais bem posicionadas nestas pesquisas, e todas deturpam a fonte que invocam. A mais repetida, o «padrão da indústria de 2%», não passa do valor de boa prática de um fornecedor de cloud, que conta um único tipo de bounce. Recolhi cada afirmação num resultado real, a 29 de agosto de 2026, e pus ao lado o documento primário.

Quanto custa prevenir e quanto custa um bounce

Verificar mil endereços custa 3,75 € no plano pago mais barato e 1,80 € no Scale, que tem cinquenta vezes mais créditos e custa vinte e quatro vezes mais: 1,95 € de diferença. Uma verificação custa um quarto de crédito, portanto mil linhas consomem 250 créditos.

Preços da Enrow em euros, com pagamento mensal. O custo de verificação é o preço mensal a dividir pelos créditos mensais, multiplicado por 250. Os créditos do plano gratuito repõem-se todos os meses.

De um lado, três euros e setenta e cinco cêntimos para verificar mil endereços; do outro, uma semana de entregabilidade degradada em todas as campanhas que saem do domínio. A comparação nem sequer é renhida, e é aí que se percebe que a taxa de bounce é mais uma decisão de compra do que uma decisão de envio.

Como vendo uma destas ferramentas, aqui ficam, de uma só vez, a declaração de interesses e os limites. A Enrow encontra e verifica emails profissionais e números de telemóvel em tempo real, e só cobra quando o resultado é válido: uma pesquisa sem resultado ou um bounce não custam um cêntimo. Cada endereço passa por mais de 10 verificações (vários testes SMTP e sondagens de catch-all a partir de servidores em regiões diferentes), e as linhas de domínios que aceitam tudo saem verificadas, em vez de ficarem arrumadas na gaveta dos «arriscados». Os ficheiros completos entram pela API ou, se trabalhar dentro do Claude ou do Cursor, pelo servidor MCP em github.com/EnrowAPI/enrow-mcp. A partir de um perfil do LinkedIn ou do Sales Navigator, a extensão Chrome envia com um clique a ficha de contacto completa e verificada para o HubSpot, o Salesforce ou o Pipedrive. Nos três, a operação cria o registo ou atualiza-o se já existir, de modo que um prospect que apareça em duas pesquisas guardadas dá um registo atualizado duas vezes, e não dois registos.

Agora os limites. A Enrow não tem uma base de contactos para consultar e não vai construir nenhuma, porque uma base armazenada só volta a ser recolhida de três em três ou de nove em nove meses, e é nesse intervalo que se dá a degradação que enche um envio de linhas mortas. Optámos por pesquisar no momento do pedido, e o preço dessa escolha é este: a lista continua a construir-se no LinkedIn ou no Sales Navigator, não aqui. O saldo de créditos também é partilhado entre as duas tarefas: se passar 40 000 linhas pelo verificador no plano Pro, os 10 000 créditos do mês esgotam-se e não sobra nada para encontrar contactos novos. Reparta esse orçamento antes de carregar o ficheiro, não depois.

FAQ

Que taxa de bounce é boa?

O valor mais usado é o do Amazon SES: manter abaixo de 2%, com revisão da conta aos 5% e suspensão possível aos 10%, contando só hard bounces. O Klaviyo é mais exigente e fixa o limite abaixo de 1,0%. O HubSpot considera boa uma taxa abaixo de 3% numa sequência. Em prospeção a frio, o objetivo realista para uma lista verificada antes do envio é ficar abaixo de 1%.

Que taxa de hard bounce é aceitável?

Os hard bounces são os que os fornecedores sancionam, portanto o número aceitável anda perto de zero. O Amazon SES conta só hard bounces na taxa que põe uma conta em revisão aos 5% e a suspende aos 10%. Uma lista B2B verificada deve ficar abaixo de 1% de hard bounces; acima de 2%, é sinal de que entraram no ficheiro endereços que não passaram por uma verificação real.

Como se calcula a taxa de bounce de um email?

Divida o número de mensagens devolvidas pelo número de mensagens enviadas e multiplique por 100. Uma campanha enviada para 5 000 endereços que gere 60 bounces tem uma taxa de 1,2%. Calcule também os hard e os soft em separado, porque o Amazon SES só conta os hard nos seus limiares de sanção e exclui as caixas cheias e os IP bloqueados.

Devo apagar os hard bounces da minha lista?

Sim, de imediato, e sem nunca voltar a enviar. Um hard bounce é uma rejeição permanente da classe 5yz, definida pela RFC 3463 como uma falha que dificilmente se resolve reenviando a mensagem tal como está. O HubSpot vai mais longe: um contacto que gere hard bounces em três ou mais contas HubSpot deixa de receber emails em todas as contas HubSpot. Apague a linha, não se limite a suprimi-la, e volte a procurar o contacto.

Uma taxa de bounce de 42% é boa?

Esse número é quase de certeza de analítica web, não de email. O Google Analytics 4 define a taxa de bounce como a percentagem de sessões sem envolvimento, e 42% é banal num site. Em email, 42% significaria uma lista nunca verificada e um domínio de envio já em sarilhos sérios. As duas métricas partilham o nome e mais nada.

Os soft bounces prejudicam a reputação de remetente?

Um soft bounce isolado é uma rejeição transitória da classe 4yz, e o Amazon SES exclui as caixas cheias da sua taxa por completo. O problema está na repetição. O Klaviyo suprime automaticamente um endereço ao fim de mais de sete soft bounces consecutivos, contados ao longo de dois anos, porque uma caixa que nunca aceita correio está funcionalmente morta, seja qual for o código que devolva.

Qual é a taxa média de bounce em cold email?

Nenhum fornecedor de envio, organismo de normalização ou empresa de estudos publica uma. Os valores que circulam à volta de 7,5% vêm de publicações em redes sociais sem fonte primária. Em vez disso, confronte os seus envios com os limites que os fornecedores publicam: abaixo de 1,0% é a faixa saudável do Klaviyo, e 5% põe uma conta do Amazon SES em revisão.

Qual é a diferença entre hard bounce e soft bounce?

Um hard bounce é permanente, traz uma resposta SMTP da classe 5yz — como o 550 5.1.1 do Gmail para uma caixa que não existe — e a linha deve ser apagada. Um soft bounce é transitório, traz uma resposta 4yz como o 452 4.2.2 de caixa cheia, e costuma resolver-se numa segunda tentativa. Nos casos-limite, os fornecedores divergem: o HubSpot classifica a caixa cheia como hard, o Amazon SES exclui-a da taxa de bounce.

Como verifiquei isto

Todos os limites desta página foram consultados diretamente na fonte primária a 29 de agosto de 2026 e citados nas palavras do próprio fornecedor, não parafraseados a partir de outro artigo. Aqui, isso pesou mais do que é costume: nenhuma das páginas que o Google mostrava nessa data para esta pesquisa indica a origem dos seus números.

O que li nessa manhã, por ordem: o FAQ do Amazon SES sobre sanções (bounce, da Q3 à Q6, e o FAQ de queixas), as métricas de entregabilidade do Klaviyo e o artigo das faixas de referência, mais a documentação de supressões, o artigo do HubSpot sobre hard e soft bounce, a sua página de sender score das sequências e as páginas de período probatório e de suspensão, as regras de remetente do Gmail, a referência de erros SMTP do Google Workspace, a definição de taxa de bounce do GA4, o artigo «About bounces» do Mailchimp, a RFC 3463 na íntegra, a documentação de bounces do SendGrid e o relatório Email Marketing Benchmarks do GetResponse. As afirmações da tabela que as confronta com a fonte foram recolhidas em resultados reais do Google, em inglês dos Estados Unidos, consultados na mesma manhã.

Houve duas fontes que quis consultar e não consegui. O comunicado JOLTS do Bureau of Labor Statistics devolveu HTTP 403 a todos os pedidos, por isso esta página não apresenta nenhum valor de mudança de emprego nem de degradação de listas. O centro de ajuda do Brevo também devolveu 403, de modo que o Brevo fica fora da tabela de limites, em vez de figurar com um número citado de memória. Por fim, não conheço nenhum limite de bounce publicado pelo Microsoft 365 e não procurei nenhum nesse dia, portanto a Microsoft também não entra na tabela.

Os números da própria Enrow vêm dos nossos dados internos, verificados a 29 de agosto de 2026. A taxa de bounce abaixo de 1% e a taxa de cobertura de cerca de 60% são médias observadas nos ficheiros que a Enrow processa. São medições, não promessas, e ninguém lhe reembolsa um bounce.

A sua taxa de bounce decide-se antes de carregar em enviar, não depois. Passe a próxima lista pela Enrow: mais de 10 verificações por endereço, catch-all resolvidos em vez de arrumados na gaveta, e 50 créditos que se repõem todos os meses, com ou sem cartão.