「Webサイトの表示速度を改善したい」「サイバー攻撃への対策を強化したい」
そのようなときに検討したいサービスの一つが、CDNやセキュリティ機能を提供するCloudflareです。
しかし、Cloudflareを導入すると、現在利用しているレンタルサーバーや独自ドメインのメールはどうなるのでしょうか？
結論からいうと、WebサイトはCloudflareを経由させ、メールは従来のレンタルサーバーで運用する構成が可能です。
Webサイトとメールは、同じドメインを利用していても、通信の仕組みや接続先を分けて管理できます。そのため、メール環境を維持したまま、Webサイト側にCloudflareのキャッシュ機能やセキュリティ機能を導入できる場合があります。
この記事では、Cloudflare導入前後の通信経路の違いから、DNSの設定、導入時の注意点まで、実務で押さえておきたいポイントを解説します。
従来、独自ドメインでWebサイトとメールを運用する場合、1つのレンタルサーバーで両方の機能を利用する構成が一般的でした。
例えば、「example.com」というドメインを取得し、レンタルサーバーでWebサイトを公開すると同時に、「info@example.com」というメールアドレスを作成する構成です。
この場合、Webサイトとメールは同じ事業者のサービスを利用していても、実際には異なる仕組みで通信しています。
このように、Webサイトの閲覧とメールの送受信では、参照するDNSレコードや通信先が異なります。
ただし、Webとメールが同じレンタルサーバー環境にある場合、契約内容やサーバー構成によっては、リソースや障害の影響を共有することがあります。
CloudflareをWebサイトのリバースプロキシとして利用すると、ブラウザとWebサーバーの間にCloudflareが入る構成になります。
従来のようにブラウザからWebサーバーへ直接アクセスするのではなく、Cloudflareを経由してWebコンテンツを取得する仕組みです。
Cloudflareは、世界各地のエッジネットワークを利用してコンテンツを配信します。
キャッシュが有効に働けば、Webサーバーまでリクエストが届く回数を減らし、応答速度の改善やサーバー負荷の軽減につながる可能性があります。
また、設定や契約プランに応じて、DDoS対策などのセキュリティ機能も利用できます。
ただし、すべてのアクセスがキャッシュから返されるわけではありません。動的なページやキャッシュ対象外のコンテンツなどは、オリジンサーバーへのアクセスが必要です。
Cloudflareは、Webサイトへのアクセスを効率化し、保護するための仕組みであり、オリジンサーバーそのものを不要にするサービスとは限りません。
Cloudflareを導入する際に重要なのが、DNSの設定です。
同じ独自ドメインを利用していても、Webサイトとメールの接続先は別々に指定できます。
例えば、次のような構成です。
この構成であれば、Webサイト側にCloudflareを導入しても、メールの受信先を従来のレンタルサーバーに維持できます。
| レコード | 主な役割 |
|---|---|
| A | ドメイン名をIPv4アドレスに対応付ける |
| AAAA | ドメイン名をIPv6アドレスに対応付ける |
| CNAME | ドメイン名を別のドメイン名に対応付ける |
| MX | メールの配送先メールサーバーを指定する |
| TXT | SPFなどのメール認証や各種ドメイン検証に利用する |
Webサイトの構成によっては、ルートドメインと「www」のレコードを設定します。一方、メールについてはMXレコードに加えて、MXが指定するメールサーバーのホスト名を正しく名前解決できる必要があります。
CloudflareのDNSを利用する場合、Web用のホスト名とメール用のホスト名を区別し、メールサーバーへの直接接続に必要なDNS設定を維持することが重要です。
一般的には、メールサーバーのホスト名はCloudflareのプロキシ対象にせず、DNSのみの設定にします。メールの配送に必要なMXレコードや、SPF・DKIM・DMARCなどのTXTレコードも、利用するメールサービスの案内に従って設定します。
なお、実際の設定はドメインやメールサービスの構成によって異なります。
ここでは、レンタルサーバーでWebサイトとメールを運用している会社を例に考えてみましょう。
この場合、Webサイトのキャッシュやセキュリティ機能を活用しながら、既存のメールアドレスやメールボックスを継続して利用できます。
メールアドレスを変更したり、すべてのメールを別サービスに移行したりする必要がない構成を選べるのが利点です。
ただし、DNSのネームサーバーをCloudflareへ変更する場合は、既存のDNSレコードを正しく移行する必要があります。レコードの設定を誤ると、Webサイトやメールが利用できなくなるおそれがあります。
キャッシュ可能なコンテンツをCloudflareから配信できれば、オリジンサーバーへのアクセスを減らし、表示速度の改善につながる場合があります。
特に、画像やCSS、JavaScriptなどの静的ファイルは、キャッシュ設定を適切に行うことで配信を効率化できます。
ただし、キャッシュの有無やコンテンツの種類、ユーザーの通信環境などによって効果は異なります。
キャッシュが有効に働けば、同じコンテンツを要求するアクセスのたびに、オリジンサーバーがファイルを返す必要がなくなります。
その結果、Webサーバーの負荷軽減につながる可能性があります。
ただし、アクセスの大部分が動的処理である場合や、キャッシュ対象外のコンテンツが多い場合は、期待するほど負荷が減らないこともあります。
Cloudflareは、Webサイトへの大量のリクエストなどに対処するDDoS対策を提供しています。また、プランや設定によっては、WAFなどの機能も利用できます。
ただし、Cloudflareを導入するだけで、すべての攻撃や脆弱性を防げるわけではありません。
オリジンサーバーへの直接アクセスを制限する必要がある場合や、アプリケーション自体に脆弱性がある場合などは、別途対策が必要です。
既存のメールサーバーをそのまま利用する構成であれば、メールアドレスやメールボックス、メールソフトの設定を大きく変更せずに済む場合があります。
Webサイトの改善とメール環境の維持を、同時に検討できる点がメリットです。
CloudflareへDNSを移行する場合、Webサイトのレコードだけでなく、メールに関係するレコードも確認してください。
特に、MXレコード、メールサーバーのホスト名、SPF・DKIM・DMARCなどの設定は重要です。
Cloudflareのプロキシを利用していても、オリジンサーバーに直接アクセスできる状態であれば、Cloudflareを経由しないアクセスが可能な場合があります。
Cloudflareによる保護を強化したい場合は、オリジンサーバーのファイアウォールや接続制限なども含めて検討します。
問い合わせフォームがレンタルサーバー上で動作している場合、Cloudflareの導入後もフォームが正常に動作するか確認してください。
フォームからの送信通知が届くか、メールの送信認証に問題がないかなど、実際にテストすることが大切です。
Webサイトが表示できても、メールが正常に動作しているとは限りません。
導入後は、独自ドメイン宛ての受信、メールソフトからの送信、過去メールの閲覧、問い合わせフォームからの通知などを確認しましょう。
Cloudflareを導入するからといって、必ずしもレンタルサーバーを解約する必要はありません。
既存のレンタルサーバーをWebサイトの接続先として残し、Cloudflareを経由してWebコンテンツを配信する構成も選べます。
メールについては、MXレコードなどを適切に設定すれば、従来のレンタルサーバーで引き続き運用できます。
大切なのは、Webサイトとメールを一つの機能として捉えるのではなく、それぞれの役割と接続先を理解して構成することです。
Webサイトの表示速度やセキュリティを改善したい場合は、現在のサーバー環境やDNS設定、メールの利用状況を確認し、自社に合った方法を選びましょう。
あわせて読みたい
必ずしも不要になるわけではありません。CloudflareはWebサイトの配信や保護に利用できますが、WordPressなどの動的処理やデータベースが必要なサイトでは、別途オリジンサーバーが必要な場合があります。
はい。DNSレコードを適切に設定し、従来のメールサーバーを接続先として維持すれば、メール環境をそのまま利用できる構成が可能です。
いいえ。キャッシュの設定やWebサイトの構成、コンテンツの種類などによって効果は異なります。導入後に表示速度やサーバー負荷を測定し、必要に応じて設定を調整することが重要です。
通常の構成では、WebサイトのHTTP・HTTPS通信とメールの通信は別の経路です。メールはMXレコードなどで指定されたメールサーバーへ配送されます。メール用ホスト名のDNS設定を正しく維持する必要があります。
※DNSの設定方法や利用できる機能は、Cloudflareのプラン、レンタルサーバー、メールサービスの構成によって異なります。変更前に各サービスの公式ドキュメントを確認してください。