Brevo SPF, DKIM and DMARC setup, step by step

To authenticate a Brevo sending domain, use the DNS records generated in your account. In the established workflow, Brevo provides a verification TXT record, DKIM as either one TXT record or two CNAME records, and a DMARC step. That workflow does not require SPF or MX for ordinary domain authentication. Dedicated-IP and newer branded-return-path setups have different requirements. Brevo domain-authentication instructions

Brevo is the current name of Sendinblue. Use current Brevo instructions even if your change ticket, integration or older tutorial still says Sendinblue. Do not create a second set of authentication records merely because the product name changed.

Employee mail through Microsoft 365 is a separate sending route; retain its configuration and use the Microsoft 365 authentication guide for that service rather than treating these application records as its configuration.

This guide describes documented setup and recommended validation. It does not claim access to your account, live DNS testing or successful message delivery.

First identify which setup your account shows

Brevo is gradually rolling out a combined domain setup covering authentication, branded subdomains and dedicated-IP association. Some accounts still show the established authentication workflow. Choose the instructions matching your interface; the expected DNS list is not identical. New Brevo domain setup

Before editing records, capture:

• The exact From address used in campaigns and transactional applications.
• Whether the route uses shared infrastructure or a dedicated IP.
• Whether the account is using established authentication or combined domain setup.
• Any existing branded subdomain or custom return path.
• The authoritative DNS provider and the existing DMARC policy owner.

Make separate test cases for marketing campaigns and transactional API or SMTP messages. They may use different From addresses or IP configurations even within one account. Testing a newsletter should not automatically sign off password-reset, receipt or application-notification traffic.

Does Brevo need an SPF record?

For the established authentication flow, Brevo says SPF and MX records are not required and are supplied when setting up a dedicated IP. Avoid adding a Sendinblue-era include just because it appears in a search result. Brevo’s SPF and MX clarification

The newer flow can supply a branded CNAME supporting SPF and return-path configuration. It also offers dedicated-IP association. That makes “Brevo never supports SPF alignment” too broad: identify the enabled configuration and inspect a real message. Brevo combined domain setup

SPF checks the envelope sender domain. If a route requires an SPF TXT update, retain one SPF policy at that DNS owner and account for the ten DNS-lookup-term limit, including nested mechanisms. SPF specification

Only where the selected route actually requires a direct SPF TXT policy, preserve existing legitimate authorizations and the approved terminal qualifier during the merge. Do not weaken another sender’s policy or insert SPF TXT at a required CNAME owner.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

The operational rule is simple: publish the account’s required records for the selected route. Do not add an include to an unrelated owner, and do not turn a CNAME-based requirement into an improvised TXT policy.

Configure the established authentication workflow

Open Settings → Senders, Domains, IPs → Domains, add the sending domain or select Authenticate beside it, and choose the available automatic or manual method. In manual setup, copy the Brevo-code TXT entry, the account’s DKIM record or records, and the DMARC requirement. Brevo warns that automatic setup may ask to replace existing DMARC; choose manual setup if you need to retain your policy. Brevo setup steps

The sending domain is the portion after @ in the From address. Authenticate each domain you use, and use domains your organization owns and controls. Public Gmail or Yahoo domains are not yours to authenticate. Brevo domain-authentication FAQ

Create a change worksheet without borrowing deployment values:

Do not publish the bracketed placeholders. They identify information to collect from your account, not sample DNS records.

Treat the new combined flow as a different change plan

The combined-flow instructions require a sending domain that is not already used on another platform or email service. Choose an unused domain or subdomain rather than repurposing an active one. A branded subdomain is required for dedicated-IP use and optional on shared IPs. The dedicated-IP association step appears only when at least one dedicated IP is not yet associated with a domain. Combined-flow prerequisites

In the new flow, select the sending domain, branded subdomain if applicable, and any dedicated-IP association. Brevo documents individual records or a managed NS-based option for subdomains. Root domains use individual records because root delegation would affect the whole domain. Depending on selections, the list may include DKIM CNAMEs, DMARC TXT, branded and tracking CNAMEs, and a dedicated-IP A record. Combined-flow record options

Treat delegation as a separate approval item. Before adding NS records, write down the precise subtree being delegated and list anything already hosted beneath it. Check website, application, verification and mail-related records. Do not change registrar-level nameservers as a shortcut for delegating a narrow subdomain.

Have the DNS owner approve the exact delegated child owner and complete issued NS target set, or the exact full owner and destination IP set for a dedicated-IP A record. Match those values to the authorized service/routing plan, not merely a screenshot. Before activation, verify the complete approved set at authoritative and recursive DNS, including authority beneath a delegated child. Stop for unapproved or mismatched destinations; preserve root nameservers, DNSSEC and unrelated mail or web services.

For an existing branded setup, map which applications use it before migration. Keep a rollback record and establish whether previously sent links or queued mail depend on the old configuration. An administrator should understand the scope of the change before clicking through a convenient automatic wizard.

Agree a recovery plan before rollout. Pause affected campaigns or transactional applications only with their owner’s approval, and restore only an approved prior sender configuration. Preserve shared signing keys, queued-message validation and previously sent link dependencies while coordinating retirement. Recheck the actual campaign and application routes after migration, dedicated-IP association changes or key rotation; a saved DNS copy alone does not restore every account-side setting.

Protect existing DNS and DMARC

Save affected records before editing. Work in the authoritative DNS zone rather than assuming the registrar’s default editor is active. After saving, check the fully qualified owner name; many interfaces append the zone name automatically.

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

If a DKIM CNAME conflicts with another entry, investigate ownership. CNAME records cannot coexist with incompatible data at the same name. Do not delete another sender’s selector just to make the editor accept a new record. DNS conflict explanation

These alias-processing controls apply only to the two-CNAME DKIM or combined-flow CNAME records, not to the single-TXT DKIM branch. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Review DMARC separately from sender onboarding. Preserve the approved enforcement level and reporting destinations. A missing reporting address is not a reason to replace an entire policy with a monitoring example. Brevo documents a missing-rua warning and how to add reporting, but choose report recipients deliberately and retain existing approved recipients when appropriate. Brevo troubleshooting

Check both the direct From-domain policy and any applicable inherited policy before adding anything. Do not create a child monitoring policy to bypass inherited protection.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Do not assume that every vendor-suggested policy change is necessary for the protocol to authenticate a message. If the UI rejects an otherwise deliberate configuration, collect the exact warning and ask support to clarify it before weakening the domain’s protection.

Validate the published configuration and the real sender

Start with public DNS. Query each owner and record type shown in the account, compare the full answer with the required value, and confirm CNAME targets resolve. If an NS delegation was used, also establish that queries are reaching the intended delegated nameservers. A local editor screenshot does not demonstrate this.

Next, use Authenticate this email domain in the established manual flow or Authenticate domain in the combined manual flow. Confirm the domain status is Authenticated; if branding was configured, its separate Branded status must also be checked. Save the status and time. Brevo recommends checking public DNS and escalating if authentication remains unresolved after 48 hours. Established verification · Combined verification

Finally, send a small authorized message through each in-scope route to a controlled mailbox. Use a fresh message, not one sent before the change. In Gmail, inspect More → Show original. How to retrieve full headers

Record the DKIM signing domain and selector. A selector identifies the public-key lookup used by that signature, so a different selector in a failing message is a useful clue rather than a cosmetic difference. DKIM signature fields

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

DMARC requires passing SPF or DKIM with alignment to the visible From domain. Relaxed alignment can use the same organizational domain, while strict alignment requires an exact match. Verify this rather than equating spf=pass with aligned SPF. Current DMARC standard

Treat stronger enforcement as a separate domain-wide decision. RFC 9989 section 7.4 requires valid DKIM for legitimate outbound mail when publishing p=reject and calls for attention to indirect-mail interoperability, including forwarding and mailing lists. One successful Brevo route does not establish readiness for all senders.

For this branded DKIM setup, require the intended Brevo signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate. Neither published records nor an account badge alone completes validation.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Troubleshooting decisions that avoid unnecessary edits

Brevo cannot find DKIM: compare owner, type and full value with the account screen. Check whether the account expects TXT or two CNAMEs. Then confirm the published zone and name suffix.

An old TXT setup needs migration: Brevo says the existing TXT configuration continues working and remains authenticated during the supported migration. Add both newly issued DKIM CNAMEs and leave the current TXT unchanged until the domain shows Authenticated. Use the migration banner when provided; if none appears, contact Support instead of assuming a self-service switch exists. Test fresh mail and review shared and queued-message dependencies before later retirement. Brevo DKIM troubleshooting

SPF passes but DMARC fails: compare the envelope domain and DKIM signing domain with From. A new root SPF include does not repair an unrelated return path.

The account is authenticated but one application fails: compare its sender address and routing settings with the successful campaign. Ask for a redacted original message, UTC send time and application identifier before changing shared DNS.

The recipient accepts the message into spam: investigate consent, complaints, content and sending reputation. Authentication does not guarantee inbox placement. Google’s sender guidance