Brevo SMTP：設定、パラメーター、トラブルシューティングのガイド

Brevo SMTP は、アプリケーションの送信メールをウェブホストのローカルなメール配送エージェントから切り離し、すべてのメッセージを認証し、記録し、レポートする基盤へ移します。設定はごく小さなものです。ホスト名 1 つ、ポート 1 つ、資格情報 2 つ。間違え方もまた小さく、そして失敗は静かに起こります。このガイドでは、設定値、資格情報のモデル、配信を成立させる DNS の作業、そしてどこかが誤っているときに遭遇するエラーを扱います。まだプロバイダーを選んでいる段階なら、まず市場全体を比較したSMTP メールサービスのガイドをご覧ください。

Brevo SMTP とは

Brevo は Brevo SMTP を自社の SMTP リレーサービスと位置づけています。アプリケーション、ウェブサイト、あるいはメールサーバーが認証済みの接続でメッセージをリレーに渡すと、Brevo が経路制御、再試行、レピュテーション、レポートを引き受けます。リレーしたメールの統計はキャンペーンの統計と並んで表示され、ハードバウンスが発生するとそのコンタクトは自動的にブロックリストへ入ります。

このリレーはトランザクションのメッセージ向けに作られています。パスワードの再設定、領収書、注文確認、アカウントの通知などです。マーケティングメールとの線引きがまだ曖昧であれば、トランザクションメールとは何かが扱っています。

SMTP か REST API か

どちらの経路も同じプラットフォームに届きます。実務的な使い分けはこうです。

明確な制限が 1 つあります。Brevo の開発者向けドキュメントは、SMTP リレーがバッチ送信に対応していないと明記し、バッチ処理は API のエンドポイントへ誘導しています。

SMTP の資格情報を作る

Brevo の SMTP 認証には、すでに手元にある資格情報と取り違えやすい 2 つの値を使います。

SMTP ログインを見つける

SMTP ログインは Brevo アカウントのメールアドレスではありません。Settings の SMTP and API ページの Login 欄に表示される独立した識別子で、形式は [email protected] です。

ここから 2 つのルールが導かれます。いずれも Brevo のトラブルシューティング文書に基づくものです。ユーザー名の欄に smtp-relay.brevo.com を入れないこと。これはリレーのホストであって、あなたのログインではありません。そして SMTP ログインを From ヘッダーに入れないこと。これはあなたを認証するもので、送信者を示すものではないからです。

SMTP キーを生成する

パスワードにあたるのは SMTP キーです。アカウントのパスワードでも API キーでもありません。

1. アカウントのドロップダウンを開き、Settings、続いて SMTP and API を選びます。
2. SMTP タブで Generate a new SMTP key をクリックします。
3. そのキーを使う連携の名前を付けます。
4. 種類を選びます。Standard は推奨される 64 文字のキー、Short は長いパスワードを扱えないクライアント向けの 15 文字のキーです。
5. 有効期限を 7 日から 1 年の範囲で設定するか、無期限を選びます。
6. Generate をクリックし、すぐにキー全体をコピーします。

キーの全体が表示されるのは一度だけで、その後は末尾の数文字しか表示されません。紛失した場合は代わりを生成し、設定を更新してください。

接続の設定値

クライアントやライブラリに入力する値は次のとおりです。

ポートの選び方

Brevo は既定として 587 を推奨しています。ポート 465 はかつて SMTP over SSL 用に割り当てられ、その後は非推奨とされましたが、いまも広く対応されており、最初のコマンドの前に接続を暗号化する必要がある場合には正しい選択です。ポート 2525 は IETF や IANA に登録されたポートではありませんが、大半の ISP とクラウド事業者が許可しているため、587 が塞がれているときの逃げ道になります。

暗号化の欄は多くの人がつまずくところです。Brevo は 465 を使う場合を除いて空欄のままにするよう案内しています。これは接続が暗号化されないという意味ではありません。587 と 2525 ではサーバーが STARTTLS を告知し、まともなクライアントは認証の前に接続を昇格させます。この案内が意味するのは、587 に接続しながら「SSL」を選んではいけないということです。ポートと暗号化が食い違うと、資格情報が正しくても認証は失敗します。

コードを書く前に接続を試す

アプリケーションのコードをデバッグする前に、リレーが応答し TLS がネゴシエートできることを確認しましょう。

openssl s_client -starttls smtp -crlf -connect smtp-relay.brevo.com:587

ハンドシェイクが成功すると、サーバーの 250 の機能一覧で終わります。そこには STARTTLS と、PLAIN と LOGIN を列挙した AUTH の行が含まれるはずです。バナーがまったく返らない場合は、資格情報ではなくネットワークの問題です。

送信ドメインを認証する

これは飛ばされがちな手順ですが、メールが届くかどうかを決めるのはここです。2024 年 2 月 1 日以降、Gmail と Yahoo の送信者要件のもとでドメイン認証は必須になっており、Brevo は Microsoft も 2025 年 5 月 5 日に同様の基準を発表したと記載しています。認証されていないメールは、どのリレーから送っても選別されるか拒否されます。

Brevo が求めるレコード

Brevo の画面からドメイン事業者にログインすればこれらを自動で追加できますし、値を自分の DNS ゾーンへ手で書き写すこともできます。DKIM がどちらの形式になるかはアカウントによります。CNAME 2 件の形式は既定で 2048 ビット鍵、TXT 1 件の形式は 1024 ビット鍵です。

SPF レコードがない理由

Brevo の FAQ は明確です。ドメインの認証に SPF と MX のレコードは必要なく、これらが提供されるのは専用 IP を設定する場合だけです。共有インフラでは Brevo がリターンパスを管理しているため、DKIM と所有権の確認が認証を担います。SPF の include を要求するプロバイダーから移行してくる場合でも、勝手に include を作らないでください。不要な include は参照回数の上限の問題を招くだけです。

DMARC は依然として重要で、Brevo は動作する出発点となるレコードを公開しています。

v=DMARC1; p=none; rua=mailto:[email protected]

まずは p=none で始めて配信に影響を与えずに集計レポートを受け取り、正規の送信元がすべて整合したら quarantine、reject へと締めていきます。その進め方はメール到達性ガイドで扱っています。

送信者を検証する

すべての From アドレスは、検証済みの送信者であるか、認証済みドメイン上にある必要があります。新しい送信者はそのアドレス宛に送られる 6 桁のコードで検証しますが、認証済みドメイン上の送信者はこの手順を省けます。だからこそ、先にドメインを認証するのです。無料のメールドメインは認証できないため、gmail.com や outlook.com の From アドレスは拒否されるか選別されます。

連携の手順

WordPress

WordPress は送信メールを wp_mail に渡し、それはホスト側が提供するものを呼び出します。これを Brevo 経由にするにはプラグインが必要です。

1. 管理画面のサイドバーで Plugins、続いて Add New Plugin に進みます。
2. Brevo を検索し、「Newsletter, SMTP, Email marketing and Subscribe forms by Brevo」をインストールして有効化します。
3. Brevo、続いて Home に進み、有効化の欄に Brevo API key v3 を入力します。この手順で API キーを使うのは、プラグインがコンタクトの同期も行うためです。Login をクリックします。
4. Transactional emails で Yes を選びます。
5. 既存の送信者を選ぶか、新しく作成します。WordPress からのすべてのメールがその送信者名とアドレスを使います。
6. アドレスを入力し、Send email をクリックしてテストを送ります。

よくあるエラーが 2 つあります。Brevo SMTP アカウントが有効化されていないためトランザクションメールが有効になっていない、というメッセージが出た場合は、Brevo のサポートにプラットフォームを有効化してもらう必要があります。別のプロセスが wp_mail を宣言しているため SMTP が使えない、というメッセージが出た場合は、競合する SMTP プラグインがあります。他のプラグインを 1 つずつ無効化してください。

サーバー側のアプリケーション

Brevo 自身の Node.js の例は nodemailer と上記の設定値を使います。

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp-relay.brevo.com",
  port: 587,
  secure: false, // 465 では true、それ以外のポートでは false
  auth: {
    user: process.env.BREVO_SMTP_LOGIN, // [email protected]
    pass: process.env.BREVO_SMTP_KEY,
  },
});

async function sendOrderConfirmation() {
  const info = await transporter.sendMail({
    from: '"Acme Support" <[email protected]>',
    to: "[email protected]",
    subject: "Your order is confirmed",
    text: "Order 10482 is confirmed and ships within two business days.",
  });
  console.log("Message sent:", info.messageId);
}

sendOrderConfirmation().catch(console.error);

ポート 587 での secure: false に注目してください。このフラグが制御するのは暗黙的な TLS であって、接続が暗号化されるかどうかではありません。nodemailer はそれでも STARTTLS を発行します。true にするのは 465 の場合だけです。

標準ライブラリを使った Python の同等の例です。

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "Acme Support <[email protected]>"
msg["To"] = "[email protected]"
msg["Subject"] = "Your order is confirmed"
msg.set_content("Order 10482 is confirmed and ships within two business days.")

with smtplib.SMTP("smtp-relay.brevo.com", 587, timeout=20) as server:
    server.starttls(context=ssl.create_default_context())
    server.login(BREVO_SMTP_LOGIN, BREVO_SMTP_KEY)
    server.send_message(msg)

どちらも資格情報を環境変数から読み込んでいます。それが次の節の話です。

キーのセキュリティとローテーション

Brevo は SMTP キーをパスワードとして扱います。運用上のルールは文字どおりに守る価値があります。

• 連携ごとに 1 つのキー。 キーごとに、それを使うシステムの名前を付けてください。漏えいや廃止のときに、失効させる対象がちょうど 1 つで済みます。
• キーをコミットしない。 環境変数、シークレット管理サービス、プラットフォームの設定ストアに置きます。ソース管理も、追跡対象の .env ファイルも、スクリーンショットも不可です。
• 無停止でローテーションする。 代わりのキーを生成し、デプロイし、送信できることを確認してから、古いキーを削除します。削除は取り消せず、使用中のキーを消すとトランザクションの送信が即座に止まります。
• 一時停止には削除ではなく無効化を。 キーは後から再有効化できます。
• 有効期限を織り込む。 キーには 7 日から 1 年の有効期限を設定でき、Brevo は 90 日間使われていないキーを失効させます。

より強い境界が必要なら、Brevo は未知の IP アドレスからのリクエストを遮断できます。許可リストは API キーと SMTP キーで共有されるため、許可した内容は両方に適用されます。コンテナやクラウドのワークロードでは注意してください。外向きのアドレスは、想定しているインスタンスの IP ではなく NAT ゲートウェイである場合があり、間違えると 525 5.7.1 Unauthorized IP address の拒否が返ります。

ストアフロント、CRM、サポートデスクと並べて Brevo を運用するチームは、いくつものキー、送信者、ドメインを同時に管理することになります。Tajo は、その設定を 4 つのダッシュボードではなく 1 か所にまとめます。

送信の上限とスロットリング

SMTP の送信はプランのメールクレジットを消費します。Free プランでは 1 日 300 通で、上限は毎日リセットされ、使い切らなかったぶんは繰り越されません。上限に達すると、Brevo はさらに最大 1,000 通を再試行のキューに保持し、それを超えたぶんは配信しません。有料プランでは 1 日の上限がなくなります。各階層の内訳はBrevo 料金ガイドで扱っています。

クレジットを完全に使い切ると、SMTP で投入されたメッセージは破棄ではなく一時停止されてキューに入ります。滞留したぶんは Transactional、Real time、Usage and plan と進んだ Email queue のセクションで確認できます。

Brevo が明示的なレート制限を公開しているのは、リレーではなく REST API のほうです。一般階層では POST /v3/smtp/email が毎秒 1,000 リクエストまでで、上限を超えると 429 Too Many Requests が返ります。API の経路では速度調整に使えるレート制限ヘッダーも返りますが、リレーにはそれがありません。

バウンスと苦情を監視する

リレーしたメールは Transactional の Statistics と Logs のページで確認できます。対応が必要なイベントは次のとおりです。

• ハードバウンス。 アドレスが無効で、Brevo はそのコンタクトを自動的にブロックリストへ入れます。
• ブロック。 その受信者は以前に苦情を出した、配信停止した、ハードバウンスした、または手動でブロックされています。
• 遅延とソフトバウンス。 受信側は接続を受け入れたものの、メッセージを保留または拒否しました。特定のプロバイダーに対して遅延が繰り返される場合は、コードではなくレピュテーションの問題を示しています。

ログのポーリングは規模に耐えません。Brevo は配信、バウンス、開封、苦情のイベントをリアルタイムでエンドポイントへ送るトランザクションの Webhook に対応しており、自社の配信抑止データを最新に保つにはこれを使います。

注視すべき数字はスパム申告率です。Gmail、Yahoo、Microsoft は送信者に 0.3% 未満を維持するよう求めており、Brevo は Gmail Postmaster Tools での監視を推奨しています。しきい値を超えてから回復するには、超えないようにするよりはるかに長い時間がかかります。

トラブルシューティング

535 5.7.8 Authentication failed

ユーザー名かパスワードを検証できませんでした。可能性の高い順に挙げます。

• [email protected] 形式の SMTP ログインではなく、アカウントのメールアドレスを使っている。
• ユーザー名の欄に smtp-relay.brevo.com を貼り付けている。Brevo はこれを最も多い原因の 1 つとして挙げています。
• SMTP キーではなく API キーを使っている。
• コピーと貼り付けの際に、キーの末尾へスペースや改行が入り込んでいる。
• 暗号化の設定がポートと合っていない。
• セキュリティ警告の後にキーが無効化された。この場合は新しいキーを生成します。

525 5.7.1 Unauthorized IP address

IP のブロックが有効で、接続元のアドレスが許可されていません。許可リストに追加してください。アプリケーションが NAT の後ろやコンテナ基盤で動いている場合は、まず実際の外向きアドレスを確認しましょう。

応答もバナーもない

TCP 接続は確立するのにサーバーが 220 の挨拶を返さない場合、認証は始まりません。障害はネットワークのあなた側にあります。企業のファイアウォールは、接続を許可しておきながら SMTP のトラフィックを黙って落とすことがあります。AWS、Azure、Google Cloud は新規アカウントの外向き SMTP を既定で制限しています。制限の解除を申請するか、ポート 2525 に切り替えてください。

450、プラットフォームが有効化されていない

SMTP アカウントがまだ有効化されていない、または送信プラットフォームが現在無効化されている、というエラーです。新規アカウントでは、トランザクション送信に Brevo サポートによる別途の有効化が必要です。運用中のアカウントでは、たいてい停止措置を意味します。保護されていないフォームがボットの登録を浴びたか、アカウントに侵害の兆候が見られたかのどちらかです。

送信者が拒否される

3 点を確認してください。ドメインが認証されていること、送信者が検証済みであること、そして From ヘッダーが SMTP ログインになっていないことです。

受理されるが迷惑メールに入る

この順序で進めます。送信ドメインが認証され DKIM が署名していることを確認します。From のドメインが無料のメールプロバイダーではなく自社のものであることを確認します。Postmaster Tools で苦情率を 0.3% のしきい値と照らして確認します。内容を見るのは、これらの確認が済んでからです。内容が最初の原因であることは、まずありません。

専用 IP

専用 IP が役立つのは、高く安定した送信量がある場合だけです。意味のある量を送る前にウォームアップが必要で、ヘッダーの mailed by とリターンパスのドメインとして現れる送信用サブドメインも必要になります。Brevo が SPF と MX のレコードを提供するのは、この構成だけです。そのサブドメイン向けの A、CNAME、DKIM、DMARC のレコードも併せて提供されます。

見落としがちな点が 2 つあります。マーケティングメール専用に設定した専用 IP は、トランザクションのメッセージを送信せずキューに積みます。設定を切り替えるか、2 本目の IP を購入してください。そして、トランザクションとマーケティングの経路を分けるには、送信者を分けた最低 2 本の IP プールが必要です。そうすればマーケティングメールの反応の弱さが、領収書やパスワード再設定の足を引っ張ることはありません。

一度で正しく設定するために

ドメインを認証し、名前を付けた SMTP キーを作り、smtp-relay.brevo.com の 587 に接続し、ダッシュボードのボタンではなく実際のコード経路からテストを送ってください。後から起きる問題のほとんどは、次の 3 つのいずれかに行き着きます。

• ユーザー名かパスワードの欄に入れた資格情報が間違っている。
• ポートと暗号化の設定が互いに食い違っている。
• 送信ドメインが一度も認証されていない。

ここを正しくすれば、リレーは背景に溶けて意識されなくなります。トランザクションの基盤とは、本来そうあるべきものです。