現代のビジネスや日常生活に欠かせない電子メールは、単なるテキストのやり取りにとどまらず、複雑で高度な技術仕様の上に成り立っています。
メールがどのような仕組みで届くのか、どんな規格に基づいて構成されているのかを理解することで、セキュリティやトラブル対応にも役立てることができます。
この記事では、電子メールの構造から各種プロトコル、セキュリティ対策に至るまで、基本的な仕様をわかりやすく解説します。
電子メールの仕様について
電子メール(Email)は、インターネットを利用した代表的な通信手段であり、個人から企業まで幅広く利用されています。
その技術的な裏側では、送信プロトコル、受信プロトコル、文字コードの扱い、さらには添付ファイルやマルチメディア対応のための拡張規格まで、さまざまな仕様や標準が関係しています。

なんだか複雑そう……。
こうした仕様は、RFC(Request for Comments)と呼ばれる文書群で詳細に定義されており、特にRFC5322はメールの基本構造を規定する重要な文書です。
ここからは、これらの技術仕様をもとに、電子メールの仕組みや規格を体系的に解説します。
RFC5322による仕様の規定
電子メールの基本仕様は、IETF(Internet Engineering Task Force)によって定められたRFC5322により定義されています。
RFC5322は、以前のRFC822を置き換える形で2008年に発行された文書で、電子メールの構文、構造、書式に関する規則を包括的に記述しています。



たとえば、ヘッダーと本文の分離方法、メールアドレスの記述ルール、メッセージIDや日付の形式など、メールの基本的な要素がどのように表現されるべきかを厳密に規定しています。
この仕様を正しく実装することにより、異なるメールソフト間で一貫性のあるメッセージ交換が可能になります。
電子メールの構造
電子メールは大きく分けて「ヘッダ」と「本文」から構成されます。
- ヘッダ(Header):送信元、宛先、件名、日時、送信経路(Receivedヘッダ)などの情報を含みます。
- 本文(Body):メッセージの内容自体です。テキスト形式の他、HTML形式もあります。
メールアドレスの仕様(RFC5322準拠)
メールアドレスの形式はRFC5322で明確に規定されており、「local-part@domain」という構造が基本となっています。
たとえば「example.user+info@example.co.jp」というアドレスのように、@の前にあたるローカルパートには英数字のほか、ピリオドやプラス記号といった一部の特殊文字も利用可能です。
一方、@の後ろに続くドメイン部はFQDN(完全修飾ドメイン名)で表され、インターネット上で一意に識別できる必要があります。
このドメイン名を使ってメールを実際に送信する際には、送信元のメールサーバはまずDNS(Domain Name System)を利用して、ドメインに対応するメールサーバのIPアドレスを調べる必要があります。
これは「名前解決」と呼ばれるプロセスで、送信先のドメインがどのサーバに属しているのかを特定するために欠かせません。



名前解決についてはこちらの記事で学びましたね。
たとえば、example.co.jp というドメインにメールを送る場合、DNSのMX(Mail Exchange)レコードを参照して、そのメールを処理するべきサーバの情報を取得します。



名前解決が正しく行われないと、メールは宛先不明として配送に失敗します。
このように、メールアドレスが機能するためには、構文上の正しさだけでなく、そのドメイン部分に対する名前解決が確実に行えることが必要不可欠です。
メールヘッダの仕様(RFC5322準拠)
電子メールのヘッダには、送信者や宛先、件名、送信日時、配送経路など、メールの管理や処理に欠かせない情報が含まれています。
これらのヘッダはRFC5322などで明確に定義されており、メールの正確な伝達とトラブル対応を支える重要な要素です。
以下に、代表的なヘッダとその用途を一覧で紹介します。
ヘッダ名 | 意味・用途 |
---|---|
From | メールの送信者を示すメールアドレスが記載される。多くの場合、表示名とメールアドレスの両方が含まれ、「山田 太郎 taro@example.com」のような形式で記述される。 |
To | メールの主な宛先である受信者のメールアドレス。複数指定されることもあり、全員に表示される。 |
Cc | カーボンコピーの送信先。Toと同様に受信者に表示されるが、主な宛先ではない補足的な受信者。 |
Bcc | ブラインドカーボンコピーの送信先。他の受信者には表示されず、秘匿してメールを共有したいときに使う。 |
Subject | メールのタイトルや主題を記載。受信者が内容を判断する目安となる。 |
Date | メールが送信された正確な日時。受信者のメールソフトではこの値をもとに並び順などが決定される。 |
Message-ID | 各メールに固有の識別子を付け、スレッド管理や重複防止、参照関係の判定などに利用される。 |
Return-Path | メールが配信できなかった場合にエラーメール(バウンス)が返送される送信元のアドレス。 |
Reply-To | 返信時に指定される返信先アドレス。Fromアドレスとは異なるアドレスを指定したいときに使用。 |
In-Reply-To | 返信先のメールに付与されたMessage-IDを引用し、スレッドの整合性を保つために用いられる。 |
Received | メールが通過した各サーバーの情報を記録する。スパム検出や配送トラブル時の追跡に役立つ。 |
MIME-Version | MIME規格のバージョン情報。メールがMIMEに準拠していることを示し、通常は”1.0″が使用される。 |
Content-Type | メール本文や添付ファイルの形式を指定。text/plainやmultipart/mixedなどが使用される。 |
Content-Transfer-Encoding | メール本文のエンコード方法。7bit, quoted-printable, base64などがあり、異なるシステム間での互換性を確保する。 |
送信・受信プロトコル
電子メールの送受信には、役割の異なる2種類のソフトウェアが連携して動作します。
まず、ユーザーが直接操作するメールソフトは MUA(Mail User Agent) と呼ばれます。
これはメールの作成・送信・受信・閲覧などを行うアプリケーションで、Outlook、Thunderbird、Apple Mail、またはスマートフォンの標準メールアプリなどが該当します。



スマホのメールアプリとかがMUAってことですね。
一方、メールの配送処理を行うのが MTA(Mail Transfer Agent) です。
MTAはSMTP(Simple Mail Transfer Protocol)を利用し、送信されたメールを他のメールサーバへ中継し、最終的に宛先ドメインのメールサーバに届ける役割を担います。
主なMTAには Postfix、Sendmail、Exim、qmail などがあり、それぞれがメール配送の自動化やエラー処理を担っています。



MTAの方は目に見えないところで働いているんだなぁ。
このMUAとMTAの関係を例えるならば、MUAが「手紙を書く人とポスト」、MTAが「郵便局と配達員」に相当します。
ユーザーがメールを送信すると、MUAはMTAにその内容を渡し、MTAは適切な宛先までメールを届けてくれるのです。
このように、電子メールの送受信は、ユーザーインターフェースとしてのMUAと、ネットワークを通じてメールを配送するMTAが協力することで実現されており、複数のプロトコルが連携して動作しています。
MIME:添付ファイルとマルチパート
MIME(Multipurpose Internet Mail Extensions)は、もともとASCII文字しか扱えなかった電子メールの仕様を拡張し、画像、音声、PDF、日本語テキストなどの非ASCIIデータをやり取りできるようにした標準規格です。
※「ASCII(アスキー)」とは、American Standard Code for Information Interchange(アメリカ情報交換標準コード)の略で、コンピューターが文字を扱うための最も基本的な文字コード体系の一つです。
もともとの電子メール仕様(RFC822や初期のRFC5322など)は、ASCII文字のみを送受信できる前提で設計されていました。
そのため、画像や日本語などの非ASCIIデータは扱えませんでした。
そこで登場したのがMIME(Multipurpose Internet Mail Extensions)です。
MIMEでは、非ASCII文字をBase64やQuoted-printableなどでエンコードし、ASCIIとして転送できるようにしています。
MIMEにより、メール本文や添付ファイルの種類、構造、エンコード方法などが明確に定義され、異なるメールソフト間でも正しく情報が伝達されるようになりました。
たとえば、メール本文が日本語で書かれていたり、写真や資料を添付したい場合、MIMEの構成要素を適切に使う必要があります。
Content-Typeヘッダではそのパートのデータがテキストなのか、画像なのかといった「種類」を指定し、Content-Transfer-Encodingではそれをどのような形式でエンコードして転送するか(Base64など)を指定します。
また、メールに本文と添付ファイルを同時に含める場合は、MIMEの”multipart”構造を使います。
これは、1通のメールを複数の「パート」に分け、それぞれの内容(例:プレーンテキスト本文とPDFファイル)を個別に記述する仕組みです。
こうした構造により、よりリッチなコンテンツを含んだメールのやり取りが可能になります。
まとめ
電子メールは、RFCによる標準化、ヘッダと本文の構造、MUAとMTAの連携、そしてMIMEによるデータ拡張など、さまざまな技術仕様が組み合わさって成り立っています。
これらの仕様は、日々膨大な数のメールが世界中で正確かつ安全に送受信されるための土台となっています。



メールという一見シンプルなツールの裏には、非常に多層的で洗練された仕組みが存在しており、これを理解することは、トラブルシューティングやセキュリティ対策、システム設計においても大きな武器となります。
今後も進化を続ける電子メールの技術を正しく活用するために、これらの基本仕様を押さえておくことが重要です。