送ったメールが届いていないかも…… 不達を疑うときにチェックすべき2つの兆候：メールが届かない時代の始まり（2/2 ページ）

[菱沼憲司，株式会社リンク]

電子メール届かない場合の7つの解決策

　電子メールが届かない原因を特定できたら、次に具体的な対策を講じる必要があります。以下に一般的な問題別の解決策を紹介します。

1．有効な正引き／逆引きDNSレコードの設定（エラーコード：4.7.23）

　電子メールを届ける際のDNS設定は送信者の正当性を示す上で非常に重要な役割を担っています。Gmailガイドラインに準拠し、迷惑メールに判定されないためにはDNSに以下の設定が適用されているかどうかを確認する必要があります。

• エンベロープFrom（※注）のドメインのMXレコードが設定されていること
• ヘッダFromのドメインのMXレコードが設定されていること
• 送信元メールサーバのSMTPホスト名にAレコードが設定されていること
• 送信元メールサーバのIPアドレスのPTRレコードが設定されていること
• 送信元メールサーバのIPアドレスが、逆引きしたホスト名のAレコードとマッチしていること

（注）：電子メールには2つのFromアドレスとして、Header-From（ヘッダFrom）とEnvelope-From（エンベロープFrom）が存在する。郵便物に例えると、AさんがBさんに電子メールを送るとき、Aさんの書いた電子メールの外側にエンベロープ（封筒）が作成される。エンベロープには実際の送信に必要な情報（エンベロープFrom）が書き込まれており、その情報を基にBさんへ届けられる。Bさんのメールフォルダに電子メールが届くとエンベロープは破棄されるため、Bさんが電子メールを開いたときにはヘッダFromだけが表示される。SPFやDKIMもエンベロープに入っている電子メールの中身まではチェックしないため、「電子メール本体に書かれた宛先や差出人（ヘッダFrom）」と「エンベロープに書かれた宛先や差出人（エンベロープFrom）」が同一でなくても電子メールは届いてしまう。

　注意点としては、クラウドサービスを利用している場合、逆引きの設定は管理事業者への依頼が必要となるケースがあります。逆引きの設定がされていないようであれば、利用中のクラウドサービスの事業者に確認してみてください。

2．SPF認証の成功（エラーコード：4.7.27）

　SPF認証は送信ドメイン認証の中でも最も普及率が高い認証方式です。設定自体も、エンベロープFromドメインのDNSサーバにTXTレコードを記載するだけのため、導入障壁も低いでしょう。しかし以下理由からSPF認証エラーになるケースが多く存在します。

1. SPFレコードの記載方法が間違っている
2. SPFレコード内の参照回数が10回を超過している
3. SPFレコードの文字数が512バイトを超過している

　自身のSPFレコードに問題がないかどうか、無償チェックツールなどを活用して再度確認してみてください。特に2番目の参照回数については、電子メール配信に関わるサービスを複数利用している場合、多くのドメインをincludeで参照することになり、知らないうちに10回の制限を超えてしまうケースが多くあります。どうしても参照回数を減らせない場合は、SPFレコードの参照回数を減らすためのサービスを利用するのも一つの方法です。

3．DKIM認証の成功（エラーコード：4.7.30）

　DKIMは送信メールに電子署名を付与し、電子メールの受信者が署名をチェックすることで送信者が偽造されていないかどうか、メールデータが改ざんされていないかどうかを確認する認証方式です。

　署名には、ヘッダFromのドメインを使用する「作成者署名」と、サービス提供事業者のドメインなどヘッダFromとは異なるドメインを使用する「第三者署名」の2種類があります。後ほど解説するDMARCアライメントにも関わってくる内容になりますが、DKIM署名は「作成者署名」に対応することを推奨しています。

　DKIMの認証が失敗する原因は幾つか存在し、よくあるのが「意図しないメールデータの改ざん」です。例えば、メールセキュリティゲートウェイの添付ファイル圧縮機能を利用すると、送信元メールサーバでDKIM署名を付与した電子メールが配信途中に添付ファイルデータが加工されることが原因で、受信側でのDKIM署名チェックで電子メールが改ざんされていると認識され、認証エラーになります。

　もし、上記のような環境で運用している場合、DKIM署名の付与をメールセキュリティゲートウェイで対応したり、ARC認証を実装したりするなど、対策方法を検討する必要があります。

4．TLS接続（エラーコード：4.7.29）

　自社でメールサーバを運用している場合は、TLS接続に対応することはそこまでハードルは高くないでしょう。自社メールサーバの設定でSTARTTLSに対応するためのミドルウェアインストールと設定を適用するだけで対応可能です。

　課題となるのは、外部のメールサービスを利用している場合です。メールホスティングサービスやメール配信サービスを利用している場合、サービス自体がTLS対応しているかどうかを確認して対応を依頼する必要があります。

　もしサービス側の対応が難しい場合は、TLS対応しているメールサービスへの移行を含めて検討が必要になると思いますので、自社メールサーバ環境がTLSに対応しているかどうかを確認してみてください。

5．DMARCの設定（エラーコード：4.7.31）

　DMARC自体の導入は簡単です。ヘッダFromドメインのDNSサーバにDMARCレコードを記載するだけで対応できます。

　ただし、その際に重要なことは、ポリシーは必ず「none（監視モード）」に設定し、DMARCレポートを受信するためのメールアドレスを設定することです。

　DMARCレポートの受信メールアドレスを設定することで、世の中のメールサーバからDMARCレポートを受信できるようになります。DMARCレポートには、自社のドメインがヘッダFromに設定された電子メールの送信ドメイン認証（SPFやDKIM、DMARC）の結果が記録されているため、メール送信環境と送信ドメイン認証の結果を把握できるようになります。

　意外と自分達が認識していない環境からも電子メールが送信されていることが多いため、まずは現状を把握するためにもDMARCレポートを受信し、可視化することをお勧めします。

6．DMARCアライメントの合格（エラーコード：4.7.32）

　DMARCアライメントには、SPFアライメントとDKIMアライメントの2種類が存在します。DMARCアライメントは以下のうちどちらかのアライメントを合格させる必要があります。なお、以下の各アライメントは「各SPF・DKIM認証が成功していることが前提」になるため注意が必要です。

1. SPFアライメント：　ヘッダFromドメインと、エンベロープFromドメインが一致するかどうか
2. DKIMアライメント：　ヘッダFromドメインと、DKIM署名のdタグで指定したドメインが一致するかどうか

　上記の通り、対策としてはシンプルですが、メール配信サービスを利用している場合は、エンベロープFromやDKIM署名がサービス提供事業者のドメインになっていることで、アライメントに失敗するケースが多いです。

　まずはDMARC認証エラーになっているメール送信元を把握しなければ、なぜアライメントが失敗しているのか、合格させるためには何を修正する必要があるのか突き止められません。その際にも役立つのがDMARCレポートです。自社の配信しているメールがDMARCアライメントに合格できているのか、網羅的に把握するためにもDMARCレポートの可視化を実施してみてください。

7．ブラックリスト登録有無の確認

　Gmailガイドラインには含まれていませんが、電子メールの到達率に大きな影響を与えるのがブラックリストです。ドメインやIPアドレスがブラックリストに登録されてしまうと、Gmailをはじめとしたメールサービスや携帯キャリア、企業ドメインを問わず、スパムメールとしてブロックされる確率が高くなります。

　そのため、メール送信元IPアドレスやエンベロープFrom・ヘッダFromのドメインに加え、電子メール本文内に含まれるURLドメインがブラックリストに登録されているかどうかを確認することは、到達率を向上させるために必要不可欠なポイントです。定期的に自社のIPアドレスやドメインがブラックリストに登録されていないかどうか、無償チェックツールなどを活用して確認してみてください。

電子メール不達の改善が進まない2つの要因

　これら一つ一つの対応は、実際の作業としてはそこまで難しいものではありません。それでも対応ができていない企業が依然として多いのは、2つの要因があると考えられます。

　1つ目は「メール送信環境が把握できていない」ことです。利用できるSaaSが増えていることから、自社のメールサーバ以外のさまざまな環境からも電子メールが送信されています。そのため、メール送信環境の把握が困難になっていると考えられます。

　2つ目は「電子メール配信における責任範囲の曖昧（あいまい）さ」です。1つ目の課題とも関連しますが、部署単位で外部サービスを利用して電子メール配信を実施している場合、誰が責任を持ってガイドラインに対応していくのかが課題になります。特に外部サービスや外部ベンダーに委託している場合、責任範囲がより曖昧になります。このように責任範囲が曖昧なため、ガイドラインへの対応が漏れてしまいやすいのも大きな要因だと考えられます。

　これらの課題をクリアし、Gmailガイドラインへの対応や電子メール不達の改善を講じるために最も良いのは、社内で旗振り役となるチームを作ることです。

　企業規模にもよりますが、近年さまざまな環境から電子メールが送られていることもあり、一人で全ての環境を把握し、対処していくことは困難です。対策チームを設置し、利用部署や外部のサービス提供事業者、外部委託業者、取引先など、関係各所とコミュニケーションを取りながら進めていくことが重要だと思います。

電子メール配信で企業に求められること

　これまでは、企業が電子メールの送信環境について管理しなくても大きな問題にはならなかったかもしれません。しかし、今回の送信者ガイドラインの改訂は、その考え方に大きな変更を迫るものでした。特にDMARCの導入と運用は、企業自身が自社のドメインに責任を持ち、対応することが求められます。今後は自社が送信している電子メールの送信ドメイン認証の結果を把握し、自社のドメインがなりすましメールの温床にならないように、送信環境を管理することが求められます。

　2024年2月に適用が開始されたGmailの送信者ガイドラインですが、今後は複数の海外キャリアや国内キャリアでも強化が予定されています。この規制強化の目的は、世界中で問題になっているフィッシング詐欺を撲滅するために、その要因となっている「悪意のあるなりすましメール」をなくすことです。

　送信者ガイドライン強化の本来の目的を考えれば、現在は導入の推奨にとどまっているDMARCも、今後はポリシーを強化することでなりすましメールを排除するように求められてもおかしくありません。そのためには、DMARCレポートを可視化することで自社のメール送信環境と認証状況を把握し、問題があれば改善することが必要不可欠となります。

　次回は、今後メールの安定的な配信に欠かせなくなるであろうDMARCについて、導入時のポイントや活用方法を詳しく解説します。