Do I need to add include:spf.brevo.com to my SPF record?

Not for standard (shared-IP) sending. Brevo's flow does not ask you to add an SPF record, and adding the include would not align to your domain because Brevo owns the envelope sender. Only add include:spf.brevo.com if you are on a dedicated IP with a custom Return-Path, and then merge it into your single SPF record.

Why doesn't Brevo give me an SPF record to add?

Because SPF is checked against the envelope sender (Return-Path), which on Brevo's shared infrastructure is always a Brevo-owned domain (sender-sib.com). So SPF passes against Brevo, not your domain, and cannot align. Brevo relies on DKIM — the two _domainkey CNAMEs — to align your domain for DMARC.

Are the DKIM records CNAME or TXT?

Newly authenticated domains get two CNAMEs (usually brevo1._domainkey and brevo2._domainkey, though some accounts label them mail._domainkey and mail2._domainkey; 2048-bit, auto-rotated by Brevo). Older accounts may instead show a single TXT record at mail._domainkey (1024-bit). Copy whichever names Brevo displays and follow the matching tab; the CNAME method is preferred.

My emails still say "via" or come from a sendinblue/brevo address — why?

Either you only verified a single sender instead of authenticating the domain, or the DKIM records have not verified yet. Authenticate the whole domain under Senders, Domains & Dedicated IPs, then confirm both DKIM CNAMEs resolve and Brevo shows green checkmarks.

Authentication won't verify on Cloudflare — what's wrong?

Almost always CNAME flattening or the proxy. Disable "CNAME flattening" in Cloudflare and set the two DKIM CNAMEs to "DNS only" (grey cloud) so they resolve to the real Brevo target, then allow propagation time before clicking Authenticate again.

I'm migrating from Sendinblue — do my old records still work?

spf.sendinblue.com may still resolve for now but is the deprecated name and is being retired. Re-authenticate the domain under Brevo to pick up the current DKIM CNAMEs, and if you need an include anywhere use spf.brevo.com rather than the old host.

Will Brevo's records conflict with Google Workspace or Microsoft 365?

No. Brevo uses its own dedicated DKIM selectors and does not require a root SPF change, so it will not overwrite your existing DKIM or SPF. Just keep a single SPF TXT record and a single _dmarc record on the domain.

SPF setup guide

SPF, DKIM & DMARC for Brevo.

Brevo (formerly Sendinblue) authenticates your domain from its Domains page, and its flow is DKIM-first, not SPF-first. Instead of pasting a shared SPF line, you publish a Brevo code TXT record to prove you own the domain and two DKIM CNAME records that delegate rotating signing keys back to Brevo — and it is those DKIM records, not SPF, that make DMARC pass. Brevo does publish a shared include (include:spf.brevo.com), but on standard shared-IP sending it is optional because Brevo controls the envelope sender. Once the Brevo code and DKIM records verify, the "via" tag disappears and your mail aligns to your own domain.

SPF include

Your DNSAdd the CNAME / TXT records

BrevoSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Brevo?

Authenticating your domain in Brevo is not housekeeping — it decides whether your mail reaches the inbox at all, and Brevo has folded it into the product as a requirement. Since February 1, 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft announced on May 5, 2025 that it would enforce the same standards. Brevo's authentication flow reflects this: a fully authenticated domain publishes a DMARC record alongside DKIM, and unauthenticated mail is throttled or rejected by these mailbox providers. Until you authenticate, Brevo sends on shared infrastructure with its own envelope domain — recipients see a "via" or "sent on behalf of" note, your From address does not align, DMARC cannot pass, and the sending reputation you build is pooled with every other unauthenticated Brevo sender. Completing the Brevo code plus DKIM CNAMEs plus DMARC fixes all of it: DKIM aligns to your domain, the "via" tag disappears, DMARC passes, and reputation accrues to you.

The SPF reality for Brevo

Brevo is technically an "include" provider — spf.brevo.com is a real, live shared SPF record (a flat list of ip4 blocks that counts as a single DNS lookup) — but the honest reality is that Brevo does NOT require it, and its standard domain-authentication flow centers on the Brevo code, DKIM, and DMARC rather than SPF. The reason: on shared IPs the envelope sender (the Return-Path / MAIL FROM the receiving server actually checks SPF against) is always a Brevo-owned domain, historically under sender-sib.com (and, on legacy Sendinblue infrastructure, mailin.fr). So even if you add include:spf.brevo.com to your root SPF, SPF authenticates against Brevo's infrastructure but does NOT align to your visible From domain — which means it cannot satisfy DMARC on its own. DMARC alignment comes entirely from DKIM: the DKIM CNAMEs sign with d=yourdomain.com (via CNAME delegation), giving relaxed DKIM alignment that passes DMARC. The one case where SPF matters is a dedicated IP, where you can set a custom bounce/Return-Path subdomain on your own domain and then include:spf.brevo.com both authorizes and aligns it. Two naming traps: use spf.brevo.com, not the deprecated spf.sendinblue.com (the old Sendinblue host may still resolve for now but is being retired), and never add a bare include:sendinblue.com — that is not Brevo's customer sending include, so adding it just pulls unrelated senders into your record and wastes a lookup.

Two ways to set it up

Recommended

DKIM via CNAME (recommended)

Two CNAMEs (brevo1._domainkey / brevo2._domainkey, or mail._domainkey / mail2._domainkey on some accounts) delegate signing to Brevo, which holds the private keys
2048-bit keys that Brevo rotates for you — you never re-edit DNS when a key changes
The default for newly authenticated domains and the strongest DKIM setup
Adds nothing to your SPF lookup budget and is what actually aligns for DMARC

Legacy

DKIM via TXT (legacy)

A single TXT record at mail._domainkey holding a static public key (k=rsa; p=...)
1024-bit key, and you must republish it by hand if it ever changes
Only appears on older accounts or where CNAMEs are not possible
In Brevo, select the tab that matches your screen — migrate to the CNAME method when you can

Step by step

In Brevo

1
Open the Domains page
Log in, click your account name (top-right), and go to Senders, Domains & Dedicated IPs, then open the Domains tab.
2
Add or select your domain
Click "Add a domain" and enter yourdomain.com (the organizational domain your From address uses), or click "Authenticate" next to a domain already listed.
3
Choose automatic or manual setup
Brevo offers "Authenticate automatically" — it logs into your DNS provider and adds the records for you — or a manual path that displays the records to copy. Pick manual if your DNS host is not supported.
4
Copy the records Brevo shows
Brevo lists a Brevo code (TXT, ownership), the DKIM records (two CNAMEs — usually brevo1._domainkey and brevo2._domainkey, though some accounts show mail._domainkey and mail2._domainkey, or a single legacy TXT at mail._domainkey), and a DMARC record (TXT). Note the exact host and target for each — they are unique to your account.

In your DNS

5
Add the Brevo code TXT
Create a TXT record on the root (host @ or blank) with the value brevo-code:<your value>. This proves ownership; it does not authenticate mail by itself, but authentication will not complete without it.
6
Add the two DKIM CNAMEs
Create the two DKIM records as CNAMEs. Brevo usually labels them brevo1._domainkey and brevo2._domainkey (some accounts show mail._domainkey and mail2._domainkey), pointing to the b1.<account>.dkim.brevo.com and b2.<account>.dkim.brevo.com targets on your screen — always copy the exact names and targets Brevo displays. Enter only the label (e.g. brevo1._domainkey) if your panel auto-appends the domain, and do not change the type to TXT.
7
Disable Cloudflare flattening / proxy
If your DNS is on Cloudflare, turn off CNAME flattening and set each DKIM CNAME to "DNS only" (grey cloud). A flattened or orange-cloud proxied CNAME returns Cloudflare's IPs instead of the Brevo target and verification fails.
8
Publish (or update) your DMARC record
Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Brevo's flow publishes a DMARC record as part of full authentication (and Gmail/Yahoo require one anyway), so don't skip it. Keep just one _dmarc record for the whole domain.
9
Skip the SPF include unless you have a dedicated IP
You do not need to touch your root SPF for standard shared-IP sending — Brevo's flow does not ask for an SPF record and include:spf.brevo.com will not align. Only if you are on a dedicated IP with a custom Return-Path do you merge include:spf.brevo.com into your single v=spf1 record.

Verify

10
Click "Authenticate this email domain"
Back in Brevo, click "Authenticate this email domain" at the bottom of the domain page. Each record shows a green checkmark / "Value matched" once it resolves. Propagation is usually minutes but can take up to 24-48 hours.
11
Confirm on a real message
Send a test from an address on the authenticated domain, open it in Gmail, and use Show original: you want DKIM: PASS with your domain and DMARC: PASS. SPF may show a Brevo envelope domain — that is expected on a shared IP.

Records to add

Brevo generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
TXT	@	brevo-code:a1b2c3d4e5f6a1b2c3d4e5f6Brevo code — domain-ownership verification; exact value is shown in your dashboard (host is the root / @)
CNAME	brevo1._domainkey	b1.yourdomain-a1b2.dkim.brevo.comDKIM key 1 (2048-bit, auto-rotated) — target is unique to your account; some accounts label this CNAME mail._domainkey, so copy the exact name/target Brevo shows
CNAME	brevo2._domainkey	b2.yourdomain-a1b2.dkim.brevo.comDKIM key 2 (2048-bit, auto-rotated) — some accounts label it mail2._domainkey; this pair is what delivers DMARC alignment
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one per domain; DKIM carries alignment. Part of Brevo's full-authentication flow
TXT	@	v=spf1 include:spf.brevo.com ~allOptional / dedicated-IP only — not part of the standard flow and will not SPF-align on shared IPs. If you add it, merge into your single SPF record

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Brevo's setup costs against that budget.

SPF 10-lookup budget1 used · 9 free

Brevo adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

DKIM is the heart of Brevo authentication because it is what aligns for DMARC. On newly authenticated domains, Brevo issues two CNAME records — typically brevo1._domainkey.yourdomain.com and brevo2._domainkey.yourdomain.com (some accounts label them mail._domainkey and mail2._domainkey) — pointing to b1.<account>.dkim.brevo.com and b2.<account>.dkim.brevo.com, where the <account> portion is unique to you. Always copy the exact record names and targets Brevo shows on your screen. Because these are CNAMEs delegated to Brevo, Brevo holds the private keys and can rotate the published 2048-bit keys behind those two selectors without you ever editing DNS again; you do not paste a public key. Older accounts may instead see a single TXT record at mail._domainkey holding a static 1024-bit key (k=rsa; p=MIIBIjAN...). That still works, but the CNAME method is preferred (2048-bit and auto-rotating) — in Brevo, select the tab that matches whichever record type your screen shows. Either way, the resulting DKIM signature carries d=yourdomain.com, so it aligns with your From domain under relaxed alignment and satisfies DMARC on its own.

DMARC

DMARC is a separate policy record on your root domain, and Brevo's current flow publishes one as part of full domain authentication — so you should treat it as required, not optional. Publish a TXT record at _dmarc.yourdomain.com beginning with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it will not affect delivery while you confirm Brevo mail passes DKIM aligned to your domain. Watch the aggregate (rua) reports for a week or two — because Brevo aligns via DKIM (not SPF), you are looking for your own domain in the DKIM result — then tighten to p=quarantine and eventually p=reject once alignment is consistent. Keep exactly one _dmarc record for the whole domain no matter how many senders you use; do not add a second one for Brevo. For reference, Brevo's own domain publishes p=reject.

Check it actually worked

Do not trust the dashboard badge alone — confirm it on a real message. In Brevo, clicking "Authenticate this email domain" shows a green checkmark / "Value matched" per record once each resolves. Then send yourself a test from an address on the authenticated domain, open it in Gmail, and choose the three-dot menu then Show original: you want DKIM: PASS showing your domain and DMARC: PASS. Note that SPF will often show a Brevo envelope domain (something under sender-sib.com / mailin.fr) rather than your domain — that is expected on a shared IP and does not matter because DKIM carries the alignment. Run your domain through Qualisend's domain health check to confirm the Brevo code, both DKIM CNAMEs, and your DMARC record all resolve, and once aggregate reports start arriving, drop one into the DMARC report analyzer — Brevo should appear as an aligned, DKIM-passing source.

Domain health check DMARC report analyzer

Common gotchas

Coverage
SPF is a red herring on Brevo: adding include:spf.brevo.com does not make DMARC pass on shared IPs because the envelope is a Brevo domain (sender-sib.com). DKIM does the aligning — do not waste time debugging SPF alignment.
DNS setup
Cloudflare CNAME flattening breaks DKIM: disable "CNAME flattening" and set the DKIM CNAMEs to "DNS only" (grey cloud). A flattened or orange-cloud proxied CNAME resolves to Cloudflare's IPs instead of the Brevo target and verification fails.
DNS setup
Use spf.brevo.com, not the deprecated spf.sendinblue.com, and never add a bare include:sendinblue.com — it is not Brevo's customer sending include, so it just pulls unrelated senders into your record and burns a lookup.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering brevo1._domainkey.yourdomain.com produces brevo1._domainkey.yourdomain.com.yourdomain.com. Enter just the label (brevo1._domainkey / brevo2._domainkey, or whatever selector names Brevo shows) when the panel adds the domain for you.
Coverage
DMARC is part of Brevo's flow now: treat it as required, add at least p=none, and keep only one _dmarc record for the domain.
Coverage
Verifying a single sender (one From address) is not domain authentication — it lets you send but still shows the "via" tag and gives no alignment. You must authenticate the domain.
Breaks auth
Keep exactly one SPF TXT record: if you do add the include for a dedicated IP, merge it into your existing v=spf1 record. Two SPF records is itself a PermError.
DNS setup
The Brevo code TXT is verification-only — do not delete it after setup. Removing it can break the domain's authenticated status even though it does not sign mail itself.

Build your SPF record

Brevo doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list