メールに関する主要なRFCとは？違反しがちなポイントをチェック

RFCとは、インターネットで用いられるさまざまな技術の標準を定めるための文書です。メールに関するRFCも多く存在しており、メールを確実に届けるためには、RFCに記載された技術仕様を理解し、それらに準拠したメール送信を行うことが重要です。本記事では、メールに関する主要なRFCの概要と、RFC違反を注意すべきポイントやチェック方法などについて解説します。

RFCとは

RFC（Request for Comments）とは、インターネット技術の標準化などを行う団体であるIETF（Internet Engineering Task Force）が発行する、インターネット技術の標準的な仕様を記した文書群です。RFCには技術的な詳細、プロトコルの定義、実装方法や運用規則などが書かれており、研究者や技術者が合意を形成するための基盤となっています。

RFCの分類

RFCはインターネット標準化過程というプロセスを経て、正式な「標準」として認められます。標準化過程にあるRFCは段階に応じて以下のステータス（Current status）に分類されます。

標準化への提唱（Proposed Standard）：標準化の最初の段階。
標準化への草稿（Draft Standard）：仕様として十分に成熟している段階
標準（Internet Standard）：標準化の最終段階で、「標準プロトコル」と呼ばれる

※ ただし、2011年に標準化過程が見直され、現在は「標準化への提唱（Proposed Standard）」と「標準（Internet Standard）」の2段階となっています。

また、標準化過程外にあるRFC文書もあり、以下のステータスが存在しています。RFCを参照する際には、その文書のステータスを確認するようにしましょう。

情報提供（Informational)：標準化過程としては処理されないが、広く周知すべきと判断された内容。ベンダー独自の仕様や、特定の分野でデファクトスタンダードとなっているものなど。
実験的（Experimental）：研究成果や実験結果により、公開して共有すべきと判断された内容。実用のためには未解決な問題などが含まれていたり、検討不足な部分が含まれていたりする可能性がある。
歴史的（Historical）：別の仕様によって使われなくなった場合など、役割を終えた文書。
現在のベストプラクティス（Best Current Practice）：インターネットにおける重要な運用手法について書かれた文書。

メール関連のRFC一覧

メールに関するRFCも複数存在しています。GmailやMicrosoft、Appleなどの主要なメールサービスプロバイダは、ガイドラインにおいて「RFCに準拠したメールを送信すること」を推奨しています。そのため、メールの到達率を向上させるためにはRFCに準拠することが重要です。

ここでは、メールに関する特に重要なRFCを紹介します。

メールの基本仕様に関するRFC

メールの基本仕様に関するRFCは次のとおりです。

RFC 5321：Simple Mail Transfer Protocol

インターネットを通じてメールを転送するためのプロトコルであるSMTP（Simple Mail Transfer Protocol）について定義したRFCです。

SMTPで扱われる基本的な用語、SMTPの通信が行われるプロセス、サーバーとクライアント間でやり取りされるSMTPコマンドや応答コード、メールサーバー実装上の考慮事項などについて説明されています。

RFC 5322：Internet Message Format

メールのメッセージ形式を定義したRFCです。メールのヘッダや本文の構成、メールアドレスなどについての仕様が記載されています。

RFC5322はテキストベースのメッセージのフォーマットを定義しており、HTML形式やテキスト以外の添付ファイルなどに関しては後述するMIMEに関するRFCで定義されています。

MIMEに関するRFC

MIME（Multipurpose Internet Mail Extensions）とは、メールでテキスト（ASCII文字）以外のデータを取り扱えるように拡張するための仕様です。

RFC 5322では、メッセージで使える文字列はASCII文字のみと定められています。そこで、MIMEによってメッセージ形式を拡張することで、音声や画像、動画のようなさまざまな形式を使用できるようになります。

MIMEに関するRFCは複数のドキュメントに分割されていますが、メッセージ形式に関係するものは次のとおりです。

RFC 2045：MIME Part One: Format of Internet Message Bodies

MIMEの基礎を定義する文書です。MIMEを使用するためのヘッダフィールドの定義や、テキスト、マルチパート、画像、ビデオなどのコンテンツタイプ、エンコーディングの種別などの指定方法を説明しています。

RFC 2046：MIME Part Two: Media Types

メールで使用できるさまざまなメディアタイプの詳細について定義しています。

RFC 2047：MIME Part Three: Message Header Extensions for Non-ASCII Text

メールヘッダ内で非ASCII文字を扱うためのメカニズムを定義しています。エンコードされたデータのフォーマットや、エンコード方法について説明しています。

日本語エンコーティングに関するRFC

ISO-2022-JPとは、日本語の文字をメールやWebページなどで使用するための文字エンコーディング方式の1つです。ASCII文字と日本語文字（漢字、ひらがな、カタカナなど）を混在させて使用できます。ISO-2022-JPに関するRFCは次のとおりです。

RFC 1468：Japanese Character Encoding for Internet Messages

日本語のテキストをメールで使用するためのエンコーディング規格である「ISO-2022-JP」について説明しています。かつて日本国内で広く採用されており、技術的には今でも有効です。ただし、現在では汎用性や拡張性の観点から、UTF-8が使用されることが増えています。

送信ドメイン認証に関するRFC

送信ドメイン認証とは、メールの送信元が正当であることを検証し、悪意のある第三者によるなりすましを防ぐための仕組みです。送信ドメイン認証にはいくつかの種類があり、それぞれ次のRFCで定義されています。

RFC 7208：Sender Policy Framework – SPF

送信ドメイン認証技術であるSPFの仕様について定義されています。SPFは、送信元メールサーバのIPアドレスを元に送信者の正当性を認証します。

詳しくはこちらの記事をご参照ください。
SPFレコードの書き方とは？記述例を総まとめ | ベアメールブログ

RFC 6376：DomainKeys Identified Mail – DKIM

送信ドメイン認証技術であるDKIMの仕様について定義されています。DKIMは、送信元メールサーバーで付与した電子署名を検証することで、メールの内容が改ざんされていないことを確認します。

詳しくはこちらの記事をご参照ください。
DKIMを導入するには？仕組みや設定方法を解説 | ベアメールブログ

RFC 7489：Domain-based Message Authentication, Reporting, and Conformance – DMARC

送信ドメイン認証技術であるDMARCの仕様について定義されています。DMARCは、SPFやDKIMで認証したドメインと、ヘッダFromのドメインが一致しているか検証することでなりすましを防止します。また、認証に失敗したメールの取り扱いを指示するDMARCポリシーや、認証結果に対するフィードバックレポートを活用することができます。

詳しくはこちらの記事をご参照ください。
DMARCとは？仕組みやメリット、導入方法まで解説 | ベアメールブログ

メールのセキュリティに関するRFC

メールのセキュリティに関するRFCは次のとおりです。

RFC 4954：SMTP Service Extension for Authentication

SMTP-AUTH（SMTP認証）は、SMTPを拡張してSMTPサーバーがクライアント（送信者）を認証できるようにするための仕様です。これにより、不正なメール送信を防ぎ、サーバーのセキュリティを向上させることができます。

詳しくはこちらの記事をご参照ください。
SMTP-AUTHとは？ SMTP認証の仕組みやセキュリティを高めるための注意点 | ベアメールブログ

RFC 3207：SMTP Service Extension for Secure SMTP over Transport Layer Security (TLS)

TLS（Transport Layer Security）を使用して安全なSMTP接続を提供するための方法が定義されています。この拡張機能を使用することで、メールサーバ間の通信が暗号化され、中間者攻撃によるデータの盗聴や改ざんを防ぐことが可能になります。

2024年2月に適用されたGmailの送信者ガイドラインにおいて、すべての送信者に対しTLS接続を使用することが要件として課せられています。

詳しくはこちらの記事をご参照ください。
STARTTLSとは？メールのTLS暗号化の仕組みから設定・確認方法 | ベアメールブログ

その他状況に応じて対応が必要なRFC

Gmailの送信者ガイドラインで対応が推奨されている内容に関するRFCです。

RFC 8058：Signaling One-Click Functionality for List Email Headers

RFC 8058は、メール受信者がマーケティングメールやメールマガジンの購読を簡単に解除できるようにするためのワンクリック登録解除機能の実装方法について説明したRFCです。

Gmailの送信者ガイドラインにおいて、1日Gmail宛に5000通以上配信する送信者は、マーケティングメールにワンクリックでの登録解除機能を実装することが求められているため、該当する場合はこのRFCの仕様に従って対応する必要があります。

詳しくはこちらの記事をご参照ください。
List-Unsubscribeとは？ RFC8058の仕様に従って実装するポイント | ベアメールブログ

RFC 8617：Authenticated Received Chain – ARC

ARCは、メールが転送される間もメールの認証情報を保持することで、転送に起因するSPF・DKIM・DMARCの認証失敗を防ぎ、最終受信者がそのメールの信頼性を判断できるようにするための仕組みです。

Gmailの送信者ガイドラインにおいても、メールを定期的に転送する場合はARCヘッダを追加することが推奨されているため、該当する場合はこのRFCに従って対応する必要があります。

詳しくはこちらの記事もご参照ください。
メールのARCとは？ ARCの仕組み、設定が必要なケースを解説 | ベアメールブログ

RFCに違反しないためのポイント

RFC違反したメールはどうなる？

GoogleやApple、Microsoftを始めとする、主要なメールサービスプロバイダでは、RFCに準拠することを推奨しています。

Google：メッセージ形式がInternet Message Format 標準に準拠（RFC 5322）

Apple：電子メールがRFC 5322に準拠するよう徹底する

Microsoft： RFC 2821、RFC 2822、およびその他を含む、メール送信におけるすべての技術仕様を満たすこと

※RFC 2821は現在のRFC 5321、RFC 2822は現在のRFC 5322

引用元：https://support.google.com/a/answer/81126?hl=ja

引用元：https://support.apple.com/ja-jp/102322

引用元：https://sendersupport.olc.protection.outlook.com/pm/policies.aspx

もしRFCに違反している場合は、受信が拒否されたり、迷惑メールとして扱われたりする可能性があります。それにより送信エラー率が高い状況が継続してしまうと、IPやドメインのレピュテーションが低下する恐れもあるため、違反している場合は迅速に対処すべきでしょう。

RFC違反となりがちなポイント

メールに関するRFCの中でも、メールサービスプロバイダが特に重視しているのはRFC 5322であることがガイドラインからも分かります。Postfixなどの普及したMTAを使用する場合、RFCへの準拠は大部分がソフトウェアによって保証されるはずですが、独自にメール送信を行う仕組みを実装した場合や、カスタマイズを行う場合には注意が必要です。

ここではRFC 5322で違反しやすいポイントにはどのようなものがあるか確認します。

必須ヘッダがない、ヘッダが重複している

RFC5322において特に重要となるのがヘッダフィールドに関する仕様で、必須のヘッダや複数あってはならないヘッダについて、不備があるとRFC違反としてブロックされる恐れがあります。

必須のヘッダ

Date	送信日時
From	送信者アドレス
Message-ID	メールを識別するためのID

Message-IDについては、RFC上では[SHOULD be present]となっていますが、事実上必須となっています。

Gmailが重複をチェックするヘッダ

To	宛先
Cc	CCの宛先
Subject	件名
Date	送信日時
From	送信者アドレス
Sender	送信者（代行する場合）
Reply-To	返信先
Bcc	BCCの宛先
Message-ID	メールを識別するためのID
In-Reply-To	返信先のメッセージID
References	スレッドの参照

Googleによれば、上記のヘッダについて重複が確認された場合、メールは宛先に配信されず、「このメッセージは RFC 5322 に準拠していません」というエラーメールが送信者に返されます。

参考：Google Workspace 管理者ヘルプ「RFC 5322（重複したヘッダー）バウンスメールのトラブルシューティング」https://support.google.com/a/answer/13567860?hl=ja#zippy=%2Cduplicate-headers-gmail-checks-for

Message-IDフォーマットの誤り

Message-IDはメールを一意に特定するためにユニークである必要があります。

Message-IDをユニークにするために、西暦日付＋連番@IPアドレス／ドメイン名といった形で採番することが一般的ですが、このIPアドレスがプライベートIPになっていたり、ドメイン名になっていなかったりすると、IDがユニークにならない恐れがあります。

Dateフォーマットの誤り

必須ヘッダであるDate:のフォーマットに間違いがないようにします。最新のRFCでは各項目の記載方法について明確に定義されています。

date-time       =   [ day-of-week "," ] date time [CFWS]
day-of-week     =   ([FWS] day-name) / obs-day-of-week
day-name        =   "Mon" / "Tue" / "Wed" / "Thu" /
                    "Fri" / "Sat" / "Sun"
date            =   day month year
day             =   ([FWS] 1*2DIGIT FWS) / obs-day
month           =   "Jan" / "Feb" / "Mar" / "Apr" /
                    "May" / "Jun" / "Jul" / "Aug" /
                    "Sep" / "Oct" / "Nov" / "Dec"
year            =   (FWS 4*DIGIT FWS) / obs-year
time            =   time-of-day zone
time-of-day     =   hour ":" minute [ ":" second ]
hour            =   2DIGIT / obs-hour
minute          =   2DIGIT / obs-minute
second          =   2DIGIT / obs-second
zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

実際の例：
Date: Tue, 09 Mar 2021 16:05:00 +0900

day-of-week	曜日（Sun, Mon, Tue, Wed, Thu, Fri, Sat）これは省略可能です
day	日付（01から31までの数字）先頭が0の場合は0をつけて二桁で表記します
month	月（Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec）
year	年（4桁の数字）
hour:minute:second	時間、分、秒（それぞれ二桁の数字） 24時間制を使用します
zone	UTC（協定世界時）からのオフセットを「+hhmm」または「-hhmm」の形式で示します UTCそのものの場合は「+0000」と記述します