Brevo

Brevo is a marketing and CRM platform (rebranded from Sendinblue in 2023) used to build and send email campaigns, manage contacts, and run marketing automations. Alongside its outbound sending infrastructure, Brevo operates plugin and integration traffic that connects outward into a customer’s own website or storefront — most commonly through e-commerce and CMS plugins (WordPress, WooCommerce, PrestaShop, and similar) — to sync product data, validate the links a merchant places in a campaign, and generate the visual previews shown inside the Brevo campaign editor.

Unlike a search crawler or a webhook delivery service, Brevo does not publish a distinguishing user-agent string for this traffic. Its documented verification path instead runs through IP address: Brevo publishes a short, fixed set of individual “Plugin IP” addresses specifically described as the addresses used “to allow Brevo to connect to your server,” separate from the broader CIDR ranges it uses for SMTP relay, webhook delivery, and data-connector traffic. That narrower, static list is what a site operator should check against, rather than trying to identify this traffic by a request header. In DataDome’s taxonomy this sits with technical partner integrations — traffic tied to an active vendor relationship (a merchant using Brevo) rather than general-purpose crawling, but still worth verifying since, as with any vendor connecting inbound, the identity is easy to claim and hard to disprove without checking the source IP.

• Link and product validation for campaigns. When a merchant builds a campaign referencing a product page or landing page, Brevo’s plugin integration connects to the site to confirm the link resolves and pull the content needed to populate the campaign.
• Preview and dynamic content generation. E-commerce plugins use this connection to fetch product images, prices, and descriptions so the campaign editor can render an accurate preview before sending.
• Catalog and inventory sync. For merchants using Brevo’s e-commerce integrations, this traffic keeps product catalogs, stock status, and pricing synchronized between the storefront and Brevo’s marketing automation rules.
• Data connector operations. A related but distinct IP range supports scheduled connections to a customer’s FTP server or database (PostgreSQL, MongoDB, BigQuery, Snowflake) for data-import integrations — a different traffic category from plugin/link validation but from adjacent infrastructure.
• Webhook delivery. Separately, Brevo pushes event notifications (opens, clicks, bounces, unsubscribes) to merchant-configured webhook endpoints from its published webhook IP ranges.

Because this traffic isn’t identified by a memorable string, its risk profile centers on IP spoofing and endpoint assumptions rather than user-agent impersonation:

• Spoofed source IPs. A request claiming to originate from Brevo’s plugin infrastructure but arriving from an IP outside the four published addresses should not be trusted — there’s no user-agent claim to check, so IP mismatch is the primary tell here.
• Endpoint probing on plugin callback paths. Where a merchant’s site exposes a specific path for Brevo’s plugin to connect to (a product feed endpoint, a webhook receiver), an attacker aware of that path may probe it directly, hoping it lacks authentication beyond an IP check.
• Assuming IP verification alone is sufficient. Brevo’s plugin IPs are a small, static, well-known list; relying on IP allowlisting without any additional authentication token or API key on the endpoint leaves it exposed to anyone who can spoof or route through one of those addresses.
• Confusing plugin traffic with webhook or SMTP traffic. Brevo uses separate IP ranges for SMTP relay, webhook delivery, plugin connections, and data connectors. Treating all of them as one undifferentiated “Brevo” allowlist authorizes more access than any single integration actually needs.
• Stale plugin connections. A merchant who deactivated a Brevo integration but left the corresponding endpoint or credentials active can continue to receive connection attempts indefinitely, widening the exposure window unnecessarily.

Spoofed traffic claiming to be Brevo’s plugin connection cannot alter what’s actually stored in a merchant’s Brevo account or trigger a real campaign send — those actions happen through Brevo’s authenticated API, not through the inbound connection to a customer’s server. The risk is local: a merchant’s endpoint processing or responding to a request that didn’t actually come from Brevo.

If this traffic is appearing in your logs, it almost always traces back to an active Brevo integration a merchant configured — most commonly a CMS or e-commerce plugin. A few things worth understanding:

• This is bidirectional, not just outbound. Brevo’s own documentation is explicit that it does not support inbound IP allowlisting on its own side — meaning the burden of allowing or restricting this connection sits entirely with the receiving site’s configuration, not with Brevo.
• Traffic volume tracks campaign and catalog activity. Expect connection attempts around campaign creation, scheduled catalog syncs, and whenever a merchant edits a campaign referencing dynamic content from their site.
• Multiple IP categories exist for different purposes. SMTP relay uses one set of ranges, webhook delivery another (the same ranges as SMTP relay, per Brevo’s documentation), plugin connections use four fixed individual IPs, and data connectors use yet another range — conflating them leads to either over- or under-permissive rules.
• A deactivated integration may still be configured. If a merchant no longer uses Brevo’s plugin but never removed the corresponding endpoint or API credentials, this traffic can continue indefinitely without an active business reason.

1. Do not look for a distinguishing user-agent. Brevo does not publish one for this traffic category, so user-agent-based rules provide no real signal here.
2. Check the source IP against Brevo’s published Plugin IPs specifically — 91.121.36.98, 91.121.61.102, 87.98.220.61, and 87.98.147.208 — rather than the broader SMTP/webhook CIDR ranges, since these are the addresses Brevo documents as used to connect into a customer’s server.
3. Separate traffic by function before applying a rule. Confirm whether the request pattern matches plugin/link-validation behavior (connecting to fetch content) versus webhook delivery (posting event data) versus data-connector activity (scheduled database or FTP access), since each uses a different published IP set.
4. Treat IP matching as necessary but not sufficient. Because this list is small, static, and public, pair it with an application-level check — an API key, shared secret, or signed request — on any endpoint Brevo’s plugin is expected to reach.
5. Confirm against your own integration configuration. If no Brevo plugin or integration is actively configured for the site in question, this traffic has no legitimate explanation and should be treated as unexpected regardless of IP match.
6. Watch for requests to endpoints that were never set up for this purpose. Genuine plugin traffic targets specific, pre-configured paths (product feeds, preview endpoints); a request pattern spreading across unrelated paths is inconsistent with documented Brevo plugin behavior.

Whether to allow this traffic depends entirely on whether the site in question is (or was) integrated with Brevo. Unlike a search crawler, blocking genuine plugin traffic for an active integration breaks the merchant’s own marketing tooling — campaign previews stop rendering correctly, and catalog sync fails silently. Reasonable grounds to restrict or investigate include:

• the site never configured a Brevo integration, and this traffic has no explainable origin;
• the source IP doesn’t match Brevo’s published Plugin IP addresses, meaning it isn’t genuinely from Brevo regardless of any other claim in the request;
• an integration was deactivated but the receiving endpoint was never decommissioned, leaving an open door with no current business need;
• the traffic is hitting paths that were never configured as part of the plugin setup; or
• the endpoint lacks any authentication beyond IP matching and needs to be hardened regardless of whether the traffic is genuine.

Because Brevo explicitly does not manage inbound access control on its own side, the responsibility for scoping and securing this connection sits with the site operator, not with Brevo.

• Allowlist only the specific IP category you need. For plugin/link-validation traffic, permit just the four published Plugin IPs on the specific endpoint the integration uses — not a broad range covering SMTP, webhook, and data-connector traffic that endpoint doesn’t need:

location /brevo-plugin-endpoint {
    allow 91.121.36.98;
    allow 91.121.61.102;
    allow 87.98.220.61;
    allow 87.98.147.208;
    deny all;
}

• Add application-level authentication on top of IP matching. A static, publicly documented IP list is a weak standalone control; require an API key or signed token on any endpoint Brevo’s plugin reaches.
• Use a dedicated path for plugin connections, separate from general application routes, so the exposure is limited to exactly what the integration needs.
• Decommission the endpoint when the integration ends. If a merchant stops using a Brevo plugin, remove or disable the corresponding server-side endpoint rather than leaving it reachable indefinitely.
• Keep the IP list current. Cross-check Brevo’s help center periodically, since these addresses are subject to change without the same structured update mechanism (a versioned JSON feed) that larger infrastructure providers publish.
• Monitor for mismatched claims. Log and alert on any request to a Brevo-integration endpoint that doesn’t originate from the published Plugin IPs, since a mismatch here is a stronger signal than volume alone.

Brevo’s plugin and link-validation traffic should be authorized narrowly and only where an active integration exists — not treated as general marketing-technology traffic to trust broadly. Because Brevo doesn’t expose a distinguishing user-agent and explicitly leaves inbound access control to the receiving site, the safest posture is to scope any allowlist to the specific, published Plugin IP addresses on the specific endpoint that needs them, layer application-level authentication on top, and treat any request claiming this identity from outside that narrow IP set as unverified regardless of what else it presents.