RFCとは、インターネットで用いられるさまざまな技術の標準を定めるための文書です。メールに関するRFCも多く存在しており、メールを確実に届けるためには、RFCに記載された技術仕様を理解し、それらに準拠したメール送信を行うことが重要です。本記事では、メールに関する主要なRFCの概要と、RFC違反を注意すべきポイントやチェック方法などについて解説します。
目次
RFC（Request for Comments）とは、インターネット技術の標準化などを行う団体であるIETF（Internet Engineering Task Force）が発行する、インターネット技術の標準的な仕様を記した文書群です。RFCには技術的な詳細、プロトコルの定義、実装方法や運用規則などが書かれており、研究者や技術者が合意を形成するための基盤となっています。
RFCはインターネット標準化過程というプロセスを経て、正式な「標準」として認められます。標準化過程にあるRFCは段階に応じて以下のステータス（Current status）に分類されます。
※ ただし、2011年に標準化過程が見直され、現在は「標準化への提唱（Proposed Standard）」と「標準（Internet Standard）」の2段階となっています。
また、標準化過程外にあるRFC文書もあり、以下のステータスが存在しています。RFCを参照する際には、その文書のステータスを確認するようにしましょう。
メールに関するRFCも複数存在しています。GmailやMicrosoft、Appleなどの主要なメールサービスプロバイダは、ガイドラインにおいて「RFCに準拠したメールを送信すること」を推奨しています。そのため、メールの到達率を向上させるためにはRFCに準拠することが重要です。
ここでは、メールに関する特に重要なRFCを紹介します。
メールの基本仕様に関するRFCは次のとおりです。
インターネットを通じてメールを転送するためのプロトコルであるSMTP（Simple Mail Transfer Protocol）について定義したRFCです。
SMTPで扱われる基本的な用語、SMTPの通信が行われるプロセス、サーバーとクライアント間でやり取りされるSMTPコマンドや応答コード、メールサーバー実装上の考慮事項などについて説明されています。
メールのメッセージ形式を定義したRFCです。メールのヘッダや本文の構成、メールアドレスなどについての仕様が記載されています。
RFC5322はテキストベースのメッセージのフォーマットを定義しており、HTML形式やテキスト以外の添付ファイルなどに関しては後述するMIMEに関するRFCで定義されています。
MIME（Multipurpose Internet Mail Extensions）とは、メールでテキスト（ASCII文字）以外のデータを取り扱えるように拡張するための仕様です。
RFC 5322では、メッセージで使える文字列はASCII文字のみと定められています。そこで、MIMEによってメッセージ形式を拡張することで、音声や画像、動画のようなさまざまな形式を使用できるようになります。
MIMEに関するRFCは複数のドキュメントに分割されていますが、メッセージ形式に関係するものは次のとおりです。
MIMEの基礎を定義する文書です。MIMEを使用するためのヘッダフィールドの定義や、テキスト、マルチパート、画像、ビデオなどのコンテンツタイプ、エンコーディングの種別などの指定方法を説明しています。
メールで使用できるさまざまなメディアタイプの詳細について定義しています。
メールヘッダ内で非ASCII文字を扱うためのメカニズムを定義しています。エンコードされたデータのフォーマットや、エンコード方法について説明しています。
ISO-2022-JPとは、日本語の文字をメールやWebページなどで使用するための文字エンコーディング方式の1つです。ASCII文字と日本語文字（漢字、ひらがな、カタカナなど）を混在させて使用できます。ISO-2022-JPに関するRFCは次のとおりです。
日本語のテキストをメールで使用するためのエンコーディング規格である「ISO-2022-JP」について説明しています。かつて日本国内で広く採用されており、技術的には今でも有効です。ただし、現在では汎用性や拡張性の観点から、UTF-8が使用されることが増えています。
送信ドメイン認証とは、メールの送信元が正当であることを検証し、悪意のある第三者によるなりすましを防ぐための仕組みです。送信ドメイン認証にはいくつかの種類があり、それぞれ次のRFCで定義されています。
送信ドメイン認証技術であるSPFの仕様について定義されています。SPFは、送信元メールサーバのIPアドレスを元に送信者の正当性を認証します。
詳しくはこちらの記事をご参照ください。
SPFレコードの書き方とは？ 記述例を総まとめ | ベアメールブログ
送信ドメイン認証技術であるDKIMの仕様について定義されています。DKIMは、送信元メールサーバーで付与した電子署名を検証することで、メールの内容が改ざんされていないことを確認します。
詳しくはこちらの記事をご参照ください。
DKIMを導入するには？ 仕組みや設定方法を解説 | ベアメールブログ
送信ドメイン認証技術であるDMARCの仕様について定義されています。DMARCは、SPFやDKIMで認証したドメインと、ヘッダFromのドメインが一致しているか検証することでなりすましを防止します。また、認証に失敗したメールの取り扱いを指示するDMARCポリシーや、認証結果に対するフィードバックレポートを活用することができます。
詳しくはこちらの記事をご参照ください。
DMARCとは？ 仕組みやメリット、導入方法まで解説 | ベアメールブログ
メールのセキュリティに関するRFCは次のとおりです。
SMTP-AUTH（SMTP認証）は、SMTPを拡張してSMTPサーバーがクライアント（送信者）を認証できるようにするための仕様です。これにより、不正なメール送信を防ぎ、サーバーのセキュリティを向上させることができます。
詳しくはこちらの記事をご参照ください。
SMTP-AUTHとは？ SMTP認証の仕組みやセキュリティを高めるための注意点 | ベアメールブログ
TLS（Transport Layer Security）を使用して安全なSMTP接続を提供するための方法が定義されています。この拡張機能を使用することで、メールサーバ間の通信が暗号化され、中間者攻撃によるデータの盗聴や改ざんを防ぐことが可能になります。
2024年2月に適用されたGmailの送信者ガイドラインにおいて、すべての送信者に対しTLS接続を使用することが要件として課せられています。
詳しくはこちらの記事をご参照ください。
STARTTLSとは？ メールのTLS暗号化の仕組みから設定・確認方法 | ベアメールブログ
Gmailの送信者ガイドラインで対応が推奨されている内容に関するRFCです。
RFC 8058は、メール受信者がマーケティングメールやメールマガジンの購読を簡単に解除できるようにするためのワンクリック登録解除機能の実装方法について説明したRFCです。
Gmailの送信者ガイドラインにおいて、1日Gmail宛に5000通以上配信する送信者は、マーケティングメールにワンクリックでの登録解除機能を実装することが求められているため、該当する場合はこのRFCの仕様に従って対応する必要があります。
詳しくはこちらの記事をご参照ください。
List-Unsubscribeとは？ RFC8058の仕様に従って実装するポイント | ベアメールブログ
ARCは、メールが転送される間もメールの認証情報を保持することで、転送に起因するSPF・DKIM・DMARCの認証失敗を防ぎ、最終受信者がそのメールの信頼性を判断できるようにするための仕組みです。
Gmailの送信者ガイドラインにおいても、メールを定期的に転送する場合はARCヘッダを追加することが推奨されているため、該当する場合はこのRFCに従って対応する必要があります。
詳しくはこちらの記事もご参照ください。
メールのARCとは？ ARCの仕組み、設定が必要なケースを解説 | ベアメールブログ
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 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をユニークにするために、西暦日付＋連番@IPアドレス／ドメイン名といった形で採番することが一般的ですが、このIPアドレスがプライベートIPになっていたり、ドメイン名になっていなかったりすると、IDがユニークにならない恐れがあります。
必須ヘッダである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」と記述します |
RFC 5322では、メールの本文・ヘッダ一行あたりの文字数について制限が設けられています。
2.1.1. 行の長さの制限
この仕様が 1 行の文字数に課す制限は二つある。CRLF を除いて、各行は 998 文字を超えてはならず(MUST)、78 文字を超えるべきではない(SHOULD)。
引用：RFC5322（Internet Message Format）日本語訳 http://srgia.com/docs/rfc5322j.html#p2.1
この「文字数」というのはASCII文字での換算であり、日本語の文字数ではありません。通常、日本語のメールは送信環境でASCII文字にエンコードされ、その際に1行78文字以内となるように自動的に改行処理が行われます。ASCII文字の1文字＝1バイトとなるため、制限をバイト数で表現する場合もあります。
一般的なメールサービスやメーラー、メール配信システムでは自動的に改行処理がされる仕様になっているものの、独自に開発したシステム（アプリケーション）にメールを作成し送信する仕組みを実装した場合は、この改行処理を組み込む必要があります。
詳しくはこちらの記事をご参照ください。
RFCで規定されているメール本文一行あたりの文字数とは？ | ベアメールブログ
自社で送信しているメールがRFCに準拠できているか、どのようにチェックすれば良いのでしょうか？ ここではRFC違反をチェックするために利用できるツールを紹介します。
RFCへの準拠を網羅的に診断できるわけではありませんが、前述したようにRFC 5322で重要となるのは大部分がメールヘッダのフォーマットです。
チェックしたいメールのヘッダ情報（メールソース）をコピー＆ペーストし、[Analyze Header]のボタンを押すとヘッダの分析情報を確認できます。メールに含まれているヘッダとそのフィールドの値、SPF・DKIM・DMARCの認証状況も併せて確認することができます。
MXTOOLBOX「Email Header Analyzer」https://mxtoolbox.com/EmailHeaders.aspx
迷惑メールスコアリングは、ベアメールが提供するメールの正常性の診断・モニタリングサービスです。テストメールを送信するだけで、多角的な診断を受けることができ、迷惑メールと判定される要因がないかチェックできます。
こちらもRFCへの準拠を網羅的に診断できるわけではありませんが、Message-IDのチェックや、ヘッダ・本文の一文あたりの長さ制限のチェックなど、重要なポイントについて確認可能です。
その他にも、送信ドメイン認証やDNSの設定、ブラックリストチェック、本文解析などが可能な他、洗い出した問題点の改善方法の確認や、GmailやiCloudといった主要なメールサービスに対する到達度の診断なども可能です。
ベアメール 迷惑メールスコアリング | メールの健全性モニタリングサービス
無料デモ診断も可能なため、ご興味のある方はお気軽にお問い合わせください。
本記事では、メールに関する特に重要なRFCについて紹介しました。メールの到達率を向上させるには、RFCに準拠したメール送信を行うことが非常に重要です。ぜひ本記事を参考に、改めてRFCの内容と自社のメール送信方法を確認してみてください。