Brevo and Cold Email: What Its Own Anti-Spam Policy Prohibits

Brevo's anti-spam policy answers the question most people arrive with, and it answers it in one sentence. Under a heading titled bought and scraped lists, the policy states that contact lists scraped from the internet, acquired or purchased from a third party are strictly prohibited on its software, and it applies that prohibition to transactional and marketing messages alike.

So the honest answer to whether you can run cold outbound on Brevo is no, by the vendor's own acceptable use policy. That is not a gap in the product. It is a deliberate boundary, and understanding why it exists is more useful than looking for a way around it, because the same logic explains why marketing sending and outbound sending should not share a domain even when they are on different platforms.

Everything below is verified against brevo.com's own legal and product pages, fetched 15 August 2026.

What the policy actually requires

The anti-spam policy is specific in a way terms-of-service documents usually are not, and three requirements are worth quoting in substance.

Consent must be active. The policy states that the contact has to tick a checkbox to subscribe and that the checkbox cannot be pre-ticked. Consent must also be explicit, meaning the contact knows which kind of messages they will receive and for what purpose. And you must be able to provide proof of opt-in for every contact at any time.

Partner opt-in and co-registration are permitted but constrained: the policy requires every partner's name to be displayed and easily available, and caps the number at ten.

Read those together and the shape is clear. Brevo is built for a list that people joined, and its compliance model assumes a retrievable record of each person joining. A cold list has no such record by construction, which is why the prohibition on purchased and scraped lists is not a separate rule so much as a restatement of the consent requirement.

The stated consequence is immediate suspension or restriction of the account, either in whole or for particular services, and the policy is explicit that this exists to protect Brevo's own reputation as much as yours. That framing is worth taking seriously rather than reading as boilerplate.

Why a shared platform is a shared reputation

The mechanism behind the policy is the same mechanism that should shape your own architecture, and it is worth spelling out because it is the actual content of this article.

A bulk sending platform routes many customers' mail through shared infrastructure. When one customer sends to a purchased list, the resulting complaints and spam-trap hits attach to that shared infrastructure, and every other customer's placement degrades slightly. Providers police this aggressively because they have to. That is why the prohibition covers transactional messages too: a customer who cannot be trusted with a marketing list is a risk on any queue.

The same logic operates one level down, on your own domain, regardless of which platforms you use. A domain has one reputation. Marketing mail to a subscriber list and cold outbound to prospects generate very different complaint rates, very different engagement profiles and very different bounce patterns. Pointing both at the same domain merges those signals into one score, and the score converges on the worse of the two behaviours. Domain reputation covers how that score is formed and why it is slow to recover.

Marketing sendingWhat Brevo is built for

• Recipients opted in and can be proven to have done so
• Complaint rates are low and engagement is measurable
• Volume is bursty, tied to campaigns and product events
• Deliverability failure costs revenue from existing contacts
• Belongs on the primary domain or a close subdomain

Cold outboundWhat Brevo's policy excludes

• Recipients have no prior relationship and no opt-in record
• Complaint and bounce rates are structurally higher
• Volume is steady and spread across many mailboxes
• Deliverability failure costs pipeline, not existing revenue
• Belongs on separate domains that cannot damage the primary

What Brevo does publish about its plans

The product side is worth reading accurately, because the platform is genuinely good at the job it is built for.

Brevo's pricing page renders its plan structure server-side while the prices themselves load in the browser, so a plain fetch of that page returns the tiers and the feature lists without the figures. The plan names published are Free, Starter, Standard and Professional, with an enterprise tier above them, and a monthly against yearly toggle that advertises a ten percent reduction on the yearly state.

The feature boundaries that are published are the useful part. Starter is described as single-user, beginning from 5,000 emails a month, and carries the drag-and-drop editor, templates, an AI content generator, advanced segmentation, forms and basic reporting, with removal of the Brevo logo listed at that level. Standard adds marketing automation with unlimited multi-step workflows, A/B testing, advanced reporting including click heatmaps and geography and device breakdowns, AI send-time optimisation, web and event tracking, and one landing page. Professional is described as starting from 150,000 emails a month and adds WhatsApp, popups, mobile and web push, ten included seats, contact scoring covering RFM and CLV, and the advanced ecommerce features.

One structural detail matters more than the tier list. Brevo meters on emails sent rather than on contacts stored, which is unusual in marketing email and is the reason it suits senders with large lists they mail infrequently. SMS credits are sold separately from the sending plans.

Because the figures render client-side, no price is quoted here. A number read from a page that did not serve it is not verified, and the vendor's own pricing page is the place to read the current rate.

That metering choice has one practical consequence worth carrying into a comparison. Platforms that charge per contact stored reward pruning a list; platforms that charge per email sent reward sending less often to more people. Neither is better in the abstract, and the right one depends entirely on the shape of your own list and cadence. Work out your annual send volume and your contact count first, then price both models against those two numbers, because a comparison run the other way around tends to reward whichever vendor structured its page more attractively.

What happens if you do it anyway

Teams do try, and the failure has a recognisable shape worth describing so nobody has to learn it live.

The first sends usually work. A new account sending a modest volume to a cold list will get most of it delivered, because nothing bad has happened yet and the platform has no reason to look closely. That early success is the trap: it reads as evidence the policy is not enforced, and it encourages scaling up.

What follows is driven by complaint rate and bounce rate rather than by anyone reading your list. Cold lists bounce harder, because addresses were guessed or bought rather than typed in by their owners, and they generate complaints at rates a subscriber list never approaches. Both are visible to the platform automatically, and both are exactly what its abuse systems are tuned to find. The account gets flagged on metrics rather than on inspection.

Suspension is the stated consequence and the policy allows it to be immediate, covering either the whole account or particular services. That is worse than it sounds for one reason people rarely think about beforehand: transactional mail usually lives on the same account. Password resets, receipts, booking confirmations and delivery notices stop with the marketing sends, and the outage hits existing paying customers rather than prospects. A cold-list experiment taking down transactional mail is a genuinely bad afternoon.

The last piece is the part that outlives the account. The sending domain accumulates a reputation of its own, held by mailbox providers rather than by the platform, and it survives moving to a different vendor. Recovering a domain that spent a month sending to a purchased list takes far longer than acquiring the list did, and for a company's primary domain there is no clean substitute for it. Domain reputation covers why that recovery is slow.

The architecture this actually implies

Put the policy and the product together and the design falls out cleanly.

Marketing email belongs on a platform like Brevo, sending from your primary domain or a subdomain of it, to a list that opted in and can be proven to have opted in. Outbound belongs on separate sending domains, on infrastructure built for rotation, with no connection to the domain your customers and subscribers already recognise. The separation protects the asset that is hardest to replace: a primary domain with years of good sending history behind it.

1. Step 1Keep the primary domain for people who know you

   Marketing, transactional and replies, on a list with a retrievable opt-in record

2. Step 2Buy separate domains for outbound

   Distinct registrations, never subdomains of the primary, so reputation cannot bleed across

3. Step 3Authenticate both independently

   SPF, DKIM and DMARC per sending domain, aligned and verified before any volume

4. Step 4Warm the outbound domains before use

   A new domain sending cold volume immediately is the fastest route to a blocklist

5. Step 5Keep the platforms separate too

   A platform that prohibits cold lists is a platform whose terms you would be breaking

The practical steps behind those middle two are covered in cold email infrastructure, and the warm-up half in email warmup services. For the wider question of which platform suits which motion, cold email software is the category comparison, and enterprise email marketing covers the same separation from the large-organisation side.

The house position

We run Email Bison for sending and HeyReach for LinkedIn, on separate sending domains that are never the client's primary. Every campaign carries exactly one message: no bumps, no thread replies, and a second contact is a fresh campaign with a genuinely different angle rather than another step under the first. That practice keeps complaint rates low for reasons that hold whichever platform is underneath, and it is one of the reasons the outbound domains stay usable.

Nothing above is a measurement of our own campaigns. It is the vendor's published policy, the vendor's published product structure, and the architectural conclusion those two support.

If the question underneath all of this is what compliant outbound actually looks like when it is set up properly, see what a first campaign looks like.

Policy and features verified as of August 2026. Verify current terms with the vendor before relying on them.