Brevo (ex-Sendinblue): Guia técnico para email transacional
Por CaptainDNS
Publicado em 16 de janeiro de 2026
Atualizado em 30 de julho de 2026
- 📢 Brevo impõe autenticação DKIM desde fevereiro de 2024: sem ela, os seus emails podem chegar desde
@brevosend.com. - A configuração DKIM pode ser em TXT (1024 bits por predefiniçã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 palavra-passe.
Mas por trás da interface de marketing escondem-se subtilezas técnicas que podem bloquear os seus envios: configuração DKIM em TXT vs CNAME, mecanismo de proteção automática que substitui o seu domínio por @brevosend.com, limites do plano Free frequentemente mal compreendidos, e escolhas API vs SMTP relay conforme os 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 a 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,complaintem 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: introduzir host + porta + credenciais, nada mais
- Reutilização de infraestrutura: a 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
Porque 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 o seu domínio de envio por @brevosend.com para maximizar a entregabilidade.
Formato observado: sua-empresa@5000001.brevosend.com
Implicação de produto: se os 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 predefiniçã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 a sua conta.
Ativar DKIM 2048 bits em configuração TXT
Se tem uma configuração TXT (1 registo) e deseja passar a 2048 bits:
- Contactar o suporte Brevo para solicitar a ativação
- Uma vez ativado, o novo valor DKIM aparece com um prefixo
sib2k - 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 os seus DNS:
-
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.
-
CNAME Flattening desativado: esta funcionalidade pode impedir a resolução correta dos CNAME DKIM. Brevo recomenda desativá-la.
SPF: porque não precisa de adicionar Brevo
Uma questão frequente dos desenvolvedores: "Devo adicionar include:spf.brevo.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.
Porque adicionar Brevo no seu SPF não muda nada
Mesmo se adicionar include:spf.brevo.com no seu SPF:
v=spf1 include:spf.brevo.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 por Brevo, 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 subscrever um IP dedicado (add-on a 251 €/ano, incluído em Enterprise).
Com um IP dedicado, Brevo pode configurar o Return-Path com o 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 o 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 porque 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):
- O 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 os seus envios
- Reputação isolada: as suas práticas determinam sozinhas a sua reputação
- Warm-up obrigatório: o IP está "frio" no início (nenhum histórico)
- Controlo total: possibilidade de usar o 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 | Porque é 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 o 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:
- Atingir os engajados primeiro: começar pelos contactos que abriram/clicaram nos últimos 30 dias
- Aumento progressivo: +15% por dia no máximo, nunca duplicação de volume
- Monitorizar 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
- 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 o 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 o 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:
- Brevo code (TXT): valida a propriedade do domínio
- DKIM (TXT ou CNAME conforme a sua configuração)
- 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 predefiniçã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 a sua app/plugin/servidor mail:
- Host:
smtp-relay.brevo.com - Port:
587(STARTTLS recomendado) - User: o seu email de conta
- Password: a chave SMTP gerada
- Host:
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)
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 deliverability, 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
Porque 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 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 a sua conta. Os CNAME são em 2048 bits por predefiniçã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 o 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.brevo.com) no meu SPF?
Não, é inútil. SPF autentica o domínio do Return-Path (sender-sib.com no Brevo), não 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 o 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 o seu volume é inferior, se os 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 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 os 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 o 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.
