RFCとは？役割や分類、メール関連のRFCを徹底解説

メール送信を行う際に欠かせない基準となるのが、「RFC（Request for Comments）」です。RFCは、インターネット技術の標準仕様を定義した文書群であり、特にメール送信に関するRFCは、メールの構造やプロトコル、セキュリティ仕様などを細かく規定しています。主要なメールサービスプロバイダやスパムフィルタリングシステムはRFC準拠を前提に動作しているため、これを無視してメールを送信すると、到達率が低下したり迷惑メール扱いされたりするリスクがあります。

例えば、必須のヘッダフィールドが欠落していたりヘッダのフォーマットが正しくなかったりすると、RFC違反として受信拒否されることがあります。また、RFCで定められたフォーマットや文字数制限を守らないと、一部のメールクライアントで表示エラーが発生することも少なくありません。これらの問題はメール配信の信頼性を損ない、IPアドレスやドメインのレピュテーション低下につながる可能性もあります。

本記事では、「メール RFC」とは何か、どのようなリスクがあるのかを詳しく解説するとともに、メール送信時にRFC準拠を確認する方法や、到達率を向上させるための方法をご紹介します。

RFCとは

RFC（Request for Comments）は、インターネット関連技術の仕様や運用に関する事項をまとめた文書です。主にIETF（Internet Engineering Task Force）が管理・公開しており、誰でもインターネット上で閲覧できます。ただし、RFCはIETF以外の団体や個人が作成することもあります。すべてのRFCが標準規格（インターネット標準）というわけではなく、提案や実験的な内容を含む文書もあります。

IETFとは

IETFは、インターネット技術の標準化を推進する団体で、通信プロトコル、セキュリティ技術、文字符号化（エンコーディング）などを規格化しています。その目的は、インターネットの設計や管理、利用方法に関する技術文書を作成し、インターネット環境を改善することです。

通信プロトコルとは、異なる通信機器同士で通信するために定められた規約や手順のことを指します。IETFが管理する主なプロトコルには以下のものがあります：

• TCP/IP：インターネット通信の基本プロトコル
• HTTP/HTTPS：ウェブ通信を行うためのプロトコル
• SMTP：メール送信のためのプロトコル
• DNS：ドメイン名をIPアドレスに変換するためのプロトコル

IETFは以下の特徴を持っています。

• 作業部会（Working Groups）：特定の技術や問題に取り組むチーム
• 分野別エリア（Areas）：ネットワークやセキュリティなどの分野に分かれて活動
• オープンな参加体制：誰でも提案や議論に参加可能

IETFで作成された規格はRFCにまとめられ、公開されます。

RFCの役割

RFCは以下の3つの重要な役割を持っています。

情報共有や議論の促進

RFCはインターネット技術に関する情報を共有し、新技術の提案や既存技術の改善を議論する場を提供します。例えば、新しい通信プロトコルやセキュリティ対策の提案がRFCとして公開されることで、技術者間の議論が活発になります。

技術仕様の標準化

RFCを通じて技術仕様が標準化されることで、異なる機器やソフトウェア間での互換性が確保されます。これにより、インターネット全体の安定性と信頼性が向上します。なお、RFCの中にはインターネット標準（STD番号が付与されたRFC）として認定されたものもあります。

技術の発展や継承

RFCはインターネット技術の進化や歴史を記録する役割も果たします。過去のRFCを参照することで技術者は失敗事例や成功事例を学び、より良い技術を開発できます。

RFCの番号割り当て

RFCには一意の番号が作成順に付与されます。この番号により、技術文書が識別され、更新や廃止があっても番号は上書きされません。新しい内容を含む場合には新たなRFC番号が発行されます。

補足として、以下の分類も存在します。

• STD番号（インターネット標準）
  RFCの中で特に重要で標準として採用されたものに付与されます。標準が更新されると対応するRFC番号は変わりますが、STD番号は維持されます。
• FYI（For Your Information）
  技術者以外の読者に向けて、特定のテーマをわかりやすく説明するRFCに付与されます。ただし、FYI番号の使用は現在では非推奨となっています。

RFCシリーズの分類

RFCには、標準化過程とそれ以外のカテゴリがあります。標準化過程は、インターネット標準になるまでのプロセスを示し、それ以外のカテゴリは情報提供や実験的な技術を対象としています。

標準化過程（Standards Track）

RFCの中でもインターネット標準化を目指す文書群で、技術仕様が「Proposed Standard」「Standard」の段階を経て承認されます。

標準化への提唱（Proposed Standard）

標準化の最初の段階で、安定して確立された技術が対象となります。この段階のRFCは、他の技術との互換性や既存の課題の解決に寄与するものとして提案されます。

標準化への草稿（Draft Standard）

過去には、この段階が標準化過程の一部でした。仕様が成熟し、実際の製品やサービスに実装される準備が整ったものが対象でした。しかし、2011年のIETFによる標準化過程の見直しにより、この段階は廃止されました。現在は、「Proposed Standard」から「Standard」に直接移行する形式が採用されています。

標準（Standard）

標準化の最終段階で、インターネット標準として認められたRFCです。これらは高い安定性と実用性を持ち、STD番号が付与されます。たとえば、SMTPの標準規格はRFC 5321（STD 10）として指定されています。

標準化過程以外のRFC文書

インターネット標準とは直接関係しない情報や実験的仕様、運用指針（BCP）などを定義したRFCが含まれます。

情報（Informational）

標準化プロセスに関連しない技術情報や仕様を記載したRFCです。たとえば、ベンダー独自の仕様や、特定の分野で事実上の標準とされている技術が含まれます。これらは、技術者や研究者にとって貴重な参考資料となります。

実験（Experimental）

実験的な技術仕様を定義したRFCです。まだ成熟していない技術が対象であり、インターネット技術の研究や開発に役立つことを目的としています。実験的RFCの中には、後に標準化過程に進むものもあります。

歴史（Historical）

廃止された技術仕様や、別の仕様に置き換えられた技術を記載したRFCです。これらは主に資料として利用され、過去の技術や議論の背景を理解するために参照されます。

現状（Best Current Practice, BCP）

現時点での最良の運用方法や指針を示したRFCです。BCPは技術仕様ではありませんが、セキュリティや管理のガイドラインとして重要です。たとえば、インターネットの安全な運用方法やポリシーに関するRFCがBCPとして指定されます。

RFCへの過程

RFCの標準化過程におけるすべての決定は、IESG（Internet Engineering Steering Group）によって下されます。IESGは、IETFのエリアディレクターによって構成されるインターネット技術運営委員会で、IETFが定める技術仕様の公開プロセスを管理しています。以下は、RFCが標準化過程を経る際の具体的な流れです。

提出

技術仕様は、以下のいずれかの方法で標準化過程に提出されます。

1. IETF分科会によるエリアディレクターの推奨
   作業グループが作成した技術仕様がエリアディレクターを通じて提出されます。
2. 個人によるIESGへの直接提出
   作業グループを経由せず、個人がIESGに直接技術仕様を提出します。

提出される技術仕様は通常、インターネットドラフト（Internet-Draft）として事前に公開されます。インターネットドラフトはIETFまたはその分野の作業グループが作成する作業文書であり、提出前に最低でも2週間以上公開され、インターネットコミュニティからのフィードバックを受けることが求められます。

検討と認可

提出された技術仕様は、IESGおよび関連する外部機関によって以下のように評価されます。

基準への適合性の評価

提出された仕様が技術的に十分成熟しているか、安定性があるかなどを評価します。

最終告知期間の設定

IESGはIETFに対して最終告知を発信し、インターネットコミュニティ全体による検討を促します。この告知期間は以下の通り設定されます：

• IETF分科会による提出の場合：2週間以上
• 個人による提出の場合：4週間以上
• IESGが追加の検討時間が必要と判断した場合：期間を延長することがあります。

最終決定の通知
最終告知期間が終了すると、IESGが技術仕様の処置（採用、却下、再検討の要請など）を決定し、その結果をIETFに通知します。

公開

IESGの承認を受けた技術仕様は、RFCエディターによりRFCとして公開されます。ただし、以下のケースでは異なる取り扱いとなる場合があります。

• 実験的RFC（Experimental）
  提出された仕様が標準化過程の要件を満たさない場合、実験的な分類に変更されます。この場合、標準化を目指すためには改訂を行い再提出が必要です。
• 歴史的RFC（Historical）
  技術仕様が利用されなくなった場合、標準化過程から外れ歴史的RFCに分類されます。これにより、その仕様が現行技術としては推奨されないことが明確にされます。

メールに関するRFC

ここでは、メールに関する主要なRFCを解説します。多くのメールサービスプロバイダは、RFCに準拠したメール送信を推奨しています。以下では、カテゴリごとに代表的なRFCを紹介します。

基本仕様に関するRFC

メールの送受信プロトコル（SMTP）やメッセージ形式（RFC 5321, RFC 5322）を定義し、メール運用の基盤を提供します。

RFC 5321（Simple Mail Transfer Protocol）

メールの送受信で使用されるプロトコルSMTPについて定義しています。このRFCには、SMTPサーバーが返すステータスコード、コマンドの仕様、メールの送信経路の記録方法、不達通知の取り扱いが記載されています。

RFC 5322（Internet Message Format）

メールメッセージの形式を定義したRFCです。メールアドレスの形式、ToやCCなどのヘッダフィールド、本文の構造などが記載されています。なお、使用可能な文字はASCIIのみであり、日本語を直接扱うことはできません。ASCII以外の文字を扱う場合は、後述するMIMEの仕様に従います。

なお、RFC 5322に準拠したメールでは使用可能な文字はASCII（7ビット文字）に限られ、日本語を直接使用することはできません。ASCII文字とは、英数字や記号、制御文字（例：改行）を含む128文字で構成された文字コードです。日本語を含む非ASCII文字をメールで扱うには、MIME（Multipurpose Internet Mail Extensions）の仕様を使用し、文字をBase64やQuoted-Printable形式でエンコードして送信する必要があります。

MIMEに関するRFC

MIME（Multipurpose Internet Mail Extensions）は、メールでASCII文字以外のデータ（添付ファイルや非ASCIIテキストなど）を扱うための仕様です。以下のRFCで構成されています

RFC 2045（MIME Part One：Format of Internet Message Bodies）

MIMEの基礎を定義したRFCで、MIMEヘッダフィールド、コンテンツタイプ（例：テキスト、画像、動画）、エンコーディング方式（例：Base64, Quoted-Printable）などが記載されています。

RFC 2046（MIME Part Two：Media Types）

メディアタイプの詳細を定義したRFCです。特定のデータ形式（例：画像、動画、音声）の表現方法や、改行の表現方法について記載されています。

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

メールヘッダで非ASCII文字を扱うための拡張を定義しています。具体的には、文字セット、エンコーディング方法、エンコードされた単語の構文が記載されています。

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

RFC 1468では、ISO-2022-JPを使った日本語エンコーディングを定義しており、かつてメールで広く利用されました。

RFC 1468（Japanese Character Encoding for Internet Messages）

日本語の文字エンコーディング規格であるISO-2022-JPを定義しています。この規格により、ASCII文字に加えて漢字、ひらがな、カタカナをメールで扱うことが可能です。かつて日本国内で広く普及していましたが、現在ではUTF-8が主流となっています。

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

送信ドメイン認証とは、メールの誤送信やなりすましを防ぐための仕組みです。SPF・DKIM・DMARCの3種類があり、それぞれ以下のRFCで定義されています。

RFC 6376（DomainKeys Identified Mail Signatures：DKIM）

DKIMは、送信時に電子署名を付与し、受信者がその署名を検証することで、なりすましや改ざんを防ぐ技術です。

RFC 7208（Sender Policy Framework：SPF）

SPFは、送信元IPアドレスが正当なものかを検証する技術です。これにより、送信者ドメインのなりすましを防ぎます。

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

DMARCは、SPFやDKIMによる認証結果とメールヘッダのFromドメインを照合することで、なりすましメールの検出を可能にします。また、認証に失敗したメールの扱いを指定できます。

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

SMTP認証（RFC 4954）や暗号化通信（RFC 3207）など、メール送信のセキュリティを向上させる仕様を定めています。

RFC 3207（SMTP Service Extension for Secure SMTP over Transport Layer Security）

TLSを使用してSMTP通信を暗号化するための仕様を定義しています。この技術により、メールサーバー間の通信でデータの盗聴や改ざんを防ぐことができます。

RFC 4954（SMTP Service Extension for Authentication）

SMTP認証を定義したRFCです。SMTP認証では、送信者がアカウント情報（ユーザー名とパスワード）を提供し、不正な利用者を排除します。これにより、迷惑メールや不正利用を防ぐことができます。

その他のRFC

ARC（RFC 8617）やワンクリック登録解除（RFC 8058）など、メール運用を効率化・信頼性向上する機能を提供します。

RFC 8058（Signaling One-Click Functionality for List Email Headers）

メールのワンクリック登録解除機能の実装方法を定義しています。この機能は、受信者が販促メールやメールマガジンを簡単に解除できるようにするためのものです。Gmailでは、大量のメールを送信する送信者に対して、この機能の実装が推奨されています。

RFC 8617（The Authenticated Received Chain Protocol：ARC）

再転送されたメールの信頼性を確保するためのARCプロトコルを定義しています。ARCヘッダを利用することで、認証情報を保持しながらメールを転送できる仕組みを提供します。Gmailでは、定期的にメールを転送する送信者に対してARCの導入を推奨しています。

メールに関するRFCに違反すると？

メール送信時にRFCに違反すると、受信拒否や迷惑メール扱いされるリスクが高まります。ここでは、RFC違反による影響や、違反を防ぐためのチェック方法について解説します。

違反した場合のリスク

RFCは法律ではなく技術規格であり、違反に対する法的な罰則はありません。しかし、メール関連のRFCに従わないと、以下のようなリスクがあります。

• 受信拒否や迷惑メール扱い
  主要なメールサービスプロバイダは、RFC準拠を前提にメールの到達可否を判断します。不正なヘッダやフォーマットエラーがあるメールは、スパムフィルタによりブロックされる可能性があります。
• レピュテーションの低下
  メールのエラー率が高まると、IPアドレスやドメインのレピュテーションが低下します。一度低下したレピュテーションを回復するには時間と手間がかかります。
• 到達率の低下
  RFC違反が続くと、送信元メールサーバーが信頼できないと見なされ、メールの到達率が著しく低下します。

これらのリスクを回避するためには、RFCに準拠したメールの送信が不可欠です。

違反していないかチェックする方法

RFCに違反していないかどうかチェックする際は、以下の3点に注意しましょう。

ヘッダフィールド

ヘッダフィールドに必要な項目が欠落しているメールは、RFC違反と見なされる可能性があります。特に以下のヘッダは重要です

• Date（メールが作成された日時）
• From（送信者アドレス）
• Message-ID（一意の識別子）

また、Gmailをはじめとするメールサービスでは以下のヘッダが重複している場合にメールがブロックされることがあります。

• To
• Cc
• Subject
• Date
• From
• Sender
• Reply-To
• Bcc
• Message-ID
• In-Reply-To
• References

ヘッダのフォーマット

RFC 5322で定義された形式に従い、ヘッダフィールドの記述やフォーマットを正確に設定する必要があります。

• Dateヘッダ
  最新のRFC（RFC 5322）では、Dateヘッダの記述形式が厳密に定義されています。これに従わないとRFC違反となり、メールが受信拒否される可能性があります。
• Message-IDヘッダ
  メールを一意に特定する識別子です。重複しないように生成される必要があり、通常はドメイン名やIPアドレスを含む形式が推奨されます。ただし、プライベートIPアドレスや誤ったドメイン名を含むMessage-IDは無効と見なされる恐れがあります。

ヘッダや本文の一行当たりの文字数

RFC 5322では以下の規定があります。

• 一行の長さは改行を除き998文字以内でなければならない
• 推奨される長さは78文字以内で、これを超えると可読性や互換性が損なわれる可能性がある

これらの文字数制限に従わないと、一部のメールクライアントで不具合が発生することがあります。

メール配信システムを活用する

メール配信におけるRFC準拠を効率的に実現するためには、専用のメール配信システムを活用することが有効です。これらのシステムは、RFCに基づいたメール送信を標準機能として備えており、手動設定や個別の確認作業を大幅に軽減できます。

API連携・SMTPリレーサービス「ブラストエンジン(blastengine)」

SPFやDKIMなどGmail送信者ガイドライン対応しており、API連携・SMTPリレーが可能なメール配信システムです。

ブラストエンジンは、SMTPリレーサーバーを使用して、簡単に大量のメールを高速配信することが可能です。さらに、メールサーバーを必要とせず、API経由でメールを送信する仕組みも提供しています。

ブラストエンジンは、サーバーの運用やメンテナンスを行っているため、常に高いIPレピュテーションを維持しながら、安全にメールを送ることができます。

以下のような課題がある場合は、ブラストエンジンの利用を検討してみることをおすすめします。

• 自社のIPアドレスやドメインがブラックリストに登録されていて、メールが届かない場合
• 国内キャリアにメールが届かず、対応方法がわからない場合
• 自社でメールサーバーを管理・運用したくない場合

また、ブラストエンジンは各メールプロバイダーや携帯キャリアのドメインに最適化されており、大規模なネットワークを経由してメール配信を行うことで、日本国内での到達率を圧倒的に高めています。

利用料金は月額3,000円からとコストパフォーマンスにも優れており、メールだけでなく、日本語での電話サポートにも対応しています。

メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

シェア1位のメール配信システム「ブラストメール」

SPFやDKIMなどGmail送信者ガイドライン対応（standardプラン以上）しており、シンプルで使いやすいメール一斉配信システムです。

ブラストメールは、14年連続で顧客導入シェア1位を獲得している信頼性の高いメール配信システムです。ブラストエンジンとは異なり、メルマガなどのメール一斉送信に利用することができます。

このメール配信システムの特徴は、使いやすさとコストパフォーマンスの高さです。さまざまな業種や官公庁でも利用されており、定番のメール配信システムとして広く知られています。

迷惑メール対策機能はもちろん、セグメント配信や効果測定、HTMLメールエディタなど、基本的な機能がすべて揃っています。最も安いプランでも、月額4,000円以下で導入することができます。

シンプルで安価なため、初めてメール配信システムを利用してみたい方にもおすすめです。無料トライアルも用意されているので、まずは試してみることをお勧めします。

まとめ

RFCは、インターネット技術の標準的な仕様をまとめた文書で、技術仕様の標準化や技術の発展・継承に役立っています。メールに関するRFCも数多くあり、特にRFC 5322はメールをやり取りするうえで重要なRFCです。

RFCに違反すると、メールの到達率やIPアドレス・ドメインのレピュテーションの低下につながる恐れがあります。RFCに違反しているかどうかチェックする際は、ヘッダフィールドやヘッダのフォーマット、一行当たりの文字数に注意です。RFCに準拠したメールを送信して、メールの到達率を向上させましょう。