次の方法で共有

Azure Communication Services メールでの送信者認証サポートのベスト プラクティス

  • [アーティクル]

この記事では、DNS レコードに関するメール送信のベスト プラクティスと、ドメインから送信されたように見えるメッセージを攻撃者が送信するのを防ぐのに役立つ送信者認証方法の使用方法について説明します。

メール認証と DNS のセットアップ

メールを送信するには、複数の手順が必要です。この手順には、メールの送信者が実際にドメインを所有しているか確認すること、ドメインの評価を確認すること、ウィルス スキャン、スパム、フィッシング詐欺、マルウェアのフィルター処理などが含まれます。適切なメール認証を構成することは、メールの信頼性を確立し、ドメインの評価を維持するための基本原則です。 メールが認証チェックに合格した場合、受信側のドメインは、それらの認証チェックに関連付けられた ID に対して既に確立されている評価を踏まえて、そのメールにポリシーを適用でき、受信者に対して、それらの ID が有効であることを保証できます。

MX (メール交換) レコード

MX (メール交換) レコードは、メールを正しいサーバーにルーティングするために使用されます。 ドメインに代わってメール メッセージを受け入れるメール サーバーを指定します。 DNS は、メール ドメインの MX レコードの最新情報で更新する必要があります。そうしないと、一部の配信エラーが発生します。

SPF (Sender Policy Framework)

SPF (RFC 7208) は、ドメイン所有者の代わりにメールを送信することを許可されたシステムの一覧を、そのドメイン所有者が標準 DNS TXT レコードを介して発行および維持できるようにするメカニズムです。 このレコードは、ドメインに代わってメールを送信する権限を持つメール サーバーを指定するために使用されます。 これは、メールのスプーフィングを防ぎ、メールの配信可能性を高めるのに役立ちます。

DKIM (Domain Keys Identified Mail)

DKIM (RFC 6376) では、組織は、受信者が検証できる方法で、メッセージの送信責任を主張することができます。 このレコードは、メールの送信元のドメインの認証にも使用され、メールのスプーフィングを防ぎ、メールの配信可能性を高めるのに役立ちます。

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC (RFC 7489) はスケーラブルなメカニズムです。これにより、メール送信側の組織は、メッセージの検証、廃棄、レポートに関するドメイン レベルのポリシーと基本設定を表現でき、メール受信側の組織は、それらを使用してメールの処理を改善できます。 また、SPF および DKIM チェックに失敗したメッセージをメール受信者が処理する方法を指定するためにも使用されます。 これにより、メールの配信可能性が向上し、メールのスプーフィングを防ぐのに役立ちます。

ARC (Authenticated Received Chain)

ARC プロトコル (RFC 8617) は、メッセージの管理の認証済みチェーンを提供します。これにより、メッセージを処理する各エンティティは、どのエンティティがそのメッセージを以前処理したかを特定でき、さらに各ホップでのメッセージの認証評価を特定できます。 ARC はまだインターネット標準ではありませんが、導入が増加しています。

メール認証のしくみ

メール認証により、送信者 (たとえば、notification@contoso.com) からのメール メッセージが正当であるか、そのメール ドメインの想定される送信元 (たとえば、contoso.com) から送信されたかどうかが確認されます。メール メッセージには、複数の発信元または送信者のアドレスが含まれる場合があります。 これらのアドレスは、さまざまな目的に使用できます。 たとえば、次のアドレスについて考えてみましょう。

  • 送信者 (Mail From) アドレスは、送信者を示し、メッセージの配信で問題が発生した場合に返信通知 (配信不能通知など) を送信する先を指定します。 これはメール メッセージのエンベロープ部分に表示され、メール アプリケーションでは表示されません。 これは、5321.MailFrom アドレスまたはリバース パス アドレスと呼ばれることもあります。

  • 差出人 (From) アドレスは、メール アプリケーションによって差出人 (From) アドレスとして表示されるアドレスです。 このアドレスにより、電子メールの作成者を識別します。 つまり、メッセージの書き込みを担当するユーザーまたはシステムのメールボックスです。 これは、5322.From アドレスと呼ばれることもあります。

  • Sender Policy Framework (SPF) は、ドメインから送信されたアウトバウンド メールが送信者本人から送信されたものであるか検証する場合に役立ちます。

  • DomainKeys Identified Mail (DKIM) により、宛先メール システムは、ドメインからアウトバウンドで送信されたメールのメッセージを信頼できます。

  • Domain-based Message Authentication, Reporting, and Conformance(DMARC) は、Sender Policy Framework (SPF) および DomainKeys Identified Mail (DKIM) と連携して、メール送信者を認証し、宛先メール システムがドメインから送信されたメッセージを信頼できるようにします。

DMARC の実装

SPF および DKIM と共に DMARC を実装すると、スプーフィングおよびフィッシング メールから強力に保護できます。 SPF は、DNS TXT レコードを使用して、特定のドメインに対する認証済みの送信側 IP アドレスのリストを提示します。 通常、SPF チェックは 5321.MailFrom アドレスに対してのみ実行されます。 したがって、SPF を単独で使用した場合、5322.From アドレスは認証されません。 このため、メッセージが SPF チェックに合格しても、そのメッセージが 5322.From 送信者アドレスを偽装している場合には、ユーザーは、そのメッセージを受信する可能性があります。

SPF の DNS レコードと同様に、DMARC のレコードは、スプーフィングとフィッシングの防止に役立つ DNS テキスト (TXT) レコードです。 DMARC TXT レコードは DNS で発行します。 DMARC TXT レコードにより、メール作成者の IP アドレスと、送信元ドメインの自己申告所有者が照合され、メール メッセージの配信元が検証されます。 この DMARC TXT レコードにより、承認済みの送信メール サーバーを識別します。 送信先メール システムでは、メッセージが承認済みの送信メール サーバーから発信されたことを確認できます。 これにより、ドメインから送信されたすべてのメールで 5321.MailFrom アドレスと 5322.From アドレス間の不一致が発生し、DMARC はそのメールに対して失敗します。 これを回避するために、ドメインに対して DKIM を設定する必要があります。

DMARC ポリシー レコードにより、ドメインは、メールで認証を使用すること、ドメインの使用に関するフィードバックを収集するメール アドレスを提供すること、認証チェックに合格しなかったメッセージの処理のための要求ポリシーを指定することを通知できます。 推奨事項は次のとおりです

  • DMARC レコードを発行するドメインのポリシー ステートメントは、可能な場合は “p=reject”、それ以外の場合は “p=quarantine” にします。
  • ポリシー ステートメント “p=none”、“sp=none”、pct<100 は、単なる遷移状態と見なす必要があり、できるだけ早く削除することを目標にします。
  • 発行対象の DMARC ポリシー レコードには、少なくとも、DMARC 集計レポートを受信するためのメールボックスを指す "rua" タグを含める必要があり、またプライバシー上の問題によりレポートを受信するときに返信を送信しないようにする必要があります。

次のステップ

次のドキュメントもご覧ください。