Deauthorize marketing vendor
How to remove Brevo (Sendinblue)from your domain's SPF and DKIM
Brevo (formerly Sendinblue) publishes authentication via an SPF include + a DKIM TXT + an optional dedicated-IP block + a click-tracking subdomain. Brevo also runs a separate transactional product (formerly SendinBlue SMTP, now Brevo Transactional Email) that uses the same authentication tree, so removing the records deauthorises BOTH the marketing campaigns and the transactional path. Important to know before flipping DNS.
When you'd want to do this
- Acquired or rebranded from Sendinblue and the legacy DNS records were never cleaned up after the move to Brevo.
- Migrated to a different marketing platform (Mailchimp, Klaviyo, HubSpot) and never removed the Brevo authorisation.
- Used Brevo for a one-off campaign or product trial; never went into production but the DNS stayed.
- Consolidating per-vendor compromise surface as part of a vendor-consolidation audit.
What Brevo (Sendinblue) adds to your DNS
You need to remove every record below for the de-authorization to be complete. Removing only the SPF include: but leaving DKIM keys published is still a partial authorization - the vendor can sign mail as your domain even without SPF alignment if the recipient has a permissive DMARC policy.
| Type | Host | Look for |
|---|---|---|
| TXT | apex (example.com) | include:spf.brevo.com The SPF include. Older Sendinblue setups may have include:spf.sendinblue.com instead - check both. Remove just this token; leave the rest of the v=spf1 record alone. |
| TXT | mail._domainkey.example.com | v=DKIM1; k=rsa; p=... Brevo publishes DKIM as a raw TXT (not a CNAME). The selector is typically "mail" but historical accounts may use "brevo" or "sib". Delete the whole TXT record. |
| CNAME | em.example.com (or mail.example.com) | shared-?.brevo.com (or shared.sendinblue.com) Optional - only present if you set up a custom sender subdomain in Brevo. The CNAME routes outbound through the Brevo MTA. Mail keeps working without this on shared IPs, but you should remove it - leftover routing into a vendor with no active account is a compromise surface. |
| TXT | apex (example.com) | brevo-code:<account-token> Domain-ownership verification TXT, published once during onboarding. Delete it. Cosmetic but worth removing - it identifies the apex as having had a Brevo account at some point. |
| CNAME | r.example.com or click.example.com | tracking.brevo.com Click-tracking subdomain. Used to rewrite outbound links so Brevo can record click-throughs. Remove it last - removing it earlier breaks click attribution in any campaign Brevo is still queuing. |
Step-by-step
- Stop sending through Brevo (Sendinblue) first. Check every app, webhook, and automation that hits the vendor's API or SMTP. Pause those before touching DNS - if you flip the DNS first you'll just spend a week chasing bounces from a vendor that's still wired up on your application side.
- Remove the DKIM record(s) at the hosts listed above. Removing DKIM first means any mail still queued from Brevo (Sendinblue) fails alignment, which is the safer failure mode - the receiver quarantines or rejects rather than silently delivering signed-as-you mail from a vendor you no longer control.
- Remove the SPF include. Open your SPF TXT record at the apex. Look for the exact
include:entry shown above. Remove the entire token (including theinclude:prefix). Leave the rest of the record untouched. Verify the byte-count of the record is now under 450. - Remove the CNAMEs, if any. CNAMEs for tracking domains and return-paths are dead weight once the vendor is gone; some DNS UIs surface them as "orphan records" later if you forget.
- Wait for propagation. 1-4 hours for most providers. The old SPF entry stays cached at receivers for the TTL you published (often 5 min - 1 hour).
Verify it's gone
Run a vendor-consolidation report on your domain. Brevo (Sendinblue)should be gone from the vendor list. If it's still showing under SPF or DKIM, the DNS edit either didn't save or hasn't propagated yet - re-check in 30 minutes.
You can also do a manual spot-check with dig TXT example.com (replace with your domain). The output should no longer show the Brevo (Sendinblue) include.
What you'll lose
Both Brevo Marketing campaigns and Brevo Transactional emails (the SMTP relay product) will start failing DMARC alignment after the DNS records are gone. Gmail / Yahoo enforce DMARC strictly for bulk senders; those messages will quarantine or reject.
The Brevo account itself stays open and you can re-publish the DNS later if you change your mind. Cancel the subscription separately in Brevo billing if you do not plan to return.
Common gotchas
Transactional path uses the same auth tree. Removing the DNS deauthorises BOTH the marketing campaigns and any password-reset / order-confirmation / receipt mail going through Brevo Transactional. Search your codebase for smtp-relay.brevo.com, smtp-relay.sendinblue.com, and any BREVO_API_KEY / SENDINBLUE_API_KEY references before flipping DNS.
Sendinblue records may still be in place. Brevo rebranded from Sendinblue in 2023; many accounts still have legacy spf.sendinblue.com includes that need to come out as well as the newer Brevo variants. Check your SPF for both.
Dedicated IP accounts have an extra block. If you bought a dedicated IP with Brevo, there is an additional ip4: entry in your SPF pointing at the leased IP. That goes once the dedicated IP returns to the Brevo pool.
Just want to rotate keys instead?
If you're keeping Brevo (Sendinblue) but want to rotate credentials (a stronger move than just changing the API key - it forces all old DKIM signatures invalid), do it from the vendor side first: Brevo (Sendinblue) console →
While you're here: audit the rest
The median domain we've analyzed has 6 vendors authorized in DNS and 3 of them can send mail as you. If you just removed one, see who else is on the list.
Run a vendor-consolidation report →