第４章

例えば、メール送信側として、送信ドメイン認証技術を導入したにもかかわらず、それ送信ドメイン認証技術導入手順

ン認証技術において、どのような意味があるのかについて補足して説明します。

が正しく運用されなければ、送信者情報を偽装していないにもかかわらず認証が失敗する

4.1.1 導入する送信ドメイン認証技術の決定

ようなメールが流通してしまう可能性があります。そのようなメールが多くなれば、その前述のとおり、送信ドメイン認証技術では、ドメイン名自体の信用も失われてしまう可能メールの送信側と受信側の双方が導入するこ性があります。

とによって、はじめて認証が可能になるため、また、メールの受信側では、送信ドメイン認証技術を利用することにより得られた認証送送側と受信側の双方での導入が同程度進むことが望ましいものです。

結果をどのように利用すべきなのかを考える導入のための費用は導入する技術によって必要があります。そのためには、実際のメー差があり、技術によっては送信側ではほとん

ルの配送形態でどのような認証結果が得られど費用がかかりませんが、いずれの技術でも、る可能性があるのかを正しく理解し、これら受信側での導入には受信時に認証するというメール配送の事情に合わせた検討が予め必要

新たな機能の追加が必要になるので、新たにになります。

費用か発生することになります。そのため、まず送信側の導入を増やすことによって、受以下では、送信ドメイン認証技術の導入に信側での認証可能なメールの割合を高め、導あたり、事前に検討すべき内容について具体入効果が得られやすい環境を作ることが普及的に解説するとともに、それらが送信ドメイを進めていくために必要となります。

図表４－２ 普及のサイクル

送信ドメイン認証技術のうち、送信側の導ればメールの送信ごとの処理が不要な入費用が低い技術は、ドメインを管理するSPF/SenderID です。そのため、導入費用のDNS 上に、導入時に SPF レコードを記述す

低さからも、まず SPF/SenderID の送信側の39

第４章

4.1.2.1 利用しているドメイン名の把握

送信ドメイン認証技術導入手順

うな方針 (discardable) を宣言することで、勝手にドメイン名を利用するようなメールを防まず、自組織内で利用しているドメイン名自体を正しく把握しなければなりません。

ぐことができます。DKIM ADSP については、3.4.6 を参照してください。

その際、メールに利用しているドメインについて把握することはもちろんですが、それ4.1.2.3 メールの配送経路の把握以外に、ドメイン名の構造上存在する上位ドメインや、メール以外の用途に使っている

次に、メールに利用しているドメインにつDNS で参照可能なドメイン名についても確いて、そのドメインを用いて送信されるメー認することが必要です。

ルの外部への配送経路を把握しなければなりません。

4.1.2.2 ドメインの利用方法の把握

配送される形態としては、大きく分けて、ドメイン名を把握したあとは、それぞれのドメインの利用方法を確認しなければなりません。
ドメインの利用方法は、メール利用の観点からは、大きく以下のように分類することができます。
(a) メールに利用しているドメイン名(b) メールに全く利用していないドメイン名

次の４つが考えられます。
(a) 単一ドメイン名を用いたメールを一つのメールサーバから配送(b) 単一ドメイン名を用いたメールを複数のメールサーバから配送(c) 複数のドメイン名を用いたメールを一つのメールサーバから配送(d) 複数のドメイン名を用いたメールを複数のメールサーバから配送(a) については、メールの配送経路を把握す(a) の場合には、そのドメインを利用するメること、適切な送信ドメイン認証技術の送信ールの出口（メールサーバ）が一つのメール側の設定をすることが必要です。メールの配サーバであることを、利用する送信ドメイン送経路の把握については、4.1.2.3 を参照して認証技術を用いて設定することになります。

下さい。
(b) については、SPF / Sender ID では、メ(b) の場合としては、送信効率を上げるためールに利用しないドメイン名であることをに複数のメールサーバを利用しているようなSPF レコードで宣言することができます。こ場合や、同じドメイン名を利用した特定のメの設定方法の詳細については、3.2.3 を参照しールの配信を外部委託しているような場合がてください。DKIM では 、DKIM ADSP であります。この場合にも、利用する送信ドメ

DKIM の認証結果をどのように扱うべきかをイン認証技術で、それぞれの送信側のメール示すポリシーを宣言できます。例えば、電子サーバが、そのドメインから配送されるメー署名が付与されていないメールを破棄するよ

ルの正しい出口（メールサーバ）であること

41

第４章

送信ドメイン認証技術導入手順を設定できます。

この場合には、それぞれのドメインが同じメールの出口を示すことで、受信側の認証に問(c) の場合としては、メールの利用目的別に題は生じません。複数のドメインを併用している場合や、組織なお、いずれの形態であっても、メールがごとにサブドメインを利用しているものの、外部に配送される前に、そのメールで利用さ全体の規模としてそれほど大きくないために、れるドメイン名の利用権限を送信者が適切にメールサーバを集約している場合などが考え有しているかを、何らかの方法で確認するこられます。また、メールサービスを外部の複とが必要です。この確認が適切に行われてい数の組織 (ドメイン名) に提供している、いわないと、利用権限のない者がドメイン名を詐ゆるホスティングサービスの場合などもあり称して不正なメールを外部に配送することがます。さらに、(b) のメール配送業務を複数受できてしまいます。こうしたことが行われる託し、複数のドメイン名を送信者情報としてと、送信ドメイン認証技術を設定していたこ利用する場合も、この形態に含まれます。

とによって、受信側のメールサーバで、詐称されたメールの認証に成功してしまい、かえって問題となってしまいかねません。

図表４ー４ 送信者情報の利用権限の確認(d) の場合には、クラウドサービスを用いたしなければなりません。

ホスティングに多く見られる形態で、複数の具体的には、メールの配送経路の方針、再ドメインで複数のサーバを共有している場合配送を行うメールの利用方針、複数のドメイがあります。また、(b) と (c) の組合せのケンを利用する場合の方針、外部ネットワークースもあります。これらの場合には、(b)、(c)から利用する場合の方針のそれぞれについてにおける対応を組み合わせることで正しい設決定が必要です。

定が可能です。
4.1.3.1 方針検討の必要性4.1.3 メールの利用方法の確認

メールの送信に利用するドメイン名と、実際事前準備の最後に、メールの利用方針を決定

42のメールの配送経路は、これまで比較的柔軟第４章

送信ドメイン認証技術導入手順に運用されてきました。しかし、迷惑メール- 外部ネットワークからの利用環境の整備がメール流量の大部分を占めるようになって（4.1.3.4）

きた現在では、正しいメールが適切に受信できるようにするために、メールの利用方針を4.1.3.2 メールの配送経路適切に決定し、運用することが必要です。
送信ドメイン認証技術が適切に機能するよ

メールの利用形態としては、（典型的なものうにするためには、正規に送信されるメールとして）１対１のコミュニケーションを目的が、送信側で利用するドメイン名に対応したとしたものがあります。そのような場合には、正しい出口（メールサーバ）からのみ配送さ送信に用いられるメールサーバが特定できまれるようになっていることが重要になります。

すので、送信ドメイン認証技術の導入にあたっても、そのメールサーバを利用ドメイン名技術革新に伴い、メールの利用形態は多様化してきています。例えば、携帯電話の通信の出口（メールサーバ）として設定することになります。

網を利用したデータ通信端末や無線 LAN のメールの利用形態には、そのような一般的アクセスポイントなどモバイル環境は急速になメール配送以外にも、顧客へのアナウンス普及してきており、それに伴い、これらの回や特定の参加者への連絡網といった多数の宛線を利用したメールの利用も増えてきていま先への一斉送信などがあります。メールの大す。

規模配信を行う場合には、送信中に通常のメまた、業務として利用するメールや、個人ールが阻害されたりすることがないように専で利用しているメール、ウェブメールなどア用のメールサーバを利用することがあります。

クセス端末をあまり選ばずしかも無料で利用

また、こうした配送処理を効率よく行うため可能なメールなど、同一の個人が複数のメーに、専門の外部事業者へ委託することがありルアドレスを利用するようになっています。

ます。これらの場合に利用する送信者情報のドメイン名については、次の２つの考え方がこうしたメールの利用形態の多様化を踏まあります。

え、それぞれのドメインごとにメールが適切(a) 大量送信用の専用ドメイン名を利用に受信できるようにするための対応が必要と(b) 通常のメールと同じドメイン名を利用なりますが、それについては、技術的に対応可能な部分や、利用方針に基づく運用によるべき部分もあります。

(a) としては、サブドメインを新たに作成する場合や、別のドメイン名を取得する場合

以下では、メールの利用方針を決定し、そなどが考えられます。この場合には、専用ドれに基づく運用を適切に行う必要がある部分

メイン名を使って配送する出口（メールサーとして、次の点について、詳細に検討します。

バ）を特定し、それぞれのメールサーバで適- メールの配送経路（4.1.3.2）

切な送信ドメイン認証技術を導入することに- 再配送メールの取り扱い（4.1.3.3）

なります。

43

第４章

送信ドメイン認証技術導入手順

た上で再配送したり、正しく認証できたメー信手段を用意し、内部ネットワークにアクセルだけを再配送したりするなどの考慮が必要

ス可能にする方法や、外部ネットワークからです。

アクセスできる位置に送信メールサーバを用意する方法などがあります。

4.1.3.4 外部ネットワークからの利用環境の整備

このような場合には、ネットワーク接続に利用している回線が OP25B を実施しているモバイル環境や社外滞在先など、外部ネッ可能性がありますので、メール配送に使われトワークからメールを送信することがありまる 25 番ポートではなく、メール投稿用のす。

587 番ポートを使えるように設定することが自組織で運営している送信用のメールサー必要です。また、送信者を正しく識別するたバは、通常、セキュリティ上の観点からファめに、SMTP AUTH (送信者認証) による認証イアーウォールなどを用意し、インターネッを行うべきであり、認証方式についても、パト側から直接通信ができないような内部ネッスワードがそのままネットワークに流れないトワークに設置されています。そのため、外方式 (例えば CRAM-MD5 など) を利用すべ部ネットワーク上からメール送信を行うこときです。

を可能とするためには、別途 VPN などの通図表４ー６

SMTP AUTH による認証

最近では、ホテルなどの環境でもインターわれる 25 番ポートを用いて直接インターネ

ネット接続サービスが提供されるようになっットへの通信ができず、一度アプリケーショてきていますが、これらの環境では特に注意ン型のファイアーウォールなどで通信が終端が必要です。されていることがあります。そのため、外部

特に、欧米のホテルなどでは、ネットワーからアクセス可能な送信用メールサーバを用クの不正利用を防ぐ目的で、メール配送に使意している場合で、MUA からは通常どおり送

45

第４章

送信ドメイン認証技術導入手順

信が行われたように見えても、実際には自組た、受信側で認証を行うことにより DNS の織の送信用メールサーバを経由せず、ホテル参照回数が増えるため、ネットワーク帯域やなどが用意しているファイアーウォールからDNS のキャッシュサーバの負荷などの考慮送信される場合があります。この場合には、も必要になります。

メールの受信側では、受信したメールが、そ一般にメールの流量は、時間帯によってばのメールのドメインの本来の出口（メールサらつきがありますし、ピーク時に極端に負荷ーバ）から送信されているメールではないたが高くなる場合もあります。導入に際しては、めに、認証が失敗することがありますので、予め一定の期間の負荷状況を計測し、予想さ注意が必要です。

れる負荷の上昇分を重ねた上で、設備設計を行うことが必要です。

4.1.4 導入計画の作成4.1.4.2 受信メールの傾向調査

送信ドメイン認証技術の導入に際しては、技術自体の違いやそれに関連した運用上の特受信側では、広く受信メールの傾向を調査

徴以外に、より実際的な側面についても検討することによって、導入する技術の判断に役し、具体的な導入計画を作成することが必要立てることができます。例えば、既に送信者です。

情報を詐称したメールに困っている場合や、その検討の際には、以下に挙げた観点が参取引先など受け取るべきメールが把握できて考になるでしょう。

いる場合には、認証の効果を予め予測するこ(a) メールサーバの負荷調査とができます。予め受け取るべきメールが明(b) 受信メールの傾向調査

確である場合は、それらのメールの送信側で(c) 認証結果の取り扱い導入している技術を受信側でも導入するべき(d) 効果の予測と見直しです。

(e) 利用者への周知

送信側についても、受信側で認証している(f) 導入手順の策定

技術が予め分かる場合には、導入に際して、参考となるでしょう。

4.1.4.1 メールサーバの負荷調査4.1.4.3 認証結果の取り扱い

メール送信側に DKIM を導入する場合や、46

メール受信側で認証を行う場合には、メール受信側では、認証の結果の利用方法も予めサーバに新たな機能を追加することが必要で決めておくことが必要です。メールヘッダにす。この機能追加により、メールサーバの負認証結果を示すだけなのか、認証が成功した荷が高くなりますので、導入前には既存のメ特定のドメインをホワイトリスト的に優先的ールサーバの負荷状態を把握することが必要に配送するのか、誤認証の可能性がないドメです。CPU などのリソースの負荷は、いずれインで認証が失敗した場合に隔離するのかなの技術を導入する場合でも高くなります。まど、認証結果を有効利用する方法はいくつか

第４章あります。受信メールの傾向調査と合わせて、送信ドメイン認証技術導入手順

4.1.4.5 利用者への周知と導入手順の策定

それぞれの認証結果と送信元のドメインに応じた、効果的な取り扱いの方針を決めることになります。

送信ドメイン認証技術を導入する際には、予めメールの利用者に対して、送信側及び受信側また、メールは多様な用途で用いられるたでの運用ポリシーを事前に説明しておくこともめ、メールシステム全体で一律に適用できな必要です。特に送信側の利用ポリシーについてい認証結果に基づいた処理も、個々のメールは、送信ドメイン認証技術の対象としているド受信者が MUA などで個別に設定することにメイン以外のドメインを送信者情報として利用より、認証結果を有効に利用できる場合があしないよう周知しておくことが重要です。メー

ります。メールサービス提供者やメールシス

ルの受信側で認証が失敗するような使い方をしテムの管理者は、こうした設定例などをマニてしまうことによって、そのドメインやメールュアル等で利用者に周知すると良いでしょう。

の送信元の評価が低下してしまう可能性があります。

4.1.4.4 効果の予測と見直し

また、メールは絶え間なく送受信されてい受信側では、事前に受信メールの調査を行ることから、メールシステムへの送信ドメイうことにより、認証による効果を予測するこン認証技術の導入やそれに基づく新たな機能とができます。また、送信ドメイン認証技術追加、仕様変更などは、頻繁にできない場合を導入するメールサーバは、今後も増えてくもあります。このため、手順を決めて、計画ることが予想されますので、導入時だけでな的に導入を進めることが必要です。

く、継続してメールの傾向を把握することがさらに、メールを送受信している相手の導有効です。これは、導入時には見送った技術入状況も変化していきますので、日頃のメーがより機能するようになっていたり、認証結ル送受信の状況の把握とともに、その結果に果をより効果的に活用できるようになってい基づいた新たな機能追加や仕様変更などの見たりするなどによるものです。

直しについて、予め計画を立てることも必要となります。

47

第４章

送信ドメイン認証技術導入手順

4.2 一般的な導入手順

うな場合には、4.1.3.2 で示したようにメールの配送経路 (出口) を正しく把握した後、それ送信ドメイン認証技術には、ネットワークをもとに SPF レコードを記述することにな方式の SPF/SenderID と、電子署名方式のります。この場合、送信側の導入に際して特DKIM の二つの技術があります。それぞれの別な費用は発生しません。

技術についての概要、導入に際しての注意点については、第 3 章で解説しています。

メールの運用自体を外部委託している場合や ISP のメールサービスを利用している場

ここでは、一般的な導入手順について、送合には、第 5 章以降を参考に、それぞれ設定信側での対応を中心に、それぞれの技術ごとして下さい。なお、DNS の運用を外部委託しに解説します。また、導入に際して既存のメていて、自由に編集が行えないような場合にールの使われ方との関係や、問題が生じる場

は、委託先に SPF レコードの設定依頼が必合の対処方法について解説します。

要になりますので、送信側の導入に際し、費用が発生する場合があります。

4.2.1 SPF/SenderID

SPF/SenderID を受信側に導入し、メールのSPF と SenderID は、送信者を認証するた

受信時に認証するためには、受信メールサーめに送信元の IP アドレスを利用するネットバへの新たな機能追加が必要になります。すワーク方式であること、認証のために送信側なわち、受信側での認証を行うためには、送のドメイン (DNS) 上にある SPF レコード信元の IP アドレスが必要になりますので、を利用するなど、多くの共通点があります。

原則として、外部から直接メールを受けるサ

ここでは、両方の技術について、導入手順のーバ上に認証機能を追加する必要があります。

ほか、そのままでは認証がうまくできない課

例えば、迷惑メールフィルタ機能を提供する

題と対処方法などについて解説します。

サーバで、送信ドメイン認証機能も提供するものがありますが、その機能を用いるために

4.2.1.1 SPF/SenderID の導入手順

は、そのサーバが外部からのメールを直接受ける位置にあるかどうかの確認が必要です。

SPF/SenderID を送信側に導入するためにオープンソースの MTA として広く使われは、対象とする送信者情報のドメインに対している Sendmail や Postfix では、MTA の拡て SPF レコードを宣言することが必要にな張機能を外部プログラムとして追加できるよります。

うに、milter インターフェースが標準で提供されています。この milter インターフェース

48

DNS サーバを自組織で管理している場合を利用した認証機能を実現するものが、同様や、運用を委託しているサービスで、DNS のにオープンソースとして公開されていますの資源レコードをある程度自由に編集できるよで、それを利用することもできます。

第４章

送信ドメイン認証技術導入手順商用のメールサーバを利用している場合やせて下さい。その場合には、認証機能の追加外部のメールサービスを利用している場合にには、新たに費用が発生する可能性がありまは、その開発元やサービス提供元に問い合わすので、確認が必要です。

図表４－７ SPF/SenderID の導入

4.2.1.2 課題と対策信者情報をそのままにして、新たな受信者へメールを再配送してしまうことに起因する問ネットワーク方式の送信ドメイン認証技術

題です。

は、メールの再配送時に認証が失敗してしま

具体的な事例としては、メール転送や古いうという問題があります。これは、メールの実装のメーリングリストサーバで発生するこ

再配送時に、メールを一旦受け取った後、送とがわかっています。

図表４－８ メール再配送による認証失敗の例

49

第４章

送信ドメイン認証技術導入手順

この問題を回避するには、メールの再配送時に、送信者情報をメールの再配送元のドメインに書き換える必要があります。

用する方法があります。
この場合、転送時にすべてのメールのリバースパスを単純に書き換えてしまうと、メールがループする可能性がありますので、転送現時点でそれほど広く運用されているもの

時に利用するリバースパスは、転送者のメーではありませんが、メールの転送に関しては、ルアドレスをそのまま利用するのではなく、以下の方法を用いることで、転送先でも正し

例えば、図表４-9 のように、メールアドレスく認証を行うことができるようになります。

のローカルパート部分を工夫して、エラーメールとして戻ってきた場合や、さらに再転送

まず、SPF の場合には、リバースパスを送されてきた場合に区別ができるようにするこ

信者情報として認証しますので、転送時に認とが必要となります。このようにすることで、証が失敗しないようにするために、転送を行転送したメールが何らかの事情で戻ってきたう際のリバースパスとして、元の送信者のリ場合に、さらに転送を繰り返さないことによバースパスを利用するのではなく、転送元（転り、不要なループを防ぐことができます。

送者）のドメインを含むメールアドレスを利

図表４ー９

メール転送への対応の例

Sender ID の場合には、送信者情報としてPRA を用いて認証しますので、メールの転送

50

メーリングリストに関しては、リストメン

時に、PRA で優先的に使われるヘッダ

バの管理のために、エラーメールの送信先を(Sender ヘッダなど)に、転送元のドメインを示すリバースパスには、メーリングリストの含んだメールアドレスを送信者情報として付管理用のメールアドレスを指定するようにな加すれば問題ありません。

っています。そのため、SPF では、リストメ

第４章

送信ドメイン認証技術導入手順

ンバ側で認証が失敗するようなケースはほとの MTA である Sendmail や Postfix のんどなくなっています。

milter インターフェースを利用することによ

しかし、一部の古い実装のサーバプログラムのメーリングリスト機能では、PRA としてり、DKIM の電子署名の作成機能を追加することができます。

From ヘッダより優先度の高いヘッダを付け

DKIM では、電子署名の作成に公開鍵暗号ないものがあり、そうした実装では、SenderID技術を使いますので、予め電子署名を作成すでは、リストメンバ側で認証が失敗してしまるときに利用する秘密鍵と、電子署名を検証います。

するために利用する公開鍵を用意する必要がこのため、メーリングリスト機能を使う場あります。オープンソースの OpenDKIM プ

合には、メーリングリスト側からメンバへのロジェクトでは、これら鍵のペアを作成する

送信時に、Sender ヘッダなどにメーリングリスクリプトプログラムもソースコード一式のスト管理用のメールアドレスを追加する機能中に含まれていますので、これを利用して鍵を持った、最近の実装のサーバプログラムをペアを生成することもできます。商用のメー利用することが推奨されます。

ルサーバを利用している場合や外部のメールサービスを利用している場合には、その開発

4.2.2 DKIM元やサービス提供元に問い合わせて下さい。
DKIM を送信側に導入するためには、新たに費DKIM では、送信者情報が正しく表明されているかどうかを、公開鍵暗号方式を利用し用が発生する可能性がありますので、確認が必要です。

た電子署名を検証することによって認証します。このため、ネットワーク方式とは異なり、DKIM を受信側に導入する場合には、メールメールの配送経路に影響を受けないという大サーバに対して、電子署名を検証し、認証処きな利点があります。その反面、メールの送理を行う機能の追加が必要になります。信側にも電子署名を作成して添付する負担が生じます。
ここでは、DKIM の導入手順のほか、運用上課題となる点について解説します。

この受信側の認証機能も OpenDKIM プロジェクトで提供されています。商用のメールサーバやメールサービスを利用している場合で導入を検討している場合には、提供元に確認が必要です。送信側への導入と同様に、新4.2.2.1 DKIM の導入手順たに費用が発生する可能性がありますので、確認が必要です。

DKIM を送信側に導入するためには、メールの送信時に電子署名を作成し、それをメールヘッダ(DKIM-Signature) として追加する機能が必要になります。
SPF/SenderID と同様に、オープンソース

51

第４章

送信ドメイン認証技術導入手順きないことになります。その結果として、受4.3 運用

け取ったメールがたまたま電子署名の対象としていないメールだったのか、誰かが詐称し送信ドメイン認証技術を導入後にも、その効て送ってきたメールなのかの判断ができない果を維持するために、日々正しく運用することことになります。この点は、メールにもともが必要です。メールシステムの管理者は、受信と備わっている送信者情報を利用する側に必要とされるメールを正しく送信すること

SPF/SenderID と DKIM の大きな違いの１により、そのドメインの信頼性を高めていくこつです。

とができます。また、送信ドメイン認証技術でこの問題に対応するため、DKIM には、3.4.6は、メールサーバだけでなく DNS も重要な役で解説した DKIM ADSP の仕組みが追加され割になっていますので、DNS が正しく機能するました。送信側で ADSP を表明することにより、ような運用が必要になってきます。

送信する全てのメールに電子署名が添付されているはずなのか (dkim=all) 、一部だけなのか4.3.1 メールサーバの運用（dkim=unknown)を送信側が示すことができます。

送信ドメイン認証技術は、送信者情報が詐称

しかし、この対応策については、まだ問題がされているかどうかを認証する技術ですが、認残っています。3.4.6.2 で解説したとおり、ADSP証されたドメインが、必要なメールを送信してを表明するのは、From ヘッダ上のメールアドいるドメインなのか、迷惑メールを送信するドレスのドメイン名のサブドメインですので、メメインなのかまでは判断しません。

ール配信を請け負う事業者が、顧客のドメインそのため、受信側での迷惑メール対策としてを From ヘッダに利用し、実際の電子署名の作は、送信ドメイン認証技術による認証に加え、成を事業者側が行うような、いわゆる第三者署ドメイン自体を評価する仕組みが別途必要にな名をどう認証するのか、が問題となります。まります。

た、同様のケースとして、メーリングリストの問題もあります。

また、送信側では、送信ドメイン認証技術を導入しても、そのメールサーバから実際にDKIM は、ドメインを自ら管理し、そのドメ迷惑メールが送信されてしまえば、ドメインインを送信者情報及び署名者情報として使う場の信用は低下してしまいます。そのため、せ合には、とてもうまく機能しますが、メールのっかく送信ドメイン認証技術を導入したにも利用形態は多様化していますので、それぞれのかかわらず、評判の悪いドメインだと判断さ使い方にうまく適合させるための工夫も必要にれないように、関係のない第三者が勝手にメなってきています。現在もこうした議論は続いールサーバを利用できないようにきちんと設ておりますので、こうした問題をうまく解決し、定し、管理することが必要になります。例え適合できるようになることが期待されます。

ば、SMTP-AUTH のパスワードに安易な文字列を設定できないようにしたり、自らのメールサーバを利用するメール送信者の PC に不正プログラム (マルウェア) が混入されて54

第４章

送信ドメイン認証技術導入手順

パスワードが漏洩しないようにしたりという刻な問題となる可能性があります。 3.2.4.3対策を講じなければなりません。また、業務で解説したとおり、SPF や Sender ID での的なものを除いて短時間で大量にメールが送SPF レコードの記述方法で、DNS の参照回信されていないか、短時間で地理的に離れた数に上限が決められているのも、受信側での場所からメール送信されていないかなどの監認証時の処理を軽減させる意味が含まれてい視等も必要になる場合もあります。

ます。

4.3.2 DNS の運用

送信側のドメインの管理元は、DNS の状態を監視したり、きちんと運用体制が整ってい送信ドメイン認証技術では、送信側から受る外部のサービスプロバイダを利用したりす

信側へ伝える、認証に必要な各種情報を DNSるなど、 DNS の維持管理を心がけるべきでを利用して受け渡しします。そのため、メーす。

ルの送信側ドメインの DNS が常に正しく動作していることが必要です。
4.3.2.1 DNS の状態監視

4.3.2.2 DNS の TTL

DNS では、問合せを高速に処理するために、キャッシュの仕組みがあります。このキャッ送信側の DNS に何らかの問題があり、受シュの仕組みとその TTL は、SPF レコード信側で、SPF レコードや DKIM の公開鍵のや DKIM の公開鍵の変更時の伝播時間と密情報が取得できなかった場合には、認証結果接な関係があります。TTL の値を大きくする

は temperror (一時的な失敗) となり、正しくことで、送信側ドメインの DNS へのアクセ認証できません。認証結果の temperror を受ス回数を少なくする ことができますが、一方信側でどのように扱うかにもよりますが、送で SPF レコードや DKIM の公開鍵や DSP

信側で送信ドメイン認証技術に関する情報をレコードを変更した場合に、受信側のメール正しく設定していたとしても、利用しているサーバに反映されるまでに時間が長くなってDNS が不安定だったり、何らかの問題があっしまいます。

て正しく情報が引き出せない状態にあったり送信側のドメインで、これら DNS 上の情

すると、場合によっては受信側で受け取って報を変更する場合には、予め利用しているもらえないことになり、送信ドメイン認証技

DNS の TTL 値を把握したうえで、その時間術を導入していない場合よりも悪い結果となに合わせて十分情報が伝播した後に、システる可能性もあります。

ムの変更や鍵の変更をする必要があります。

また、送信側の DNS からの応答が遅かっ

DNS の TTL 値の変更が可能な場合には、前たり、応答を返さないなど不安定な状態にあもって TTL 値を短い時間に設定しておくと、ったりする場合には、受信側での認証処理に変更作業までの時間を短くすることができま負荷がかかる原因になります。特に、大量のす。

メールを受けているメールの受信者には、深55