Email authentication for Brevo: SPF, DKIM and DMARC

19 May 2026 · 12 min read

Brevo (formerly Sendinblue) is a shared-infrastructure email platform, and that single fact shapes everything about how you authenticate it. Unlike a self-hosted mail server where you control the sending IP and the bounce address, Brevo sends your campaigns and transactional mail from a large pool of IP addresses it shares with thousands of other senders, and it stamps its own bounce domain onto the envelope. If you set up SPF the way you would for your own server and then turn on DMARC enforcement, you can silently break delivery, because the part of SPF that DMARC actually cares about will not line up with your domain.

This guide is specific to Brevo. It covers the exact include you publish, how Brevo's two-selector DKIM works, why the return-path matters so much here, and the concrete path to p=reject without losing mail. If you only ever read one provider authentication guide, read the one for the provider you actually use, because the alignment behaviour differs between them and a generic checklist will mislead you.

Why Brevo is different from your own mail server

Three pieces of identity travel with every message:

• The From header, the address your recipients see (for example hello@yourdomain.com).
• The DKIM signature, a cryptographic signature whose d= tag names the signing domain.
• The return-path (also called the envelope-from or MAIL FROM), the address bounces are sent back to. This is the domain SPF checks.

DMARC does not care whether SPF or DKIM merely pass. It cares whether they pass and align: the domain they authenticate must match the domain in the From header. This is the single most important concept for Brevo, so it is worth saying plainly.

On Brevo's shared sending infrastructure, the return-path is Brevo's own bounce domain, not yours. Historically this has looked like kh.d.sender-sib.com or a similar .sender-sib.com / .mailin.fr host. When a receiving server runs SPF, it checks that bounce domain, sees Brevo's spf.brevo.com IPs, and SPF passes for Brevo. But because the bounce domain is sender-sib.com and your From header is yourdomain.com, SPF does not align with your domain. SPF passes; SPF alignment fails.

That leaves DKIM to carry DMARC. Brevo signs your mail with a key whose d= matches your domain, so DKIM passes and aligns, and DMARC passes on the DKIM side. This is by design. The practical consequence: on Brevo's shared pool, DKIM is the load-bearing mechanism for DMARC, and SPF alignment is not available. Get DKIM right and you can reach p=reject safely. Misunderstand it and you will chase an SPF alignment that can never happen on shared IPs.

You can confirm what is aligning for any of your live mail with the DMARC report analyzer, which breaks aggregate reports down by source so you can see Brevo's traffic and whether it is passing on DKIM, SPF, or both.

Step 1: add your domain in Brevo

Before any DNS work, add and verify the domain inside Brevo so the platform generates the correct, account-specific records for you.

1. Log in to Brevo and go to Senders, Domains and Dedicated IPs, then the Domains tab.
2. Click Add a domain and enter your sending domain, for example yourdomain.com.
3. Brevo presents the DNS records you need to publish: a Brevo code (verification) TXT record and the DKIM records.

Always copy the exact values from your own Brevo dashboard. Selector names and CNAME targets are account- and key-specific, and the examples in this article are representative, not your literal values.

Step 2: publish the Brevo code (domain verification)

The Brevo code is a verification-only TXT record. It proves you control the domain and unlocks authenticated sending. It plays no part in SPF, DKIM or DMARC, but Brevo will not fully authenticate the domain until it resolves.

It looks like a TXT record placed at the domain root:

Type:  TXT
Host:  @            (i.e. yourdomain.com)
Value: brevo-code:abcdef0123456789abcdef0123456789

Some DNS hosts want the host field left as @ or blank for the root; others want the full yourdomain.com. Publish it, then move on; you do not need to wait for it before adding the rest.

Step 3: enable and publish DKIM (the part that matters most)

DKIM is what makes DMARC pass on Brevo's shared infrastructure, so this is the step to get exactly right.

Brevo offers DKIM in two forms, and you should prefer the CNAME form:

• CNAME DKIM (recommended). Brevo publishes and rotates the actual key on its side; you publish CNAME records that delegate the lookup to Brevo. The CNAME default is a 2048-bit key. Because Brevo owns the target, it can rotate keys without you touching DNS again.
• TXT DKIM (alternative). Brevo gives you a TXT record containing the public key directly. The TXT default is a 1024-bit key, and you have to update DNS yourself if the key ever changes.

Brevo uses two DKIM records, not one, so it can rotate between them. Depending on your account and when it was created, the selectors are commonly named mail._domainkey and mail2._domainkey, or the newer per-account form brevo1._domainkey and brevo2._domainkey. Both selectors must be published for authentication to be complete and for key rotation to keep working.

A representative CNAME setup looks like this:

Type:  CNAME
Host:  mail._domainkey.yourdomain.com
Value: b1.yourdomain-xxxx.dkim.brevo.com

Type:  CNAME
Host:  mail2._domainkey.yourdomain.com
Value: b2.yourdomain-xxxx.dkim.brevo.com

If your account uses the newer selectors, the hosts will read brevo1._domainkey.yourdomain.com and brevo2._domainkey.yourdomain.com instead, pointing at the matching *.dkim.brevo.com targets shown in your dashboard. Copy the exact targets from Brevo; do not type them from a blog post.

Three practical points that catch people out:

• Host field format. Some DNS providers want the bare label, mail._domainkey, and append the domain for you. Others want the fully qualified mail._domainkey.yourdomain.com. Entering the full host on a provider that also appends the domain produces a broken record like mail._domainkey.yourdomain.com.yourdomain.com. If verification fails, this doubling is the first thing to check.
• Cloudflare CNAME flattening. If your DNS is on Cloudflare, make sure the DKIM CNAME records are DNS-only (grey cloud), not proxied (orange cloud), and be aware that Cloudflare can flatten a root-level CNAME into other record types. For DKIM selectors specifically, leave them as plain unproxied CNAMEs so the delegation to *.dkim.brevo.com resolves intact. A flattened or proxied DKIM record will fail validation.
• Do not also publish a conflicting TXT. If you choose CNAME DKIM, do not additionally paste a TXT public key at the same selector. One record per selector.

Once the records resolve, return to Brevo and click Authenticate this email domain (or the Verify button). Correct records show a green tick. You can independently confirm the signature is live and well-formed with the DKIM checker, entering your domain and the selector (for example mail).

Step 4: SPF, and why it is optional on shared IPs

This is where a generic guide will steer you wrong. The canonical Brevo SPF include is:

Type:  TXT
Host:  @
Value: v=spf1 include:spf.brevo.com ~all

(Older accounts may still reference include:spf.sendinblue.com; the current host is spf.brevo.com.)

Here is the honest truth for shared-pool sending: this SPF record does not make DMARC pass for Brevo, and Brevo does not require it for domain authentication. Because the return-path is Brevo's bounce domain rather than yours, SPF is evaluated against sender-sib.com, not yourdomain.com, so even a perfect include:spf.brevo.com cannot align with your From header. DMARC on Brevo passes through DKIM alignment only.

So why publish the SPF include at all?

• It is good hygiene and harmless, and it can help with non-DMARC heuristics and some receivers' reputation signals.
• If you later move to a dedicated IP (covered below), Brevo can set a custom return-path on your own domain, and then SPF alignment becomes possible and the include becomes load-bearing.
• It keeps your overall SPF posture coherent if you send from multiple providers.

The thing not to do is assume that adding include:spf.brevo.com is what gets you to enforcement. On shared IPs it is DKIM that does that work. Equally, do not bloat your single root SPF record by stacking every provider you have ever trialled; SPF allows a maximum of 10 DNS lookups and include:spf.brevo.com consumes one or more of them. If your record is creeping toward the limit, validate it with the SPF checker and read how to fix SPF PermError from too many lookups. For background on what each mechanism means, the glossary defines SPF, DKIM, DMARC and alignment.

A single domain must have exactly one SPF TXT record. If you already send through, say, Google Workspace and Brevo, merge them:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com include:spf.brevo.com ~all

Never publish two separate v=spf1 records; receivers treat that as a permerror and SPF stops working entirely.

Step 5: custom return-path and From alignment

By default on shared IPs you cannot change the envelope-from, and that is fine because DKIM carries DMARC. But two scenarios let you align SPF as well:

Dedicated IP. Brevo offers dedicated IPs for higher-volume senders (Brevo's published guidance points to roughly 50,000 or more emails per week with consistent volume, plus a warm-up period of several weeks). With a dedicated IP, Brevo can configure a custom return-path on your own domain, for example bounce.yourdomain.com, by having you publish a subdomain that points into Brevo's infrastructure. Once the envelope-from is bounce.yourdomain.com, SPF is evaluated against your domain and SPF alignment becomes available in relaxed mode (the organisational domain matches). You then add the dedicated IP to your SPF record, for example:

Type:  TXT
Host:  @
Value: v=spf1 ip4:203.0.113.45 include:spf.brevo.com ~all

With a dedicated IP and custom return-path, you can have both SPF and DKIM aligned, which is the most robust position. But understand it is optional polish on top of DKIM, not a prerequisite for DMARC.

From-address consistency. Whichever setup you use, send from a consistent, authenticated From domain or subdomain. A common, clean pattern is to dedicate a subdomain to Brevo (for example news.yourdomain.com or mail.yourdomain.com) so your marketing reputation is isolated from your corporate mail. If you do that, authenticate that subdomain in Brevo and publish the DKIM and (optionally) SPF records under it. DMARC uses the organisational domain for relaxed alignment, so DKIM signing news.yourdomain.com still aligns with a From of you@news.yourdomain.com and, in relaxed mode, with the parent organisational domain too.

Step 6: the DMARC record and reaching enforcement

DMARC ties it together: it tells receivers what to do when a message fails both SPF-aligned and DKIM-aligned checks, and where to send you reports. You publish it once at _dmarc.yourdomain.com, regardless of how many providers you use.

Do not start at p=reject. Start in monitor-only mode so you can watch Brevo (and everything else) before enforcing.

Stage 1: monitor. Publish a p=none record with reporting turned on:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

p=none changes nothing about delivery; it just asks receivers to send aggregate reports (rua). adkim=r and aspf=r request relaxed alignment, which is what allows a news.yourdomain.com DKIM signature to align with a yourdomain.com organisational domain. You can build a correct record with the DMARC generator and validate an existing one with the DMARC checker.

Stage 2: read the reports. Let it run for one to two weeks of normal sending. Aggregate reports arrive as XML, which is unreadable by eye, so feed them to the DMARC report analyzer. You are looking for one thing: is Brevo traffic passing DMARC via aligned DKIM? It should show your Brevo-sent volume with DKIM pass and DKIM aligned. If you have a dedicated IP with custom return-path, you should also see SPF aligned. While you are here, confirm every other legitimate source (your own mailbox provider, any helpdesk, any billing tool) is also aligned, because DMARC enforcement affects all of them, not just Brevo.

Stage 3: quarantine, partially. Once Brevo and your other sources are consistently aligned, step up cautiously using the percentage tag:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

pct=25 applies quarantine to a quarter of failing mail, limiting blast radius while you watch reports. If nothing legitimate is being quarantined, raise to pct=50, then pct=100.

Stage 4: reject. When p=quarantine; pct=100 has run clean, move to full enforcement:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

At p=reject, anything failing aligned authentication is rejected outright, which is exactly what stops spoofing of your domain. Because you reached this point by confirming Brevo's DKIM alignment first, your Brevo mail keeps flowing.

For a fuller walk-through of the staged rollout independent of provider, see how to move from p=none to p=reject safely, and for the modern mailbox-provider rules driving all of this, the bulk sender requirements.

Common Brevo authentication mistakes

• Expecting SPF to fix DMARC on shared IPs. It cannot align. DKIM is the mechanism. Only a dedicated IP with a custom return-path makes SPF alignment possible.
• Publishing only one DKIM selector. Brevo uses two (mail/mail2 or brevo1/brevo2). Publish both, or rotation will eventually break signing.
• Cloudflare proxying or flattening the DKIM CNAME. Keep DKIM CNAMEs DNS-only and unflattened so they resolve to *.dkim.brevo.com.
• Doubling the host suffix. mail._domainkey.yourdomain.com.yourdomain.com from entering a full host on a provider that auto-appends the domain.
• Two SPF records. One v=spf1 line only; merge providers into it.
• Jumping straight to p=reject. Always monitor, then quarantine with pct, then reject.
• Forgetting other senders. DMARC is domain-wide. If your CRM or invoicing tool is not aligned, enforcement will hit it too.

Verify the whole chain

Before and after you reach enforcement, confirm each layer resolves:

• DKIM checker: query selector mail (and mail2) and confirm a valid 2048-bit key resolves through the CNAME.
• SPF checker: confirm a single valid record under 10 lookups, with include:spf.brevo.com present.
• DMARC checker: confirm the policy, reporting address and alignment tags are what you intend.
• DMARC report analyzer: confirm Brevo traffic is passing on aligned DKIM before you tighten the policy.

If you also publish MTA-STS or BIMI, note that BIMI requires p=quarantine or p=reject first, so reaching enforcement through Brevo is a prerequisite for a verified logo in the inbox.

The practical takeaway

For Brevo on shared infrastructure, the rule is short: DKIM does the work, SPF is optional, DMARC enforcement is reached through aligned DKIM. Publish the Brevo code, publish both DKIM CNAME selectors (kept unproxied and unflattened), add include:spf.brevo.com for hygiene, then move DMARC from p=none to p=quarantine to p=reject while watching aggregate reports to confirm Brevo's DKIM is aligned at every step. If you want SPF aligned too, that comes with a dedicated IP and a custom return-path on your own subdomain, not with the shared pool.

If you would rather not babysit selectors, percentages and XML reports yourself, our done-for-you DMARC service takes your domain from p=none to p=reject with continuous monitoring and change alerts, and our free monitoring will email you the moment a Brevo DKIM record stops resolving or your alignment slips. Start by running your domain through the DMARC report analyzer to see exactly how your Brevo mail is authenticating today.