【第280回】 Google と 米Yahoo を追う Microsoft の「送信ガイドライン」
さて、今回の内容は、メール送信者にとって少し耳の痛い内容かもしれませんが、一方で私たちは一個人として企業からのメール受信者でもあります。そのため、これを前向きな改善の機会と捉えるべきです。
2023 年 10 月に Google と 米Yahoo の共同声明があり、2024 年 6 月 以降施行されている「一括送信者」のための「送信ガイドライン」ですが、本日、2025 年 5 月 5 日 からは Microsoft が追随する形になりますので、Outlook や Hotmail のメールドメインも影響を受けることになります。
今回の変更では、1 日あたり 5,000 通以上のメールを送信するドメインに対し、条件が課されます。このガイドラインは Google や 米Yahoo のものと非常に似ています。そのため、既に Google や 米Yahoo のタイミングで対策を取っている場合、大きく恐れる必要はありません。
認証について - 必須事項
SMTP（Simple Mail Transfer Protocol）では、メール送信者が本当にその本人であるかを検証する仕組みがありません。そのため、送信者の正当性を確認するために、以下のようなメール認証技術が必要です。
1. SPF（送信者ポリシーフレームワーク）
SPF は、特定のドメインから送信されるメールアドレス（MAIL FROM / エンベロープ FROM）が、許可されたサーバーから送信されているかを確認します。DNS に設定された TXT レコード（SPF レコード）を使い、送信元サーバーの正当性を検証し、なりすましを防ぎます。
DNS サーバーはドメイン名と送信元サーバーの IP アドレス（or ホスト名）を紐づける形で管理しているので、ドメイン名の問い合わせに対して、どの送信元サーバーの IP アドレスが登録されているかを回答してくれます。
仕組み：「このドメインのメールアドレスは、このサーバーから送信されるべき」というポリシーに基づいて検証します。
失敗時：なりすましの可能性があると判断されます。
ガイドラインの要件：ドメインの DNS レコード（SPF レコード）に、正確な送信元 IP アドレス（そのドメインを利用してメールを送信することが許可されている）が登録されている必要があります。
2. DKIM（ドメインキー識別メール）
DKIM は、メール送信時に電子署名を付与し、受信者サーバー側で署名の検証を行うことで、変更や改ざんを防ぎます。電子署名では「公開鍵」暗号方式を利用し、送信元サーバー上の「秘密鍵」で署名を作成し、受信者サーバー側は DNS サーバーに登録された「公開鍵」を取得して検証します。
仕組み：送信元サーバーがメッセージ全体、またはメッセージヘッダーに電子署名を付けて送信し、受信者サーバーがそれを検証します。これによりメッセージの変更や改ざんを防止します。
SPF との違い：SPF は MAIL FROM アドレスと送信元 IP アドレスが正当であるかを検証しますが、DKIM は FROM アドレスとメール内容の整合性を検証し、担保します。
参考：送信元メールアドレスの種類
①「ヘッダー FROM」「FROM」・・・受信 BOX 上で表示されるアドレス
②「MAIL FROM」「エンベロープ FROM」・・・実際の差出人アドレス
ガイドラインの要件：メールの整合性と信頼性を検証するために、DKIM 署名が有効である必要があります。
3. DMARC（ドメインベースのメッセージ認証、レポートおよび適合）
DMARC は、SPF や DKIM と連携して、メールの送信者情報（MAIL FROM とFROM アドレス）が一致しているかを確認します。また、DMARC ポリシーを設定することで、認証に失敗したメールへの対処方針を設定できます。
DMARC 認証のプロセス：
SPF チェック
MAIL FROM のドメインと送信元 IP アドレスが一致するかを確認
DKIM チェック
FROM アドレスが署名された内容と一致するかを確認
DMARC ポリシー
SPF や DKIM のいずれか、もしくは両方が整合しており、かつ MAIL FROM と FROM アドレスのドメインが一致するかを確認
認証に失敗した場合の対処方法（受信拒否＝バウンス、隔離＝迷惑メール、受信許可＝何もしないで送信）を定義
ガイドラインの要件：SPF や DKIM のいずれか、もしくは両方が整合しており、最低限 p=none（何もしないで送信）のポリシーが設定されていること。
SPF、DKIM、DMARC はそれぞれ異なる役割を持ちつつ、相互に補完し合うことで、メールのなりすましやフィッシング攻撃からの保護を実現します。これらをすべて正しく実装することで、メールセキュリティの水準を最大限に高めることが可能です。
メール衛生について - 推奨事項
一括送信者は、メール送信の品質と信頼を維持するために、次の慣行を採用する必要があります。
1. 準拠した P2（プライマリ）送信者アドレス
「送信元アドレス」や「返信先アドレス」が有効であり、実際の送信元ドメインを反映し、返信を受信できることを確認します。受信者にとっては受信トレイが有効ということももちろん大事ですが、ドメインがメールを受信できることを意味し、DNS の構造上、有効であることを確認します。
2. 機能的な登録解除リンク
特にマーケティングメールや大量メールの場合、受信者が今後のメッセージの受信を停止するための簡単ではっきりと見える方法を提供します。
3. 透明なメール送信方法
正確なメール件名を使用し、誤解を招くようなヘッダーを避け、受信者がメッセージを受信することに同意していることを確認します。
4. リストの衛生とバウンス管理
無効なアドレスを定期的に削除して、スパムの苦情、バウンス、無駄なメッセージを削減します。
以下の記事は Google と 米 Yahoo の「送信者ガイドライン」について書いた記事ですが、180 日間で一度もメールを開封していない購読者を特定して、Salesforce Marketing Cloud の Automation Studio を使って、その購読者を除外する方法を書いたりしていますので、ぜひ参考にしてください。
違反するとどうなる？
特に認証または衛生に関する重大な違反があった場合、Microsoft 側は準拠していない送信者に対して、迷惑メールとしてのフィルタリング や 送信ブロック（バウンス）などのアクションを実行する権利を持ちます。
拒否されたメッセージには、「550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.」（「550; 5.7.515 アクセスが拒否されました。送信元ドメインが必要な認証レベルを満たしていません」）というエラーメッセージが表示されます。
※この送信ガイドラインに関する詳細は、以下の記事をご確認ください。
いかがでしたでしょうか。
前述の通り、すでに Google や 米Yahoo などの対策を実施済みであれば、過度に心配する必要はありません。多くの方は、何らかの対策を既に講じていることでしょう。そのため、Outlook や Hotmail などで新たな「送信ガイドライン」が 2025 年 5 月 5 日から導入されたという事実を認識しておくだけで十分だと思われます。
今回は以上です。
