スパイラル サポートサイト

powered by SPIRAL PLACE®

HOME > 機能 > 送信ドメイン認証技術

送信ドメイン認証技術　～なりすましメールと判定されないために～


ビジネスや一般のコミュニケーションにおいて、必要不可欠となった電子メールは、今ではダイレクトメール等と比べ、読まれやすいという特徴からメルマガに代表される情報を訴求するのに欠かせないツールとなりました。こういった中、企業やサービスになりすましたメールによるフィッシング被害が増加し、一般消費者の個人情報を搾取する等の犯罪が後を絶ちません。
この状況を改善する為に、メールサービスを提供する携帯キャリアやISP、フリーメール等は正当な送信者であることを証明できる技術「送信ドメイン認証技術」を使用した迷惑メールフィルタやなりすましメール拒否機能等を提供し、世の中のなりすましメールを排除するようになりました。
スパイラルを利用してメールを送信する場合は、スパイラルの配信システムを利用しながらも、ユーザは送信者情報であるFromアドレスを自身のドメインに設定してメールを送る事が可能です。
この為、スパイラルから送信されたメールはFromアドレスの管理主体と異なる送信元から実際は送信している為、受信側からなりすましメールであると判定される場合があります。
ここでは、送信ドメイン認証技術の概要と送信ドメイン認証に対応したメールをスパイラルから送る為にユーザがすべきことを説明します。


送信ドメイン認証の技術

送信ドメイン認証技術とは、メールの送信ドメインが正当なものであることを証明する技術で、メール受信側が送信元詐称のメール発見に役立ちます。
この技術は、送信元の住所であるIPアドレスを検査する「ネットワーク方式」とメールにパスポートを付与して出国し、入国を許可する「電子署名方式」があります。


［２つの送信ドメイン認証技術］

SPF/SenderID方式DKIM
Sender Policy Framework/Sender ID正式名称DomainKeys Identified Mail
DNSに宣言するだけで対応できるので導入が比較的容易である。
メールの転送に弱い。		特徴メール本文の改ざんを検知できる。
メール送信システムに署名機能が必要。
送信メールアドレスのドメインに、送信に使用するIPアドレスを公開、受信時に送信元IPアドレスと宣言しているIPアドレスを比べて評価
※SPFはMAIL FROMが、SenderIDはPRAに基づくアドレスが認証対象		認証方法メール送信時に秘密鍵で署名した電子署名をメールに付与、受信時に署名ドメインがDNSに宣言している公開鍵で正当性を評価
なし。
※ドコモ社の送信ドメイン認証に対応する場合は、送信ドメインのDNSにスパイラルの送信元IPアドレスを公開する必要があります。		スパイラルユーザーの対応なし。
※署名ドメインをメール作成者にする場合は、公開鍵をDNSに公開する必要があります。


SPF／SenderIDとは

SPF／SenderIDは、ネットワーク方式の送信ドメイン認証です。送信メールアドレスのドメインに、送信に使用するIPアドレスを公開、受信時に送信元IPアドレスと宣言しているIPアドレスを比べて評価し認証します。


  • SPFの認証

　　　　　
　（１）メール送信サーバがメールを送信します。
　（２）受信サーバは、メールの送信元のドメインを見て、DNSサーバにSPF問い合わせをします。
　（３）DNSサーバのSPFレコード※１のIPアドレスが、送信元のIPアドレスと一致すれば、認証成功となります。
　　※１　SPFレコード：メール送信時に使用する送信元のIPアドレスの情報をDNSサーバに公開する際の記載箇所、または記載内容。

SPFとSenderID

SPFとSenderIDは、同じネットワーク方式ですが、認証に利用する送信元の情報ソースが異なります。
メール送信を郵便に例えると、SPFは「封筒の送信者情報」で認証します。一方、SenderIDは「便箋の送信者情報」をもとに認証します。


封筒と便箋に記載する情報が異なる際に、対応が異なる場合があります。

［SPFとSenderIDで認証する送信元の違い］

方式認証対象
SPFMAIL FROM：封筒（エンベロープ）記載の送信者アドレスが認証対象。受信メールではReturn-Pathで確認可能。
SenderIDPRAに基づく情報：便箋（メールヘッダ）記載の送信者情報。
PRAの認証対象は、Resent-Sender／Resent-From／Sender／From　の順で優先順位がつけられ、いずれかのアドレスが認証対象。


DKIMとは

DKIMは、電子署名方式の送信ドメイン認証です。 メール送信時に秘密鍵で署名した電子署名をメールに付与、受信時に署名ドメインがDNSに宣言している公開鍵で正当性を評価し認証します。


  • DKIMの認証

　　　　　
　（１）送信者のDNSサーバに、電子署名の公開鍵を公開します。
　（２）秘密鍵で電子署名を作成し、メールに付加します。
　（３）送信サーバがメールを送信します。
　（４）メール受信サーバは、メールの送信元のドメインを見て、DNSサーバに公開鍵を問い合わせをします。
　（５）DNSサーバの公開鍵を使って、メールの電子署名を検証します。


DMARCとは

DMARCとは、送信ドメイン認証技術の一つで、既に普及しているSPFとDKIMの検証結果を利用し、 差出人をなりすましたメールを受信側がどう扱うべきかの方針（ポリシー）を、送信元ドメインの管理者が 宣言するための仕組みです。
送信元ドメインの管理者は、SPFとDKIMの両方の認証に失敗したメールに対して、「そのまま通す（none）」、 「隔離する（quarantine）」、「受信拒否する（reject）」というように、受信時の処理方法をDMARCポリシーとして 宣言します。
これにより、自社のドメインをなりすまして送られるなりすましメールを排除する効果を高められるなど、メール の信頼性を確保することが可能になります。 ]


方式DMARC
正式名称Domain-based Message Authentication, Reporting and Conformance
特徴送信ドメインの管理者が、認証失敗時の方針（ポリシー）を宣言できる。
なりすまし状況のレポートを受け取れる。
認証方法SPFとDKIMの検証結果を利用。
DNSに宣言している方針（ポリシー）に応じて受信メールの処理が決まる。
スパイラルユーザーの対応任意。
※DKIM署名ドメインをメール作成者にする場合は、公開鍵をDNSに公開する 必要があります。


  • DMARCの仕組み

　　　　　


スパイラルユーザーがすること

送信ドメイン認証に対応したメールをスパイラルから送るためにユーザがすべきことを説明します。

SPF／SenderIDに対応する場合

スパイラルでは、SPF／SenderIDの送信者情報である「MAIL FROM」や「Sender」にスパイラルの情報を記載してメールを送信し、送信サーバのIPアドレスをDNSサーバに公開しています。そのため、通常のSPF／SenderIDに対応する場合、特に対応作業は必要ありません。
［スパイラルの送信元情報］※メールグループで設定するメール

認証技術認証対象ドメインユーザーの対応
SPFMAIL FROM
（エンベロープ）		smp.ne.jp無
SPF（docomoの場合）From
（メールヘッダ）		「差出人メールアドレス」に指定したドメイン有
SenderIDSender
（メールヘッダ）		smp.ne.jp ※
※ 次のドメイン宛に配信する場合のみ、Senderを付与します。
ezweb.ne.jp／*.ezweb.ne.jp		無

docomoに送る場合のSPF／SenderID対応について

docomoが提供しているなりすましメール対策機能は、スパイラルユーザが設定するFromアドレスを認証対象としています。そのため、当該機能でなりすましメールと判定されないためには、FromアドレスのドメインのDNSサーバにSPFレコードを記述する必要があります。
SPFレコードの記述については、DNSサーバの管理担当者にご相談ください。

　DNSサーバに登録するSPFレコードの記述例）
　　　
　　　※　example.com <Fromアドレスのドメイン>
　　　　　192.0.2.1 <Fromアドレスのドメインが利用している送信サーバのIPアドレス>

　DJBDNSの記述例）
　　　
　　　※　example.com <Fromアドレスのドメイン>
　　　　　192.0.2.1 <Fromアドレスのドメインが利用している送信サーバのIPアドレス>

なお、設定したSPFレコードは以下チェックツールから確認が可能です。
SPF Record Testing Tools
SPF Surveyor

DKIMに対応する場合

１．対応
スパイラルから配信する全てのメール※はDKIM署名を付与して送信します。
通常は、スパイラルのドメインが署名した「第三者署名」によるものですが、メール作成者であるユーザによる署名の「作成者署名」で署名することも可能です。作成者署名の場合はユーザによるドメインの登録と鍵の設定が必要になります。
　※メールグループで設定するメール

［署名パターンとユーザの設定］

署名パターン署名者ユーザー設定
第三者署名スパイラルなし。
作成者署名ユーザー・差出人メールアドレスのドメインを署名ドメインに登録し、キーペアを設定する。
・DNSサーバに公開鍵を設置する。

（１）スパイラルで署名（第三者署名）する場合

スパイラルは、作成者署名のないメールに、自動的にスパイラルが署名する機能を備えています。スパイラルが署名する第三者署名を利用する場合、対応作業はありません。
※ DNSサーバにDKIMの署名ポリシーを記載するDKIM-ADSPを宣言している場合は、第三者署名によるメール配信を設定できないことがあります。

（２）差出人メールアドレスのドメインで署名（作成者署名）する場合

送信メールの差出人メールアドレス（Fromアドレス）のドメインで署名する「作成者署名」でメールを送信する場合は、操作画面でドメインの登録と署名に必要なキーペア（秘密鍵・公開鍵）の生成を設定します。設定後に生成した公開鍵をDNSサーバに公開します。

［作成者署名時の設定］

設定ステップ内容
1.署名ドメイン登録とキーペアの生成差出人メールアドレスに使用するドメインを登録し、同時に署名に使用するキーペアを生成します。
スパイラルではキーペア自動生成ツールを提供していますが、ユーザが生成したキーペアを登録することも可能です。
［DKIM署名ドメインの新規登録画面］
2.公開鍵の宣言DKIM署名の認証に使う公開鍵をDNSサーバに登録する。
公開鍵は、DKIM署名ドメインの登録画面からダウンロード可能です。

［DNSサーバに、公開鍵の設置］
DNSサーバへの公開鍵の登録については、DNSサーバの管理担当者にご相談ください。

　DNSサーバに登録するTXTレコードの記述例）
　　　
　　　※　D20101215-spiral01 <セレクタ>
　　　　　example.com <署名ドメイン>
　　　　　MIGfMA0GCSqGSIb3...(省略) <公開鍵データ>

２．確認
（１）信号で確認するDKIM設定状況
スパイラルでは、ユーザーが設定している差出人メールアドレスがDMARCレコードを宣言していた場合、DKIMやSPFの検証を実施し、DMARCレコードに記載のポリシーと配信設定内容を比較、DMARCの設定状態が適切かどうかを信号とメッセージでわかりやすく確認できるようになっています。


信号認証結果と配信設定の可否
認証に成功し、配信を設定できます。
※作成者署名の場合
認証に成功し、配信を設定できます。
但し、DKIM-ADSPで[unknown]が宣言されているため、送信時には注意が必要です。
FromアドレスドメインのDNS管理者に確認してください。
※第三者署名の場合
認証に失敗している為、配信を設定できません。
（認証失敗の理由）
・公開鍵が正しく宣言されていません。
・DKIM-ADSPで[all]または[discardable]が宣言され、作成者署名のみの送信ポリシーであるにも関わらず第三者署名のメールを送信しようとしています。FromアドレスドメインのDNS管理者に確認してください。

　※　DKIM-ADSPの認証結果による受信可否は各受信プロバイダの設定となります。
　※　信号が赤色の場合は、適切な設定がなされていないことが想定されます。
　　　ドメインやDNSの管理者またはユーザーズデスクまでお問い合わせください。

（２）DKIM署名の確認方法
メール受信時にDKIM認証を実施しているメールサービス(ex.Gmail)にテストメールを送信し、受信メールのヘッダからDKIM署名の内容と認証結果を確認することができます。
［ヘッダに記載されるDKIM署名と認証結果］

ヘッダ記載例確認点
DKIM-Signature:v=1; a=rsa-sha1;
c=relaxed/relaxed;
d=example.com;
s=D20101215-spiral01;
t=1282117486;
bh=fK0VLNXFVdGze		署名の確認
・署名ドメイン（d=)を確認する。
スパイラルで署名している場合は「smp.ne.jp」、作成者署名の場合はFromアドレスのドメインと一致していること。
・セレクタ(s=)がDNSに設置したセレクタと一致していること。
Authentication-Results:mx.google.com; spf=pass
smtp.mail=spiral-error@smp.ne.jp
dkim=pass
header.i=@pi-pe.co.jp		認証結果の確認
・認証結果(dkim=)が「pass」となっていること。

その他の認証結果に、以下のようなものがあります。

認証結果説明
noneDKIM署名が付与されていない。
neutralDKIM署名が付与されているが、文法の誤りなどで照合できない。
passDKIM署名が付与されていて、受信者にとって受け入れられるものであり、かつ、照合に成功した。
policyDKIM署名が付与されているが、ローカルポリシーによって受け入れられない。
failDKIM署名が付与されていて、受信者にとって受け入れられるものであるが、照合と認証に失敗した。
temperror一時的な問題で認証処理が実行できなかった。
permerror永続的なエラーで認証処理を実行できなかった。

上記の認証結果はRFC5451をもとに作成しています。
認証結果はメール受信サーバが記述するため、受信側の仕様によっては結果の記述に差異がございます。

DMARCに対応する場合

[DNSサーバに、DMARC宣言を行う]
DNSサーバへのDMARCレコードの登録については、DNSサーバの管理担当者にご相談ください。
　DNSサーバに登録するTXTレコードの記述例）
　　　
　　　※　p=none <認証失敗時の処理ポリシー>
　　　　　example.com <Fromアドレスのドメイン>