Brevo SMTP: SPF, DKIM, and DMARC in 15 Minutes

Most developers treat email authentication as an afterthought. They wire up SMTP credentials, send a test, see it land in inbox, and ship. Then two weeks later a client calls because their invoices are going to spam. I've lived that call more than once.

Brevo (formerly Sendinblue) is my current go-to for transactional SMTP on client projects — cheap, reliable, generous free tier, and the dashboard is actually usable. But getting SPF, DKIM, and DMARC right matters more than picking the right provider. Here's the 15-minute version I've done enough times to have it memorized.

What These Three Records Actually Do

I'll skip the textbook definitions and give you the practical version.

SPF tells receiving mail servers which IP addresses are allowed to send email for your domain. Without it, any server on the internet can claim to be noreply@yourdomain.com. SPF is a TXT record on your root domain.

DKIM adds a cryptographic signature to outgoing messages. The receiving server fetches your public key from DNS and verifies the signature. If someone tampers with the message in transit, the signature breaks. Brevo generates the key pair for you — you just publish the public key.

DMARC is the policy layer that sits on top of both. It tells receiving servers what to do when SPF or DKIM fails: nothing, quarantine (spam folder), or reject. It also gives you a reporting address so you can see who's spoofing your domain. Without DMARC, SPF and DKIM are suggestions. With DMARC, they're enforced.

All three together is what Gmail and Outlook actually want to see in 2024. Google's bulk sender requirements made that official. Don't skip any of them.

Getting Your Credentials Out of Brevo

Log into Brevo, go to Senders & IP under the SMTP & API section, and add your domain. Brevo will show you exactly three DNS records to add. Here's what each one looks like in practice.

SPF Record

Brevo wants you to authorize their sending servers. If you're only using Brevo and no other sending service, your SPF record looks like this:

Host: @  (or yourdomain.com, depending on your DNS provider)
Type: TXT
Value: v=spf1 include:spf.brevo.com ~all

If you're already sending from another service — say, Google Workspace for your staff email — you need to merge them, not create two SPF records. Two SPF TXT records on the same host will break SPF entirely. Merge them:

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

The ~all is a softfail. Some people advocate -all (hardfail), but I stick with ~all until DMARC is solid and I've been watching reports for a few weeks. Hardfailing while you're still figuring out your sending infrastructure can get legitimate mail rejected.

DKIM Record

Brevo generates a DKIM key pair when you add your domain. The public key goes into DNS as a TXT record on a subdomain. It looks something like this:

Host: mail._domainkey.yourdomain.com
Type: TXT
Value: k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...(long base64 string)

Copy this exactly from the Brevo dashboard. Don't retype it. DNS providers sometimes mangle long TXT records — if yours has a character limit per string, you may need to split the value into chunks of 255 characters wrapped in quotes, like:

"k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN" "AdditionalCharactersHere..."

Most modern DNS UIs handle this automatically, but Cloudflare for example will silently truncate if you're not careful. After adding it, verify with:

nslookup -type=TXT mail._domainkey.yourdomain.com

If you get the record back, you're good. If you get nothing after 30 minutes, check for trailing spaces or quote issues in your DNS UI.

DMARC Record

This is the one most tutorials rush through. Here's a DMARC record I'd actually deploy on day one:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1;

p=none means "monitor only" — don't reject or quarantine anything yet. This is intentional. You want to see what's actually sending email as your domain before you start blocking things. The rua tag is where aggregate reports go (daily digest), and ruf is where forensic reports go (per-failure). Use an address you actually check.

After a couple weeks of looking at reports with no surprises, I move to p=quarantine, then eventually p=reject. Never go straight to p=reject on a domain that's been sending mail for a while. You will break something.

Wiring Brevo SMTP into Laravel

Once DNS is settled, here's how I configure transactional mail in a Laravel project. In .env:

MAIL_MAILER=smtp
MAIL_HOST=smtp-relay.brevo.com
MAIL_PORT=587
MAIL_USERNAME=your-brevo-login@email.com
MAIL_PASSWORD=your-smtp-key-from-brevo-dashboard
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=noreply@yourdomain.com
MAIL_FROM_NAME="Your App Name"

Note that MAIL_USERNAME is your Brevo account login email, not the from address. And MAIL_PASSWORD is the SMTP key from the SMTP & API section — not your account password. That trips people up every time.

For a quick smoke test from tinker:

use Illuminate\Support\Facades\Mail;
use Illuminate\Mail\Message;

Mail::raw('DKIM test from Brevo', function (Message $message) {
    $message->to('you@youremail.com')
            ->subject('Brevo SMTP Test');
});

Then open that email in Gmail, click the three dots, "Show original", and look for:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com;
Authentication-Results: spf=pass; dkim=pass; dmarc=pass

All three passing is what you're after. If any of them say fail, stop and fix DNS before going to production.

The Gotchas That Bit Me

Brevo's SMTP key vs. API key. These are different things. The SMTP key is under Settings > SMTP & API > SMTP. The API key is for the REST API. Using the API key as the SMTP password gets you an auth error with no helpful message.

DNS propagation is real. I always wait 30 minutes minimum after adding records before clicking "Verify" in Brevo's dashboard. If you verify too early and it fails, Brevo won't always tell you when it passes on a retry — you have to come back and trigger verification again manually.

Subdomain senders need their own records. If you're sending from notifications@app.yourdomain.com, your SPF and DMARC records need to be on app.yourdomain.com, not just yourdomain.com. I handled this wrong on a client project last year — a healthcare SaaS where appointment reminders were coming from a subdomain. Deliverability was fine for months until Gmail tightened requirements, then it quietly started junking. Caught it in DMARC reports.

~all vs -all in SPF. If you're using p=reject in DMARC, you can harden SPF to -all. But don't do both changes at once. Change one thing, watch reports for a week, then change the other.

Brevo's free tier limits. 300 emails/day on the free plan. Fine for development, not for production with any real volume. The cheapest paid plan is $25/month for 20,000 emails. Know this before you promise a client "free email sending."

When I'd Reach for Brevo, and When I Wouldn't

I default to Brevo for small to mid-size client projects — e-commerce stores, practice management tools, real estate apps — where transactional email volume is in the hundreds to low thousands per month. The price-to-reliability ratio is hard to beat, the dashboard lets non-technical clients see what's being sent, and setup is genuinely fast once you know the DNS dance.

I wouldn't use Brevo for high-volume marketing email blasting (that's a different deliverability problem and tools like Klaviyo or Customer.io are purpose-built for it). I also wouldn't use it for clients who need granular per-message delivery webhooks baked into a complex workflow — Postmark has better developer ergonomics there and their deliverability for transactional mail is slightly better in my experience.

For a healthcare client where email contains PHI, I won't use Brevo at all. They don't offer a BAA. That's a hard stop. For those projects I'm either using SendGrid (which does offer a BAA) or routing through the EHR's own messaging system entirely.

The Bottom Line

SPF, DKIM, and DMARC are 15 minutes of DNS work and then they're done. There's no excuse for shipping a project without them. Start DMARC on p=none, watch the reports for two weeks, tighten it up — that's the whole playbook. Your future self won't have to explain to a client why their password reset emails are landing in spam.