Brevo integration

What a Brevo build usually covers

• Two way contact sync, keyed so one person stays one record, not three.
• Event tracking from your site or app, so automations fire on what someone did.
• Transactional email and SMS through the API, on your own templates.
• SPF, DKIM and DMARC on your sending domain, marketing and transactional apart.
• Webhooks for delivered, bounced and unsubscribed, written back to your CRM.
• Unsubscribes honoured everywhere, and alerting when the sync stops.

The integration is the easy half. Deliverability decides whether it mattered

You can wire Brevo to every system you own and still have nobody read the mail. Deliverability is a reputation problem, not an API problem.

Authentication, without the jargon

SPF is a record in your DNS naming the servers allowed to send for your domain. DKIM signs each message, which proves it came from you and was not altered on the way. DMARC ties the two together: it tells receiving servers what to do when a message fails both checks, and asks them to report what is being sent in your name.

Start DMARC on monitoring, read the reports, then tighten to quarantine and reject. Skip that and you block your own invoices, because there is always a forgotten sender.

Mail sent from a gmail.com or outlook.com address fails these checks by design, because the policy for that domain belongs to its owner and you are not it. Bulk senders are expected to authenticate on a domain they control, so a free address is a delivery problem rather than a cosmetic one.

The old list is the expensive mistake

Reputation builds per sending domain over weeks. Import a list from 2019, send to all of it at once, and you hit dead mailboxes and spam traps in the same hour. Hard bounces tell a provider you don't know who your contacts are. Complaints say worse. The cost is not one bad campaign, it is filtering that follows the domain for months. Warm up instead: start with contacts who opened recently and add older segments gradually.

Never share a subdomain between marketing and transactional

Password resets and receipts are the mail people actually want. Campaigns generate the complaints. Reputation is tracked at subdomain level, so keep the two apart and a rough campaign week can't stop a customer resetting their password.

The sync side, once the mail is landing

Decide the key first. Email is the obvious identifier and the wrong one, because people change addresses and households share them. Store your own contact ID on the record and match on that.

Events are what automation should run on, not lists. "Abandoned a cart on Tuesday" is a trigger. "Sits in the newsletter list" is not.

Two way sync needs a rule about which system wins per field, or the two sides overwrite each other at three in the morning. We set direction per field and make writes idempotent, so a retry after a timeout doesn't create a second contact. If the wider CRM needs work, our CRM solutions team scopes it alongside.

How the build runs

1. We map the data

   Which system owns which field, and where the duplicates come from.

2. Scope and price

   Fixed scope, fixed number, dates in writing.

3. Build and authenticate

   DNS, templates, sync and webhooks on staging, tested with real payloads.

4. Send in stages

   Warm up, watch the bounce rate, then hand over with monitoring on.

Who this suits, and who it doesn't

It suits businesses on Brevo copying data in and out by hand, and anyone whose automations fire on the wrong trigger or not at all.

It doesn't suit one newsletter a month to 300 people.

Why build it with us