DMARC
← Blog

Authenticating Brevo: SPF, DKIM and DMARC alignment

By Thomas · virtual CISO · 2026-07-28

Brevo — the email platform formerly known as Sendinblue — ships newsletters, order confirmations and automation flows for hundreds of thousands of organizations every day. A considerable share of those accounts still runs on default settings: messages go out, mostly arrive, and everything looks fine. Behind the scenes the picture is far less flattering. Without domain authentication, those sends are signed in the name of shared infrastructure, not in the name of the organization shown in the sender field. DMARC can therefore never validate them, and deliverability tops out at a ceiling that no amount of subject-line or content tweaking will ever lift.

The paradox is that Brevo does things properly: the platform offers full domain authentication, with DNS records handed over ready to paste from the interface. What is usually missing is the configuration step itself — or an understanding of what it actually changes. Publishing two TXT records takes ten minutes; grasping why a DKIM signature in the domain's own name is precisely what makes DMARC pass takes a little longer, and that is what this guide is for.

On the agenda: why an unauthenticated ESP caps deliverability, the setup on the Brevo side (mail._domainkey and the verification code), the decisive matter of DKIM alignment, the SPF envelope question — the most misunderstood of all —, the mailbox providers' requirements for bulk senders, and the final proof, read straight from the RUA reports.

Why an unauthenticated ESP caps deliverability

A Brevo account without domain authentication sends technically correct messages: the platform signs them with DKIM, but with a domain it owns or shares across thousands of customers. The From: field shows marketing@example.com, while the cryptography speaks in a third party's name. The two voices do not match, and that dissonance has two very distinct consequences.

The first is mechanical: DMARC fails. The protocol does not merely require SPF or DKIM to pass; it requires at least one of the two to pass and to align with the From: domain. A perfectly valid DKIM signature applied by a shared domain does not meet that condition. As long as nothing aligns, the DMARC policy of example.com stays condemned to p=none: hardening it would send the organization's own campaigns to quarantine, then to outright rejection.

The second is more insidious: reputation. The filters at Gmail, Yahoo and Microsoft build their trust per authenticated domain. When the signature belongs to shared infrastructure, the reputation earned through careful sending practices dissolves into the behavior of thousands of other senders — the least careful ones included. example.com accumulates nothing of its own: every campaign starts from scratch, and the glass ceiling stays in place no matter how polished the content gets.

Domain authentication at Brevo

In the Brevo interface, everything happens in the settings, under the senders and domains section. For each sending domain, the platform generates a set of DNS records to publish in the domain's zone, at the usual DNS host. Two records carry the substance: the DKIM public key, placed under the mail selector, and a verification code proving control of the domain.

mail._domainkey.example.com.   TXT   "k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…"
example.com.                   TXT   "brevo-code:7f3a92c1d5e84b06"

The values above are illustrative: each account receives its own, to be copied verbatim from the interface — the public key in particular, long and utterly intolerant of typos. Two classic traps lie in wait at data-entry time: some DNS hosts append the domain name automatically to the "name" field (in which case mail._domainkey must be entered alone, or the result is mail._domainkey.example.com.example.com), and long keys sometimes need splitting into several quoted strings depending on the zone editor. A command-line check settles any doubt:

dig TXT mail._domainkey.example.com +short

If no DMARC record exists yet at _dmarc.example.com, this is the right moment to publish one — at p=none with a rua address, so the reports start flowing in without blocking anything. Ready-to-adapt DMARC record examples cover the most common starting configurations. Once the records have propagated — minutes to hours depending on TTLs — Brevo validates the domain, and every message now leaves signed d=example.com, selector mail.

DKIM alignment: what actually makes DMARC pass

The word that matters in this whole operation is neither "signature" nor "key": it is alignment. A message signed by one of the platform's technical domains passes DKIM in the cryptographic sense — the signature is valid, nothing was tampered with. But DMARC adds an identity requirement on top: the d= domain of the signature must match the domain of the visible From:. d=example.com with a From: at example.com: aligned, DMARC passes. d= on a shared domain: DKIM "pass", DMARC "fail".

In relaxed mode — the default, and the right choice for an ESP — the match happens at the organizational-domain level: a From: at news.example.com signed d=example.com remains aligned. DMARCbis, the current version of the standard, now determines that organizational domain through a walk of the DNS tree (the Tree Walk) rather than the old Public Suffix List — a change of internal machinery that alters nothing in the configuration gesture itself. Strict mode, for its part, demands an exact match between the two domains; it is reserved for organizations where fine-grained control outweighs flexibility.

The entire value of Brevo's domain authentication lies in this shift: the shared signature becomes a signature in the organization's name. None of this mechanics is specific to Brevo, either: the equivalent setup at Mailjet follows the same pattern, and alignment at Mailchimp raises exactly the same question with different screens and one more CNAME. The principle stays constant from one ESP to the next: the domain that signs must be the domain that shows.

SPF and the envelope: why alignment will not come from there

The most widespread reflex is to add the platform's include to the domain's SPF record and consider the job done. That is a double misreading. SPF is not evaluated against the visible From:: it is evaluated against the MAIL FROM of the SMTP envelope — the Return-Path, the technical address that collects bounces. And at Brevo, as at most ESPs, that envelope address stays on a domain operated by the platform: that is exactly what lets it process bounces and list hygiene at scale. So SPF does pass, genuinely… but in the name of Brevo's envelope domain, not in the name of example.com. The outcome: a "pass" without alignment, hence no contribution to DMARC whatsoever.

Editing the SPF record of example.com changes none of this — receiving servers query the envelope domain's record, never the From: domain's. A superfluous include merely burns through SPF's budget of ten DNS lookups without bringing anything in return. This split between raw SPF and the DMARC verdict is one of the most frequent sources of confusion when reading reports; it is dissected in why DMARC fails while SPF passes.

The practical conclusion is crisp: with an ESP, DKIM carries the alignment on its own — and that is enough, since DMARC only asks for one of the two mechanisms to be aligned. Some ESPs offer an optional custom envelope domain that adds SPF alignment on top; a welcome refinement, not a prerequisite.

Gmail, Yahoo, Microsoft: no longer optional

Since February 2024, Gmail and Yahoo have imposed a baseline on bulk senders — on the order of 5,000 messages per day toward their mailboxes: SPF and DKIM in place, a published DMARC record (p=none at minimum), a From: that actually aligns, one-click unsubscribe, and a complaint rate kept below roughly 0.3%. Microsoft followed in 2025 with comparable requirements for its consumer mailboxes. A moderately active Brevo newsletter crosses those thresholds quickly.

Concretely, a Brevo account without domain authentication ticks the "DKIM" box in the technical sense but fails the alignment criterion — the very one these requirements target. The consequences arrive in stages: more frequent spam placement first, then outright rejections on the highest-volume campaigns. What used to be good practice has become the price of entry to the inbox; domain authentication is no longer an expert tweak, it is the basic ticket.

The proof in the RUA reports

Once the domain is authenticated, validation is read neither in Brevo's interface nor on the faith of a single test message: it is read in the aggregate DMARC (RUA) reports, sent daily by the receivers themselves. Those reports record, IP by IP, what Gmail, Microsoft or Yahoo actually observed. After activation, Brevo's sending IPs must appear there with a DKIM "pass" whose signing domain is example.com:

<row>
  <policy_evaluated><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
</row>
<auth_results>
  <dkim><domain>example.com</domain><selector>mail</selector><result>pass</result></dkim>
</auth_results>

The spf line of the evaluation often stays at "fail" in the DMARC sense — that is the platform's envelope, unaligned — and this is perfectly normal: the aligned dkim is enough to carry the overall verdict. The real points of vigilance lie elsewhere: sends still signed by the shared domain (a forgotten sub-account, a transactional stream configured separately, a department that wired up another tool on its own), or an unknown source emitting in the domain's name with no relation to Brevo at all. That is exactly the kind of drift a continuous reading of the reports reveals — and that hand-opened XML files will not reveal for long: tooled-up monitoring exists for precisely this reason.

In summary

An unauthenticated Brevo account works, but tops out: shared signature, diluted reputation, DMARC failing permanently. Domain authentication — the DKIM key under mail._domainkey plus the verification code, values supplied by the platform — moves the signature onto the organization's domain; the alignment of that d= with the From: is what makes DMARC pass. SPF, evaluated against the platform's envelope, generally brings no such alignment: DKIM carries it alone, and that is sufficient. The Gmail, Yahoo and Microsoft requirements have turned all of this into a condition of entry for bulk sending, and the RUA reports deliver the proof, IP by IP.

To locate the starting point, running the domain through a free DMARC analysis shows within seconds whether the sends sign under the right name and what the published policy is worth. Opening an account then makes it possible to follow the RUA reports week after week and to raise the policy toward p=reject once alignment is demonstrated — with authenticated Brevo traffic leading the way.

Enforcing DMARC, in practice

Thomas, the virtual CISO of DMARC.com, identifies every legitimate sending source, writes the exact DNS records, and takes a domain from p=none to p=reject — without breaking its mail.

Get to p=reject — free

Related guides

About the author

Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.