Brevo SPF, DKIM and DMARC: a setup that passes DMARC

Brevo's domain authentication screen hands you a small set of DNS records: a verification TXT value proving you own the domain, a DKIM record carrying a public key, and SPF guidance. Publish all of them, then verify the result from outside Brevo — because a verified domain in the dashboard and a DMARC-aligned message are two different states.

Get the records from the dashboard, not from a blog post

The one rule that saves the most time: the DKIM public key is unique to your account, so it can only come from Brevo's *Senders → Domains* screen. Anything you copy from an article will fail. The pattern you are looking for is:

Brevo publishes spf.brevo.com as its SPF include. Merge it into the record you already have — never add a second one:

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

Two v=spf1 records on a domain is a specification violation that makes receivers return PermError and ignore SPF entirely. This is the single most common mistake when adding a second sending platform.

Why SPF is often not what makes Brevo mail pass

SPF is evaluated against the envelope sender — the MAIL FROM, which you see as Return-Path in a delivered message — not against the From address your recipient reads. Hosted platforms commonly send with their own bounce domain so they can process bounces. When that happens:

• SPF passes, because the envelope domain's record authorises the sending IP.
• DMARC still needs *alignment*: the authenticated domain must match the From domain. An envelope on the platform's domain does not align with yours.
• So DMARC passes on DKIM, because the DKIM signature is made with the key published under *your* domain.

Check which path is carrying you. Send a message to a mailbox you control and read the headers:

Return-Path: <bounces+123@...>
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=...;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass header.from=yourdomain.com

If dkim=pass shows header.i=@yourdomain.com, you are aligned and safe at p=reject. If it shows the platform's domain instead, your DKIM is not aligned and tightening DMARC will break your campaigns.

Verify each record from the command line

dig +short TXT yourdomain.com
dig +short TXT <selector>._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

Read the selector out of a real message's DKIM-Signature header (s= tag) rather than trusting what you think you published. If the DKIM query returns nothing, the usual causes are:

• The host field was entered with the domain appended, giving selector._domainkey.yourdomain.com.yourdomain.com. Many DNS panels append automatically; enter only the relative part.
• The key was truncated. A 2048-bit key exceeds the 255-character limit for a single TXT string. Split it into multiple quoted strings inside one record; the resolver concatenates them. Do not create a second record.
• You are still inside the old TTL. Query a public resolver with @8.8.8.8 to confirm.

DMARC, in the right order

Publish monitoring first:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

Leave it for a week, confirm from the reports that Brevo's traffic shows DKIM alignment on your domain, then move to p=quarantine and later p=reject. If you send platform mail from a subdomain, set sp= explicitly rather than letting it inherit the apex policy.

Tracking links and the subdomain question

Brevo, like most platforms, can serve click-tracking links from a subdomain of your domain via a CNAME. Doing so is worth it: recipients see your domain in every link instead of a shared tracking host whose reputation you do not control. It does not affect SPF, DKIM or DMARC — link domains are reputation signals, not authentication ones — but shared tracking domains are a genuine filtering risk in their own right.

A related decision: send marketing mail from a subdomain such as news.yourdomain.com and keep the apex for human, one-to-one mail. Each gets its own SPF budget and its own reputation, and a bad campaign stops costing you replies to your sales mailbox.

What not to do

• Do not publish a second SPF record. Merge, always.
• Do not add include:spf.brevo.com and then assume you are done. If the envelope is on Brevo's domain, that include is doing less for you than the DKIM record is.
• Do not set p=reject on the same day you connect a new platform. Verify alignment in headers and reports first.
• Do not keep includes for platforms you stopped using. Each one burns part of SPF's 10-DNS-lookup budget, and includes that resolve to nothing count against the two-void-lookup limit as well.
• Do not re-use the same DKIM selector for two platforms. Selectors are namespaces; collisions overwrite a working key.

MailPilot warms mailboxes over OAuth or SMTP/IMAP and checks the SPF, DKIM and DMARC state of the sending domain continuously, so a truncated DKIM key or a duplicated SPF record surfaces as a failing check rather than as a gradual drop in placement.