Brevo deliverability: domain authentication and shared IPs

Brevo sends from shared IP pools it manages, so your IP reputation is largely the platform's problem and mostly fine. What is yours: the sending domain's authentication, the list, and the shape of your sending. Fix them in that order.

Authenticate the sending domain first

In Brevo's senders and domains settings, add your sending domain and publish the DNS records it shows you — a DKIM record on the selector Brevo generates, a verification record proving you control the domain, and the SPF or return-path record that makes the envelope domain yours. Copy the exact values from that screen; they are account-specific and change over time, so never reuse values from an article or an old runbook.

Until this is complete, your mail is signed by the platform's domain. SPF and DKIM pass — for Brevo — and DMARC does not align with your visible From address. If your domain publishes p=quarantine or p=reject, you are instructing receivers to filter your own campaigns.

Verify from the receiving side rather than from the settings screen: send to a mailbox you control, open the raw headers, and confirm dkim=pass with header.i= on your domain and dmarc=pass with header.from= on your domain.

Also publish DMARC yourself if you have not: p=none with a rua= address first, read a week of aggregate reports to find senders you forgot about, then tighten to quarantine. For 5,000+ messages a day to Gmail you additionally need a one-click unsubscribe header (RFC 8058); Brevo adds the unsubscribe mechanics for campaigns, but confirm it is present in a received message.

While in DNS: one SPF TXT record only, and count its DNS lookups. Ten is the limit per record, and crossing it is a permerror that breaks every sender on the domain simultaneously.

Shared IPs, and when a dedicated one helps

A shared pool means your sending is judged alongside other senders, and the platform actively protects the pool — which is why new accounts and large first imports attract scrutiny or review. That is the pool working as intended.

A dedicated IP is available at higher volumes and is only worth it when your volume is high and consistent. Reputation on an IP decays when it goes quiet, so a sender with two big campaigns a month will re-warm forever and perform worse than on the shared pool. If you take one, ramp it deliberately: small volumes to your most engaged contacts first, doubling every few days, holding whenever deferrals rise.

Then the list and the pattern

• Segment by engagement. Opened or clicked in the last 90 days is a workable definition; everything older goes into a separate, small, carefully-worded stream or nowhere at all.
• Remove hard bounces from your source system, not just from Brevo, or your next import re-adds them.
• Suppress role addresses for marketing. Nobody at info@ subscribed.
• Smooth the volume. Spikes after long silences are treated as suspicious; split large sends across hours or days.
• Separate streams. Transactional mail (Brevo can send it via its API or SMTP) should use a different subdomain from campaigns so a promotional complaint spike cannot delay password resets.

Thresholds: hard bounces under 2%, complaints under 0.05%, Gmail user-reported spam rate under 0.1% against the published 0.3% bulk-sender limit, checked per sending domain in Postmaster Tools.

What Brevo's numbers can and cannot show

The delivery figure in any ESP, Brevo included, is an acceptance figure: the receiving server answered 250 and took custody. The folder decision happens afterwards, inside the receiver, and is never reported back. A campaign can show a high delivery rate and sit entirely in Junk.

Open rate is also a weak input now — Apple Mail Privacy Protection pre-fetches images and proxies inflate opens unevenly. Use clicks, replies and conversions as outcomes, and seed-based placement testing per provider to see folders.

Fix order, condensed

1. Authenticate the sending domain and verify alignment from real headers.
2. Publish DMARC with reporting, read the reports, then tighten.
3. Prune and segment; remove bounces from the system of record.
4. Ramp a newly authenticated domain starting with the most engaged contacts.
5. Check the Gmail spam rate per domain in Postmaster Tools, and check the domain against live blocklists — remembering that SORBS shut down in June 2024 and Validity's Heatwave blocklist launched on 3 September 2026, so your lookup set should be current.
6. Run a seed placement test per provider before and after each change, so you know which change worked.

Health thresholds at a glance

What not to do

• Do not import a purchased list. Shared-pool platforms review accounts for exactly this, and the bounce profile is unrecoverable.
• Do not re-add unsubscribed contacts under a new list name.
• Do not send a re-engagement blast to a dormant two-year segment from your main domain.
• Do not judge a fix by open rate.
• Do not change platform to escape the problem; an unauthenticated domain and a tired list behave the same everywhere.

MailPilot does not integrate with Brevo, and we are not going to imply it does. It works on the sending domain and mailbox layer underneath: SPF, DKIM and DMARC verification, warm-up over OAuth (Gmail, Outlook) or SMTP and IMAP (SendGrid, Amazon SES, Mailgun, Postmark, custom SMTP), real per-provider inbox placement through a seed network, and daily per-mailbox reputation tracking.