Brevo emails going to spam? 'Verified' doesn't mean authenticated

The most common Brevo spam problem hides behind a green checkmark. Your domain shows "verified" in Brevo's dashboard, so you assume authentication is done. But verification and authentication are different steps: the verification code TXT proves you own the domain, while only the DKIM CNAME records make Brevo sign email as your domain. Add the first and skip the second and every campaign still goes out signed by Brevo's shared infrastructure, with your deliverability riding on the reputation of thousands of strangers. Sixty seconds with the free Brevo checker tells you which situation you're in.

This trips up careful people, so it's worth understanding exactly how.

Ownership is not a signature

Brevo's domain setup hands you several records, and they do different jobs:

• a Brevo verification code TXT record: proves to Brevo that you control the domain
• DKIM CNAME records at brevo1._domainkey and brevo2._domainkey: these are the authentication, the thing that makes receivers see your domain vouching for your mail
• your DMARC record, which Brevo asks about but which is yours, not theirs

The dashboard turns friendly the moment ownership is proven, and that's where a lot of setups stop. Everything looks green, campaigns send fine, and the mail is signed as shared infrastructure the entire time. Under Gmail and Yahoo's bulk-sender rules, which since February 2024 expect mail authenticated by the sender's own domain, that gap widens into a spam-folder problem.

If our checker finds neither brevo1/brevo2 nor the older names answering on your domain, this is you, and the fix is ten minutes in Brevo's settings under Senders, Domains & Dedicated IPs: copy the CNAMEs, add them to your DNS, done.

Which generation are your records?

Brevo used to be Sendinblue, and the rename left DNS archaeology behind. Current accounts get DKIM CNAMEs at brevo1._domainkey and brevo2._domainkey. Earlier generations used mail._domainkey and mail2._domainkey, and the oldest tutorials floating around describe TXT-based records from the Sendinblue era.

The trouble starts when someone follows a guide from the wrong generation. You end up with records that exist, look plausible, and don't match what your account actually signs with. If you inherited a domain setup and aren't sure what vintage it is, don't guess from tutorials: check what actually answers. The checker probes both generations and shows you which names respond and with what, which settles the question in one pass.

The reliable source for your records is always your own Brevo dashboard, because it shows your account's values, not a blog post's.

The SPF include most Brevo users don't need

You'll find guides insisting you add spf.brevo.com to your SPF record. That include matters for dedicated-IP setups, where Brevo's docs walk you through it. On ordinary shared sending, Brevo handles the envelope side itself and DKIM is your authentication path; the include does nothing for you there.

A stray include isn't fatal, but it isn't free either: every include costs DNS lookups against SPF's hard limit of ten, and a domain that blows past the limit fails SPF for everything, including your ordinary business email. SPF records accumulate includes like drawers accumulate cables. If yours is long, an audit is worth more than an addition.

The checklist, in order

1. In Brevo (Senders, Domains & Dedicated IPs): confirm domain authentication is complete, not just the verification code. Copy the DKIM CNAMEs.
2. Add them in your DNS exactly as given. If your dashboard auto-appends your domain to names, enter only the part before your domain.
3. Publish DMARC if you don't have it: TXT at _dmarc.yourdomain.com, value v=DMARC1; p=none; rua=mailto:you@yourdomain.com. No email tool can do this for you.
4. Re-run the checker. It verifies the DKIM names, your DMARC, your SPF record's validity, MX, and your domain against 24-plus blocklists together, so if the problem is elsewhere you find out now rather than after a week of tinkering.

Propagation can take a couple of hours; failed-then-passing an hour later is normal, not flaky.

The bigger pattern behind all of this: the dashboard said one thing, DNS said another, and mail folders were decided by DNS. That gap doesn't just exist at setup. Records drift, requirements tighten, and dashboards keep smiling. Inbox Decay watches the DNS side continuously and emails you when reality changes, which beats discovering it in a quarterly engagement review. Free to start, and the fix instructions come with it.