How to Configure SPF for a Custom Domain with Brevo

If you are sending marketing or transactional email from a custom domain through Brevo, your SPF record needs one include statement: `include:spf.brevo.com`. That is the public directive Brevo publishes so receivers can verify that mail claiming to come from your domain was actually sent by Brevo's infrastructure.

The rest of this article is about putting that line in the right place, combining it with your other sending services, and verifying it actually works.

Which include statement does Brevo publish today

Brevo publishes its SPF information under a single subdomain: `spf.brevo.com`. To authorize Brevo to send mail on behalf of your domain, your SPF record needs the directive:

include:spf.brevo.com

If you find documentation that says `include:sendinblue.com`, that is the older Sendinblue name from before the rebrand. The current, supported include is `spf.brevo.com`. If you have the older one in your record from a previous setup, replace it. Receivers follow the chain, so a stale include does not fail SPF by itself, but it adds to your lookup count without giving you anything.

You do not need to add Brevo's individual IP addresses or IP ranges to your SPF. The include statement pulls in everything Brevo uses to send, including the ranges they add or remove as they grow. Maintaining your own list of Brevo IPs is a maintenance trap. The day Brevo rotates an IP range, your SPF silently starts failing. The single include is both simpler and more durable than the manual list.

Where the SPF record goes: sending subdomain, not apex

This is the part most people get wrong, and it is the part that bites you six months later when you switch ESPs.

If your marketing mail goes out as `news@mg.yourcompany.com` and you have configured a sending subdomain in Brevo, the SPF record goes on the sending subdomain, not on the root `yourcompany.com`.

The full TXT record at `mg.yourcompany.com` looks like this:

v=spf1 include:spf.brevo.com ~all

The `v=spf1` opens the record. The `include:spf.brevo.com` authorizes Brevo. The `~all` is a soft fail qualifier for anything that did not match. This is the minimum working record.

Why not the apex domain? Two reasons.

First, a future platform switch should not affect your transactional mail. If your transactional mail also comes from `yourcompany.com` (for example, from a helpdesk tool or your CRM), and you put Brevo's include on the apex, switching marketing ESPs means editing the apex record. If you ever fat-finger the syntax during that edit, your transactional mail can start failing SPF. The same risk applies to any other future edit.

Second, a mistake on the apex is visible to anyone who runs a security scan against your root domain. A mistake on a sending subdomain is contained. If you publish `+all` on `mg.yourcompany.com`, only mail claiming to come from `@mg.yourcompany.com` is affected. If you publish `+all` on `yourcompany.com`, every mail flow from your domain is affected.

Combining Brevo with other sending services

Most companies do not send all of their email from one service. A typical setup looks like:

Marketing: Brevo
Transactional: Postmark, SendGrid, or Amazon SES
Helpdesk: Zendesk, Help Scout, or Front
Internal notifications: an HR system, a monitoring tool, or a status page

Each of these services has its own include statement. Your SPF record on the sending subdomain becomes a list of those includes. A real-world example for a company that sends marketing through Brevo and transactional through Postmark from the same custom domain looks like this:

v=spf1 include:spf.brevo.com include:spf.messagingengine.com ~all

The order of the includes does not matter. What matters is the total number of DNS lookups the record forces, because SPF has a hard limit of 10 DNS lookups per check. If your record, plus everything those includes pull in, exceeds 10, the check fails by definition. Your record is treated as if it does not exist, and receivers apply their default policy (often reject).

What this looks like in practice when something goes wrong: a campaign that lands in spam, an inbox-provider bounce report that says "SPF fail" with no obvious typo, and a DNS panel that shows the record is there. The cause is almost always a chain that has crept past 10 lookups because someone added a vendor include six months ago and never checked again.

How to stay under the 10-lookup cap

Each `include:` statement in your record costs at least 1 DNS lookup, and the include target often chains to several more. A short list to keep in mind:

Audit each include. Some ESPs chain to several other subdomains. Each is a lookup.
Use `ip4:` and `ip6:` directives for services that publish a small, stable list of IPs. These do not count as lookups.
Drop includes for services you no longer use. Old vendor records are common lookup-budget leaks.
If you are consistently above 10, split your sending across more subdomains, each with its own focused SPF record.

The Brevo include on its own adds 1 lookup for the include itself, plus however many chained lookups Brevo's `spf.brevo.com` record contains. The exact count varies; a typical reading is single-digit. Either way, you have room for a few more services, but you do not have unlimited room, and you do not want to discover you have run out by checking a tool after a campaign has already started failing.

What about the existing root-domain SPF record

If you already have an SPF record at `yourcompany.com` (the apex), leave it alone unless you are sending marketing mail from that exact domain.

The apex SPF record is for the From address users see in their inbox when mail comes from `@yourcompany.com`. If your marketing From address is `news@mg.yourcompany.com` (the subdomain), the receiving mail server is checking the SPF record at `mg.yourcompany.com`, not at `yourcompany.com`. The apex record is irrelevant for that check.

The common mistake is putting the Brevo include on the apex because that is where the user adds "a SPF record" without realizing there is a per-host DNS lookup. The two records do not interact. A correct setup has both:

`yourcompany.com` TXT: `v=spf1 include:spf.messagingengine.com ~all` (or whatever your transactional mail uses, or nothing if you do not send from the apex)
`mg.yourcompany.com` TXT: `v=spf1 include:spf.brevo.com ~all` (Brevo)

Two records, one per sending host, each authorizing only the services that actually send from that host. That is the right shape.

How to verify the record actually works

Adding a record to your DNS panel and waiting is not a verification step. DNS propagation is fast, but typos in long include strings, missing trailing dots, and forgotten spaces are not. You need a tool that runs the actual DNS chain and counts the lookups.

DMARCFlow has a free SPF checker built for exactly this. Point it at `mg.yourcompany.com` and it does four specific things:

1. Pulls the TXT record at that host.

2. Walks the include chain and counts every DNS lookup it triggers.

3. Reports the total against the 10-lookup cap.

4. Flags any include that does not resolve, so you can see a stale `include:sendinblue.com` before you send a campaign.

If you would rather use a different tool, the criteria are the same. What you want is one that follows the chain to the end, not one that just checks the first record.

A working result from any of these tools looks like this:

Syntax: valid `v=spf1` record
Lookups: under 10 (with margin)
All includes: resolve to valid SPF records
Qualifier: `~all` or `-all` (not `+all`, which would authorize anyone)

Run the check after you publish the record and again after every change. If the check reports `+all`, change it. The `+all` qualifier passes SPF for any sender, which makes the record meaningless and gives spammers a free pass to send mail as your domain.

Frequently asked questions

Do I need to add Brevo's individual IP addresses to my SPF?

No. The `include:spf.brevo.com` directive pulls in every IP Brevo uses, including the ones they add next month. If you maintain a static list of Brevo IPs, it will drift and your SPF will start failing when Brevo rotates infrastructure. The single include is both simpler and more durable.

Can I put the Brevo include on my apex domain instead of a sending subdomain?

You can, but you should not. The apex SPF record is meant to authorize senders for `@yourdomain.com`. If your marketing From address is on a subdomain, the receiving mail server checks the SPF record at that subdomain, not at the apex. Putting Brevo on the apex does not help your marketing mail and creates a maintenance trap for your other sending, because a future platform switch forces you to edit the apex record again.

Why does my SPF still fail after I added the Brevo include?

Three common causes. First, the record is on the wrong host. It has to be on the exact subdomain your From address uses, not on the apex. Second, the include is on the wrong zone. Some DNS providers have a "main domain" panel and a "subdomain" panel, and the record lands in the wrong one. Third, you are above the 10-lookup cap because of older includes you have not pruned. A free SPF checker will show which of these is the actual cause. If you want a tool that walks the chain and reports the lookup count, DMARCFlow's free SPF checker is built for that.