Brevo (ex-Sendinblue): Guia técnico para email transacional
Por CaptainDNS
Publicado em 16 Genver 2026
- 📢 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): contatar o suporte para ativar 2048 bits no TXT.
- SPF não é necessário em IP compartilhado: 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 compartilhado 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 se escondem sutilezas 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) | Compartilhados com o IP |
Quando escolher a API REST?
Privilegie a API se você 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,complaintem tempo real - Controle 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 você 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 você 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 enquanto você envia a partir de @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 registros | Tamanho de chave padrão | Para ativar 2048 bits |
|---|---|---|---|
| TXT (legacy) | 1 apenas | 1024 bits | Contatar o suporte Brevo |
| CNAME (recente) | 2 distintos | 2048 bits | Já ativado por padrão |
Configuração TXT (1 registro):
Type: TXT
Nome: mail._domainkey
Valor: k=rsa;p=MIIBIjANBgkqh...
Configuração CNAME (2 registros):
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 no console do 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 você tem uma configuração TXT (1 registro) e quer passar para 2048 bits:
- Contatar o suporte Brevo para solicitar a ativação
- Uma vez ativado, o novo valor DKIM aparece com um prefixo
sib2k - Atualizar o registro 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 muito longo, você precisa 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 você usa a Cloudflare para gerenciar seus DNS:
-
Modo DNS only obrigatório: o registro DKIM deve ter a nuvem cinza (DNS only), não laranja (proxy). O modo proxy quebra a autenticação DKIM.
-
CNAME Flattening desativado: esta funcionalidade pode impedir a resolução correta dos CNAME DKIM. Brevo recomenda desativá-la.
SPF: por que você não precisa adicionar o 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 que você adicione include:spf.sendinblue.com no seu SPF:
v=spf1 include:spf.sendinblue.com ~all
Isso não muda nada no alignment DMARC pois:
- SPF autentica sempre o domínio do Return-Path (
sender-sib.com) - O Return-Path continua controlado pelo Brevo, e você não pode alterá-lo
- DMARC verifica o alignment entre Return-Path e From header, que continua diferente
- 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 você assinar 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
Você vai precisar então adicionar seu IP dedicado no seu SPF:
v=spf1 ip4:77.32.170.5 ~all
Mas em IP compartilhado (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 a você um endereço IP exclusivamente reservado aos seus envios. Mas a maioria dos usuários não precisa dele.
IP compartilhado vs IP dedicado: compreender a diferença
IP compartilhado (padrão em todos os planos):
- Seu tráfego de email é roteado via IPs compartilhados 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)
- Controle 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 você 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 controle | 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 compartilhado:
- 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 | Contatos 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 contatos engajados < 90 dias |
| D21 | ~43.000 | Incluir contatos menos recentes |
| D28-56 | Até ao volume alvo | Subida progressiva até 100k+ |
Regras estritas durante o warm-up:
- Atingir os engajados primeiro: começar pelos contatos que abriram/clicaram nos últimos 30 dias
- Aumento progressivo: +15% por dia no máximo, nunca duplicação de volume
- Monitorar as métricas: bounce rate < 2%, complaint rate < 0.1%, abertura > 20%
- 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
- Monitoramento ativo: acompanhar 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 compartilhado
O SPF passa a ser necessário: com IP dedicado, você precisa configurar o 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?
Você 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 gerenciar o warm-up e a vigilância
Permaneça em IP compartilhado se:
- Volume < 50.000/semana
- Envios irregulares ou esporádicos
- Puramente transacional baixo volume
- Sem recursos para gerenciar ativamente a reputação
Na dúvida, comece pelo IP compartilhado. Os pools Brevo são bem gerenciados, e você sempre pode migrar para IP dedicado mais tarde, quando seu volume e sua regularidade estiverem 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 |
| Contatos 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 |
| Usuários | 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 você enviar 200 emails transacionais via API, sobram 100 créditos para campanhas.
Limites de contatos por plano e patamar
Armadilha frequente: o número de contatos 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 | Contatos 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 contatos, mesmo que você envie para apenas 200 pessoas. Para remover esse limite, é preciso passar ao patamar 20.000 emails/mês (contatos ilimitados no Starter).
Rate limits API: RPS e RPH
Brevo aplica rate limits por tier (General/Advanced/Extended). Em caso de ultrapassagem, você 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 contatos | 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 (contatos 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 contatos | 300 | 600 |
| Media library | 2 GB | 5 GB |
Leitura importante: estas quotas plataforma são máximos técnicos; os limites comerciais (contatos 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 registros DNS a criar:
- Brevo code (TXT): valida a propriedade do domínio
- DKIM (TXT ou CNAME conforme sua configuração)
- DMARC (TXT): política de tratamento dos emails não conformes
- Criar esses registros no seu registrar (atenção aos duplicados)
- Verificar a propagação (pode demorar 24-48h)
3. Ativar DKIM 2048 bits se necessário
Se você tem uma configuração TXT e quer 2048 bits:
- Contatar o suporte Brevo
- Uma vez ativado, atualizar o registro DNS com o valor
sib2k... - Se o valor ultrapassa 255 caracteres, usar a ferramenta splitter de Brevo
Se você 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
- Host:
5. Testar e monitorar
- 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 você ultrapassar 300 emails/dia:
- Passar ao plano Starter (5.000 emails/mês = ~160/dia)
- Verificar o limite de contatos conforme o patamar escolhido
- Se grandes volumes + necessidade de reputação isolada: considerar o IP dedicado (251 €/ano)
Guias técnicos: outras plataformas de email transacional
Descubra nossos guias completos para outras soluções de email transacional:
- Postmark: configuração DKIM e REST API - Especialista em entregabilidade, DKIM 1024 bits, Message Streams
- SendGrid: autenticação de domínio e Web API v3 - DKIM 2048 bits com rotação, IP dedicado a partir de 50k/mês
- Mailgun: DKIM com rotação automática - Return-Path nativo, rotação DKIM 120 dias
- Amazon SES: Easy DKIM e Custom MAIL FROM - $0.10/1000 emails, 7 regiões EU
- Mailjet: API v3.1 e configuração DKIM - DKIM 2048/4096 bits, aquisição Sinch
- Mandrill: integração Mailchimp transacional - Requisito Mailchimp Standard, blocos de 25k emails
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 o 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 registros 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?
Você não escolhe: o Brevo gera uma configuração TXT (1 registro) ou CNAME (2 registros) conforme a sua conta. Os CNAME são em 2048 bits por padrão, os TXT em 1024 bits exceto pedido ao suporte. Se você puder escolher, prefira CNAME (mais simples, 2048 bits nativo, sem limite 255 caracteres).
O plano Free é suficiente para uma app em produção?
Sim, se o seu volume é ≤ 300 emails/dia e você 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, o Brevo não obriga você a usar campanhas de marketing. Você pode criar uma conta apenas para API/SMTP transacional. O limite de 300 emails/dia no plano Free é global (transacional + campanhas), mas se você envia apenas transacional, tem 300 créditos disponíveis.
Como gerenciar o limite de 255 caracteres nos registros 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í o SPF passa a ser 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 o seu volume é inferior, se os seus envios são irregulares, ou se é transacional puro < 10.000/mês, fique no IP compartilhado. Na dúvida, comece pelo IP compartilhado 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 compartilhado, 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 gerenciar 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 registro 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 usuários. 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 contatos mais engajados. Um gap > 30 dias requer recomeçar do zero.
-
STARTTLS: Mecanismo de criptografia oportunista para SMTP. Inicia em claro depois upgrade para TLS. Porta 587 recomendada.
