去年の秋から八ヶ月ぐらい、Gmailと米国Yahoo!のあれで書いたとおりいろいろあって、最終形態が来ると思われてた六月は少なくともGoogleのガイドラインやFAQに大きな変化がないまま終わって七月です。各所のメールシステム担当者さんも「とりあえず乗り切ったか？」という心持ちでしょうか。
令和六年前半のいろいろ
大晦日の記事に書いてないこともいろいろありました。ここから暫くは本題のメルマガ考察に入るまでの落語で言うマクラです。
Sisimai 5.0.0を急いでリリースした
Gmail二月動乱(一連の騒ぎを個人的にそう呼んでる)でドメイン認証に注目が集まり、二月二日*1に急遽Sisimai 5.0.0をリリースしました。
なんで急ぎのリリースになったかと言えばドメイン認証関係のエラーを"AuthFailure"ってバウンス理由で検出できるように2022年の段階で実装していたものの、まったく開発が進んでないGo言語版のシシマイが完成した時に合わせてVersion 5(Goだけに)*2として出すかなぁと思ってたところに二月動乱、 急にいろいろ変化する？何より僕が仕事で見ているメールサーバーでSisimai 5の機能がわりと直ぐに必要ってのが大きな理由です。
あと、Gmailのガイドラインに書いてたRFC5322に準拠するように*3って部分に起因するRFC違反も独立したバウンス理由として検出できるように"NotCompliantRFC"として、 PTRレコード*4の不備に起因するエラーは"RequirePTR"として、 それぞれリリース直前に実装したわけです。
実際のところ二月に入る以前にガイドラインの各項目にビシャッと対応したので、 僕が見ている範囲ではメールが送れなくてキューが死屍累々とか担当者が阿鼻叫喚とか、そういうのは特に何もなく穏やかに夏を迎えました。
ガイドライン変更の追跡を強化
年末にGoogleのガイドラインを筆頭に重要そうなドキュメントの変更が容易に追跡できるようリポジトリを作ったのですが、 おそらく他のメールサービスもいずれはGoogleや米国Yahoo!の方針と同じ方向に舵を切ると予想して、 Microsoft*5とApple*6の関係してそうなPostmaster系のドキュメントも追加しました。
そう言えば今日は毎月恒例SMTPの日で25²(==625)って最強クラスやし数日ぶりに二月動乱の更新状況を確認したら米国YahooのFAQが更新されてた。解釈と文脈がイマイチ分からんのやけど8/1までにSender Hubにドメインを登録しておいたほうが良さそうな雰囲気やと思う、たぶん。https://t.co/wpt6u9BYTD
— ネコ物質²²⁰ (@azumakuniyuki) June 25, 2024
残念ながら(幸いにも)今のところ目立った変化は無いのですが、何かあれば観測できるはずです、たぶん。
MTAの配信速度調整
春ごろにアプリケーションサーバーのスケールアップがあり、配信するメールサーバーの速度調整をしました。 Googleをはじめ、大きなメールサービスから怒られない程度の速度かつキューが滞留しないちょうど良い塩梅のチューニングです。
調整する度にキューがどの程度の速度で捌けていて負荷とか接続数とかプロセス数とか、 大丈夫かどうかを観察するのにqueuemetreって小さいスクリプトを作りました。 元々はMTAの速度調整で毎回毎回その場凌ぎの使い捨てスクリプトを書いてたのですが、 少しずつコードが違う似たような内容の似たような名前のスクリプトが四枚か五枚ぐらいあって、 纏めてビシャッとリポジトリも作った次第です。
これはキュー数と接続数と負荷やメモリを一定時間毎に表示して送信速度や同時接続数上限値を探るための観測スクリプトなんやけど使い捨てで書いてPC内のどこに最新版があるのか分からんし名前も全て違うのをビシャッとどうにかしたやつ、大量配信MTAの調整に使う。https://t.co/z6bXiKUJpx
— ネコ物質¹⁵⁵ (@azumakuniyuki) April 24, 2024
配信について、昔は超高速配信！みたいなスピード狂っぽい雰囲気でしたが今は速すぎると怒られる*7 ケースも多々あるので、相手側MTAになるべく負担をかけずにキューが残らないように適切な速度で配信する方が重要であると思います。
スパム報告率を下げる
メールサーバーを立てたりDKIM署名を付けるようにしたりDMARCレコードの宣言とレポートの確認やメールサーバーの技術的な調整に比べると、 ドメイン認証を筆頭にガイドラインの完全なる準拠の準備を関係者へ周知して納得してもらって合意を形成するのって遥かに難易度が高いと知りました。
で、スパム報告率を0.30%または0.10%以下まで下げて維持するのもなかなか難しいようで、いろいろ各所から相談を受けました。
ワンクリック購読解除(List-Unsubscribe)を実装することで「登録解除はログインが必要で面倒くさいからスパム報告でいいか」によるスパム報告を回避する効果はあると言えますが 「そもそもスパム報告されるのっておかしくない？みんな自分の意思で購読しているとちがうの？」って疑問から、この記事の本題であるメルマガについて考察します。
メルマガについての考察
ここから本題です。
普段はバウンスメールをいい感じに上手いことビシャッと解析して構造化するライブラリを作っているので、 メール配信におけるSMTPを中心とした技術的ないろいろは適度に経験値があるものの、マーケティング分野は深い専門知識を持っていません。
とは言え「メール詳しいですよね？」「まぁ多少は...」「メルマガなんですけどね」って感じでいくつも相談をもらって「さて、どうするか？」と考えた結果、 Gmailとか送信先メールサーバーの気持ち*8になって合理的に考えればだいたい妥当な解決策は立案できるなぁって 結論を得たと思います。
それと、ここでの「メルマガ」「メールマガジン」は「大量配信しているマーケティング系メール」の総称を意味しています。 サイト側で生じた変化を通知するメールもメルマガに相当するものであると認識しています。
ダブルオプトインの機械寄りな合理的説明
考察って言うか、まぁこれはマーケティングに長けた人から見れば当たり前のことであると思いますが、徹頭徹尾ダブルオプトインは必須です。 みなさんご存知のとおり、一般的なダブルオプトインの流れは以下の通りです。
1. ユーザーがWEBサイトで自分のメールアドレスを入力する
- 自分の意思でWEBサイトに来て購読の第一歩を踏み出す
- 自分の意思で自分のアドレスを入れてもらう
2. (1)で入力したメールアドレスにメールが来る
- メールアドレスが間違ってたらメールは来ない
- メールアドレスが合っていてもフィルターなどで弾かれる可能性がある
- 弾かれてなくてもスパム扱いされてInbox/(受信トレイ)に入ってこないかも
3. (2)で受け取ったメールを開きURLも開き購読を開始
- Inbox/(受信トレイ)に来たメールを開いてURLも開く
- スパム扱いされていたら探して救出してURLを開く
- 同じWEBサイトが開いて確かに自分が購読を希望するメルマガであると確認する
僕は職業柄、渡した名刺に書いてるアドレスにメールマガジンが来るのは別に構わない、 中身より先にヘッダーを見てニヤニヤする*9って立場ですが、 一般的にはアタマから尻尾の先まで自分の意思による購読開始が望ましいと考えます。
Google/Gmailの気持ちで考える
二月動乱に関係した話なのでGmailと書いていますが、どのようなメールサービスでも内部処理は同じであると推測されます。 受け取る側のメールサーバーになって考えると、上記で重要なのは3-aと3-bです。
- Gmailの内部システムは「ユーザーがメールを開いた」事実を記録する
- 同じくスパム扱いされてたメールをユーザーが救出した事実も記録する
- メールに書いてるURLを開いたことをGmailが検出できるかどうかは知らない
- 僕はWEBの技術に詳しくない
- まぁなんらかの手段でURLを開いた事実ぐらい捕捉してると思う(たぶん)
- ユーザーによってはサイトにかかれていた
From:と実際に来たメールのFrom:が同じドメインであると確認する
つまりユーザーにとって初めましてのドメインから来た1通目のメール(ダブルオプトインの第一段階で入れたメールアドレスに送られてきたメール)が開かれ、書かれているURLも開かれたならば、ユーザーはそのメールのFrom:ヘッダーに書いているドメインからのメールを必要としている、とGmailは機械的に判断するものと推測されます。
ダブルオプトインしない場合
となると、ダブルオプトインなしでいきなり1通目から大量配信のメルマガが来た場合、Gmailはどのように判断するか。
僕がGmailなら「なんやなんや？このユーザーさん宛てに知らんドメインから突然メールがめっちゃ来たけどなんやねんこれ？分からんしスパムってことにするわ」 「ホンマに大事なメールやったらユーザーさんが探して開いて救出すると思うし放置されるならスパム確定やな」と考えます。
つまりユーザーにとって初めましてのドメインから来た1通目のメールがメルマガ、いつ送られてくるのか分からない、ユーザーが探しもしない、開いてない、 迷惑メールフォルダで見つけたけど見捨ててるようなメールは不要なメールであろうとGmailは機械的に判断すると予想できます。
実際は内部でどうフラグが立って、どう処理されているのかは知りませんが、自分が大規模なメールサービスの受信側を実装するなら同じ判断をします。 誰であれそうすると思います。
ドメインは変えない
上述のとおり、機械の立場になって合理的に考えると、初めましてのドメインから来る1通目のメールはユーザーによって確実に開いてもらう必要があります。
となると、スパム扱いされてるっぽいからFrom:のドメインを変える、開封率(Appleの件があるので
指標としてはもう使えない雰囲気)やクリック率が悪いから心機一転ドメインを変えるのは確実に悪手であると言えるでしょう。
これは実社会における商取引でも同じことが言えます。
- 女将「うちは京料理の料亭ミケ村、いつも九条ネギを買ってるキジトラ青果店の金ちゃん、そろそろ来る頃やな」
- 犬山「お世話になります、浜路ホールディングスの犬山っス！夏目の後任です〜」
- 女将「え？浜路さん？夏目の金ちゃんは？」
- 犬山「あーうちキジトラ青果店さんを吸収合併しまして〜夏目は異動です〜」
- 女将「へぇ〜おたくも大変やねぇ、そやけどいきなり合併とか言われましてもハイそうですかってわけにもいきませんしねぇ」
- 女将「とりあえず上のモンに確認してみんと何も分からへんし今日のところはお引き取りしてもろてええですか」
- 女将 (なんか突然やし怪しいし他所さんからネギ買おうかな...)
ってな扱いを受けるわけです、当然です。
本来ならば夏目さんが後任である犬山さんを連れて料亭ミケ村に行き、「来月から犬山が担当します」と 紹介するのが筋です。ある日いきなり得意先を名乗る知らん人が来たらお店の人は最大限に疑いをかけるわけです。 正規の手順で後任を紹介していない以上、ミケ村の女将さんを騙そうとしている詐欺師の可能性も充分に考えられます。
メールのFrom:ドメインについても同様です。
SMTPやDNSに詳しい人ならば、いきなり現れたドメインをwhois(1)したりNSレコードやMXレコードを調べたり、Received:ヘッダーを追ったりして、元々のドメインと同じ組織が所有している・配信していると突き止めることができるかもしれません。しかし、技術的に調査可能でもそこまでする人はほぼいないでしょう。
サービスのリニューアルや合併などでドメインを変えざるを得ない場合は、 面倒でも信頼性の観点から時間をかけて新しいドメインでの配信について各ユーザー(購読者)の同意を得る必要があると考えるのが合理的です。
ローカルパートも変えない(なるべく)
これはGoogleがサブドメインも含めて大量送信者であるかどうかを判断すると言っているので、確証はありませんがローカルパートの変更による悪影響は、 ドメインを変えることよりも少ないと予想されます。
ただし、ユーザーが作っているフォルダ分けルールに一致しなくてInbox/に入る、通知がバンバン鳴る、「あーもう💢最近読んでないしスパム報告*10するわ💢」 という行動も予想されるので、無闇に変えないほうが良いのは確実でしょう。
スパムトラップ
古来(20世紀の終わりぐらい？)から、WEBサイトをクローリングして得たアドレスを集積して購読者リストを太らせ無断でメールマガジンを送ると、 スパムトラップで一発アウトになることがあります。もちろん現代でも存在します。
理不尽にSMTPが421で拒否されつづける場合、可能性として配信対象にスパムトラップアドレスが混ざっているかもしれません。
スパムトラップであるメールアドレスは、ローカルパートやメールアドレス全体の字面から見分けることはできないと言えます。
「いやいやいや、うちはクローリングとかしてないで」「リストの購入もしたことないしな」という場合でもスパムトラップアドレスが混ざっている可能性はあります。 ダブルオプトインを導入していなかった僅かな時代に何処かの誰かが怪しい入手経路のリストにあるメールアドレスを勝手に大量登録してた、 今でもそのアドレスは配信対象になっている、というケースです。
ではどうすれば良いか？配信対象を確実にダブルオプトインで登録してもらった人に限定するのが合理的な解法です。
とは言え、歴史の長いサイトやメルマガではダブルオプトイン導入以前からの購読者もたくさん居てはると思いますので、 そのあたりはサイト側で持っているユーザーのステータスやら多種多様な変数を加味して判断するのが良いです、たぶん。
Sunset Policy
サンセットポリシーという概念については SendGridさんの記事「Sunset Policyの必要性と実戦例」が詳しいので一読の価値があります。
要点は反応のない購読者への配信を止めるという話です。 Googleのガイドラインでも「望んでいる人にだけ送信しましょう」*11 と言ったことが書いてあります。これもまた解釈が難しいガイドラインであると思いますが、メルマガを開いている人や本文中のURLを開いてくれる人は メルマガを望んでいる人と認識して良いでしょう。
例えば僕が購読しているメールマガジンの中では、いろいろ統計データを集めているStatistaと Q&AサイトのQuoraは、おそらくサンセットポリシーを導入しています。 配信されてくるメルマガを数ヶ月間ほど開きもしてなかったところ、いつのまにかメールが配信されなくなってました。
「あれ？そう言えばメール来てない？んん？」と思ってサイトに行き、ログインして確認すると配信がOFFになってたので 「Sunset Policyか！」と理解しました。サイトへのログイン自体が引き金となってメルマガの配信が復活したパターンも観測しています。
ソファーでゴロゴロしつつテレビを見ながら知らん間に寝落ちして、家族がテレビを消した瞬間に目を覚まし「見てた！いま見てたのに！」で再びテレビを点ける感じですね。
更に厳格な運用として、一定期間ログインが無いアカウントは停止状態(Suspend)になるサービスもあります。 Zohoは「しばらくログインがないし来月にアカウントを止めるで」ってメールが来ます。
サンセットポリシーの適用対象となったメールアドレスに「メルマガ止めますよ〜」といった案内を送るのも良いかも知れません。
このあたり、サンセットポリシーを適用する条件をどう構築するかってのはサイトによって、メルマガによって何もかもが異なると思いますが、 前述のスパムトラップアドレスなんかはログイン履歴もメールを開いた記録も何もないと推測できますので、サンセットポリシーで除外可能であると言えます。
要点は大量登録大量配信こそパワーみたいな時代はとうの昔に終わっているので、 ちゃーんと読んでくれる購読者さんや活動してくれるユーザーさんに配信資源を使ってより良い体験をしてもらおうという方策です。
宣伝
メルマガ配信に於てはガイドライン準拠や低スパム報告率維持も大事ですが、バウンス率も低く抑える必要があります。
「いや、そんなん商用の配信サービスに任せておけばええやん？」ってところなんですが、月に数千万通とか数億通とか配信する場合、 自前のメールサーバーでないと向こう三軒両隣の目玉と言う目玉が飛び出る値段になります。
そこでビシャッとバウンスメールを解析していい感じに構造化するSisimaiの出番 *12 というわけです。
二月動乱あたりから「Sisimaiってどんなところが使ってはります？」という質問をちょいちょい頂くようになりました。
今年でリリースから10周年*13ということもあり、少しは能動的に宣伝もしようかと 三月ごろに把握しているユーザー企業さんに声をかけてお願いしてLIBSISIMAI.ORGにロゴを掲載させていただきました。 掲載に際してご連絡・ご対応いただきご快諾いただいた企業様へ改めてお礼申し上げます。
「うちもSisimai使ってるよ！」「ロゴ乗っけてもOKですよ」って企業さんやサービスさんがおられましたら、 GitHubのIssue#61に投げていただくか、 showcase-7e87@libsisimai.com*14 までご一報くださいますと大変うれしいです。
短文？
学部も院も文系出身なのでブログの1万文字は短文という認識です、暑中お見舞い申し上げます。
*1:別居しているうちのネコ殿を保護した日であり仮のお誕生日・めでたい🎉
*2:Goだけに次の機会はSisimai 5.5とか
*3:Format messages according to the Internet Format Standard
*4:The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.
*9:Received:で配信サービスを調べたりDKIM署名のセレクターを見たりList-UnsubscribeのURL構造を眺めたり
*10:ここで1クリック購読解除のList-Unsubscribeを実装していれば先ず「購読解除します？」と聞かれスパム報告率上昇に寄与するのを防げるかも知れない
*11:you should send email only to people who want to get messages from you.
*12:そもそもこのブログは「Sisimaiのことを書く」と言っているのでここが本題と同じぐらい重要な内容とも言えます
*13:初回リリース日が2014年8月16日・五山送り火と同じ日・めでたい🎉
*14:このメールアドレスは夏が終わるまで存在します
