How to set up DMARC/DKIM/SPF for Brevo
Published 3 Aug 2026
Updated 9 Oct 2026
15 min read
Summarize with
Updated on 9 Oct 2026: We updated Brevo's setup steps for branded Return-Path options and DMARC enforcement without pct.
Brevo domain authentication needs the DKIM records displayed in your account and one DMARC TXT record, plus a Brevo verification TXT record when shown. Do not add a Brevo SPF include solely for domain authentication. Without a branded Return-Path, SPF can pass for Brevo's domain without matching your visible From domain. DMARC should pass through DKIM instead.
Choose manual authentication when a domain already has DMARC, because Brevo's automatic flow can offer to replace that record. Brevo's authentication guide covers the existing DNS flow. Record names and verification buttons differ in the newer domain setup.
Add your domain
- Open Domains. In Brevo, open the account dropdown, then go to Settings > Senders, Domains, IPs > Domains.
- Start setup. Select Add a domain. If the domain already appears, select Authenticate or Authenticate domain beside it.
- Enter the sender domain. Use the domain after the @ in the From address, without a URL scheme. Add each domain or subdomain that Brevo will use.
- Choose the method. Use automatic authentication for a new domain with supported DNS. Choose Authenticate the domain yourself or Manual when DMARC already exists or you need change control.
- Record the values. For manual setup, keep the Brevo page open and copy each DNS record displayed for the chosen configuration.
- Verify the domain. After publishing the records in the later steps, select Authenticate this email domain or Authenticate domain, and confirm the Domains page shows Authenticated.
Automatic authentication connects Brevo to the DNS provider, detects the provider, publishes the requested records, and verifies them. If Brevo asks to replace an existing DMARC record, cancel that path and switch to manual authentication. A domain must have only one DMARC record.
Add DNS records at the provider named by your authoritative nameservers. If GoDaddy is the registrar but Cloudflare hosts DNS, edit Cloudflare > DNS > Records. Choose Other in Brevo if that DNS provider is not listed.
Authenticate the exact visible sender domain. For news@example.com, add example.com. For news@mail.example.com, add mail.example.com. Use a dedicated marketing subdomain when operational separation is useful, and use that authenticated name in the From address.
Brevo Domains page with the Add a domain dialog
The existing manual flow displays a Brevo code TXT record, either two DKIM CNAME records or one DKIM TXT record, and a DMARC TXT record. Copy what the account shows because record shapes vary by setup.
Brevo's newer guided setup also offers a branded subdomain for shared or dedicated IPs. Availability varies by account. If the labels differ, preserve the same rule: never replace a working DMARC record without reviewing its reporting address and policy.
Use a domain you control
Brevo cannot authenticate a free mailbox domain such as gmail.com or yahoo.com. Use a business domain where you can publish DNS records. Keep the Brevo code and DKIM records in DNS for as long as Brevo sends for the domain.
Set up SPF
- Identify the setup. For Brevo domain authentication, do not publish an SPF include solely because Brevo sends your mail.
- Keep one SPF record. Retain the SPF TXT record needed by your other sender sources. Never create a second SPF record at the same hostname.
- Handle branded sending separately. For branded or dedicated-IP sending, publish the exact records Brevo displays for the Return-Path hostname.
- Check the result. Test the hostname that actually carries your SPF record and confirm one valid record with no SPF permerror.
Unbranded shared-IP sending uses a Brevo-controlled Return-Path, so an SPF pass authenticates that Brevo domain rather than your visible From domain. Expect SPF alignment failures in DMARC data for this setup. They are acceptable when DKIM passes and its signing domain matches the From domain.
The legacy include spf.sendinblue.com and spf.brevo.com are associated with Brevo, but their presence in old documentation is not a reason to add either one. For branded or dedicated-IP sending, copy the account-specific DNS records Brevo displays.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Check your existing SPF record at its actual hostname. For a Brevo message, SPF is evaluated at the smtp.mailfrom domain, usually visible in Return-Path. A clean result has one SPF record, valid syntax, and no more than ten DNS-triggering SPF terms, including nested include and redirect evaluations.
If the checker reports multiple records, merge the mechanisms into one record instead of keeping two TXT values that both begin with v=spf1. If it reports too many lookups, remove unused sources before changing the result qualifier.
Shared IP without branding
- SPF action. Do not add a Brevo include.
- Return-Path. Brevo-controlled domain.
- DMARC path. Matching DKIM signature.
- Expected report. SPF unaligned, DKIM pass.
Branded or dedicated IP sending
- SPF action. Copy Brevo's supplied DNS value.
- Return-Path. Branded sending subdomain.
- DMARC path. SPF or DKIM can match.
- Expected report. Follow account-specific records.
Set up a branded Return-Path
Brevo's newer domain setup offers optional branding on shared IPs and requires branding for its dedicated-IP flow. A branded subdomain puts the Return-Path under your domain and adds an SPF matching path alongside DKIM.
- Choose an unused prefix such as mail for the branded subdomain in Brevo's guided setup.
- For individual DNS setup, publish the supplied branded CNAME and the other displayed records.
- If Brevo-managed setup is offered for a sending subdomain, add both NS records exactly where instructed. Brevo then maintains the delegated zone.
- Confirm Branded as well as Authenticated, then check a live message's Return-Path and SPF result.
Keep the branded CNAME hostname free of conflicting TXT records. Review existing DNS before delegating a subdomain, and retain control of the root domain.
Verify relaxed SPF alignment in a test message. With aspf=s, the Return-Path domain must exactly match the From domain; branding alone does not satisfy that rule. Keep DKIM passing regardless.
Set up DKIM
- Open authentication. On Brevo's Domains page, select Authenticate beside the sender domain, choose manual authentication, and continue.
- Publish the Brevo code when shown. Create the TXT record using the exact name and value shown. This proves control of the domain.
- Copy every DKIM record. Publish both CNAME records when Brevo shows DKIM 1 and DKIM 2. If the account shows one TXT record, publish that TXT record instead.
- Preserve exact hostnames. Do not add the domain twice if the DNS provider automatically appends it. Save each record with the default TTL.
- Keep signing records active. Keep every required verification and DKIM record in DNS while Brevo sends for the domain.
Newer Brevo configurations commonly show two DKIM CNAME records. That model lets Brevo rotate signing keys without another DNS change. Older accounts can still show one DKIM TXT record. Follow the account screen exactly because changing a CNAME into TXT, guessing a selector, or publishing only one of two records stops verification.
Brevo's CNAME DKIM keys are 2048-bit. For a legacy 1024-bit TXT key, ask Brevo support to enable 2048-bit signing and publish the replacement value.
A DNS console can label the same fields as Name and Target, Host and Value, or Record and Content. The left field receives the DKIM name from Brevo. The right field receives Brevo's target or public key. In Cloudflare, set DKIM CNAME records to DNS only and turn off flattening for those records so Brevo can find the CNAME targets.
Brevo manual authentication screen with verification and DKIM records
Copying is safer than retyping. A missing dot, a repeated domain suffix, or a clipped CNAME target can leave Brevo showing Not authenticated even when the record looks plausible in the DNS console. Compare the resolved public record with the value on this screen.
For a two-CNAME setup, both selectors must resolve before Brevo can rotate between them. For a TXT setup, the value normally begins with v=DKIM1 and contains the public key. Do not split it unless the DNS provider requires quoted chunks.
Brevo DKIM record layoutDNS
Type: CNAME Name: <copy DKIM 1 name from Brevo> Value: <copy DKIM 1 value from Brevo> TTL: default Type: CNAME Name: <copy DKIM 2 name from Brevo> Value: <copy DKIM 2 value from Brevo> TTL: default
The layout above is a field map, not a substitute for the values in your account. If Brevo displays a single TXT record, use its displayed type, name, and complete public key instead of these CNAME fields.
After DNS resolves, send a message and inspect its authentication results. DKIM should report pass, and the d= domain in the DKIM signature should match the visible From domain under DMARC's matching rule. Relaxed matching uses the same organizational domain; strict adkim=s requires an exact domain match.
Do not guess the selector
Brevo can show different selectors and record types across accounts. Publish every record displayed for your domain. A copied selector from another Brevo account will not validate your key.
Set up DMARC
- Check for an existing policy. Look up _dmarc on the exact From domain and check any inherited policy for a sending subdomain. Keep existing quarantine or reject enforcement.
- Use one TXT record. Create or edit the TXT record at _dmarc. Multiple DMARC records make evaluation fail.
- Start with monitoring. If no direct or inherited enforcement policy applies, publish p=none with an aggregate report address that can process XML reports.
- Keep stronger enforcement. If the domain already uses p=quarantine or p=reject, do not weaken it to p=none. Fix Brevo DKIM under the current policy.
- Verify public DNS. Confirm the version, policy, and rua tag parse correctly before asking Brevo to authenticate the domain.
For a new deployment without an existing enforcement policy, publish the record below as a TXT value at _dmarc.example.com and replace the reporting mailbox with one you control.
The p=none policy collects evidence without asking receivers to quarantine or reject failures. It does not protect the domain on its own. Its purpose is to expose every sending source and confirm that Brevo passes through DKIM before enforcement.
For news@mail.example.com, the direct record belongs at _dmarc.mail.example.com. If it is absent, an applicable parent policy can govern the subdomain through sp or p. Check that policy before adding p=none, which would override inherited enforcement.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator if you need to add tags without breaking syntax. Keep one rua tag in the DMARC record. For an external reporting domain, confirm it publishes the required authorization TXT record or a wildcard authorization; a valid rua address alone does not authorize third-party reporting.
Do not publish Brevo's suggested DMARC value beside your existing record. Preserve the policy and reporting recipients you already use. If you add another recipient, put comma-separated addresses in the single rua tag.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Test the visible From domain. The checker should identify the direct or inherited policy, verify that v=DMARC1 is first in the record, and parse the aggregate reporting destination.
For a saved result with parsed tags, use the DMARC checker. A syntactically valid record still needs live mail evidence, so confirm Brevo's DKIM domain in aggregate reports before enforcement.
Keep an existing enforcement policy
Do not move p=quarantine or p=reject back to p=none just because Brevo displays a starter record. Publish Brevo's DKIM records, verify signed mail, and leave the stronger policy in place.
Verify and troubleshoot
- Wait for DNS. Allow normal propagation time. Brevo states that authentication can take up to 48 hours.
- Run Brevo verification. At the bottom of the manual DNS screen, select Authenticate this email domain or Authenticate domain.
- Confirm domain status. Return to Domains and look for Authenticated beside the correct sender domain.
- Send a real test. Send through the same Brevo campaign or transactional route used in production, with the authenticated From domain.
- Read authentication results. Require DKIM pass and DMARC pass. SPF can pass but remain unaligned without a branded Return-Path.
- Fix the public record. If verification fails after 48 hours, compare public DNS with every name, type, and value in Brevo.
Brevo's Authenticated status proves that the required DNS records were found. It does not prove that every application uses the correct From address or that live mail passes DMARC. A production-path message is the final test. For SMTP or API sending, use an address on the authenticated domain in From, not the SMTP login.
When Brevo still shows Not authenticated, check the most common DNS mistakes first: an apex added twice to a hostname, only one DKIM CNAME published, a CNAME changed into TXT, a proxy enabled on the record, or a second DMARC record.
Brevo Domains page showing authenticated and unverified domain states
A green Authenticated state is the account-side target. If a domain remains unverified, reopen it, choose manual authentication, and compare the displayed DNS values against public resolution instead of repeatedly saving the same records.
DNS propagation can be uneven during the first hours. Recheck the specific authoritative values and give Brevo time to refresh. If the public values are still wrong, edit the zone that is authoritative for the domain, not a stale DNS panel.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send the Suped email tester address a message through Brevo. The report checks the actual message path, including SPF, DKIM, DMARC, visible content, and transport details. This catches application-level sender mistakes that a DNS-only test cannot see.
DKIM pass plus DMARC pass is the required outcome for unbranded shared-IP mail. SPF alignment can fail because the Return-Path remains under Brevo's infrastructure. Do not hold back DMARC enforcement for that expected condition.
Read Authentication-Results written by the receiving mail server. Compare smtp.mailfrom with header.from for SPF matching, and header.d with header.from for DKIM matching. The domains below are illustrative; SPF passes for a different domain while DKIM and DMARC pass for example.com.
Illustrative results for unbranded shared-IP mailtext
Authentication-Results: receiver.example; spf=pass smtp.mailfrom=return-path.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
|
|
|
|---|---|---|
Brevo status | Authenticated | Compare DNS |
DKIM | Pass, matching | Check selector and From domain |
SPF | Pass, unaligned | Investigate SPF failure; unaligned SPF is expected |
DMARC | Pass | Fix DKIM match |
Expected results for Brevo shared-IP mail without branding
Monitor Brevo authentication failures
- Collect DMARC reports. Route rua data into a service that parses XML and groups Brevo traffic by source.
- Set failure alerts. Notify the owner when DKIM or DMARC pass rates drop, a record disappears, or an unknown source starts sending.
- Watch the source identity. Without branding, expect Brevo infrastructure names in SPF data while requiring your domain in the DKIM signature.
- Assign each issue. Give DNS, Brevo account, and application changes an owner with a verification step.
- Review weekly. Check volume, passing sources, failures, and new senders even when no alert fires.
A one-time green status in Brevo will not detect a later selector deletion, DMARC syntax change, or application that starts using an unauthenticated From domain. Aggregate reports provide continuing evidence, but raw XML is slow to interpret and easy to ignore. Reports usually arrive daily, so report-based alerts follow receipt rather than each send.
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring groups Brevo traffic, tracks authentication failures, and provides issue alerts with remediation steps.
Periodic manual checks
- Detection. Only when someone checks.
- Evidence. Scattered DNS and headers.
- Ownership. Often informal.
- Scaling. Repeated per domain.
Suped monitoring
- Detection. Automated issue alerts.
- Evidence. Grouped DMARC sources.
- Ownership. Actionable fix steps.
- Scaling. Multi-domain and MSP views.
A useful Brevo alert distinguishes an SPF authentication failure from an expected SPF alignment failure on unbranded mail. Check DKIM matching and new sources before deciding whether DMARC is at risk.
Alert on changes and failures
Track record changes, new sources, authentication-rate drops, and policy regressions. Suped's automated issue detection turns findings from DNS checks and received reports into specific remediation tasks.
Secure your domain with p=reject
- Inventory every source. Use DMARC reports to identify Brevo and every other legitimate sender using the From domain.
- Fix Brevo DKIM first. Require stable DKIM pass and matching across campaigns, automations, and transactional routes.
- Start quarantine. After approved sources pass, publish p=quarantine without pct and monitor legitimate failures.
- Validate quarantine. Keep p=quarantine until approved mail streams pass consistently and remaining failures have been classified.
- Move to reject. Publish p=reject, keep rua reporting, and continue monitoring for new sources or DNS regressions.
Do not wait for SPF alignment on unbranded Brevo shared-IP mail. The enforcement gate is stable DKIM authentication that matches the visible From domain. Other sending sources still need their own valid DMARC path before the policy reaches reject.
Move each stage only after reports show that legitimate volume passes consistently. Review low-volume transactional streams as carefully as campaigns, because password resets and receipts can disappear in aggregate percentages.
RFC 9989 made pct historic. Remove it rather than relying on percentage sampling. For a limited pilot, use an isolated sending subdomain with its own DMARC policy; receivers still apply their local handling rules.
A controlled DMARC enforcement path
Advance only when legitimate Brevo mail and every approved source pass DMARC.
Observe
p=none
Collect reports and classify all sources.
Quarantine
p=quarantine
Confirm approved mail passes consistently.
Enforce
p=reject
Request rejection of mail that fails DMARC.
At each step, compare total legitimate volume with passing volume by source. Stop the rollout when a known sender fails. Fix its DKIM or SPF path, verify live mail, and resume after that source passes.
A final reject record should retain the aggregate reporting address so new failures remain visible. Keep one TXT record at _dmarc and continue monitoring after enforcement.
Final DMARC recordDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped helps with this rollout by grouping sources and tracking DMARC pass rates before each policy change. Its alerts remain useful after p=reject, when a DNS change has higher delivery impact.
For teams that want policy changes without repeated TXT edits, Suped's Hosted DMARC keeps the policy workflow and monitoring in one place.
The reject readiness test
Brevo mail passes DKIM with your From domain, every approved source has a working DMARC path, and remaining failures have been investigated. Review forwarding-related failures before requesting p=reject.
Brevo authentication FAQ
Older Sendinblue names still appear in Brevo message headers. They are clues for identifying traffic, not instructions to publish DNS records. Always copy the records shown in your Brevo account.
Brevo domain authentication does not require adding a Brevo SPF include to your root domain. Keep the SPF record required by your other senders. Without branding, Brevo's Return-Path does not match your From domain, so DKIM provides the DMARC pass. The newer branded setup also supports SPF matching; publish only the records your account shows.
Two CNAME selectors let Brevo rotate DKIM keys without asking you to replace a public key in DNS. Publish both records exactly as displayed. Some older accounts show one DKIM TXT record, which should remain a TXT record.
Yes. DMARC passes when either SPF or DKIM passes and matches the visible From domain. For unbranded Brevo shared-IP mail, DKIM should provide that matching result. An unaligned SPF result is expected when DKIM and DMARC pass.
Brevo states that DNS changes can take up to 48 hours to appear as authenticated. Recheck the domain during that period. After 48 hours, compare every public record with Brevo's displayed type, name, and value.
Basic Brevo domain authentication does not require changes to your mailbox MX records. Keep existing incoming-mail records. For dedicated-IP setup, publish only the additional records shown, and let Brevo manage reverse DNS (PTR) for the IP.
Edit the existing DMARC record to add your chosen aggregate reporting address. Preserve any p=quarantine or p=reject policy and existing reporting recipients. Put multiple destinations in one comma-separated rua value, and confirm DNS authorization for external reporting domains.
