Brevo WordPress email: plugin, SMTP or API?

Quick answer: For password resets, form notices, and similar messages already generated by WordPress, start by evaluating Brevo’s official WordPress plugin. Its documented connection uses an API v3 key; its transactional-email setting routes WordPress mail through Brevo SMTP. Build a direct Email API integration when a developer needs to own message construction, templates, application responses, or event handling. Sources: Brevo’s WordPress plugin guide and transactional options.

Consider one WordPress site sending password resets, account notices, form confirmations and order messages. Brevo’s setup and developer documentation, checked on October 3, 2026, provide three connection routes. Before switching any of them, confirm that transactional sending is active and your sender is verified.

Match the route to the message owner

For messages that WordPress core or an installed plugin already creates, the immediate task is delivery. Brevo’s official WordPress plugin can route those messages without requiring a developer to rebuild their bodies or triggers. A custom application may instead need to select a template, supply recipient-specific data and handle events in its own code.

Use the credential for the selected row. If the official plugin rejects its account key, check that the API v3 key is complete and active; an SMTP key or older API key will not substitute for it. The setup requirements and troubleshooting steps appear in Brevo’s plugin guide and the WordPress.org listing.

The From address is separate from authentication. It identifies the sender the recipient sees, and Brevo requires the relevant sender or domain verification. The SMTP login is not that address. Check the visible sender as well as the credential when following the SMTP troubleshooting guide or Email API instructions.

Keep an internal record of which integration uses each credential, without copying the secret into the record. Brevo’s SMTP-key guide warns that deleting a key can stop applications still using it. That matters when a WordPress site shares an account with another application: retiring one connection should not silently disable the other.

Check account readiness before switching critical mail

Brevo’s documentation notes that transactional service on a new account may need activation or a support request. This is an account-specific state, so a complete API v3 key does not establish that sending is enabled. The plugin setup guide and SMTP troubleshooting guide are the current references. Confirm the account’s status, sender verification, and available email credits before moving password resets or order mail.

The official plugin also describes one-way contact sync from WordPress to Brevo and a manual initial sync. That is a separate feature from routing operational mail. If the immediate goal is to send a password reset, avoid using a contact-sync screen as evidence that the transactional route is configured. Conversely, do not assume mail routing automatically produces the contact-list sync you want. Review each feature on its own terms. Source: Brevo plugin guide.

Another source of confusion is an existing SMTP plugin. Brevo’s plugin guide warns that third-party SMTP plugins can conflict with its own route. Before changing the live site’s mail path, inventory the plugins and custom code that currently intercept WordPress mail. The goal is one deliberate route for each operational message, with a known way to restore the previous configuration if the change fails.

A controlled migration for ordinary WordPress mail

Begin with a written list of the messages the site relies on: account creation, password reset, form notification or confirmation, comment notice, and order event if the site’s commerce plugin sends one. Note which WordPress component constructs each message, where it is supposed to go, and which sender address it uses. That inventory keeps a successful test of one form email from being mistaken for proof that all operational mail paths work.

1. Record the present route. Note the active mail plugin, any custom mail hook, current sender identity, and a rollback path. Keep existing credentials protected; do not paste keys into documentation or screenshots.
2. Prepare Brevo. Confirm that the account’s transactional service is active, that the intended sender or domain is verified, and that the current account has credits for the expected workload. Brevo publishes these as distinct setup and failure checks. Sources: plugin guide and SMTP troubleshooting.
3. Connect the official plugin. Use the active API v3 key requested by its current instructions, then confirm the plugin recognizes the account. Enable its transactional-email route and select the intended sender according to the live plugin flow. Source: Brevo plugin guide.
4. Avoid competing routes. Review other SMTP plugins or custom mail hooks before the change. If one remains necessary for a separate workload, make the ownership of each message explicit rather than leaving two integrations to compete for the same WordPress mail.
5. Trigger representative messages. Use a safe recipient and exercise the real password-reset, form, and order or notification paths that matter to the site. Compare the WordPress action, Brevo’s available sending information, and the recipient’s result.
6. Keep a rollback decision. If a critical path fails, return that path to its previously documented route while investigating. Changing routes without knowing how to restore them can turn a recoverable configuration issue into missed account mail.

The sequence emphasizes message types, not a single “test email” button. A plugin-generated notification can differ from a password-reset message in sender, content, or trigger. Testing the events users actually need is the only way this site-specific migration can support a practical go-live decision.

Assign an owner for API failures and events

A direct Email API integration needs a developer to decide what happens after the initial request. Keep the returned message ID with the application’s record of the event that caused the email. If a customer asks about a missing notice, that association gives support a way to trace the correct send rather than searching only by address.

Plan for three different failures: the application never attempted a request, Brevo rejected the request, or Brevo accepted it and a later delivery event needs attention. Each requires a different response. Repeatedly retrying a request with invalid sender details will not fix the sender; repeating an already accepted business event may send a duplicate message. Define who can investigate and replay failed work, and keep sensitive content and credentials out of routine logs.

Brevo’s transactional overview describes event webhooks. If the application uses them, specify which events it needs, which record they update and how that update affects the user’s next action. For example, an operations dashboard might need a failed-delivery state that prompts staff to verify an address. Merely collecting webhook events without an action or an owner adds maintenance without resolving the missing-mail problem.

Write these responsibilities down before choosing a custom integration. Include credential rotation, changes to templates, monitoring of failures and a handover route if the original developer leaves. For a site whose existing WordPress messages already meet its needs, this additional work may be unnecessary.

Diagnose the failed step, not just the missing email

If a message does not arrive, work through the route in order. Did WordPress produce the intended message? Is the official plugin connected with a valid API v3 key? Is transactional sending active? Is the selected From sender verified? Is another SMTP plugin intercepting mail? Does the Brevo account show a queued, blocked, or rejected event? Brevo’s SMTP troubleshooting guide describes several possible failure areas, including account activation, blocked contacts and provider rejection. It also says exhausted email credits can queue messages. A queued message is a different problem from a WordPress trigger that never fired.

For a direct API integration, the developer can also retain the returned message ID and correlate it with later event information where that workflow is implemented. For the plugin path, use the reporting and troubleshooting information available to the account rather than assuming that a missing inbox message identifies the exact failure point. A successful request still needs to be followed through to the recipient or the relevant delivery event.

Use the official plugin for existing WordPress messages, and choose a custom API integration when the application’s message or event requirements justify a developer maintaining it. For campaign sending and other decisions, see the email software hub.