次の方法で共有

送信者認証のサポートに関するベスト プラクティス

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

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

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

MX (Mail Exchange) レコード

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

SPF (送信者ポリシーフレームワーク)

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

DKIM (ドメイン キー識別メール)

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

DMARC (ドメイン ベースのメッセージ認証、レポート、準拠)

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

ARC (認証済み受信チェーン)

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

電子メール認証のしくみ

電子メール認証では、送信者からの電子メール メッセージ ( notification@contoso.com など) が正当であり、その電子メール ドメイン (たとえば、contoso.com) の想定されるソースから送信されていることを確認します。

電子メール メッセージには、複数の送信元アドレスまたは送信者アドレスが含まれている場合があります。 これらのアドレスは、さまざまな目的で使用されます。 たとえば、次のアドレスを考えてみましょう。

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

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

  • Sender Policy Framework (SPF) は、送信ドメインから発信されるメールが正しい送信元からのものであることを検証するのに役立ちます（言われている通りの送信元から来ていることを確認する）。

  • DomainKeys Identified Mail (DKIM) は、宛先メール システムがドメインから送信されたメッセージを信頼するのに役立ちます。

  • ドメイン ベースのメッセージ認証、レポート、および準拠 (DMARC) は、送信者ポリシー フレームワーク (SPF) と DomainKeys Identified Mail (DKIM) と連携して、メール送信者を認証します。 この方法により、宛先メール システムはドメインから送信されたメッセージを信頼できます。

DMARC の実装

SPF と DKIM を使用して DMARC を実装すると、スプーフィングやフィッシングメールに対する高度な保護が提供されます。 SPF は DNS TXT レコードを使用して、特定のドメインに対して承認された送信 IP アドレスの一覧を提供します。 通常、SPF チェックは 5321.MailFrom アドレスに対してのみ実行されます。 つまり、SPF を単独で使用する場合、5322.From アドレスは認証されません。 これにより、SPF チェックに合格してもスプーフィングされた 5322.差出人アドレスを持つメッセージをユーザーが受信できるシナリオが可能になります。

SPF の DNS レコードと同様に、DMARC のレコードは、スプーフィングやフィッシング詐欺を防ぐのに役立つ DNS テキスト (TXT) レコードです。 DNS で DMARC TXT レコードを発行します。 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 タグが含まれている必要があります。また、プライバシー上の懸念があるため、レポートを受信するときに返信を送信しないようにする必要があります。

次のステップ