Brevo (ex-Sendinblue): Guia técnico para email transacional

⚡TL;DR

• 📢 Brevo impõe autenticação DKIM desde fevereiro de 2024: sem ela, seus emails podem chegar desde @brevosend.com.
• A configuração DKIM pode ser em TXT (1024 bits por padrão) ou CNAME (2048 bits nativo): contactar o suporte para ativar 2048 bits no TXT.
• SPF não é necessário em IP partilhado: DKIM sozinho é suficiente para passar DMARC pois o Return-Path usa o domínio Brevo (sender-sib.com).
• IP dedicado desnecessário para a maioria: requer 100k+ emails/semana regulares e um warm-up de 4-8 semanas. Fique no IP partilhado se volume < 50k/semana.
• O plano Free oferece 300 emails/dia com acesso completo à API transacional e webhooks, sem expiração.

Introdução

Brevo (anteriormente Sendinblue) consolidou-se como um ator importante do email marketing na Europa, com uma solução transacional robusta utilizada por milhares de desenvolvedores para emails de confirmação, notificações e resets de senha.

Mas por trás da interface de marketing escondem-se subtilezas técnicas que podem bloquear seus envios: configuração DKIM em TXT vs CNAME, mecanismo de proteção automática que substitui seu domínio por @brevosend.com, limites do plano Free frequentemente mal compreendidos, e escolhas API vs SMTP relay conforme seus casos de uso.

Este guia destina-se a desenvolvedores, DevOps e administradores de sistemas que procuram integrar Brevo para email transacional sem surpresas desagradáveis. Detalhamos os pontos críticos, as configurações essenciais e as escolhas técnicas a fazer conforme sua stack.

API ou SMTP relay: qual escolha para email transacional?

Brevo oferece dois métodos de integração para email transacional, ambos disponíveis desde o plano Free.

Comparação rápida

Critério	API REST	SMTP relay
Integração	Código HTTP (SDK ou cURL)	Configuração SMTP padrão
Flexibilidade	Templates dinâmicos, batch, webhooks nativos	Conteúdo inline apenas
Débito	Até 6M versões/hora em batch	Depende do cliente SMTP
Tracking	messageId retornado imediatamente	Via webhooks ou logs
Compatibilidade	Requer dev customizado	Funciona com tudo (CMS, servidores mail)
Rate limits	Documentados (RPS, RPH)	Partilhados com o IP

Quando escolher a API REST?

Privilegie a API se precisar de:

• Personalização avançada: variáveis dinâmicas via params, templates reutilizáveis, conteúdo HTML/texto inline
• Batch transacional: até 1.000 versões personalizadas por chamada, 6.000 chamadas/hora = 6 milhões de versões/hora teórico
• Webhooks nativos: eventos sent, delivered, opened, clicked, bounced, complaint em tempo real
• Controlo fino: tags, headers personalizados, agendamento diferido, anexos (até 4 MB unitário, 20 MB total)

Endpoint principal: POST https://api.brevo.com/v3/smtp/email

Exemplo de envio simples:

curl -X POST https://api.brevo.com/v3/smtp/email \
  -H "api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sender": {"email": "no-reply@captaindns.com", "name": "SeuProduto"},
    "to": [{"email": "user@captaindns.com", "name": "John Doe"}],
    "subject": "Confirmação da sua inscrição",
    "htmlContent": "<p>Olá {{params.nome}}, bem-vindo!</p>",
    "params": {"nome": "John"}
  }'

Quando escolher o SMTP relay?

Privilegie o SMTP se precisar de:

• Compatibilidade máxima: plugins WordPress/WooCommerce, CMS, aplicações legacy, servidores mail existentes
• Configuração zero código: inserir host + porta + credenciais, nada mais
• Reutilização de infraestrutura: sua app já envia via SMTP, basta mudar os parâmetros

Configuração oficial:

SMTP server: smtp-relay.brevo.com
SMTP user: [seu email de conta]
SMTP password: [chave SMTP dedicada - NÃO a chave API]
Port: 587 (STARTTLS) ou 465 (SSL) ou 2525 (fallback)

Ponto de atenção crítico: o "SMTP password" é uma chave SMTP dedicada, distinta da API key. É o erro mais frequente durante a configuração.

Configuração DKIM: o ponto crítico a não falhar

Por que a autenticação tornou-se obrigatória

Desde 1 de fevereiro de 2024, Brevo impõe a autenticação de domínio para conformar-se com as exigências do Gmail e Yahoo. Microsoft seguiu em maio de 2025.

Consequência se não configurar DKIM: Brevo ativa automaticamente um mecanismo de proteção que substitui seu domínio de envio por @brevosend.com para maximizar a entregabilidade.

Formato observado: sua-empresa@5000001.brevosend.com

Implicação de produto: se seus destinatários veem um domínio @brevosend.com quando envia desde @captaindns.com, não é um bug SMTP/API, mas um problema de autenticação DNS não resolvida.

TXT vs CNAME: duas configurações possíveis

Brevo gera dois tipos de configuração DKIM conforme a antiguidade e parametrização da sua conta:

Tipo	Número de registos	Tamanho de chave padrão	Para ativar 2048 bits
TXT (legacy)	1 apenas	1024 bits	Contactar o suporte Brevo
CNAME (recente)	2 distintos	2048 bits	Já ativado por padrão

Configuração TXT (1 registo):

Type: TXT
Nome: mail._domainkey
Valor: k=rsa;p=MIIBIjANBgkqh...

Configuração CNAME (2 registos):

Type: CNAME
Nome: brevo1._domainkey
Destino: b1.captaindns-xx.dkim.brevo.com

Type: CNAME
Nome: brevo2._domainkey
Destino: b2.captaindns-xx.dkim.brevo.com

Regra de ouro: os valores exatos são sempre exibidos na consola Brevo durante a configuração. Não copiar/colar de documentação externa, sempre usar o que Brevo gera para sua conta.

Ativar DKIM 2048 bits em configuração TXT

Se tem uma configuração TXT (1 registo) e deseja passar a 2048 bits:

1. Contactar o suporte Brevo para solicitar a ativação
2. Uma vez ativado, o novo valor DKIM aparece com um prefixo sib2k
3. Atualizar o registo DNS no seu registrar com o novo valor

Atenção: alguns registrars limitam os campos TXT a 255 caracteres. Se o valor DKIM 2048 bits for demasiado longo, deve dividi-lo em vários segmentos entre aspas:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." "...continuação da chave..."

Brevo oferece um "DNS record splitter tool" na sua interface para gerar este formato automaticamente.

Armadilhas Cloudflare a evitar

Se usa Cloudflare para gerir seus DNS:

1. Modo DNS only obrigatório: o registo DKIM deve ter a nuvem cinza (DNS only), não laranja (proxy). O modo proxy quebra a autenticação DKIM.

2. CNAME Flattening desativado: esta funcionalidade pode impedir a resolução correta dos CNAME DKIM. Brevo recomenda desativá-la.

SPF: por que não precisa adicionar Brevo

Uma questão frequente dos desenvolvedores: "Devo adicionar include:spf.sendinblue.com no meu SPF?" Resposta curta: não, e não serviria para nada.

Compreender o porquê requer entender a diferença entre dois endereços de email distintos em cada mensagem:

O From header (endereço visível): no-reply@captaindns.com

• É o endereço que o destinatário vê no seu cliente de email
• DKIM assina este domínio (captaindns.com)

O Return-Path (Envelope From, endereço técnico): bounce@kh.d.sender-sib.com

• É o endereço técnico usado pelos servidores SMTP para rotear a mensagem
• SPF autentica este domínio (sender-sib.com), não o seu
• Invisível para o destinatário, visível apenas nos headers brutos

Como DMARC funciona com Brevo

DMARC exige que pelo menos um método (SPF ou DKIM) passe em "alignment" com o domínio From:

Método	Domínio autenticado	Domínio From	Alignment?	Resultado DMARC
SPF	sender-sib.com (Return-Path)	captaindns.com	❌ Não	Não contribui
DKIM	captaindns.com (assinatura d=)	captaindns.com	✅ Sim	✅ DMARC passa

Explicação: SPF valida que o IP de envio está autorizado para sender-sib.com (o domínio do Return-Path). Mas DMARC verifica se o domínio autenticado corresponde ao domínio From (captaindns.com). Como sender-sib.com ≠ captaindns.com, SPF não passa em alignment.

Por outro lado, DKIM assina o domínio captaindns.com (via assinatura d=captaindns.com), que corresponde exatamente ao From header. DKIM passa em alignment, portanto DMARC passa.

Por que adicionar Brevo no seu SPF não muda nada

Mesmo se adicionar include:spf.sendinblue.com no seu SPF:

v=spf1 include:spf.sendinblue.com ~all

Isso não muda nada no alignment DMARC pois:

1. SPF autentica sempre o domínio do Return-Path (sender-sib.com)
2. O Return-Path continua controlado por Brevo, não pode alterá-lo
3. DMARC verifica o alignment entre Return-Path e From header, que continua diferente
4. Portanto SPF não contribui ainda para DMARC

Veredicto: adicionar Brevo no seu SPF é inútil para o alignment DMARC. DKIM é amplamente suficiente.

A exceção: IP dedicado

SPF torna-se pertinente apenas se subscrever um IP dedicado (add-on a 251 €/ano, incluído em Enterprise).

Com um IP dedicado, Brevo pode configurar o Return-Path com seu domínio (bounce@captaindns.com em vez de bounce@sender-sib.com). Nesse caso:

• SPF autentica captaindns.com (Return-Path)
• DKIM autentica captaindns.com (From header)
• Ambos passam em alignment → dupla validação DMARC

Deverá então adicionar seu IP dedicado no seu SPF:

v=spf1 ip4:77.32.170.5 ~all

Mas em IP partilhado (planos Free a Professional), DKIM sozinho é suficiente para DMARC.

IP dedicado: quando e por que considerar?

O IP dedicado é um add-on a 251 €/ano (incluído em Enterprise) que atribui um endereço IP exclusivamente reservado aos seus envios. Mas a maioria dos utilizadores não precisa dele.

IP partilhado vs IP dedicado: compreender a diferença

IP partilhado (padrão em todos os planos):

• Seu tráfego de email é roteado via IPs partilhados com outros clientes Brevo
• A reputação do IP é coletiva: Brevo mantém pools de IP reputados
• Sem warm-up necessário: os IPs já estão "aquecidos" graças ao volume global
• Entregabilidade otimizada por Brevo (rotação de IP, gestão de reclamações)

IP dedicado:

• Um endereço IP apenas para seus envios
• Reputação isolada: suas práticas determinam sozinhas sua reputação
• Warm-up obrigatório: o IP está "frio" no início (nenhum histórico)
• Controlo total: possibilidade de usar seu domínio para o Return-Path (alignment SPF)

Quando escolher um IP dedicado?

Brevo recomenda um IP dedicado apenas se cumprir TODOS estes critérios:

Critério	Limite mínimo	Por que é importante
Volume semanal	50.000 a 100.000 emails/semana	Volume insuficiente → reputação instável
Regularidade de envio	Pelo menos 3 campanhas/semana	Gaps > 30 dias → IP esfria, warm-up a refazer
Engajamento elevado	Taxa de abertura > 20%, bounce < 2%	Mau engajamento em IP dedicado → reputação cai rápido
Necessidade de controlo	Isolar reputação transacional vs marketing	Separar fluxos críticos (transacional) e marketing

Exemplos de casos de uso legítimos:

• Finanças/saúde: conformidade regulamentar exigindo um IP dedicado rastreável
• Grandes volumes regulares: 200.000+ emails/semana com envios diários
• Necessidade de whitelisting: alguns clientes B2B exigem whitelistar seu IP
• Separação transacional/marketing: evitar o impacto das campanhas marketing nos emails transacionais críticos

Quando permanecer em IP partilhado:

• Volume < 50.000 emails/semana
• Envios irregulares (uma vez/mês, trimestrais)
• Início de atividade (histórico de engajamento insuficiente)
• Puramente transacional baixo volume (< 10.000/mês)

O processo de warm-up: 4 a 8 semanas incompressíveis

Um IP dedicado novo tem uma reputação nula aos olhos dos ISPs (Gmail, Yahoo, Outlook). Enviar 100.000 emails de uma vez num IP frio = spam garantido.

Plano de warm-up recomendado por Brevo:

Dia	Volume	Alvos
D1	3.000	Contactos mais engajados (aberto < 30 dias)
D2	3.450	+15% do volume anterior
D3	3.968	+15%
D7	~6.700	Continuar +15%/dia
D14	~17.000	Alargar aos contactos engajados < 90 dias
D21	~43.000	Incluir contactos menos recentes
D28-56	Até ao volume alvo	Subida progressiva até 100k+

Regras estritas durante o warm-up:

1. Atingir os engajados primeiro: começar pelos contactos que abriram/clicaram nos últimos 30 dias
2. Aumento progressivo: +15% por dia no máximo, nunca duplicação de volume
3. Monitorizar as métricas: bounce rate < 2%, complaint rate < 0.1%, abertura > 20%
4. Sem interrupção: um gap de 7+ dias desacelera o warm-up, 30+ dias = recomeçar do zero

Exemplo de erro fatal:

❌ Dia 1: 3.000 emails (OK)
❌ Dia 8-20: sem envio (férias)
❌ Dia 21: 50.000 emails de uma vez
→ Resultado: spam massivo, reputação destruída, impossível recuperar

Restrições e armadilhas de um IP dedicado

Compromisso exigido: manter uma disciplina de envio rigorosa

• Sem "pausa" > 30 dias sem recomeçar o warm-up
• Volume regular: melhor 50k/semana constante que 200k/mês esporádico
• Monitorização ativa: seguir bounce/complaint/engajamento em tempo real

Custo total de posse:

• 251 €/ano (add-on)
• Tempo de engenharia: 4-8 semanas de warm-up com vigilância
• Risco: má gestão = reputação pior que em IP partilhado

SPF torna-se necessário: com IP dedicado, deve configurar SPF para autorizar seu IP:

v=spf1 ip4:77.32.170.5 ~all

Pool de IP: para volumes muito grandes (> 500k/semana), Brevo oferece pools de vários IPs dedicados para distribuir a carga e manter a reputação.

Veredicto: quem realmente precisa de um IP dedicado?

Precisa de um IP dedicado se:

• Volume regular > 100.000 emails/semana
• Envios diários ou no mínimo 3x/semana
• Necessidade de whitelisting cliente ou conformidade regulamentar
• Orçamento e recursos para gerir o warm-up e a vigilância

Permaneça em IP partilhado se:

• Volume < 50.000/semana
• Envios irregulares ou esporádicos
• Puramente transacional baixo volume
• Sem recursos para gerir ativamente a reputação

Na dúvida, comece pelo IP partilhado. Os pools Brevo são bem geridos, e pode sempre migrar para IP dedicado mais tarde uma vez seu volume e regularidade estabelecidos.

Limites técnicos a conhecer antes de começar

Plano Free: 300 emails/dia, mas com qual perímetro?

O plano Free de Brevo oferece um acesso surpreendente às funcionalidades transacionais, mas com limites rigorosos:

Limite	Valor	Comportamento
Emails/dia	300	Reset diário, sem rollover
Contactos armazenáveis	100.000
Branding	Obrigatório	"Sent with Brevo" não removível
Campanha > 300 destinatários	Apenas 300 enviados no dia J	Requeue manual necessário
Utilizadores	1 apenas (owner)
Webhooks transacionais	✅ Incluído	Todos os eventos disponíveis
API REST	✅ Incluído	Acesso completo, rate limits padrão
SMTP relay	✅ Incluído	Host smtp-relay.brevo.com
Retenção dos logs	✅ Ilimitada

Ponto positivo: todas as funcionalidades transacionais estão disponíveis no plano Free, incluindo webhooks, API e SMTP relay. O limite de 300 emails/dia é suficiente para dev/staging ou apps de baixo volume.

Ponto de atenção: o limite de 300 emails/dia é um limite global (campanhas + transacional). Se enviar 200 emails transacionais via API, restam 100 créditos para campanhas.

Limites de contactos por plano e patamar

Armadilha frequente: o número de contactos armazenáveis não é apenas determinado pelo plano (Starter/Standard/Professional), mas também pelo patamar de volume de emails escolhido.

Plano	Patamar emails/mês	Contactos max
Starter	5.000	500
Starter	10.000	1.500
Starter	20.000+	Ilimitados
Standard	5.000	1.500
Standard	20.000	10.000
Professional	20.000	2.000
Professional	100.000+	100.000+

Exemplo concreto: um plano Starter a 5.000 emails/mês permite armazenar apenas 500 contactos, mesmo que envie apenas a 200 pessoas. Para levantar este limite, é preciso passar ao patamar 20.000 emails/mês (contactos ilimitados no Starter).

Rate limits API: RPS e RPH

Brevo aplica rate limits por tier (General/Advanced/Extended). Em caso de ultrapassagem, recebe um código HTTP 429 Too Many Requests.

Exemplos de limites genéricos:

Endpoint	RPS (pedidos/segundo)	RPH (pedidos/hora)
GET /v3/smtp/emails	2	7.200
Endpoints contactos	10	36.000

Batch transacional: permite 6.000 chamadas/hora × 1.000 versões por chamada = 6 milhões de versões/hora teórico.

Recomendação: para jobs de notificações em massa (alertas, lembretes, digests), usar o batch transacional em vez de chamadas unitárias para otimizar os rate limits.

Quotas plataforma (máximos técnicos)

Além dos limites comerciais (contactos conforme plano), Brevo aplica quotas técnicas por recurso:

Recurso	Planos gerais	Enterprise
Campanhas email armazenadas (drafts incluídos)	10.000	50.000
Campanhas email agendadas simultaneamente	150	300
Workflows automation ativos	50	500
Listas de contactos	300	600
Media library	2 GB	5 GB

Leitura importante: estas quotas plataforma são máximos técnicos; os limites comerciais (contactos conforme plano/patamar) podem ser mais baixos e aplicam-se primeiro.

Plano de ação: configuração em 6 etapas

1. Criar a conta e validar o sender

• Criar uma conta Brevo (Free possível)
• Criar um "sender" (endereço From) em Settings > Senders & IP
• Validar o endereço via link recebido por email

2. Autenticar o domínio (DKIM obrigatório)

• Ir a Settings > Senders & IP > Domain authentication
• Brevo exibe 3 registos DNS a criar:
  1. Brevo code (TXT): valida a propriedade do domínio
  2. DKIM (TXT ou CNAME conforme sua configuração)
  3. DMARC (TXT): política de tratamento dos emails não conformes
• Criar estes registos no seu registrar (atenção aos duplicados)
• Verificar a propagação (pode demorar 24-48h)

3. Ativar DKIM 2048 bits se necessário

Se tem uma configuração TXT e deseja 2048 bits:

• Contactar o suporte Brevo
• Uma vez ativado, atualizar o registo DNS com o valor sib2k...
• Se o valor ultrapassa 255 caracteres, usar a ferramenta splitter de Brevo

Se tem uma configuração CNAME: 2048 bits já ativado por padrão.

4. Escolher e configurar o método de envio

Opção A: API REST

• Gerar uma API key em Settings > API keys
• Implementar o endpoint POST /v3/smtp/email
• Criar templates em Campaigns > Transactional templates se necessário
• Configurar webhooks transacionais em Settings > Webhooks

Opção B: SMTP relay

• Gerar uma chave SMTP (distinta da API key) em Settings > SMTP & API
• Configurar sua app/plugin/servidor mail:
  • Host: smtp-relay.brevo.com
  • Port: 587 (STARTTLS recomendado)
  • User: seu email de conta
  • Password: a chave SMTP gerada

5. Testar e monitorizar

• Enviar um primeiro email de teste
• Verificar em Transactional > Email logs que o envio está OK
• Configurar webhooks para rastrear eventos (delivered, bounced, etc.)
• Verificar que o domínio From é o seu (não @brevosend.com)

6. Otimizar conforme o volume

Se ultrapassar 300 emails/dia:

• Passar ao plano Starter (5.000 emails/mês = ~160/dia)
• Verificar o limite de contactos conforme o patamar escolhido
• Se grandes volumes + necessidade de reputação isolada: considerar o IP dedicado (251 €/ano)

FAQ

Por que meus emails chegam desde @brevosend.com quando envio desde meu domínio?

É o mecanismo de proteção automática de Brevo ativado quando seu domínio não está autenticado (DKIM ausente ou inválido). Brevo substitui o domínio de envio por @brevosend.com para maximizar a entregabilidade no Gmail/Yahoo. Solução: configurar corretamente os registos DKIM nos seus DNS e aguardar a validação.

Qual é a diferença entre chave API e chave SMTP?

A chave API serve para as chamadas REST (POST /v3/smtp/email), a chave SMTP serve para autenticação no relay SMTP (smtp-relay.brevo.com). São duas credenciais distintas geradas em Settings > SMTP & API. Confusão frequente: usar a API key como password SMTP não funciona.

DKIM em TXT ou CNAME: qual escolher?

Não escolhe: Brevo gera uma configuração TXT (1 registo) ou CNAME (2 registos) conforme sua conta. Os CNAME são em 2048 bits por padrão, os TXT em 1024 bits exceto pedido ao suporte. Se tiver a escolha, prefira CNAME (mais simples, 2048 bits nativo, sem limite 255 caracteres).

O plano Free é suficiente para uma app em produção?

Sim, se seu volume é ≤ 300 emails/dia e aceita o branding "Sent with Brevo". Todas as funcionalidades transacionais (API, SMTP, webhooks, logs ilimitados) estão disponíveis no plano Free. Ideal para MVP, staging, ou apps de baixo volume. Para remover o branding, é preciso passar ao Starter + add-on "Remove logo" (9 €/mês).

Posso usar Brevo apenas para email transacional sem fazer campanhas?

Sim, Brevo não obriga a usar campanhas de marketing. Pode criar uma conta apenas para API/SMTP transacional. O limite de 300 emails/dia no plano Free é global (transacional + campanhas), mas se envia apenas transacional, tem 300 créditos disponíveis.

Como gerir o limite de 255 caracteres nos registos TXT para DKIM 2048 bits?

Alguns registrars (OVH, Gandi) limitam os campos TXT a 255 caracteres. Brevo oferece uma "DNS record splitter tool" que divide o valor DKIM em vários segmentos entre aspas. Formato: "primeira parte..." "continuação...". Cada segmento tem menos de 255 caracteres, e o DNS concatena automaticamente.

Devo adicionar Brevo (include:spf.sendinblue.com) no meu SPF?

Não, é inútil. SPF autentica o domínio do Return-Path (sender-sib.com no Brevo), não seu domínio From. Como DMARC verifica o alignment com o domínio From, SPF não contribui para DMARC no Brevo. DKIM sozinho é suficiente para passar DMARC. Exceção: com um IP dedicado, Brevo pode usar seu domínio para o Return-Path, e aí SPF torna-se pertinente.

Devo contratar um IP dedicado para meu projeto?

Provavelmente não. Um IP dedicado requer um volume mínimo de 50.000 a 100.000 emails por semana, com envios regulares (pelo menos 3x/semana). Impõe um warm-up de 4 a 8 semanas e uma disciplina rigorosa (sem pausa > 30 dias). Se seu volume é inferior, se seus envios são irregulares, ou se é transacional puro < 10.000/mês, permaneça em IP partilhado. Na dúvida, comece pelo IP partilhado e migre depois se necessário.

Glossário

• SPF (Sender Policy Framework): Protocolo de autenticação que lista os servidores autorizados a enviar emails para um domínio. SPF autentica o domínio do Return-Path, não o From header. Com Brevo em IP partilhado, SPF não passa em alignment DMARC pois o Return-Path é sender-sib.com.

• DKIM (DomainKeys Identified Mail): Protocolo de autenticação que assina criptograficamente os emails para provar que provêm do domínio declarado. DKIM assina o domínio do From header. Exigido pelo Gmail/Yahoo desde fevereiro de 2024.

• DMARC (Domain-based Message Authentication, Reporting & Conformance): Protocolo que verifica o alignment entre SPF/DKIM e o From header. DMARC passa se pelo menos SPF ou DKIM passa em alignment. No Brevo, apenas DKIM contribui para DMARC (exceto IP dedicado).

• Return-Path (Envelope From): Endereço técnico invisível usado pelos servidores SMTP para rotear o email e gerir os bounces. SPF autentica este domínio. No Brevo, é bounce@kh.d.sender-sib.com, não seu domínio.

• Alignment DMARC: Mecanismo que verifica se o domínio autenticado por SPF ou DKIM corresponde ao domínio From. Modo relaxed (padrão): os subdomínios passam. Modo strict: correspondência exata requerida.

• CNAME (Canonical Name): Tipo de registo DNS que aponta para outro domínio. Usado por Brevo para delegar a gestão das chaves DKIM aos seus servidores.

• Rate limit: Limite de débito expresso em RPS (pedidos por segundo) ou RPH (pedidos por hora). Ultrapassagem → código HTTP 429.

• Batch transacional: Método de envio permitindo personalizar até 1.000 versões de um email numa única chamada API. Otimiza os rate limits para notificações em massa.

• Webhook: URL HTTP chamado automaticamente por Brevo durante eventos (delivered, bounced, opened). Permite um rastreio em tempo real sem polling dos logs.

• Sender: Endereço email From validado no Brevo. Cada sender deve ser verificado (link por email) antes de ser usado.

• IP dedicado: Endereço IP isolado apenas para seus envios. Evita o impacto da reputação dos outros utilizadores. Requer um warm-up progressivo de 4 a 8 semanas. Permite o alignment SPF usando seu domínio para o Return-Path. Recomendado para volumes > 100.000 emails/semana regulares. Add-on 251 €/ano, incluído em Enterprise.

• Warm-up: Processo de aumento de carga progressivo de um IP dedicado novo. Começa a 3.000 emails/dia e aumenta 15% por dia durante 4 a 8 semanas. Atinge primeiro os contactos mais engajados. Um gap > 30 dias requer recomeçar do zero.

• STARTTLS: Mecanismo de encriptação oportunista para SMTP. Inicia em claro depois upgrade para TLS. Porta 587 recomendada.

Fontes oficiais

• Rebranding Sendinblue → Brevo
• Pricing e planos