taikiito.comを本格運用にして、ハマった3つの問題と直し方

• 公開日：: 2026-08-19
• タグ：: 個人ドメイン・インフラ

英語版: English

前回、taikiito.comという自分の名前のドメインを確保したところまで書いた。今回は、そのドメインを実際に使える状態に仕上げていく話。

Cloudflare Accessをバイパスできる抜け穴があった

アクセス周りの設定を見直している最中、ドメインではなくLightsailのオリジンIPに直接アクセスしてみたところ、普通に開けてしまうことに気づいた。

ドメイン経由のアクセスにはCloudflare Accessによる認証ゲートを設けていたが、オリジンIPに直接アクセスすればそのゲートを完全にバイパスできる状態になっていた。

同日中に ufw を導入し、inbound の80/443番ポートを Cloudflareの公開IPレンジ(https://www.cloudflare.com/ips-v4)からのみ許可、それ以外はデフォルトで拒否する設定にした。SSH(22番)は明示的に ufw allow OpenSSH で許可を先に入れてから有効化した(この順番を間違えると、ufw有効化と同時にSSH接続自体が失われるリスクがある)。適用後、ドメイン経由のアクセスは変わらず機能し、オリジンIP直接アクセスは接続不可になった。

2つ目のオリジンを追加したときの522エラー

このドメインの下に、MulmoClaude用の2つ目の入り口と、デジタル名刺用のサブドメインを追加した(どちらも実在のURLはここには書かない。前者はCloudflare Access越しとはいえサブドメイン名自体を晒したくないし、後者は名刺ページに連絡先が載っている)。

2つ目の入り口のDNS(Aレコード)とCloudflare Accessのポリシーを設定した直後、アクセスするとCloudflareの 522エラー(オリジンへの接続タイムアウト) が出た。原因は、SSL/TLSの暗号化モードがゾーン(ドメイン)ごとに個別管理されていること。新しい taikiito.com ゾーンはデフォルトの Full モードになっていて、Cloudflareがオリジンの443番ポートへHTTPS接続を試みるが、nginx側は80番しか listen していなかった。既存のドメインと同じ Flexible モードに変更したら、即座に解消した。

SPF/DKIM/DMARCを設定してメールも作った

ドメインを持ったので、iCloud+の Custom Email Domain 機能を使って [email protected] を作った。追加契約は不要で、案内された通りにDNSレコードを3つ登録するだけだった。

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF(TXT): v=spf1 include:icloud.com ~all
• DKIM(CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

これらは「このメールは、なりすましではなく本当に自分のドメインから送られている」ことを証明する仕組みで、値をコピーして貼り付けるだけの単純作業だった。

一部の宛先にだけ届かない

設定は正しく完了したはずだったが、試しに別のメールアドレス宛に送ってみたところ、そちらには届かなかった。バウンス(エラー返信)は一切なかった。

念のため DMARC(TXT、v=DMARC1; p=none; rua=mailto:(レポート送付先))も追加し、外部のDNSチェッカーで正しく反映されていることも確認した。それでも届かない。原因は、SPF/DKIM/DMARCがすべて正しくても解決できない、ドメインの送信履歴(センダーレピュテーション)の問題だった。フィルタが厳しいメールサーバーほど、この影響を強く受けるらしい。

技術的に打てる手は尽きたので、これは時間が解決してくれるのを待つことにした。

つづく。