What DNS records does Brevo domain authentication need?

Per Brevo's current help documentation, the classic flow uses three to four records: a TXT holding your Brevo code (ownership proof), DKIM — today a pair of CNAMEs at brevo1._domainkey and brevo2._domainkey (2048-bit by default, letting Brevo rotate keys without your involvement; older accounts hold a single 1024-bit DKIM TXT and are offered migration), and a DMARC TXT that Brevo generates as v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com. Brevo's recommended path is automatic authentication, where you log in to your DNS provider from Brevo and it publishes the records; if an existing DMARC record is found, automatic mode asks to replace it with Brevo's, and declining sends you to the manual flow. Copy every value from your own Brevo screen — targets are account-generated.

Does Brevo need an SPF record or an SPF include?

Not on the standard shared-IP setup. Brevo's FAQ states it verbatim: 'The SPF and MX records are not required to authenticate a domain. We only provide these records when setting up a dedicated IP.' The widely-published instruction to add include:spf.brevo.com to your SPF contradicts Brevo's documentation — do not add it. On shared sending, DMARC alignment is carried by the DKIM signature (d= equals your authenticated sending domain). SPF becomes your record only in the dedicated-IP flow, where it lives on the IP's required subdomain (either two NS records delegating to Brevo, or an advanced seven-record manual set). Brevo's newer unified authentication flow adds a branded subdomain which Brevo says also enables full SPF alignment.

What happens if I send from an unauthenticated domain in Brevo?

Brevo rewrites the sender: marketing mail goes out under a brevosend.com domain and transactional mail under t-sender-sib.com (per Brevo's documentation). Recipients see a sender that is not your domain, and DMARC alignment for your domain is impossible. It is the same family of fallback as SendGrid's send-as-sendgrid.net behaviour — the platform protects deliverability by borrowing its own domain, at the cost of your brand and your policy.

Brevo · Domain authentication

Brevo domain authentication — three records, zero SPF record

First published 20 October 2026 · From Brevo's Help Center (six articles, read in full). Brevo is mid-rollout of a newer unified flow; this guide covers the classic flow completely, flags the new one where it changes facts, and follows the standing rule: your screen outranks every article.

THE SET Brevo code TXT · DKIM CNAMEs brevo1/brevo2 · DMARC (Brevo-generated)

Brevo says it in its own FAQ: “The SPF and MX records are not required to authenticate a domain. We only provide these records when setting up a dedicated IP.” So if a tutorial is walking you through an SPF include for Brevo, it's walking you out of Brevo's documentation.

DKIM carries alignment on shared sendinginclude:spf.brevo.com — not a Brevo instruction

The ladder

Settings → Senders & IP → Domains → Add a domain. (Menu names drift slightly between Brevo versions; the domain list is the destination.)
Choose Automatic authentication (Brevo's default and recommendation): log in to your DNS provider from Brevo and let it publish. If it finds an existing DMARC record it will ask to replace it with Brevo's — that's a policy decision (see §3), not a formality; declining routes you to manual.
Manual path: publish the Brevo-code TXT, the DKIM records, and the DMARC TXT exactly as your screen shows them.
Cloudflare readers: Brevo's own documentation is explicit here (unusually) — Proxy status OFF on both DKIM CNAMEs, and CNAME flattening OFF, “or DKIM authentication will fail.”
Verify in Brevo until the domain shows authenticated; propagation is the only wait.
Create your sender on the authenticated domain, then test-send and read headers: dkim=pass, your domain.

The records

Record	Form (values always from your screen)
Brevo code (TXT)	Ownership proof token. Keep it — deleting it in a later “cleanup” de-authenticates the domain it proved.
DKIM	Current: CNAMEs `brevo1._domainkey` + `brevo2._domainkey`, 2048-bit by default, Brevo-rotated. Legacy accounts: a single 1024-bit TXT — a migration banner offers the CNAME form; it's an improvement, not a forced march. (Older Sendinblue-era posts reference other selector names; your screen's names rule.)
DMARC	Brevo generates: `v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com` — reports go to Brevo's processing address. One DMARC record with a rua is enforced; Brevo documents the merge/delete resolutions if you already have one (our DMARC guide covers the surgery rules).
SPF / MX	Not part of shared-IP authentication (Brevo's sentence, §1). They appear only in the dedicated-IP flow, on that IP's mandatory subdomain: either 2 NS records delegating to Brevo (Simple) or a 7-record manual set incl. SPF (Advanced).

§3 — the DMARC decision inside the setup

Brevo's generated record is a starter: p=none (monitor) with reports to Brevo's address. Two deliberate upgrades await you later: reports to your own address too (add a second rua destination or your own), and the policy climb to quarantine/reject (our rollout guide). Accepting Brevo's replacement during automatic auth is fine if your current record is itself just a starter; if you've already climbed to enforcement with your own reporting, decline, go manual, and keep your record — adding Brevo needs nothing in _dmarc beyond its authenticity.

Alignment truth

DKIM: signs with d= = your authenticated sending domain → DMARC's leg on shared sending. Sender must be an address on that domain: Brevo's own materials contain an internal tension (prose allowing “matches or is a subdomain of,” an example table marking subdomain-sender/root-auth as ✗) — the safe reading the evidence supports: authenticate the exact domain you send from.
SPF: not yours to align on shared IPs (Brevo's return-path arrangement); the newer unified flow's branded subdomain is documented by Brevo as enabling “full SPF alignment on your sending domain.” Which flow your account has is visible in your setup screens — follow the one you're in.
Unauthenticated sending is rewritten: marketing → a brevosend.com sender; transactional → t-sender-sib.com. Alignment and brand both gone — the platform's safety net, not a configuration.

Traps

Trap	Reality
Sendinblue-era instructions	The rebrand renamed more than the logo: selector names and flows drifted. Date-check anything that still says Sendinblue.
Adding `include:spf.brevo.com` “for completeness”	Contradicts Brevo's FAQ; spends your 10-lookup budget; authenticates nothing Brevo checks.
Authenticating domain A, sending from domain B	Rewritten sender, no alignment. The sender address's domain is the unit of authentication.
Flattening/proxy left on at Cloudflare	Brevo-documented failure, §2 rung 4. One of the few ESPs whose own docs name this trap — honour it.

FAQ

Subdomain or root for the sending domain?

Brevo mandates a subdomain only for dedicated-IP and the new NS-delegated setup; for classic authentication the root works. Sending from a subdomain (e.g. em.) remains sound reputation hygiene (our standing advice across ESPs) even where not mandated.

“Authenticate automatically” wants my DNS login. Safe?

It's Brevo's documented, recommended flow (a delegated connection publishes only the setup records). If your organisation's policy forbids it, the manual path is fully supported — same records, your hands.

Reports go to Brevo. Can I read my DMARC reports too?

Yes — add your own rua address to the record (multiple destinations are legal) and read them with the method in our DMARC-reports guide (Article #36 in this series).

Sources

Brevo Help Center — Authenticate your domain (canonical flow, records, FAQ incl. the SPF/MX sentence), DKIM troubleshooting (brevo1/brevo2 hostnames, Cloudflare conditions), DMARC articles (generated record, single-record resolutions), dedicated-IP setup (Simple NS / Advanced records), sender-rewrite behaviour for unauthenticated domains, the unified-flow rollout notes.

Verification note: the record inventory, DKIM forms and SPF position were confirmed from Brevo's Help Center on 20 October 2026. Account-generated target values and the rollout status of the new flow can't be published generically — your Brevo screen is, as everywhere in this series, the specification.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.