第３章

3.2 Sender Policy Framework (SPF)

送信ドメイン認証技術

カテゴリの RFC（RFC4408） として標準化されています。SPF では、リバースパスを元3.2.1 概要に認証を行います。

Sender Policy Framework （SPF）は、元

3.2.2 SPF の仕組み

Pobox 社の Meng Wong 氏により提唱されたネットワーク方式の送信ドメイン認証技術です。SPF は、IETF の MARID WG 等におSPF の動作の概要を、図表２−４に示します。

いて数々の議論と検討を経て、現在、実験的

図表３－１

SPF による認証の仕組み

送信側では、あらかじめ、自ドメインののメールサーバ（認証対象のメールサーバ）

DNS サーバ上に、自ドメインの送信者がメーの IP アドレスが、一致するか確認すること

ルを外部に向けて送出する可能性のあるメーで、認証を実施します（図表３－１の③）。

ルサーバの IP アドレスの一覧を公開します（図表３－１の①）。これを「SPF レコード」

3.2.3 送信側の設定と呼びます。
受信側では、メールの受信時に、送信者とメールの送信側では、DNS 上で SPF レコして指定されたリバースパスのドメイン部分ードを公開するだけで SPF の運用を開始でに示されるドメインの DNS サーバより、きます。RFC4408 では、SPF レコードは、SPF レコードを取得します（図表３－１の

DNS の TXT レコードか SPF RR レコード②）。そして、その SPF レコードに指定され（以下「SPF 資源レコード」といいます。）ている IP アドレスと、 SMTP で接続した先として公開することが定められています。た17

第３章

送信ドメイン認証技術

だし、現時点では、SPF という新しい RR レ

SPF レコードには、当該ドメインに属するコード（以下「資源レコード」といいます。
）

メールアドレスを送信者として、そのドメイを取り扱えないリゾルバや DNS サーバの実ン外にメールを送信する可能性のあるメール

装 が 存 在 す る た め 、 SPF 資 源 レ コ ー ド とサーバ（MTA）の、外向けの IP アドレスのTXT レコードの両方を利用して公開します。

リストを記述します。

なお、SPF レコードは、SPF 資源レコードと TXT レコードとの両方を同時に公開可能

SPF では、IPv6 を含む IP アドレスを直ですが、SPF 資源レコードが存在する場合に接記述するほか、簡略に公開可能にする記述

は、受信側で、SPF 資源レコードのみを参照法が提供されています。SPF レコードの簡単すべきとされています。

な例を、図表３－２に示します。

例１） a. example.com.

IN TXT

例２） b. example.com.

IN TXT "v=spf1 +ip4:192.0.2.1 -all"例３） b. example.com.

IN SPF "v=spf1 +ip4:192.0.2.1 -all""v=spf1 -all"

図表３－２SPF レコード記述例

１つめの例は、a. example.com をドメイン記述方法の詳細は、3.2.4 で解説します。名 と し て 持 つ ア ド レ ス （ 例 え ば user@a.
example.com ）からは、一切メールを送信し3.2.4 SPF レコードの記述法ないことを意味するものです。
２つめの例は、b. example.com をドメイン

SPF レコードは、最初にバージョンを記述名として持つメールアドレス（例えば、し、空白（半角スペース）を入れて、定義をuser@b.example.com ） か ら の メ ー ル は記述します。定義は、空白（半角スペース）192.0.2.1 の IP アドレスを持つホストからので区切り、複数記述できます。

み送信されるという意味を持ちます。
３つめの例は、SPF 資源レコードとして公開した場合です。

バージョン 空白定義

空白 定義・ ・ （以下繰り返し）

図表３－３

3.2.4.1 バージョン

定義ードが、SPF のどのバージョンの文法にしたがって記述されているかを示します。

バージョン（Version）は、その SPF レコ

18

RFC4408 で定義されている SPF レコー

第３章

ドの文法はバージョン１のみであり、”v=spf1”と記述することとされています。それ以外の送信ドメイン認証技術

ディレクティブは、限定子（qualifier）と機構（mechanism）で構成します。

記述（例えば、”v=spf1.0” 等）をすると、そ

図表３－２の例 2 では、"-all" と "+ip4:の SPF レコードは不正なものとして、受信192.0.2.1" がディレクティブです。 "-all" の側で、無視されることになります。

うち、"-" が限定子で、"all"が機構です。また、重要な点は、RFC で定められた文法に従わない、誤った SPF レコードを記述すると、受信側ではその SPF レコードを無効として扱うということです（具体的には、3.5.3.2 で"+ip4:192.0.2.1" のうち、"+" が限定子で、"ip4:192.0.2.1" が機構です。
修飾子の例としては、"redirect=a.com" 等があります。

解説する ”permerror” として扱われることになります。
）。したがって、記述は慎重に行い、受信側での認証の処理では、定義は左から公開に際して SPF レコードの記述について右へと評価します。認証対象のメールサーバ

試験を行えるサイトなどを利用して試験を行の IP アドレスに対して最初にマッチした定義うことなどにより、記述ミスがないことを確の限定子によって認証結果が決定されます。

認するべきです。

いずれの定義にもマッチしない場合は、“neutral“ と評価されます（“neutral“ について3.2.4.2 定義は、3.5.3.2 で解説します。）。

定義（terms）は、ディレクティブ（directive）と修飾子（modifier）で構成します。

定義 ＝ ディレクティブ（directive）（限定子（qualifier）＋機構（mechanism））＋修飾子（modifier）

図表３－４(a) 限定子

定義

限定子には、”+” 、”-” 、”~” 、”?” があ

限定子（qualifier）には、認証対象のメー

り、”+” 限定子は省略可能です。それぞれ

ルサーバの IP アドレスが、それに続く機構についての認証結果とその意味を、図表３にマッチした場合の認証結果を指定します－５に示します。

（図表３－４を参照）。
表記+-

認証結果passfail~softfail?

neutral

意味当該ドメインの送信メールサーバとして認証する当該ドメインの送信メールサーバとして認証しない当該ドメインの送信メールサーバとして認証しないが、正当なメールであっても認証失敗する可能性もある認証されたかどうかを判断されたくない

図表３－５

限定子

19

第３章

送信ドメイン認証技術(b) 機構”a”、”mx” などがあります。機構の種類と、機構（mechanism）には、認証対象のメールサーバの IP アドレスと照合する条件

それぞれの引数及び機能を、図表３－６に示します。

を記述します。機構には、”all”、”include”、機構

引数allなし

include

ドメイン名

a

ドメイン名

mx

ドメイン名

ptr

ドメイン名

ip4

IP ネットワークアドレス（CIDR 表記可能)又は IP アドレス

ip6

IPv6 ネットワークアドレス又は IPv6 アドレス

existsドメイン名

機能・ すべての IP アドレスにマッチする。
・ SPF レコードの末尾におかれ、デフォルトの動作を定義するために利用される。
・ 引数に与えられたドメインの SPF レコードを使って認証処理を実施する。
・ その結果が pass、temperror 又は permerror の場合にのみ値が採用される。すなわち、include に指定された先のドメインの SPFレコードによって fail の判定が与えられても、それが認証結果としては採用されない。
・ 認証対象のメールサーバの IP アドレスが、ドメイン名に与えられた FQDN の A レコードのいずれかであれば、マッチする。
・ 認証対象のメールサーバの IP アドレスが、ドメイン名に対応する MX レコードに指定されているホストの A レコードのいずれかであれば、マッチする。
・ MX は複数与えられる場合があるが、10 個までの MX ホストに対して検査する。
・ 認証対象のメールサーバの IP アドレスをリバースルックアップし、得られたホスト名でさらに正引きを実施して IP アドレスを得て、その IP アドレス（複数の IP アドレスが得られる場合がある）が送信元ホストの IP アドレスを含む場合でかつ、リバースルックアップによって得られたホスト名が ptr の引数に与えられたドメイン名と一致するかそのサブドメインである場合に、マッチする。
・ リバースルックアップに失敗した場合は fail とみなす。負荷の多い処理となるため、あまり利用は推奨されない。
・ そのドメインのメールを送信する可能性のあるメールサーバのIP ネットワークアドレス又は IP アドレスを引数に指定する。
・ 認証対象のメールサーバの IP アドレスが、指定された IP ネットワークに含まれているか、IP アドレスに合致する場合に、マッチする。
・ そのドメインのメールを送信する可能性のあるメールサーバのIPv6 ネットワークアドレス又は IPv6 アドレスを引数に指定する。
・ 認証対象のメールサーバの IP アドレスが、IPv6 ネットワークに含まれているか、IPv6 アドレスに合致する場合に、マッチする。
・ 引数であるドメイン名に指定された表記で A レコードのルックアップを実施し、該当の A レコードが存在すればマッチする。
・ SPF のマクロ機能とあわせての利用を想定する。

図表３－６機構(c) 修飾子

20

修飾子（modifier）は認証についての付加のように認証結果に影響を与えるものもあ的な情報を与えるものです。機構とは異なります。修飾子について、図表３－７に示り、直接、認証結果を与えませんが、redirectします。

第３章

送信ドメイン認証技術

3.3 Sender ID

できます。RFC4407 は、この PRA の扱いを定義した RFC です。ヘッダに対して認証処

3.3.1 概要

理をするため、SMTP での通信上では、メール本文の内容をある程度読み込んだ上でない

Sender ID はネットワーク方式の送信ドメと認証が行えません。したがって、MAIL コマイン認証技術です。Microsoft 社が提唱したンドを受信した段階で認証結果が得られる

Caller ID for E-mail と SPF を統合する形でSPF に比べて、受信側では、運用時に、やや策定されました。Sender ID の仕様は、 SPFシステム負荷が高くなる場合があります。

の RFC（RFC4408）と同じく実験的カテゴリの RFC（RFC4406 と RFC4407）として、3.3.2 Puported Resposible Adress(PRA)標準化されています。
Sender ID は、SPF の影響を強く受けてお前述のように、Sender ID では、ヘッダ上のり、送信側では、SPF （RFC4408）で定義さ送信者アドレスから送信元のドメインを判断れている SPF レコードを利用して認証情報します。このとき、送信者を表す複数のヘッを公開できます。さらに、 Sender ID 独自でダを利用することで、転送時の問題を回避す拡張した宣言書式もあります。

るように考えられています。一般に、メールの送信者を表すヘッダは ”From” ですが、SPF と Sender ID の大きな違いは、 SPF

PRA では、それだけでなく、”Resent-Sender”、がリバースパスを対象に認証するのに対して、”Resent-From”、”Sender”、”From” の各ヘッ

Sender ID では、ヘッダ上の送信者アドレス

ダについても、この順に優先度が高い者としを対象に認証することもできます。実際に受て参照します。図表３－８にそれぞれのヘッ信者が見るヘッダ上のアドレスを検査するこダの概要を示します。

とで、フィッシィング対策としての効果を強める狙いがあります。
ま た 、 複 数 の 送 信 ヘ ッ ダ （ PurportedResponsible Address。以下「PRA」といいます。
）を利用することで、転送時の問題を回避ヘッダResent-Sender:Resent-From:Sender:From:

概要メールを転送したり、メーリングリストで再送する際に、転送等をしようとした者の代理でその転送等を実際に行った者（Resent-From と Resent-Sender が同じアドレスになる場合は Resent-Sender は付与しない）メールを転送したり、メーリングリストで再送する際に、その転送等を行った者メールの送信処理者（メールの送信者の代わりにメールの送信処理を実際に行った者）メールの送信者（メールを実際に作成した者）

図表３－８

22

PRA（Purported Responsible Address）

第３章

なお、メールを転送するときや、メーリングリストで再送するときには、図表３－９で送信ドメイン認証技術

ックスにひもづくアドレスを Resent-Fromヘッダで指定します。

示すように、その転送等を実施するメールボ

図表３－９

転送時のＰＲＡ追加

認証時には、まず、Resent-Sender ヘッダヘッダなどのヘッダを追加されていれば、受が存在する場合には、それを利用して認証を信側で認証を行うことができます。RFC5322

行います。Resent-Sender ヘッダが存在しな

では再送時には、再送フィールドを入れるべい場合には、次に、Resent-From ヘッダを探きと記載されており、また、再送ヘッダを入し、存在すれば、それを利用して認証します。

れる場合は、Resent-From を利用するとしてResent-From ヘッダもない場合は、次に、いるので、メールを再送する場合、Sender ヘッダ、さらにそれもなければ、From

Resent-From ヘッダを付与するべきです。な

ヘッダという順番で対象を変えます。From

お、直接は関係ありませんが、Resent-Fromヘッダが複数存在する場合は認証処理に失敗

ヘッダを付与した場合は、Resent-Date と再します。

送信時間を付与しなければなりません。

このようにすることで、たとえ、メールの3.3.3 SPF レコードのバージョン

配送時に転送等が行われて、From ヘッダでの認証ができなくても、転送時に、Sender ヘ

Sender ID では、 SPF で定義されているッダや Resent-From ヘッダ、Resent-Sender

SPF レコードを spf1 （バージョン 1）とし23

第３章

送信ドメイン認証技術て 扱 い 、 Sender ID の SPF レ コ ー ド をspf1 のレコードしか公開していないサイspf2.0 （バージョン 2.0）として扱います。

トからのメールについても Sender ID では

spf2.0 の SPF レコードでは、From ヘッ認証対象としており、その場合、リバースパダのアドレスを含む PRA を認証対象とする

スとPRA を 対 象 と し て 認 証 し ま すか、リバースパスを認証対象とするか、また（ ”spf2.0/mfrom,pra” と宣言されているとみその両方を対象とするかを、 SPF レコードなすことになります）。

上で指定できます。具体的には、レコードのまた、1 つのドメインで、spf1 と spf2.0 の先頭のバージョンの表記である ”spf2.0” に２つの SPF レコードを同時公開できます。

つづけて、認証対象のスコープを記述します。

図表３－10 は、spf2.0 と spf1 の SPF レ

PRA を 対 象 と し て 認 証 す る 場 合

コードの例です。バージョンの記述方法が微は ”spf2.0/pra” と、リバースパスを指定する

妙に異なるので、公開するときは間違えない

場合は ”spf2.0/mfrom” と、両方を対象とするように気をつけることが必要です。

場合は ”spf2.0/mfrom,pra” と記述します。

(spf2.0)
example.org.

IN

TXT

"spf2.0/pra include:example.org -all"(spf1)example.org.

IN

TXT

"v=spf1 include:example.org -all"

図表３－１０24

spf2.0 と spf1 の SPF レコードの例

第３章

3.4 Domainkeys Identified Mail (DKIM)

送信ドメイン認証技術

図表３−11 では、次のような手順で DKIM 送信ドメイン認証を実施しています。

3.4.1 概要①

example.jp ではあらかじめ DNS に電子署名に使う公開鍵を公開しておくDomainkeys Identified Mail (DKIM) は、電②

example.jp のメールサーバでは送出メ

子署名方式の送信ドメイン認証技術です。ールの本文とヘッダを元に電子署名を付与

IETF において、Sendmail 社の Eric Allman 氏する等を中心として検討が進められ、RFC4871 及び RFC5672 として標準化されました。さらに 、 DKIM の 標 準 を 補 う も の と し て③

メ ー ル を example.com の サ ー バ にSMTP で送信する④example.com の メ ー ル サ ー バ は

DKIM-ADSP と いう標準があ り、 RFC5617

DKIM-Signature の d パラメータに指定さで標準化されています。

れたドメイン部である example.jp の DNS

図表３−11 に示すように、DKIM では、送信側でメールから電子署名を作成して付与し、へ公開鍵を問い合わせる⑤

example.jp から取得した公開鍵により受信側でその電子署名を検証するという方法

電子署名を照合して OK であれば認証成で送信者のドメインの認証を行います。メー功

ル本体（ヘッダ及びメール本文の内容）をもとに電子署名を作成するので、中継メールサーバ（MTA）などで何らかの理由で電子署名又は電子署名の元になったメール本体のデータが変更されなければ、たとえメールが転送されても、転送先で認証が可能です。

25

第３章

送信側は、次の手順で電子署名を作成し、DKIM-Signature ヘッダをメールに追加します。
1. 電子署名を作成する対象となるメールか確認する2. 電子署名を作成する対象となるヘッダを決定し、h タグに列挙する3. メール本文の内容から l タグに指定した送信ドメイン認証技術

外の DKIM-Signature ヘッダの値を併せてハッシュを作成する4. 公開鍵を利用して、DKIM-Signature ヘッダの電子署名データからハッシュを取り出す（復号する）5. 電子署名から取り出した（復号した）ハッシュと、受信したメールから作成したハッシュを比較して、同じであれば認証成功

長さを取り出し、正規化処理を実施する4. ヘッダ、正規化したメール本文の内容、こ3.4.5 認証結果の扱いれから追加する DKIM-Signature ヘッダの電子署名のデータを除いた部分をつな

DKIM では、認証する対象の送信ドメインげたデータに対して、ハッシュを作成する

は、メールの From ヘッダから取り出すので5. ハッシュに対して電子署名を作成し、はなく、DKIM-Signature ヘッダに指定されてDKIM-Signature ヘッダとして付与したのいるドメインや送信アドレスを対象に認証しち、DKIM-Signature 自体をヘッダに追加ます。このため、ヘッダ上の送信者であるする

From 行の値と、認証に利用したドメイン名が異なる場合が存在します。DKIM の RFC

3.4.4 受信側での処理においては、認証結果に対するメールの扱いについてははっきりと定義されておらず、受信側では、メールに付与されたDKIM-Signature ヘッダを取り出し、次の手順

DKIM-ADSP の RFC において説明されています。

で電子署名の検証を行います。
1. DKIM-Signature ヘッダの d タグ、 s タグの値から、公開鍵を取得する FQDN を

DKIM-ADSP については 3.4.6 で、認証結果の詳細については 3.5 で解説します。

作成する2. 公開鍵を取得する。このとき、 i タグに設定してあるメールアドレスのローカルパ

3.4.6DomainKeys Identified Mail (DKIM)

Author Domain Signing Practices (ADSP)

ートが DKIM レコードの g タグの条件パターンにあわない場合は、電子署名の照3.4.6.1 概要合を行わない3. h タグに記述してあるヘッダと、メール本

Author Domain Signing Practices（ADSP）

文の内容（ l タグで有効な本文の長さが指とは、 DKIM の認証結果をどのように扱うべ定してある場合は、先頭からその長さだけきかを示すポリシーを送信側で公開するものを切り出したもの）及び電子署名データ以です。

29

第３章

送信ドメイン認証技術

3.4.5 で解説したように、DKIM では、メーと、電子署名を作成したドメインが異なる場

ルの DKIM-Signature ヘッダから認証対象の合があります。

ドメインを取り出しますので、From ヘッダ

まず、DKIM-ADSP では、これを図表３－に指定されている送信者アドレスのドメイン分類

16 のように整理しています。

原文

認証成功した電子署名

Valid Signature

メール作成者アドレス

Author Address

メール作成者ドメイン

Author Domain

メール作成者ドメイン電子署名

Author Domain Signature

図表３－１６

意味DKIM の電子署名の認証処理に成功した電子署名（DKIM-Signature ヘッダ）メールの From ヘッダに指定されている送信者アドレスメール作成者アドレスのドメイン部分照合が成功した電子署名で、かつ、DKIM-Signature ヘッダの d タグに指定したドメインとメール作成者ドメインが同一である電子署名

DKIM-ADSP で追加された署名およびメール作成者の整理

DKIM-ADSP では、メール作成者ドメインとなります。

電子署名として認証できれば、そのメールの<ドメイン名> は、From ヘッダのアドレス

送信ドメインは認証された（pass）と判定しのドメイン名部分となります。電子署名の検ます。認証に成功した電子署名がないメール、証に使う公開鍵を DKIM-Signature ヘッダの検証した電子署名のドメインがメール作成者d タグや i タグをもとに読み出すのに対して、ドメインと異なる場合などにおいて ADSPADSP は、ヘッダ上の送信ドメインから取りレコードを参照する必要があります。

出す点が相違していますので、注意が必要です。

3.4.6.2 ADSP レコードの公開

ADSP は、”dkim=値” で記述します。値には、図表３－17 に示すものがあります。

ADSP も DNS 上に TXT レコードで公開します。公開に利用する FQDN は_adsp._domainkey.<ドメイン名>

値allunknowndiscardable

概要このドメインから送信されるメールは、すべてメール作成者ドメイン電子署名が与えられる。
このドメインから送信されるメールのいくつか又はすべてに、メール作成者ドメイン電子署名が得られる。
このドメインから送信されるメールは、すべてメール作成者ドメイン電子署名が与えられる。そして、もしメール作成者ドメイン電子署名が得られない場合は、受信者はそのメールを破棄することが望まれる。

図表３－１７30

DKIM-ADSP の値第３章

3.4.6.3 DKIM-ADSP 利用上の注意点

送信ドメイン認証技術

ール作成者ドメイン電子署名で認証に成功した場合）のみの結果を利用し、それ以外の場

メール作成者ドメイン電子署名以外のケー合は、その結果だけでなりすましメールであスの場合、特にメーリングリストに投稿したると判断しないようにすることが必要です。

メールの場合の扱いなどについては、現在も検討中となっており、特に送信側で ADSP レコードを公開する場合には、注意が必要です。
また、受信側では、認証に成功した場合（メ31第３章

送信ドメイン認証技術

3.5 認証結果のヘッダへの表示

RFC5451 では、認証結果を記録するヘッダとして、Authentication-Results ヘッダを利用す

3.5.1 Authentication-Resultsるよう定義されています。
Authentication-Results ヘッダを利用して送信ドメイン認証技術による認証の結果を記録した例を、図表３－18 に示します。該当のメールのヘッダに記録する場合の方法は 、 RFC5451 で 標 準 化 さ れ て い ま す 。

Authentication-Results: smtp.example.co.jp;dkim=pass (1024-bit key) header.i=user@example.com; spf=pass (example.co.jp: domain ofuser@example.com designates 192.0.2.1 as permitted sender) smtp.mail=user@example.com

図表３－１８Authentication-Results ヘッダを利用して記録した例

3.5.2 ヘッダの詐称

3.5.3 認証方法ごとの結果表示

Authentication-Results ヘッダには、認証を3.5.3.1 概要実施したメールサーバの ID も同時に記録します。１つの Authentication-Results ヘッダで、また、このヘッダの詐称を防ぐために、ま複数の種類の認証方式による認証の結果を表ったく関係のない外部のドメインから、内部示できます。図表３－18 の例では、dkim との ID が認証を実施したメールサーバとしてspf の結果が表示されています。

ヘッダに記録されたメールを受信した場合にAuthentication-results ヘッダの表示の方法は、そのヘッダを削除することが必要です。

を、図表３－19 に示します。１つの認証方法による認証の結果は、１つの「認証結果情報」に表示します。「認証結果情報」は、「認証結果」、「理由」及び「プロパティ情報」で指定します。

Authentication-Results: 認証実施ホスト ID;バージョン; 認証結果情報; 認証結果情報;・・・※ バージョンは、省略可能※ 認証結果情報は、認証結果 理由 プロパティ情報 が指定されます。
－ 理由は、省略可能－ プロパティ情報は、指定されないか、１つ以上指定される場合があります。

図表３－１９32

Authentication-results ヘッダの表示の方法

第３章「認証結果」は、認証処理の結果を表示す

送信ドメイン認証技術

定される認証方法の概要を図表３-20 に示しるもので、「認証方式ラベル=認証結果の値」

ます。

で表示されます。
「認証方式ラベル」として指認証方法iprevauthdkimdkim-adspdomainkeyssender-idspf

説明RFC5451 にて定義されている接続ホストの IP アドレスの逆引きに基づく認証方法SMTP 認証 (SMTP AUTH)DKIM 送信ドメイン認証DKIM-ADSP 送信ドメイン認証DomainKeys 送信ドメイン認証Sender ID 送信ドメイン認証SPF 送信ドメイン認証

図表３－２０

認証結果一覧

「プロパティ情報」では、認証対象が何で複数の認証方式の結果を表示する場合は、”;”あったかを表示することが可能です。表示す（コロン）で区切って並べます。認証方式ラる場合には、認証対象が何であったかを示すベルと認証対象タグとして指定されるものを、認証対象タグと、その実際の値を組として、図表３－21 に示します。

認証対象タグ=認証対象の値の形で表します。
認証方式dkimdkim-adspsender-idspf

認証対象タグheader.iheader.dheader.fromheader.ヘッダ名smtp.mailfromsmtp.helo

意味DKIM 認証において i= タグに指定された送信者を元に認証を行ったDKIM 認証において d= タグに指定された送信者を元に認証を行ったDKIM-ADSP 認証処理において From ヘッダを元に認証を行ったSender ID の認証において、表示されたヘッダ名のヘッダに対して認証行ったSPF 認証においてエンベロープの送信者に対して認証したSPF 認証において HELO コマンドの引数のホスト名を元に認証した

図表３－２１

プロパティ情報一覧

3.5.3.2 SPF 及び Sender ID での結果表示

３－22 で示すように、”none”、”neutral”、”pass”、”policy”、”hardfail”、”softfail”、”temperror”、”Authentication-Results ヘ ッ ダ で は 、 SPF

permerror” があります。

及び Sender ID での認証結果の値には、図表
値noneneutralpasspolicyhardfailsoftfailtemperrorpermerror

意味SPF レコードが宣言されていない送信元のドメインでは、該当のホストが認証できたかできないかを明らかにしない認証に成功した認証は成功したがローカルなポリシーによってその認証結果は受け入れられない認証が失敗した認証は失敗であるが、はっきりと認証失敗としては扱ってほしくない一時的な問題で認証処理を実行できなかったSPF レコードの文法的な誤りなど永続的なエラーで認証処理を実行できなかった

図表３－２２

SPF での認証結果の値

33

第３章

送信ドメイン認証技術”none” は、SPF レコードが公開されていは ”neutral” になるとされています。

ないため、認証できなかった場合です。この”softfail” は、SPF レコードが公開されてお場合、送信ドメイン認証では、送信元についり、送信元の IP アドレスが「~」クオリファての評価が下せないため、従来どおりスパムイヤの条件にマッチする場合です。RFC でフィルタを通すなどしてメールの扱いを決定は、”fail” と ”neutral” の中間くらいの扱いをします。結果が none だった場合には、メーすべきであるとされています。結果ルを即座に受信拒否すべきではありません。

が ”softfail” である場合には、メールを即座に”neutral” は、送信ドメインの SPF レコードが、例えば「v=spf1 ?all」のように定義され受信拒否すべきではありません。
”temperror” は、一時的な障害で認証処理がている場合や、失敗した場合です。対応としてはメールを一「v=spf1 +ip4:xxx.xxx.xxx.xxx ?all」

時エラー（4XX）で受信拒否するか、そのまのようにレコードの末尾が「?all」と定義されま受信することになります。受信した場合は、ていて、先立つほかの条件にマッチせず「?all」少し厳しく扱うべきです。

にマッチした場合です。 RFC には、neutral”permerror” は、SPF レコードは公開されは none と同じように扱うべきであるとされているが、SPF レコードの記述に誤りがあるています。また、softfail よりは正当性が高い場合などです。この結果であっても、永続的ものとして扱う可能性があるとも説明されてな受信拒否をすべきではありません。

います。結果が neutral だった場合には、メールを即座に受信拒否すべきではありません。

3.5.3.3 DKIM での結果表示”pass” は、送信元の IP アドレスが SPFレコードにマッチし、認証に成功した場合でDKIM 認 証 の 結 果 と後 述 の DKIM-ADSPす。送信ドメインは正当であるので、あとは認証の結果は、それぞれ別のものとして扱わその送信ドメインの評価に従ってメールを処れます。

理します。
“hardfail“ は、SPF レコードが公開されてで示すように、”none”、”neutral”、”pass”、いるが、送信元の IP アドレスが「-」クオリ”policy”、” fail”、”temperror”、”permerror” がファイヤの条件にマッチする場合です。
「?all」あります。

や「~all」が末尾に設定されている SPF レコードを持つ送信ドメインのメールに対しては、この結果は発生しません。なお、RFC では、「all」の記述が省略された SPF レコードに対して、どの条件にもマッチしない場合

34

DKIM での認証結果の値には、図表３－23