エージェントだけの受信トレイはありません。CAN-SPAM法も、Gmail のしきい値も、マーケティングとトランザクションを送信経路で分ける必要も同じです。
エージェントは、人と同じ送信インフラを使ってキャンペーンを開始できます。それでも Gmail に見えるのは、これまでどおり差出人、ドメイン、メッセージです。
メールボックスプロバイダーが評価するのは、ドメイン、IP、迷惑メール報告率です。人が「送信」をクリックしたかどうかは評価しません。エージェントが販促の本文をトランザクション用のIPから送れば、手作業で起こした場合と同じ問題を抱えることになります。違うのは、それが早く起きることだけです。
この記事は到達率ガイドを補うもので、その代わりになるものではありません。到達率ガイドでは、レピュテーション、認証、リストの健全性を扱っています。この記事で取り上げるのは、送信ボタンを押すのがソフトウェアになったときに起きるミスです。
CAN-SPAM法は、商用メッセージに適用されます。「主な目的」による判断基準が見るのは件名と本文であり、それを誰が入力したかではありません。
請求書とオファーが混在するメッセージでは、その主な目的を判断します。件名、アカウント情報の配置、販促の目立ち方が判断材料になります。短い販促のフッターがあるだけで、利用明細書が自動的に商用メールになるわけではありません。FTCのガイダンスには例も載っています。商用メッセージには、偽りのないヘッダーと件名、住所、そして機能する配信停止の手段が必要です。
逆も同じです。実際のセキュリティイベントをきっかけにエージェントが送ったパスワードリセットは、本文がそのイベントの内容にとどまっている限り、トランザクションメールのままです。
Gmail の送信者の要件には、すべての送信者に向けたルールと、個人の Gmail アカウント宛てに1日あたり約5,000通に達する一括送信者向けの、より厳しいルールがあります。より厳しい要件には、次のものが含まれます。
p=none またはそれより厳しいポリシーのDMARCとのアライメント。List-Unsubscribe と List-Unsubscribe-Post）。トランザクションメールは、ワンクリックのルールの対象外です。ただし、認証は免除されませんし、テンプレートにセールの情報を詰め込めば、迷惑メール報告も免れません。
Yahoo は、送信量の多い送信者に、マーケティングメールとトランザクションメールを別々のIPから送り、できればドメインも分けるよう求めています。エージェントがどの送信元を使うのかは、あいまいなデフォルトに任せず、自分で確認しましょう。
キャンペーンとオートメーションには、販促用の送信元をエージェントに渡しましょう。ウォームアップしてきたドメイン、迷惑メール報告が来ることを想定しているIP、テスト済みの配信停止ヘッダーです。
トランザクションメールは、別の送信元に分けておきます。Brew では、その送信元は用途を「トランザクション」に設定したドメインで、メール自体はトリガー付きの公開済みオートメーションです。テンプレートを作るのはエージェントでもかまいません。それでも、イベントごとの送信経路は、JSONのペイロードを付けた POST /v1/automations/triggers/{triggerEventId}/fire であるべきで、「この下書きをリストに送って」ではありません。
認証済みのドメインがいくつもあるからといって、「どれが届くか試す」ために、エージェントに差出人アドレスを選ばせてはいけません。そうすると、2つのレピュテーションを同時に育てることになり、どちらも把握できなくなります。
起こりがちな失敗は、誤字ではありません。公表したことのない数字を引用した流暢な段落や、領収書のように見える件名です。
確認待ちのキューを挟まずにエージェントに送信させる前に、次のことを行いましょう。
Harmonya の Cory Nelson さんは、この流れを信頼して任せる前に、最初のキャンペーンをこうして確認したと Noah Adelstein さんに話しています。これが正しい順番です。
ドメインを認証し、正しい送信元を選び、最初のキャンペーンを承認済みのブリーフと照らし合わせて確認しましょう。アシスタントの権限と確認設定も見直してください。MCPクライアントによって、承認の求め方は異なります。
でっち上げの数字を防ぐブリーフの書き方は、メールエージェントへのブリーフの書き方で紹介しています。Harmonya が最初のキャンペーンをどう確認したかは、Harmonya がニュースレターをライフサイクル施策に変えた方法をご覧ください。
