DKIMドメインのアライメントの失敗 - RFC 5322による修正

RFC5322のアライメントエラーは、"From: "ヘッダーのドメイン（ユーザーから見える）とDKIMのd=ドメイン（署名内）が一致しない場合に発生する。DMARCは、"From: "ヘッダーのドメインがSPFまたはDKIMによって認証されたドメインと一致することを要求する。

DKIMは、電子メールが転送中に操作されたかどうかをチェックするのに役立ちます。DMARCの目的上、DKIMは電子メールを送信したと主張するドメインの身元も認証します（d=を介して）。DMARCは、電子メールメッセージの「From:」アドレスが、SPFおよびDKIMによって認証されたドメインと一致するかどうかをチェックします。

RFC 5322とは？ 

RFC 5322は、"From: "ヘッダーを含むインターネットEメールヘッダーの構文を定義している。DKIMとDMARCは、認証のためにこれらのヘッダーに依存している。一方SPFは、RFC 5321に従ってエンベロープの送信者（MAIL FROM）をチェックする。RFC 5322は2008年10月に発行され、現在では電子メールのヘッダーと本文をフォーマットするための標準となっている。 

アライメント要件がなければ、攻撃者は単に有効な SPF またはDKIMレコードを悪用しつつ、別のドメインの「From:」アドレスを偽装することが可能でした。整合性要件が導入されたことで、ハッカーの攻撃は格段に困難になります。ドメインが一致しない場合、DMARC認証は失敗し、メールはスパムフォルダに振り分けられるか、完全に拒否されることになります。 

DKIMドメイン・アライメントとは？

DKIMドメインアライメントとは何かを最もよく理解するためには、まずDKIMがどのように機能するかを理解することが役に立つだろう。 

DKIMとは何か？

DKIM（DomainKeys Identified Mail）とは、個人または組織が電子メールの送信に責任を持つことを可能にする電子メール認証プロトコルである。メールボックス・プロバイダが電子メールが転送中に操作されていないことを確認するためにチェックできるデジタル署名を追加します。

電子メールを送信する際、送信ドメインは秘密鍵で送信メッセージに署名する。その後、受信サーバーは、ドメインのDNSで公開されている公開鍵の助けを借りて署名をチェックする。 

DKIM署名の重要な要素である「d=」タグは、メッセージに署名する責任を負うドメ インを指定する。このドメインはDKIMヘッダーに含まれ、受信サーバーが検証のために公開鍵をチェックするのに使われる。

の違いである。 リラックスと ストリクトDMARCのアライメントモード

DMARCアライメントは、"From: "ヘッダーのドメインが、SPFまたはDKIMによって認証されたドメインと一致することを保証します。DMARCには、relaxとstrictの2つのアライメントモードがある。

• アライメントの緩和：From: "ヘッダーのドメインは、SPFまたはDKIM認証で使用される組織ドメインと一致する必要があります。これは、より「寛容」で柔軟なモードで、サブドメインやサードパーティのメールサービスを使用する場合に特に便利です。
• ストリクトアライメント： ストリクトアライメントモードの場合、"From: "ヘッダーのドメインは、SPFまたはDKIM認証で使用されるドメインと完全に一致する必要がある。

DKIMとRFC 5322のアライメントが重要な理由

DKIMとRFC5322のアライメント要件の主な目的は、不正アクセスを防ぐことである。 

核心的問題DMARCのアライメント要件

DMARCは、電子メールの "From: "ヘッダーのドメインが、DKIM署名の "d="フィールドで指定されたドメインと少なくとも部分的に一致することを要求する。厳格なアライメントでは、ドメインは完全に一致しなければならない。リラックスアライメントでは、少なくとも同じ組織ドメインを共有する必要があります。

よくあるミスマッチのシナリオ

よくあるミスマッチのシナリオをいくつか紹介しよう： 

マーケティング・ツールの活用

マーケティングツールは、しばしば[email protected] などのアドレスからメールを送信しますが、DKIM「d=example.com」ドメインで署名します。このような状況では、DKIMアライメントが厳格なアライメント（adkim=s）に設定されていると、DKIM署名のアライメントに失敗する可能性があります。

電子メールの転送 

通常、転送はDKIMよりもSPFに大きな影響を与えますが、DKIMも転送中に失敗する可能性があります。ただし、メッセージが変更された場合（メーリングリストなどによる）に限ります。なお、「From:」ヘッダーが転送元によって変更されることは稀です。

ここにズレの例を挙げる：

• From: [email protected] (RFC 5322 ヘッダー)
• DKIM-Signature: d=example.com (ドメインがずれており、DMARCは失敗)

アライメント問題の一般的な原因

アライメント不良の最も一般的な原因には、以下のようなものがある： 

サードパーティ・サービスの利用

ドメインアライメントが適切に設定されていないサードパーティの外部プロバイダ経由でメールを送信すると、DKIMドメインRFC 5322のアライメントに失敗する可能性があります。 

DKIMレコードの設定ミス

DKIMレコードやセレクタの設定が間違っていると、ズレが生じやすくなります。ちょっとした設定ミスでも、メール配信に影響を与える大きな失敗につながる可能性があります。 

ドメインの矛盾

DKIM署名と「From:」ヘッダーで異なるドメインを使用している場合、RFC 5322のFromヘッダーの不一致が発生しても不思議ではない。ドメインの不一致が、見落としや設定ミスによるものであれ、意図的に設定したものであれ、どちらの場合でも、不一致とその後の問題が発生する可能性は高い。 

RFC 5322のアライメントの失敗を診断する方法

RFC 5322のアライメントの問題を診断するための2つの簡単なステップをご紹介します。

1. RFC 5322のアライメントの失敗を診断したい場合は、まず、DMARCのレポートを注意深く確認してください。 DMARCレポートを注意深く確認してください。
2. 次に、次のような電子メール認証ツールを使用することができます。 DKIMチェッカーやdigコマンドなどのメール認証ツールを使ってDNSレコードを確認します。これにより、DKIM署名が適切に発行され、送信ドメインと一致していることを確認できます。

DKIM-RFC 5322の不整合を修正する方法

ここでは、DKIM-RFC 5322のずれを修正するための、簡単に実行できる手順をいくつか紹介します。

1.DKIMドメインとFromドメインの一致

DKIM署名は常に"ヘッダーと ヘッダーと同じドメインを使用するようにしてください。これは、あなたのドメインから直接送信されるメールに最適です。

2.アライメントモードを設定する

お客様の好みとニーズに最も適したアライメントモードを設定してください。DMARCポリシーで、厳格なアライメント（完全一致が必要な場合）にはadkim=sを、緩やかなアライメント（サブドメインも許可する場合）にはadkim=rを使用してください。

3.サブドメインのDKIMキーを追加する

From:」アドレスにサブドメインを使用している場合は、そのサブドメインを使用してメッセージに署名するようにDKIMを設定するか、DMARCのアライメントモードを適宜調整してください。

4.最初の "From: "ヘッダーを保持する。 

メッセージヘッダ内の元の「From:」ドメインを保持するように、メールサービスを設定する必要があります。電子メールの転送中に、仲介者が意図せずに「From:」ヘッダーやメッセージの他の部分を変更し、DKIMのアライメントを壊し、DMARCの失敗を引き起こす可能性があります。元の "From: "ヘッダーを維持することで、ドメインアライメントを維持することができ、以下のように組み合わせることができる。 ARC (Authenticated Received Chain)と組み合わせることで、仲介者の変更にもかかわらず、受信者サーバーがメッセージの正当性を評価するのに役立つ追加の認証コンテキストを提供することができる。

5.テストと検証

テストと検証は、しばしば見落とされがちだが、プロセスにおける重要なステップである。ドメインのアライメントとDKIMのセットアップをチェックするために使用できる、自由にアクセスできるツールがたくさんあります。このようなツールを使用することで、DMARC認証がパスし、メッセージが意図した受信者に確実に配信されるようになります。 

プロのアドバイス

エラーのないアライメントを実現するためのヒントは以下の通りです。

SPF + DKIM アライメント

DMARCは、RFC 5322.Fromヘッダーのドメインを、SPF（MAIL FROM）およびDKIM（d=）によって認証されたドメインと比較する。 

サードパーティ製ツールによるヘッダーの破損を避ける

ヘッダーを改ざんするようなサードパーティのEメールサービスプロバイダー（ESP）は使用しないようにしましょう。本格的な導入に移る前に、ESPのコンプライアンスをテストすることができます。そうすることで、配信に関する問題を回避しながら、コンプライアンスを確保することができます。

まとめ 

RFC 5322のアライメントエラーは、特にメールマーケティングツールの使用時やメール転送時に、様々な状況で発生する可能性があります。最も一般的な原因としては、サードパーティサービスの使用、DKIMレコードの設定ミス、ドメインの不一致などが挙げられます。 

DMARCレポートアナライザでRFC 5322のアライメント失敗を簡単に診断でき、視覚的で人間が読めるDMARCデータから認証の問題を素早く検出・特定できます。 

PowerDMARCは、エラーのない電子メール認証への旅を開始し、アライメントの失敗を防止するのに役立ちます。まずは 15日間無料トライアルをお試しください！

• について
• 最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• SOAシリアル番号の形式が無効です：原因と解決方法 - 2026年4月13日
• Gmailで安全なメールを送信する方法：ステップバイステップガイド - 2026年4月7日
• Outlookで安全なメールを送信する方法：ステップバイステップガイド - 2026年4月2日