自社ドメインからのメール送信
ボットは、あなた自身の ドメインのアドレス（たとえば noreply@example.com）から顧客へメールを送れます。ただし、実際に送信するのは当社のサーバーです。そのため最初の送信前に、ドメインの DNS へ 3 つのレコードを一度だけ追加する必要があります。以下では、なぜ必要か、何を追加するか、その後どうなるかを説明します。
DNS レコードがないとメールが届かない理由
受信側 — Gmail、Outlook、あるいは顧客のメールサーバー — の視点で見てください。あなたのドメインから来たと 主張する メールが、そのドメインに属さないサーバーから届きます。これは偽装とまったく同じ見え方です。フィッシングはこの形で行われます。
受信側が両者を見分ける方法は 1 つしかありません。ドメイン自身に「この送信者は本当にあなたの代理として動いているか」と尋ねることです。その答えを、あなたはドメインの DNS に公開します。DNS はあなただけが管理できる唯一の場所であり、だからこそ受信側が信頼する唯一の場所です。
その答えがない限り、まっとうなメールサーバーはそのメールを疑わしいものとして扱わざるを得ません。よくて迷惑メールフォルダー、悪ければ拒否され、受信者はメールの存在すら知りません。
つまり以下の 3 つのレコードは、形式でも画面上のチェックボックスでもありません。それ自体が あなたの許可 です。
3 つのレコードとそれぞれの役割
DKIM — 本物であることを証明する署名
DKIM は送信するすべてのメールに付く暗号署名です。プラットフォームがドメイン用の鍵ペアを生成し、秘密鍵は当社側に残ってメールに署名し、公開鍵をあなたが DNS に公開します。受信側はあなたの DNS から公開鍵を取り、署名を検証します。一致すれば、そのメールは秘密鍵を持つ者が送ったものであり、途中で本文が改ざんされていないことになります。
DKIM がないと: 署名を検証する手段がありません。メールは署名なし・信用なしに見え、他のどの設定でも埋め合わせできません。3 つの中で DKIM が最も重要です。
SPF — あなたの名前で送信してよいサーバーの一覧
SPF は別の問いに答えます。「このドメインのメールはそもそもどのサーバーから来てよいのか」です。送信元の一覧であり、ホスティングのメールサーバー、すでに利用中の配信サービス、そしてボットが送信できるよう当社の送信サーバーが含まれます。
SPF がないと: メールはドメインが「知らない」サーバーから届きます。フィルターにとっては典型的な偽装の兆候で、他の疑わしさに上乗せされます。
DMARC — 検証に失敗したとき受信側がどうするか
DKIM と SPF は「本物かどうか」に答えます。DMARC はその次の問い、本物でなかったらどうするか に答えます。何もせずレポートだけ送る、迷惑メールに入れる、拒否する — 受信側へのあなたの指示です。同時に DMARC は、あなたの名前で送られたメールに関する集計レポート（第三者による偽装の試みを含む）の送付先アドレスでもあります。
最初は最も緩い「レポートのみ」から始めてください。厳格化は、正規の送信者すべて（経理、CRM、ニュースレター、このボット）が検証を通ることを確認してからです。早すぎる厳格な設定は、あなた自身のメールを削り始めます。
DMARC がないと: 受信側ごとに判断がばらばらになり、あなたの名前のメールに何が起きているか把握できません。
追加するレコード
まず管理画面でドメインを登録します。Email セクション → 「Sending domains」 → 「Add domain」 ボタン。ダイアログの入力欄は 3 つです。ドメイン そのもの（例: shop.example.com）、アドレスの ローカル部（@ より前、通常は noreply）、そして受信者にアドレスの代わりに表示される 送信者名。保存すると DNS レコードが画面に現れます。
3 つとも、ドメインの DNS の TXT レコードです。ドメインを管理している場所（レジストラの管理画面、または DNS プロバイダー）で追加します。
以下の値は example.com を例にしています。ご自身のドメインに置き換えてください。ドメインごとの正確な値は管理画面のドメインカードに表示されるので、そこからコピーしてください。 とくに DKIM は、値にあなた自身の公開鍵が含まれ、ドメインごとに異なるため、ドキュメントから取ることはできません。
画面上では各レコードが 「Host」 と 「Value」 の 2 つの欄に分かれており、それぞれに 「Copy」 ボタンが付いています。DNS プロバイダーの対応する欄へ 1 つずつコピーしてください。2 つの部分をひとまとめに貼り付けることはできません。
| 種別 | レコード名（host） | 値 |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= に続けて管理画面の長い鍵 |
| TXT | example.com（ドメインのルート） | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
つまずきやすい点が 2 つあります。
- 多くの管理画面はレコード名にドメインを自動で付け足します。名前欄にすでに「.example.com」と表示されているなら、フルネームではなく
mybot._domainkeyだけを入力してください。そうしないとmybot._domainkey.example.com.example.comになります。 - DKIM の値は長く、鍵の内部に改行や空白が入ってはいけません。マウスでの選択ではなくコピーボタンを使ってください。
すでに SPF レコードがある場合
SPF レコードはドメインに 1 つだけ です。ホスティングや CRM、別のニュースレターサービスで既にメールを送っているなら、そのレコードは存在します。2 つ目を追加せず、既存のレコードの末尾の ~all の前に include を書き足してください。
v=spf1 include:spf.your-provider.jp include:esp.getmybot.dev ~all
1 つのドメインに SPF レコードが 2 つある状態は、1 つもないのと同じ誤りです。受信側がどちらを信じてよいか分からず、検証は通りません。
注意: 他社のレコード経由で「カバーされている」状態では不十分です。現在のプロバイダーが自社の SPF に当社を含めていても、当社の include はあなたのレコードに直接入っている必要があります。理由は後述の「ドメイン確認」を参照してください。
SPF に IP アドレスではなく include を使う理由
もっとも多い誤りは、メールヘッダーやフォーラムで見かけた IP アドレスを貼り付けることです。それはしないでください。
include:esp.getmybot.dev は、当社が保守する送信サーバー一覧への参照です。現在この名前が指すのは中継サーバー 1 台です。将来は台数が増えたり、移転したり、入れ替わったりします。そのとき当社側で一覧を更新すれば、あなたのレコードは何も触らずに動き続けます。要点はここにあります。アドレスは 1 か所で変わり、各顧客の DNS では変わりません。
手書きの IP アドレスは、その瞬間に事実と合わなくなります。メールは何の予告もなく SPF に失敗し始めます。管理画面にエラーも通知も出ません。気づくのは「何も届いていない」と言う顧客からです。
include:esp.getmybot.dev とだけ書き、それ以上は付け足さないでください。
ドメイン確認
ドメイン確認 とは、プラットフォームが自らあなたのドメインの DNS を参照し、3 つのレコードが揃っていることを確かめる処理です。3 つとも通ればドメインは 確認済み となり、送信が許可されます。1 つでも通らなければ保留のままです。
確認されるのは「レコードが存在するか」だけではありません。
| レコード | 実際に確認される内容 |
|---|---|
| DKIM | レコードが公開され、あなた自身の 公開鍵を含んでいること。他人の DKIM や、以前の鍵のまま古くなったものは通りません。 |
| SPF | レコードが存在し、直接 include:esp.getmybot.dev を含むこと。include:esp.getmybot.dev.other-domain.example のような紛らわしい値は該当しません。 |
| DMARC | レコードが公開され、v=DMARC1 で始まること。ポリシーそのもの（p=、rua=）は確認しません。それはあなたの判断であり、当社への許可ではないからです。 |
DMARC の確認が緩い理由: DMARC は DKIM と SPF の結果を受信側が どう扱うか を指示するものであり、あなたの名前で送る権利を当社に与えるものではありません。その権利は最初の 2 つのレコードだけが与え、いずれも内容まで完全に確認されます。
他社の include は該当しません
include:esp.getmybot.dev は あなた自身の SPF レコード に入っている必要があります。あなたの SPF が第三者を include し、その第三者のレコードが当社を include している場合、確認はそれを認めません。プラットフォームは他者の include の連鎖をたどらないためです。理由は単純で、「まさにこのドメインが当社を許可したのか」という問いの答えを曖昧にしないためです。
実務上は、「プロバイダー経由でカバーされている」と確信していても、当社の include をあなた自身のレコードへ直接追加してください。画面自体の SPF の説明にも同じことが書かれています。ドメインにすでに SPF レコードがある場合は、レコードごと置き換えるのではなく、その中に include:... の値を追加してください。そのドメインは当社以外の経路でもメールを送っている可能性があるからです。この注意書きは常に表示されており、確認が失敗したときだけ出るものではありません。
DNS は即座には更新されません。 レジストラで保存したあと、レコードはネームサーバーに行き渡る必要があります。通常は数分、ときに数時間、まれに 1 日程度です。プロバイダーと TTL によります。これは正常な挙動で、当社側で早めることはできません。
とはいえ受け身で待つ必要はありません。プラットフォームは保留中のドメインを 1 時間ごと に自動で再確認しますが、ドメインカードには 「Verify now」 ボタンがあります。同じ確認を即時に実行し、結果をその場で表示します。レコードを保存したらすぐ押してください。入力ミスがあれば 1 時間後ではなく 1 秒で分かります。何度押しても構いません。
ドメインの状態はカードに表示されます。「Pending verification」、「Verified」、「Not verified」 のいずれかです。未確認のあいだは、カードに「Sending from this domain is disabled until it is verified.」という注意も表示されます。
結果は「失敗」だけでは終わりません。 3 つのレコードにはそれぞれ画面上の状態 — 「Passing」、「Not passing」、「Not checked yet」 — と、何が問題かを説明する行が付きます。
SPF については画面が 2 つの状況を区別します。これがこの流れで最も重要な区別です。
- ドメインに SPF レコードがまったくない。 上の表の値で新たに公開してください。
- SPF レコードはあるが当社の include が入っていない。 すでにある レコードに include を追記してください。2 つ目を作らず、丸ごと置き換えもしないでください。同じメッセージは連鎖のケースも明示的に扱います。include が他社の SPF レコード経由でしか当社に届いていない場合は該当しません。連鎖はたどらないからです。
2 つ目のケースがこの流れで最も紛らわしい場面です。レコードはすでにあり、自分で読み返したばかりなのに、確認は拒否する。エラーメッセージは now、レコードの隣に常時表示されている注意書きとまったく同じことを述べます。すでにあるものに当社の include を追記してください。
確認が通らない場合:
- 3 つのうちどれが「Not passing」になっているか、その説明に何と書かれているかを読み、それに従ってください。
- レコードが本当に公開されているか確認します。多くの管理画面では「変更を適用」を別途押す必要があります。
- レコード名でドメインが二重になっていないか確認します（上記参照）。
- SPF レコードが 1 つだけであること、そして当社の include がそのレコードの中にあることを確認します。
- 少し待って再度確認します。変更がまだ行き渡っていない可能性があります。
確認が済むまで送信は動きません（仕様です）
ドメインが確認済みになるまで、メールは 送信されません。「送信されて迷惑メールに入る」のではなく、そもそも出て行きません。試行は未確認ドメインのエラーで終わり、ログに残ります。
これは意図的な仕様であり、不具合ではありません。自分自身を保証していないドメインからのメールは迷惑メール報告につながり、報告はプラットフォームの全顧客が共有する送信基盤の評判を傷つけます。1 通送らないほうが、送ってから半年かけてブロックリストを抜け出すより安上がりです。だからこそ警告ではなく禁止にしています。
このエラーが出たら、サポートに連絡する前に DNS レコードを確認し、確認操作を実行してください。大半はレコード名の入力ミスです。
配信停止・苦情・配信失敗
事前に知らないと驚く 3 つのルールです。
すべてのマーケティングメールにワンクリックの配信停止が入ります。 プラットフォームが本文末尾の配信停止リンクと、メールソフトが送信者アドレスの横に「登録解除」ボタンを描くための技術ヘッダーを自動で付けます。設定でもレイアウトでも外せません。配信停止はメールを開くことも確認画面も要さず、即座に効きます。Gmail をはじめとする大手が大量送信者に求める要件で、これがないメールは確実に迷惑メール行きです。
配信停止は最終的で、画面から取り消せません。 配信停止したアドレスには、このボットのメールは二度と届きません。「元に戻す」ボタンも、リストの再インポートによる抜け道もありません。本人の意思を飛び越えて解除されることはありません。戻れるのは本人だけで、あなたの購読フォームから再度登録した場合に限ります。
さらに厳しい場合があります。メールソフトで 「迷惑メールを報告」 を押された場合、そのアドレスは恒久的に閉じられます。あなたのフォームからの再登録でも開きません。前回の結末をすでに把握しており、そうしたアドレスへの再送はドメインの評判をもっとも早く壊すからです。法的要請により手動で閉じられたアドレスも同じ挙動です。
恒久的な配信失敗（ハードバウンス）はアドレスを永久に抑止します。 受信側のサーバーが「そのメールボックスは存在しない」と応答した場合、アドレスは配信不能として印を付けられ、以後の送信から外れます。一時的な状態ではありません。存在しない宛先を叩き続けることは、他のすべてのアドレスを巻き込んで迷惑メールフィルターに落ちる最短経路です。
一時的な失敗（メールボックス満杯、サーバー一時停止）はアドレスを 閉じません。送信は続きます。
開封数が実際より少なく出る理由
メールの統計には開封数がありますが、これは常に実態より小さくなります。集計の誤りではなく、開封の測り方そのものによるものです。
開封は、メールソフトがメール表示時にサーバーからごく小さな追跡画像を読み込んだときに記録されます。最近のソフトは既定でリモート画像を読み込みません。読み込むもの（Apple Mail などのプライバシー機能）は、メールを開いていない人の分まで前もって一括で読み込みます。前者では開封が失われ、後者では実在しない開封が計上されます。メールの開封をこれ以上正確に数える方法は、当社にも他社にもありません。
そのため画面には注記が添えられています。この数値は 下限 であって正確な値ではありません。同じ偏りが全メールに等しくかかるので、メール同士の比較には使えますが、「何人が読んだか」の答えとしては使えません。
信頼できる反応指標が必要なら 「Link clicks」 を見てください。リンクのクリックは実在の人の実際の行動で、誰かが先回りして代行することはありません。「Delivered」、「Unsubscribes」、「Complaints」、「Bounces」 も正確に数えられます。これらはメールサーバーからの報告であり、メール内の画像によるものではないからです。いずれも同じ Email 画面の 「Sending stats」 ブロックにあります。