メール送信を行う上で知っておきたい用語一覧まとめ

[blastengine](https://blastengine.jp/)のエバンジェリストを続ける中で、さまざまな用語に触れる機会がありました。メールは古参のインターネットプロトコルですが、悪用されることも多々あり、それを防ぐために新しい技術が開発されています。

ということで、そうした用語とその意味をまとめてみました。

## メールのセキュリティ関連

### SPF

SPFは、Sender Policy Frameworkの略で、メールの送信元のドメインが正当なものであるかを確認するための技術です。メールの送信元ドメインが、正当なSMTPサーバーから送信されたものであるかを定義します。

こうしたメール関係のセキュリティは、DNSのTXTレコードに記述されます。たとえばblastengineをSMTPリレー（後述）として利用する場合、以下のようにTXTレコードを設定します。

```
txt @ v=spf1 include:spf.besender.jp ~all
```

こうすることで、 `spf.besender.jp` が自分たちの送信ドメインに対する正当なSMTPサーバーであることを示します。

### DKIM

DKIMは、DomainKeys Identified Mailの略です。こちらも、メールの送信元ドメインが正当なものであるかを確認するための技術です。メールのヘッダー情報、本文を秘密鍵で署名し、 `DKIM-Signature` ヘッダーにその署名を記述します。さらに公開鍵をDNSのTXTレコードに記述します。たとえば、以下のように設定します。

```
txt default._domainkey v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDd8K
```

受信側のサーバーでは、この公開鍵を使ってメールの署名を検証し、正当なメールであるかを確認します。

### ARC

ARCは、Authenticated Received Chainの略で、メールの転送経路を追跡するための技術です。メールの転送経路が複数のSMTPサーバーを経由する場合、その経路が正当なものであるかを確認します。

これは、DKIMにおいてメール転送した際に、新しいヘッダーが追加されて検証に失敗してしまう問題を回避します。 `ARC-Authentication-Results` ヘッダーにその情報を記述し、転送後も正当なメールであるかを確認できます。

### DMARC

DMARCは、SPFとDKIMによって検証に失敗したメールをどう取り扱うかを定義する技術です。不正なメールと判定されたら、「何もしない」「スパムフォルダに移動する」「拒否する」のいずれかのアクションを指定します。

DMARCも、他と同じくDNSのTXTレコードに記述します。たとえば、以下のように設定します。

```
txt _dmarc v=DMARC1; p=none; rua=mailto:report@example.com; ruf=mailto:abuse@example.com
```

レポートがXML形式で送られるので、それを解析して、不正なメールを検知できます。たとえば本来は正当なSMTPサーバーのものだった場合、対応することでレポートが改善されるでしょう。

### BIMI

BIMIは、Brand Indicators for Message Identificationの略で、正当な送信元だった場合に、企業やサービスのブランドロゴを表示する技術です。元々はDMARCを設定した企業・サービスに対して、その特典的な位置付けだったと言われています。

現在、BIMIに対応しているのはGmail、ドコモメール、メール（Apple）、Yahoo.comなどがあります。BIMIは、ロゴの商標を取得する必要があって、若干ハードルが高いのです。しかし、Googleが2024年9月にCommon Mark Certificates（商標不要）に対応すると発表したので、今後は普及が進むでしょう。

[Google Workspace Updates: Gmail allows more senders to protect their brand using BIMI Common Mark Certificates](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html)

BIMIも他と同じく、DNSのTXTレコードに記述します。たとえば、以下のように設定します。

```
txt default._bimi v=BIMI1; l=https://example.com/logo.svg
```

### SMTPリレー

SMTPリレーは、インターネット黎明期と現在では意味が若干変わっています。昔のインターネットでは、配信先のメールサーバーに直接接続できないため、中継するSMTPサーバーを経由してメール配信を行うことを指していました。

現在は、そうした目的での中継は不要になっています。そして、今は自社のSMTPサーバーに代わって、大量のメール配信を行ったり、メール配信を安定的に行うために利用されます。

[私たちの提供するblastengine](https://blastengine.jp/)も、その一つです。

### レピュテーション

レピュテーションとは、信頼性を意味します。メール配信の中では、IPレピュテーションとドメインレピュテーションの2つがあります。IPレピュテーションは、特定のIPアドレスがメールサーバにとって信頼されているかどうかを意味します。一時期、パブリッククラウドを利用したスパムメール配信が横行し、どのインスタンスのIPアドレスもブラックリストに載っているという事態が発生しました。

ドメインレピュテーションは、さらにそれがドメイン単位で行われます。再販されているドメインを使ったら、過去にスパムの温床になっていた…なんてこともあります。

IPレピュテーション、ドメインレピュテーションはたとえば[Email Blacklist Check](https://mxtoolbox.com/blacklists.aspx)や[MultiRBL\.valli\.org](https://multirbl.valli.org/lookup/)等を使って確認できます。少なくとも、ここでブラックリストに入っているものは使わない方が良いでしょう。

### S/MIME

S/MIMEは、Secure/Multipurpose Internet Mail Extensionsの略で、メールの暗号化技術です。メールの送信者が秘密鍵で署名し、受信者が公開鍵で検証することで、メールの送信元が正当なものであるかを確認します。

最初に公開鍵を交換しなければならないのがネックですが、セキュリティを重視する場合は有効な技術です。添付ファイルも含めて暗号化されるので、暗号化Zipファイルよりお勧めです。

### GPG

GPGは、GNU Privacy Guardの略で、PGP（Pretty Good Privacy）のオープンソース実装です。GPGは、メールの暗号化技術として有名です。S/MIMEと同じく、秘密鍵で署名し、公開鍵で検証することで、メールの送信元が正当なものであるかを確認します。

GPGも、S/MIMEと同じく公開鍵を交換するのが課題になります。

### STARTTLS

STARTTLSは、SMTPの暗号化技術です。最初から暗号化するならばSMTPSやESMTPSを使いますが、STARTTLSは途中から、暗号化通信に切り替える技術です。

そのため、既存のポート（25番）を使って暗号化通信を行うのに適しています。STARTTLSに対応していなければ既存のまま、対応していれば暗号化通信と既存のリソースを活かせるのがメリットです。

### DANE

DANE（DNS-based Authentication of Named Entities）は、メールサーバー間の通信をより安全にするための仕組みです。DNS（Domain Name System）のレコードに、メールサーバーの暗号化に関する情報を登録して、なりすましや中間者攻撃を防ぎます。

実際に設定するのはTLSAレコードと呼ばれるもので「証明書の使用用途」「証明書の選択方法」「マッチングタイプ」「証明書の関連付け」などを設定します。たとえば、以下のように設定します。

```
_25._tcp.example.com.  IN  TLSA  1 2 1 (ハッシュ値)
```

### DNSSEC

DNSSECは、DNSのセキュリティ拡張です。DNSのデータが改ざんされていないかを確認するための技術です。DNSSECは、DNSのデータに署名を付与し、公開鍵をDNSのレコードに記述します。DANEではDNSSECを利用してDNSの検証を行い、失敗した場合にはメール配信を行いません。

### MTA-STS

MTA-STSもDANEと同じく、メールサーバー間の通信をより安全にするための仕組みです。メールサーバーがMTA-STSポリシーを公開し、メールサーバーがそのポリシーに従って通信を行います。

DANEとの違いとしては、DNSSECに依存しないので導入しやすいという点が挙げられます。また、ポリシーでTLSのバージョンを指定するなどの違いがあります。

以下は、MTA-STSのポリシーの例です。

```
_mta-sts.example.com.  TXT  "v=STSv1; id=2023010100; max_age=31536000; mxpolicy=enforce; mode=testing; uri=https://mta-sts.example.com/policy.txt"
```

## メールプロトコル

### SMTP

SMTPは、Simple Mail Transfer Protocolの略で、メールの送信を行うためのプロトコルです。SMTPは、メールの送信元、送信先、メールの内容を定義し、メールの送信を行います。

### ESMTP

ESMTPは、Extended Simple Mail Transfer Protocolの略で、SMTPの拡張版です。ESMTPは、SMTPの機能を拡張し、メールの送信をより効率的に行います。

元々のSMTPではサポートされていなかった添付ファイル（MIME）や認証（SMTP AUTH）などがESMTPでサポートされています。そのため、現在ではESMTPが主流となっています。

### SMTPS

SMTPSは、SMTP over SSLの略で、SMTPの暗号化技術です。SMTPSは、SMTPの通信をSSL/TLSで暗号化し、メールの送信を安全に行います。通常のSMTPでは、パスワードや本文もすべて平文で送信されるので、そのままでの運用は危険です。

### IMAP

IMAPは、Internet Message Access Protocolの略で、メールの受信を行うためのプロトコルです。IMAPは、メールサーバーに保存されたメールを取得し、クライアントに表示します。

IMAPはメールをサーバーに蓄積するので、複数のデバイスで同じメールを見られたり、クライアント側のストレージを節約できるのがメリットです。

### IMAPS

IMAPSはIMAP over SSLの略で、IMAPの暗号化技術です。IMAPの通信をSSL/TLSで暗号化し、メールの受信を安全に行います。

### POP3

POP3は、Post Office Protocol version 3の略で、メールの受信を行うためのプロトコルです。POP3はメールボックスからメールを削除するので、メールはサーバーに保存されません。

メールサーバー側のメールボックス容量が小さい場合や、メールをサーバーへ保存したくない場合に利用されます。

### POP3S

POP3SはPOP3 over SSLの略で、POP3の暗号化技術です。POP3の通信をSSL/TLSで暗号化します。

### SMTP AUTH

SMTP AUTHはSMTP Authenticationの略で、SMTPの認証技術です。SMTP AUTHにはPLAIN、LOGIN、CRAM-MD5などの認証方式があります。

## メールヘッダーなど

### Message-ID

Message-IDは、メールのユニークな識別子です。Message-IDは、メールの送信元、送信先、送信日時などの情報を元に生成されます。返信時に `In-Reply-To` に対して、このMessage-IDを記述することで、メールがスレッド化されます。

### MIME

MIMEは、Multipurpose Internet Mail Extensionsの略で、メールの機能拡張技術です。メールに添付ファイルを追加したり、HTMLメールを送信したりする機能を提供します。

### boundary

boundaryは、MIMEで使用される区切り文字です。boundaryは、メールの本文と添付ファイルを区切るために使用されます。メール内において、ユニークな文字列を設定します。ファイルや本文ごとに異なるboundaryを設定します。

メールライブラリを使っている場合は自動で設定されますが、時々自作する必要性に迫られることもあります。

### List-Unsubscribe

List-Unsubscribeは、メーリングリストからの解除方法を記述するヘッダーです。List-Unsubscribeにはメールの送信先、解除方法などの情報が記述されます。

解除方法としては、特定のメールアドレスに対してメールを送信するか、特定のURLにアクセスする方式があります。両方設定できますが、Gmailの場合はデフォルトではメール送信方法のみサポートされます。URLアクセス方式はどのタイミングで（配送量、期間などによる？）サポートされるかは不明です。

記述例は以下のようになります。

```
List-Unsubscribe: <mailto:unsubscribe-999@example.com>, <https://example.com/unsubscribe/999>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
```

## まとめ

メールはさすがに歴史が長いだけあって、さまざまな技術が詰まっています。元々がシンプルだったために、不正利用が多く、フィッシング詐欺やマルウェアの拡散などが横行しています。そうした被害者にならないのはもちろん、場合によってはいつの間にか加害者になっていた…なんてことがないよう、適切なメールサーバーの設定や運用が求められます。

blastengineはデベロッパーフレンドリーなメール配信サービスとして、安定したメール配信を提供しています。ぜひメール送信の安心・安全な運用にご利用ください！

[【公式】ブラストエンジン（blastengine）｜API連携・SMTPリレー](https://blastengine.jp/)