Practical tools for system, network, security, and operations administrators.

SEC-C0737 · Email Provider Authentication Guides

Brevo Email Authentication Guide

Authenticate a Brevo sending domain, formerly Sendinblue, using the records the console shows.

Updated 25 October 2026 · Pillar guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

SPF, DKIM, and DMARC for Brevo

Brevo sends mail for a domain you administer. SPF names the servers allowed to send. DKIM signs with a key whose public half you publish in DNS. DMARC tells receivers what to do when those checks fail, and where to send reports. Brevo, formerly Sendinblue, shows the domain authentication records in its console. Copy those. An old Sendinblue screenshot is not a source if the console now shows different hosts. You copy every value from the console you already operate. You do not invent an include, and you do not type a record from memory.

This page does not teach you to spoof a domain or to bypass DMARC. The domain in the ticket is yours. example.com is documentation. The email security guide is the meaning of the three records. The certificate guide is the habit of keeping a private key out of DNS and out of the ticket. The network desk owns how a DNS change is published.

The generators on this site draft an SPF line, a DKIM setup note, and a DMARC alignment check. They run in the browser. They do not log into Brevo. A draft that adds a second SPF record is a draft you refuse. One TXT that starts with v=spf1 is the rule.

DMARC starts at p=none with a rua mailbox a person will open. p=quarantine and p=reject are later, after a report shows only senders you recognise. A reject policy on the day you add Brevo is how you lose mail from the sender you forgot.

A lab domain, then the real From domain

In the lab, use a domain you can break. Open the Brevo console and find the authentication page for the sending domain. Copy the SPF fragment and the DKIM host and value it shows. Paste them into the draft only after they match the screen. If the console shows nothing, you are not ready to publish.

Publish on the lab domain. Send one message to a mailbox you can read. Read the authentication results you are allowed to see. SPF, DKIM, and the From domain are the three lines in the ticket. A failure is the result. You do not add a second include to hide it.

Point DMARC at p=none and a rua address that arrives somewhere you check. Leave it there through the interval you wrote down. Unknown sources go back to the console question: is this Brevo, or is it another sender the email guide told you to list.

Authenticate the domain you send campaigns from. A test campaign to yourself is the message you read headers on. Code that sends through the SMTP relay is the same domain, or it is a second ticket.

# Brevo lab. Review before you publish DNS.
# Copy from the console. Do not invent an include.
# One SPF record. A second v=spf1 TXT is a mistake.
# DKIM private key stays at the sender. Never in DNS. Never in the ticket.
# DMARC p=none until a report is read.
# example.com is not your production domain.
# prompt-for-this is not a token.

A change you can finish

Production is the real From domain, the values copied from Brevo, and p=none. Other senders already on that domain stay in the one SPF record. You do not replace the whole record with only this vendor unless the email guide's sender list says you are the only sender.

Rollback is the previous TXT records, saved before the publish. You can put them back. You practised that path on the lab domain.

  1. Confirm you administer both the Brevo account and the DNS domain.
  2. Copy SPF and DKIM from the console. Do not type them from memory.
  3. Merge into the single existing SPF record. Do not add a second one.
  4. Publish DKIM exactly as the console shows, public key only.
  5. Publish DMARC at p=none with a rua mailbox you will read.
  6. Send one message and read the results.
  7. Do not move to p=reject in this window.

Mistakes that outlive the command

Brevo email authentication fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Decisions to write down before the window

One decision for Brevo email authentication: The From domain is the one in the ticket, and you control its DNS. Every current sender, including Brevo, is on one list. SPF values were copied from the console in this window, not from memory. There is exactly one SPF record after the change. DKIM is the selector the console showed, and the private key is absent from the ticket. DMARC is p=none. The rua mailbox has an owner. A test message's results are written down. The previous DNS is the rollback. p=quarantine or p=reject is a later ticket with a report attached. The email guide remains the policy. This page is the vendor console. And no spoofing and no bypass steps are in the notes.

The hour you stop

Write the hostname or the system name, the owner, and the clock time before you change anything for Brevo email authentication. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.

A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.

Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.

Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next system waits until someone else can repeat the proof from the notes. Brevo email authentication is done for this window when the proof is written, not when the tool printed a file.

This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.

Brevo checks before mail is called authenticated

Confirm this before you call the change done: The console and the DNS zone are both yours. The copied SPF fragment matches the screen. A second SPF record was not created. Existing senders are still represented. DKIM public DNS matches the console. No private key is in DNS or the ticket. DMARC policy is none. The rua address received a test or is monitored. The hostname in the prompt matches the hostname in the ticket for Brevo email authentication. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for Brevo email authentication happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.