お問い合わせ

お問い合わせ
お電話

お電話

ビジネスパートナー募集

0120-941-670

平日 10:00～19:00

お問い合わせ お問い合わせ

お問い合わせ
資料DL 資料DL

資料DL
検索 検索

検索
twitter

公式X
facebook

公式Facebook

Close

テックブログ

メール

セキュリティ メール

メール送信と不正メール対策の流れ — なぜメール転送がうまくいかないことがあるのか

メール送信と不正メール対策

ようやく入社２年目となりました、社内で修行中の H.M です。今回はメールの配送と検証についてです。

Google が POP受信機能を停止して久しくなります。POP受信機能が無くなったためやむなくメール転送を使うようになった方もいらっしゃると思います。

しかし、インターネットメール(以下、単にメール)を転送すると迷惑メールに分類されてしまうことがよく起こります。厄介なことに、転送メールが迷惑メールになったりならなかったりするため、転送設定のどこに問題があるのかと混乱してしまう方々も多いかと思います。これは、現在のメールシステムが不正なメールに対処しようとしてきた結果、メールの転送には不向きな状況が生じているためです。

ここでは、メールがどのように送受信されるか、また不正メールに対してどのように対処してきているかを説明したうえで、転送時になぜそのようなことが起こるのか理解することを目指していきたいと思います。

メールの送受信を担う SMTPサーバ

メールの送受信をおこなうのは SMTPサーバと呼ばれるサーバです。現在、一般的な概念として SMTPサーバは下記の３つの機能を持つモデルで説明されます。

  • MSA (Message Submission Agent) ： メールユーザからの送信メールを受け付ける
  • MTA (Mail Transfer Agent) ： サーバ間のメールの輸送をおこなう
  • MDA (Mail Delivery Agent) ：自サーバ宛のメールをメールボックスに保存する

このモデル上では、メールは下記の流れで送受信します。

　メーラ => MSA => 送信元 MTA => 送信先 MTA => MDA => メールボックス

MSA および MTA は SMTP と呼ばれるプロトコルを使用してメールの受け渡しを行います。

なお、上記の説明は概念的なもので、機能が別々に実装されているわけではなく、またメール送受信も現在、標準的におこなわれている流れであることに注意してください。

メールシステムの構成と送信の流れ

ご存じのとおり、メールを送受信するためにはメールアドレスが必要です。メールアドレスは下記のような文字列です。

　{ローカルパート}@{ドメイン}

例えば、メールアドレスが「hirashain@netassist.ne.jp」であれば、「hirashain」がローカルパートで、「netassist.ne.jp」がドメインです。

メールアドレスはドメイン所有者が発行します。一般的には、ドメイン所有者はメールアドレスを発行したユーザのために、下記のシステムを用意します。

  • SMTPサーバ (MSA/MTA/MDA)
  • メールボックス

先に説明した流れのとおり、メールユーザはメーラを使って MSA に接続してメールを送信します。メールボックスに保存された受信メールは、POP3 や IMAP4 の通信方法を使って受け取ります。

まとめ直すと、メールは基本的には下記の流れで送信されます。

  1. 差出人のユーザはメーラを使って、メールアカウントが使用できる MSA に接続して、メールを投稿する
  2. MSA からメールを受け取った MTA が、宛先ドメインの MTA に接続してメールを受け渡す
  3. 宛先の MTA から引き渡されたメールを MDA がメールボックスにメールに保存する
  4. 宛先ユーザはメーラを使ってメールボックスに接続し、受信したメールを確認する

一般的にはユーザが MSA やメールボックスに接続するには、メールアドレスと合わせてドメイン所有者で発行したIDとパスワードを使って認証する必要があります。

なお、MSA と同一サーバ上に宛先のメールボックスがあった場合、送信したメールはサーバ間で受け渡しをせず、MDA を通じて直接メールボックスに保存されます。

また、メールの転送も SMTPサーバがおこないますが、こちらは改めて後述します。

メール送信に対する規制

実はメールシステムはもともとバラバラだった様々な電子メールシステムをインターネットで共通で使用できるようにしていくために、折衷も含めてかなり自由度が高いシステムで成り立っています。

前節まででメール送受信の標準的な説明をしましたが、これらは Submission Port および OP25B という規制が普及した後のことになります。それ以前は SMTP サーバはどこからでも 25番ポートでアクセスでき、メーラからも宛先ドメインの SMTPサーバに直接メールを送ることができる状況でした。

しかし、インターネットメールの普及が進み、またそれに伴う不正なメール送信も増えたため、SMTPサーバを管理しやすくする目的で、メールの投稿 (Submission) の受け付けは 587番ポートで MSA の機能としておこない、メールの輸送 (Transport) については引き続き 25番ポートで MTA の機能でおこなうように標準化が進みました。また、SMTP プロトコルを拡張して、MSA に接続する際の認証をおこなえるようにしました。

これによりメールサービスではメールの投稿と輸送を分離したうえで、メール利用者にはアカウントを発行して、認証した者だけに自社の MSA を利用させることが標準となっていきました。

また、インターネット接続事業者は利用者にメールサービスを提供するとともに、外部の MTA に接続できないように、25番ポートの外部インターネット接続を規制しました。この規制を Outbound Port 25 Blocking、略して OP25B と呼びます。

これらの対策が普及して、多くの一般ユーザは認証した MSA を経由する以外にはメールの送信ができなくなり、不正メールの抑止につながりました。

但し、OP25B はメールを送信する側の規制であり、インターネット接続事業者やホスティング事業者、
サーバ管理者の協力が不可欠です。インターネットに接続できるネットワークやサーバのすべてを OP25B で規制できるわけではなく、規制されないネットワークやサーバの一部では、いまだに不正メールを送るものがあります。

OP25B に縛られずに不正メールを送るサーバに対してはブラックリストを作成するサービスも運営されており、不正メールの送信元と考えられる IP アドレスを公表しています。このブラックリストを MTA で参照して、自動的にブロックするように設定することもできます。

SMTP のコマンドと、メールに含まれるメールアドレス

SMTP プロトコルを通じてメールを送るクライアントは MSA もしくは MTA に接続して、主に下記のコマンドを使用してメールを受け渡します。

・EHLO <hostname>
　接続元のサーバのホスト名を示します。
　EHLO の代わりに HELO を使用する場合もあるため、以降は HELO/EHLO と併記します。

・MAIL FROM: <reverse-path>
　エラー時の通知先のメールアドレスを渡します。

・RCPT TO: <forward-path>
　宛先のメールアドレスを渡します。

・DATA
　メールのコンテンツを渡します。

DATA で渡すメールのコンテンツには下記が含まれます。

  • Header fields
  • Body

MTA が MSA や他の MTA から自ドメイン宛のメールを受け取ると、そのメールのコンテンツは MDA を経由してメールボックスに保存されます。

私たちはメールをメーラの画面で確認しますが、そこに表示される本文はコンテンツの Body に入っています。添付ファイルがある場合も Body の一部として保持されています。

また、メーラで表示される差出人や宛先のメールアドレスは、前述の reverse-path や forward-path ではなく、コンテンツの Header fields に下記のフィールド名で存在します。

  • “From” ヘッダフィールド： 差出人メールアドレス
  • “To” ヘッダフィールド： 宛先メールアドレス

メーラで返信する際は、コンテンツに含まれる上記の “From” ヘッダフィールド (ただし From とは別にReply-To ヘッダフィールドがあれば Reply-To) のメールアドレスが宛先になります。

ここまでで述べたメールアドレスは慣習的に下記の呼び方がされており、このブログでも以降はこの名前を使用します。

  • ヘッダFrom ： コンテンツの “From” ヘッダフィールド
  • ヘッダTo ： コンテンツの “To” ヘッダフィールド
  • エンベロープFrom ： エンベロープの reverse-path
  • エンベロープTo ： エンベロープの forward-path

エンベロープFrom とエンベロープTo をまとめてエンベロープと呼ぶことがあります。エンベロープは SMTPサーバ間でのメールの受け渡しのための情報で、配信が完了すれば失われます (ただし、一部のメールヘッダには転記され、SMTP のログなどにも記録はされます)。

実は、SMTPサーバがメールの送受信者を確認するときにはコンテンツの Header fields を見ません。MSA からメールを受け取った MTA はエンベロープTo を見て、そのドメインの MTA にメールを受け渡します。その際、エンベロープの内容も基本的にはそのまま送信先の MTA に引き渡します。また、メールの輸送でなんらかのエラーが生じた場合、MTA はエンベロープFrom にその通知を送ります。

なお、よくある例えで、コンテンツは手紙の内容を書いた便箋、エンベロープはそれを送る際の封筒と言われることがありますが、SMTPサーバはコンテンツの中身を見れますし、エンベロープやコンテンツに追記や書き換えをすることもあるので、そのまま鵜呑みにはしないほうがいいです。

送信先の MTA への接続

インターネットで特定のドメインのサービスに接続するためには DNS を参照してドメイン名に対する IPアドレスを取得します。DNS で取得できる情報をレコードと呼び、IPアドレスの取得時には DNS に対して A レコード(IPv6 の場合は AAAA) を要求します。

MSA からのメールを MTA が送る場合も、送信先の MTA に接続するために DNS を参照しますが、メールの場合、送信元 MTA はまず DNS に対してエンベロープTo のドメインパートの MX レコードを要求します。MX レコードはメールを受け取る MTA のホスト名が登録されていますので、そのホスト名に対して A (もしくは AAAA) レコードを問い合わせることで送信先 MTA の IPアドレスが取得できます。

なお、MX レコードが無い場合は、フォールバックとしてエンベロープTo のドメインパートのA (もしくは AAAA)レコードを MTA の IPアドレスとして使用します。

バウンスメール

MTA が受け取ったメールが、なんらかの理由でエラーとなって届かないことがあります。このとき、MTA はエンベロープFrom のメールアドレス宛に配送に失敗したことを通知するメールを送ります。このメールをバウンスメールと呼びます。

バウンスメールを送る際、バウンスメールの配送先でも再度エラーが発生してバウンスメールが無限に発生することを防ぐために、MTA はバウンスメールのエンベロープFrom を空(<>) にします。

なお、よくバウンスメールの宛先は Return-Path のメールヘッダであると説明されますが、Return-Path ヘッダは MDA がメールを受けるときにエンベロープFrom のメールアドレスを参照して追加するもので、MTA がバウンスメールを送信する際に参照するものではありません。

SPF：IPアドレスによる SMTP への接続元の確認

では逆に、送信先の MTA に接続してきた送信元 MTA が差出人のドメインのものであるか正しく確認することはできるでしょうか。

前述したとおり、メール送信の無法地帯である状況は MSA の導入や OP25B によって改善しましたが、それでも規制されていないサーバからの不正メール送信は可能です。このような不正メールはメールアドレスを詐称して、所有していないドメインのメールアドレスを名乗ってくることも多いです。メールアドレスの詐称は簡単です。メールを送信する際に、エンベロープFrom やヘッダFrom に偽りのメールアドレスを設定するだけです。もちろんメールコンテンツも自由に設定できます。

このことから、送信元 MTA の IPアドレスが差出人のドメインに紐づいているか確認することは不正メールを排除するひとつの手段になります。その１つの方法が SPF (Sender Policy Framework) です。

SPF に対応するには、ドメイン所有者がそのドメインの DNS に TXT レコードとして SPF のレコードを登録します。SPF のレコード内容は「v=spf1」で始まり、メールを送信する MTA の IPアドレスのリストなどを記述した文字列です。SPF のチェックをおこなう MTA では、送信元のドメイン情報に対して DNS の TXT レコードを問い合わせ、SPF があるか確認します。この時に使用する送信元のドメイン情報は、SMTP の HELO/EHLO コマンドのホスト名、もしくはエンベロープFrom のドメインが使われますが、一般的には通常のメールではエンベロープFrom のドメインで検証がおこなわれます。但し、バウンスメールではエンベロープFrom が空になっているため、HELO/EHLO のホスト名が利用されます。

インターネットでは接続してきた通信相手の IPアドレスはわかりますので、DNS から SPF の情報を取得できれば、そのIP アドレスがそのドメインからメール送信元として許可されているかを確認することができます。

残念ながら SPF の設定はドメイン所有者に義務づけられているものではないため、不正メールを送っていない MTA でも SPF を DNS 登録していないことがあります。このため、SPF レコードが登録されていないという理由でメールの受信拒否をしてしまうと、場合によっては不正ではないメールが届かないことも起こるため注意が必要です。

とはいえ、SPF の普及率はかなり高く、迷惑メール判定として使用するひとつの有効な手段です。

DKIM：署名によるメール改竄対策

前述したとおり、SMTPサーバはメールのコンテンツやエンベロープに追記、書き換えをおこなうことができます。今時のメール事情ではメールの内容が送信の過程で書き換えられるということは起こりえないように思われますが、メールの改竄対策として DKIM が登場するまでは、SMTPサーバでメールの書き換えが起こりうることは当たり前の状況でした。

しかし、受信したメールの内容が送信したメールの内容から変わってしまったことを受信者が知ることができないのは、特に商業メールにおいては企業の信用にかかわる問題です。

DKIM (DomainKeys Identified Mail) はメールのコンテンツが改竄されたことを検知できる仕組みで、迷惑メールによるフィッシング詐欺などの増加に伴ってメール改竄に対する意識も高まり、商用メールでの採用が増えていきました。

DKIM の改竄検知は、いわゆる電子署名(以下、署名)を利用し、下記のようにおこなわれます。

  • 署名では公開鍵暗号を使うため、送信側で秘密鍵と公開鍵のペアを作成する。
  • 秘密鍵は送信側の MTA に保管し、公開鍵は DNS で公開する。
  • 送信側の MTA は秘密鍵でメールのコンテンツに対する署名を生成して、メールの Header Fields に追加する。
  • 受信側の MTA は公開鍵でメールのコンテンツに対する署名を検証し、コンテンツが改竄されていないかを確認する。

署名と検証

ここで少し、署名がどのようなものか確認します(読み飛ばしていただいても結構です)。

署名とは、送受信した電文が途中で改竄されず、かつ電文自体が送信者から送られてきたものであることを受信側で確認するために、送信元で生成する追加データです。

署名を生成するために送信側ではまず、電文に対するメッセージダイジェスト(MD)を生成します。
MD は下記のような性質を持ちます。

  • 電文を入力として生成される値。
  • 電文の長さにかかわらず MD の長さは一律同じ。
  • 同じ電文に対しては同じ MD が生成される。
  • 電文の一部が異なるだけでも全く異なる MD が生成される。
  • MD から元の電文を生成することはできない。
  • 異なる電文で同じ MD を生成できるものを探すことは困難。

MD はイメージしにくいものですが、簡単な例として下記のようなものが考えられます。

  • 電文の文字は 1文字ごとに数字で表されることから、電文の全ての文字の数字を足し合わせ、それを特定の数字で割り算した余りを用いる。

この例の場合、どこかの文字を 1だけ小さいものにすると MD も 1だけ小さくなるため「電文の一部が異なるだけでも全く異なる MD が生成される」は満たせませんし、更に別の文字を 1だけ大きくすることで MD は同じ値になってしまうので「異なる電文で同じ MD を生成できるものを探すことは困難」も満たせませんが、それ以外の項目については MD のイメージに近いものです。

現在、MD の生成には SHA-256 が多く使われています。また、セキュリティ上は脆弱ですが、互換性のために SHA1、MD5 を使用することもあります。

送信側で電文と一緒に MD を送信すれば、受信側で同じように電文に対する MD を生成して、電文と一緒に送られてきた MD と一致するか確認することで、改竄の検知ができるように思われます。しかし、実際はそれだけでは不足があります。なぜなら経路の途中で電文が改竄され、更に MD が改竄した電文から生成したものに入れ替えられたら、改竄を検知できないからです。

ここで、電文と MD のどちらも改竄されていないことを検知できるようにするために、MD を元にして送信側で生成した情報を署名と呼びます。

  • 署名を生成するために、送信側はまず秘密鍵と公開鍵のペアを生成し、公開鍵を公開しておきます。
  • 送信側が MD から署名を生成するときに秘密鍵を使用します。
  • 受信側では改めて電文から MD を生成し、送信側で生成した MD と一致するかを公開鍵と署名を使って検証します。

公開鍵から秘密鍵を計算することは困難で、鍵のビット数が大きければ事実上不可能です。もし経路の途中で第三者が電文を改竄しても、第三者は送信者の秘密鍵が無いため、公開鍵による検証に合格できる署名を生成できません。このことから、署名を検証することで、秘密鍵を持つ送信者の電文が改竄されていないかを検知することができます。

また、公開鍵を公開している身元が明らかであれば、署名の検証によって身元の確認までおこなうことができます。DKIM では公開鍵の公開を DNS でおこなうことで、公開鍵がドメイン所有者のものである根拠としています。

DKIM の改竄検知

前述したとおり、DKIM では公開鍵を DNS で公開します。その際、「セレクタ」と呼ばれる文字列を決め、公開鍵は下記のサブドメインの TXT レコードで公開します。

　セレクタ._domainkey.ドメイン

「セレクタ」は、必要に応じて鍵を変更できるようにするためのものです。鍵を変更する際は「セレクタ」も変更します。

DKIM ではメール送信時、署名の情報をメールコンテンツの Header fields に DKIM-Signature というヘッダ名で追加します。DKIM-Signature の内容は「タグ=値」の形式で記されており、下記の内容を含んでいます。

  • d=[ドメイン]
  • s=[セレクタ]
  • bh=[コンテンツ Body の MD]
  • h=[署名対象のコンテンツ Header fields の名前のリスト]
  • b=[署名]

　※MD は前節で説明しているメッセージダイジェストのことです。

[署名] の対象となる電文は、下記の２つを結合したものです。

  1. “h=” にリストされた Header fields をメールコンテンツから抽出したもの
  2. [署名] 部分を空にした DKIM-Signature のヘッダフィールド

1 は、差出人(From)、宛先(To)、タイトル(Subject) などのヘッダフィールドが該当します (h で指定されている必要があります)。2 は、前述した DKIM-Signature で署名以外の内容すべてが含まれます。DKIM は、これらに対する改竄があったかについて [署名] を使って検証することができます。

ですが、上記の署名対象にメールコンテンツの Body、すなわちメールの本文は含まれていません。その代わり、2 では bh、すなわち [コンテンツ Body の MD] が含まれています。

もしメール本文が改竄されれば、受信した [コンテンツ Body の MD] と bh が食い違ってしまいます。また bh が改竄されれば、[署名] を生成した電文が変わってしまうため、署名の検証で改竄が検知されます。このように、[コンテンツ Body の MD] を署名対象に含めることで、メール本文の改竄も検知できるようになっています。

受信したメールの検証手順も示しておきます。

  • メールの [コンテンツ Body の MD] を求めて、DKIM-Signature の bh と比較する。一致しなければ改竄があったことになる。
  • DKIM-Signature の d (ドメイン) と s (セレクタ) より DNS名(セレクタ._domainkey.ドメイン)を作成し、DNS から公開鍵を取得する。
  • 前述した [署名] の対象となる電文を作成し、この電文の MD を求める。
  • この MD と、公開鍵を使って、b (署名) を検証する。検証に合格しなければ改竄があったことになる。

DKIM の検証が不合格となるケース

意図的な改竄以外で DKIM の検証に影響を与える一般的な要因として、SMTPサーバでの下記の動作が考えられます。

  • メールの Header fields の追加
  • メールの Body に対して、改行の追加や文字コード変更

SMTPサーバはメールを受け取るごとに、受け渡しなどの履歴をメールの Header fields に追加しています。DKIM-Signature ではどの Header fields を署名対象するかを h= で明示しますが、ここに SMTP サーバが追加するヘッダが含まれている場合、DKIM の検証で不合格となる可能性があります。

また、古い SMTP サーバの場合に、Body の１行の長さが長い場合に折り返しの改行を追加したり、8bit のデータを 7bit に変換するなどが発生することがあります。

DMARC による差出人の検証

OP25B、SPF、DKIM の導入によって、不正メールの対策は進みましたが、これでもメーラで表示される差出人、つまりヘッダFrom は詐称できてしまいます。すなわち、SPF、DKIM ともに、DNS で参照するドメインが ヘッダFrom (メーラで表示される差出人) のドメインである必要はないのです。

このため、ヘッダFrom のドメインが SPF もしくは DKIM で参照するドメインと一致するか確認して、
メーラで表示される差出人メールアドレスの詐称を検知できるようにしたのが DMARC です。

DMARC に対応するには、送信側で “ヘッダ From のドメイン” に対して下記をおこなう必要があります。

  • DNS に DMARC レコードを設定する
  • 下記のいずれかに対応する
    • SPF 検証に対応する
    • DKIM 検証に対応する

上記のいずれも、ヘッダFrom のドメインでおこなうことに注意してください。また、DMARC の SPF 検証ではエンベロープFrom のドメインを使用します。HELO/EHLO のホスト名は使用しません。

DMARC のチェックをおこなう MTA では、メールを受信すると下記の手順で検証をおこないます。

  1. SPF および DKIM の検証をおこなう
  2. ヘッダFrom のドメインの DMARC レコードを DNS から取得する。
  3. DMARC レコードが取得できた場合、DMARC 検証を実施する。
    1. SPF の検証に合格し、検証で使用したドメイン(エンベロープFrom)がヘッダFrom のドメインと一致しているかを確認
    2. DKIM の検証に合格し、DKIM-Signature の d= のドメインがヘッダFrom のドメインと一致しているかを確認
  4. 3-1、もしくは 3-2 のどちらかが確認できた場合に、DMARC 検証に合格したと判断する

3-1、3-2 で、検証で使用したドメインとヘッダFrom のドメインが一致することを、アライメントと呼びます。つまり、アライメントとは下記のことを指します。

  • SPF ではエンベロープFrom とヘッダFrom のドメインの一致
  • DKIM では DKIM-Signature の d= のドメインとヘッダFrom のドメインの一致

なお、SPF、DKIM、DMARC の検証は、下記が信頼できることを前提としています。

  • ドメインを設定できるのはドメイン所有者のみ
  • 接続元の IP アドレスが偽装されていない
  • 署名の改竄がされない

DMARC を検証することで、メールの差出人(ヘッダFrom)のドメインが詐称されていないか確認することができます。

現在、商用メールでは DMARC が広く普及しています。大きな理由のひとつが Google による大量メール送信に対する規制で、Gmail 宛に 1日5000通を超えるメール送信者に対して、DMARC への対応を求めており、これに従わない場合は迷惑メールと判断されたり、メールの受信を拒否されることがあります。

メールの転送と SPF

メールの転送とは、宛先となる MTA で一旦受け取ったメールを、別のメールアドレス宛に再配送することを言います。転送時には、エンベロープTo として転送先のメールアドレスが使用されます。

しかし、転送時には、転送先の MTA に接続してくる IPアドレスは 転送元の MTA のものとなる一方で、
エンベロープFrom は元の差出人のままであるため、SPF の検証が不合格になることがあります。

転送したときに SPF に合格させるためには、通常のメール送信の SPF 対応と同様に、下記の条件が必要です。

  • 転送元の MTA の IPアドレスを含む SPF レコードを DNS のドメインに設定する
  • 転送時にエンベロープFrom を上記のドメインのメールアドレスに書き換えて送信する

これにより、転送時でも SPF に合格するように設定できますが、バウンスメールへの配慮が必要です。エンベロープFrom を書き換えなければ、転送時にエラーが発生した場合にはバウンスメールがもともとの差出人に戻ります。しかし、書き換えてしまえば、もとの差出人にはバウンスメールは届きません。

転送しても SPF に合格し、かつエラーメールも元の差出人に戻るようにするための仕組みとして SRS があります。転送時に SPF で合格するための条件は前述のとおりですが、SRS はエンベロープFrom の書き換えに工夫を施し、メールアドレスのローカルパートに、差出人のメールアドレスを仕込みます。

もし転送先でエラーが発生した場合、バウンスメールのエンベロープTo には転送時に書き換えたメールアドレスが入っているので、そのローカルパートから差出人のメールアドレスを取り出したうえで、元の差出人にバウンスメールを転送します。

以上のような方法で転送時でも SPF に合格させることは可能になりますが、SPF に合格させるために エンベロープFrom を書き換えてしまうためSPF のアライメントは不一致(ヘッダFromと一致しない)となります。このため、差出人のドメインで DKIM に対応していない場合は、DMARC 検証は不合格となります。

メールの転送と不正メール対策との相性

不正メールが蔓延している現在において、メールサービスは不正メール対策が必須であり、特に商用メールでは DMARC の対応を求められるようになってきています。

一方で、ここまで見てきたように MTA が受け取ったメールが DMARC に合格していたとしても、それを転送した場合に、差出人のドメインが DKIM に対応していない場合は、SPF で合格していたとしても転送先で確実に DMARC に不合格となります。

SPF、DKIM、DMARC の対応はメールを送信する側で選択することであり、転送する側で制御することはできません。

転送元でおこなった SPF、DKIM、DMARC の検証結果を転送先に伝える仕組みとして ARC があります。ARC は転送元で検証した結果と転送経路の情報をメールヘッダに保存したうえで、その内容に対する改竄の検知ができるようにする仕組みです。

しかし、そもそも転送元の検証結果自体に虚偽が無いかを転送先で検証することまではできないことから、転送メールの不正メール対策としては根本的な解決方法にはなりません。

このように、メールの転送と不正メール対策は相容れない部分があり、現時点でメール転送時に不正メールとして判断されないための完全な解決方法は存在していません。

まとめ

SMTPサーバと不正メール対策の概要を通して、メールの転送に対する課題の理解を目指して説明してきました。なるべく簡潔にするために不必要な詳細には立ち入らず、わかりやすい説明をしようと努めましたが、理解しにくい部分もあったかと思います。皆様のお役にたつようであれば幸いです。

それではまた。楽しいインターネットライフを！

参考文献

「RFC 2476 : Message Submission」
https://datatracker.ietf.org/doc/html/rfc2476

「RFC 4409 : Message Submission for Mail」
https://datatracker.ietf.org/doc/html/rfc4409

「RFC 5321 : Simple Mail Transfer Protocol」
https://datatracker.ietf.org/doc/html/rfc5321

「RFC 5322 : Internet Message Format」
https://datatracker.ietf.org/doc/html/rfc5322

「RFC 7208 : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1」
https://datatracker.ietf.org/doc/html/rfc7208

「RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures」
https://datatracker.ietf.org/doc/html/rfc6376

「RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC)」
https://datatracker.ietf.org/doc/html/rfc7489

フィッシング対策協議会
送信ドメイン認証技術導入実施状況について ～ ISP、CATV、モバイル事業者、フリーメール事業者における導入・設定状況 ～
https://www.antiphishing.jp/report/wg/cert_20250916.html

Google「メール送信者のガイドライン」
https://support.google.com/a/answer/81126

この記事をシェアする

  • facebook
  • twitter
  • hatena
  • line
URLとタイトルをコピーする

実績数30,000件！
サーバーやネットワークなど
ITインフラのことならネットアシストへ、
お気軽にご相談ください

0120-941-670

【受付時間】 10:00～19:00（平日）

お問い合わせ