Brevo currently documents an established domain-authentication flow and a newer combined domain setup that is rolling out gradually. The new flow can also configure branded links and dedicated-IP association. Identify which one your account shows before deciding how many DNS records to expect. A single old recipe can omit required records or overwrite a policy that already protects other mail.
Identify the account flow and intended identity
Use the domain after @ in the intended From address, not a website URL. Confirm control of that domain and authoritative DNS access. Retain current SPF, DKIM, DMARC and any records at proposed branded subdomains. Decide whether this is authentication alone or a broader return-path and link-branding change.
The established authentication guide points to the new flow when available. Under Settings, Senders, Domains, IPs, Domains, add the domain or select Authenticate for an existing entry. Its manual path uses a Brevo verification TXT, either one DKIM TXT or two DKIM CNAMEs, and a DMARC TXT record. Copy the values generated for the account.
Preserve policy when choosing automatic or manual setup
Brevo offers automatic DNS configuration through a connected DNS-provider flow and a manual alternative. Its guide warns that an existing DMARC record may be replaced if that option is accepted. If you need to preserve the existing policy, choose the manual route and reconcile the required records without duplicating DMARC.
Review any DNS access grant before approving it. Giving a provider configuration access is a different decision from copying a public TXT record. Record the actual changes made by automation, including any reporting address. Do not lower an existing quarantine or reject policy merely because a setup example uses none.
Treat the new combined flow as a separate architecture
The new setup guide distinguishes individual records from Brevo-managed subdomain delegation. Root domains use individual records; NS delegation requires a subdomain. The documented alternatives are up to seven individual DNS records or two NS records for Brevo-managed setup. A branded subdomain is optional on shared IPs but required on dedicated IPs. The generated set depends on branded-subdomain and dedicated-IP choices. It may include DKIM CNAMEs, a branded return-path CNAME, tracking records, DMARC and a dedicated-IP A record where applicable.
Use a currently unused subdomain and review every service affected before delegation. The new guide specifies that the selected sending domain must not already be used on another platform or email service. For an established shared corporate domain, resolve that requirement with Brevo before proceeding rather than assuming the older flow's configuration can be transplanted unchanged. Do not change the root nameservers to emulate a subdomain instruction.
Publish exact records and verify the result
For individual records, preserve owner, type and full value as displayed. Check whether the DNS editor expects a full name or relative label. A CNAME owner must not carry conflicting ordinary records. Retain both generated DKIM selectors when the workflow supplies two; a currently unused selector can be part of rotation, not debris.
Query the exact owners at authoritative DNS. For aliases, inspect the returned CNAME and destination; for TXT, compare the complete reconstructed string. Return to Brevo and run its authentication check. A green configuration status is useful, but the final test is a controlled message through the real campaign or transactional route.
Record visible From, envelope domain, DKIM d=/s= and trusted receiver results. Confirm an aligned passing path. Do not add an arbitrary SPF include at the corporate root to fix a provider-owned return path. Conversely, when the new architecture provisions a branded return path, verify that the message actually uses it rather than assuming the DNS record alone changes the envelope.
Recover and maintain the chosen configuration
Illustrative regression: automation offers to replace an existing reject policy with a monitoring example. Stop that policy change, use the manual route and preserve the approved policy while configuring the generated DKIM records. This is an example of change review, not an observed account event.
If validation fails, compare the published name and value before waiting on caches or regenerating keys. Preserve prior records, pause affected sends when necessary and restore only approved changes. Recheck after a flow migration, dedicated-IP association, sender-domain change or rotation. This guide documents current public instructions; no Brevo account or live DNS was changed.
Stop a delegation at the correct boundary
For written case BR-01, assume the newer flow is visible, the root example.com serves staff mail and a website, and the proposed sending subdomain emails.example.com is unused. The root is not an acceptable shortcut for NS delegation. The DNS owner must first approve the exact subdomain boundary and verify it has no hidden dependencies; generated NS targets are unknown in this case and must not be guessed. If the owner approves only individual records, that approval does not authorize future provider control through delegation. Preserve the root mail and web records. After the separate account setup, a hypothetical message with From news@emails.example.com and passing DKIM d=emails.example.com, s=demo1 would align exactly; actual SPF, branded-link behavior and delivery remain untested. This is a planning exercise, not a performed delegation or send.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.