独自ドメインから始める事業用IT基盤
独自ドメインから、
Webとメールを
構築・確認し、
維持する。
独自ドメイン、仕事用メール、Webサイト。 ドメイン契約、DNS、Web公開、メール送受信の役割を分け、ReactorFront（リアクターフロント）の実構成に沿って、設定順と外部からの確認方法を説明します。
約20分 / 実地確認: 2026-08-23
この基盤を整えた理由
まず欲しかったのは、
仕事の「住所」でした。
脱サラし、税務署へ開業届を提出して、フリーランスとして生きていくと決めた。 屋号をReactorFront（リアクターフロント）と定めた後、最初に立ち止まったのは、意外にもメールアドレスでした。
無料のGmailアドレスでも、仕事そのものには困らないかもしれません。 けれど、せっかく屋号を掲げるなら、その名前を持つ独自ドメインのメールアドレスがほしい。 自社サイトも、借り物に見えない独自ドメインのURLで公開したい。そう考えるようになりました。
そこでXServerドメインでドメインを契約し、Google Workspaceで仕事用メールを整備しました。 Webサイトとメールという二つの入口がそろったことで、屋号は届け出の紙に書かれた名前から、 インターネット上に自分の居場所を持つ事業へと、少しずつ形を変えていきました。
事業の連絡先として書ける
ネット銀行へ口座開設を申し込む際、事業計画書へ独自ドメインのメールアドレスと自社サイトを記載できました。
名刺に、屋号の入口を載せられる
名前や電話番号だけでなく、仕事用メールと自社サイトのURLを、ReactorFrontの連絡先として案内できました。
事業の通知を、一か所へ集められる
freee会計をはじめ、Google Workspaceなど事業で使うサービスの登録先・通知先を、個人用メールと分けて管理できます。
本記事の ReactorFront、リアクターフロント、検索時に使われる小文字表記 reactorfront は、すべて小野賢太郎が運営する同じ事業を指します。
reactorfront.jp は、その事業がWebと仕事用メールに使う独自ドメインです。
独自ドメインは、見栄えを整えるためだけのものではありませんでした。
外へ示す信用の手掛かりであり、事業の連絡と契約を整理するための基準点でもあります。
この入門は、その基準点をどう作り、どう守ってきたかを、実体験から順にほどく記録です。
ReactorFrontの実構成
ReactorFrontの実構成を、
ケーススタディにする。
ReactorFrontは、XServerドメインで契約した独自ドメイン、GitHub PagesのWebサイト、Google Workspaceの仕事用メールを組み合わせています。 外部の問い合わせへ正式な情報を返すDNS（権威DNS）にWeb・メール用レコードを設定し、SPF・DKIM・DMARCも有効化しました。 設定後は公開DNS、HTTPS、受信側の認証結果、DMARCレポートを継続して確認しています。
本文では実ドメインを example.com に置き換え、サービス間の関係と検証方法を説明します。
アカウント固有のトークンや鍵は公開せず、値を取得する公式資料へのリンクを示します。
最初に分ける四つの役割
契約先と、実際に担う機能を分ける。
一社が複数サービスを提供していても、レジストラ、権威DNS、Web、メールは別の機能です。
ドメインを契約・更新する事業者（レジストラ）
example.com を登録・更新する事業者です。契約が失効するとWebとメールの両方へ影響します。
正式なDNS情報を返す場所（権威DNS）
ドメインのDNSレコードを保持し、問い合わせへ応答します。NSレコードを見れば、現在の管理先を特定できます。
Webサイトの公開先（Webホスティング）
サイトをHTTPSで配信するサービスです。この構成では、GitHub Actionsでビルドした静的サイトをGitHub Pagesから配信します。
仕事用メールの送受信先（メールサービス）
独自ドメインのメールボックスと送受信機能を提供します。この構成ではGoogle Workspaceです。
契約先の名称だけで判断せず、最初にDNSの管理先を示す NS（ネームサーバー） を確認します。 XServerドメインなら、契約一覧のクイックメニューにある「DNSレコード設定」が入口です。レンタルサーバーの管理画面とは別の場合があります。
XServerドメイン公式: DNSレコードの編集 ↗GitHub Pagesを選んだ理由
無料だから、だけでは
選ばなかった。
開業時に必要だったのは、会社案内、プロフィール、実績、技術記事を公開する場所でした。 コメントや会員機能よりも、更新の履歴を残し、壊れた時に戻せて、サーバーを抱えず公開できることを優先しました。
静的サイトを、追加のサーバー契約なしで公開する
Astroが生成したHTML、CSS、JavaScriptをGitHub Pagesから配信します。公開リポジトリならGitHub Freeで利用でき、OSやWebサーバーを自分で保守しません。
更新した事実と、変更前の状態を残す
commit、変更差分（diff）、Pull Requestで、いつ何を変えたかを追えます。不具合があれば、履歴を消さず、変更を取り消すcommit（revert）で戻せます。
ビルドと公開を、同じ場所で自動化する
mainへ反映するとGitHub Actionsが検査して公開用fileを生成し、成功したfileだけをPagesへ公開します。失敗した工程と対象commitも実行履歴に残ります。
動的機能を持たないことも、設計として選ぶ
Pages単体にはDB、ログイン、コメント、いいね、フォーム受付APIがありません。必要なら外部サービスを足せますが、今は保守対象を増やさない方を選びました。
公開と配信の仕組み
一台を持たず、GitHubの配信基盤を借りる。
個人で一台のWebサーバーを立てる構成では、アクセスはその一台へ集中します。 GitHub PagesはGitHubの配信基盤と、利用者に近い拠点から配信する仕組み（CDN）を通じて静的fileを返すため、同じページへのアクセスが続いても、毎回配信元まで到達するとは限りません。
GitHubは、Pagesを世界各地のデータセンターから配信し、大量の通信で停止を狙うDDoS攻撃への追加防御も提供すると説明しています。 通常のアクセス集中や、単純な連続再読み込みを、個人管理の一台構成より受け止めやすいことも採用理由でした。
ReactorFront本番の応答
- HTTP
200 OK- DNS
- 複数のPages用IPへ解決
- Edge
japaneast/cache-nrt- Cache
X-Cache: HIT
確認時点では、東京・成田側のFastlyキャッシュから配信されました。ヘッダー名や内部構成は変更され得るため、恒久仕様としては扱いません。
GitHub Pagesには月間通信量の目安となる上限と、一定時間内の要求回数を制限する仕組みがあり、要求過多を示すHTTP 429やサービス障害も起こり得ます。 あらゆる規模のDDoSへ耐える保証ではありません。決済、認証、SaaS提供などへ用途が変わる場合は、別の基盤を再検討します。
GitHub公式: GitHub Pagesとは ↗ GitHub公式: Actionsによる公開 ↗ GitHub公式: CDNとDDoS防御 ↗ GitHub公式: 利用上限 ↗
Webとメールの行き先を示すDNSレコード
DNSレコードが、
Webとメールの
行き先を決める。
レコード種別ごとに役割は異なります。同じ名前・種別の重複や古い値を避け、設定値は利用サービスの管理画面と公式ドキュメントから取得します。
example.com → GitHub PagesのIP IPv4 / IPv6 www.example.com → owner.github.io サブドメイン向け example.com → 管理画面が示すメールサーバー 優先度あり 所有確認 / SPF / DKIM / DMARC 秘密鍵は置かない ドメイン契約とDNS
名前を契約し、編集場所を確定する。
ドメインを契約したら、自動更新と連絡先メールを確認します。次にNSレコードを調べ、現在の権威DNSとレコード編集画面を特定します。
Resolve-DnsName example.com -Type NS- 契約の自動更新と支払い方法を確認する
- NSの結果とDNS編集画面が一致するか確認する
- 変更前のDNSレコードを控える
Webサイト
GitHub Pagesで、
検査・生成・公開をつなぐ。
先にGitHubのrepository設定画面（Settings > Pages）で、公開元をGitHub Actionsにします。
ReactorFrontでは、mainへの反映または手動実行を起点にAstroが公開用の静的fileを生成し、成功したfileをPagesの公開環境（github-pages environment）から公開します。
www.reactorfront.jp
自動実行の設定（workflow）では、ソースの取得（checkout）、必要packageの導入、Astroの検査、公開用fileの生成、Pagesへの受け渡し、本番公開（deploy）を順に行います。
公開権限は contents: read、pages: write、id-token: write に絞り、公開用fileの生成（build）が成功した後だけdeployを開始します。
mainへ反映したcommitと、Actionsの実行対象が一致する- 公開用fileの生成（build）と本番公開（deploy）の両方が成功している
- Pages設定に正しいカスタムドメインが表示される
- Enforce HTTPS が有効で、本番URLがHTTPSで開く
- 問題があれば失敗した工程を確認し、必要に応じて変更を取り消すcommit（revert）を反映する
次にGitHub側でカスタムドメインを登録・検証し、DNSへA / AAAA / CNAMEを追加します。
ルートドメインと www のどちらを正規URLにするかも決めます。
@ → GitHub Pages公式のIPwww → owner.github.ioIPや確認手順は変更され得ます。設定時点のGitHub公式文書と、自分のリポジトリ設定画面を正としてください。ワイルドカードDNSは使いません。
APIキー、復旧コード、秘密鍵、管理画面の確認値をcommitしません。ブラウザへ配信するJavaScriptや環境変数も、利用者から見える前提で扱います。
GitHub公式: 公開元の設定 ↗ GitHub公式: Actions workflow ↗ GitHub公式: カスタムドメイン設定 ↗ GitHub公式: ドメイン所有確認 ↗ GitHub公式: HTTPS ↗
仕事用メール
Google Workspaceへメールを届ける。
Google Workspaceでドメイン所有を確認し、管理画面が指定するMXレコードをDNSへ登録します。 優先度は数値が小さいほど先に使われます。既に問題なく稼働している旧形式のGoogle MXは、理由なく置き換えません。
- 管理画面に表示されたMXの値と優先度を使う
- 同じドメインの不要な旧MXが混ざっていないか確認する
- 作成した独自ドメインアドレスで送受信を試す
メール送信元の認証
SPF・DKIM・DMARCを順番に有効化する。
3つは重複機能ではありません。送信元の許可、電子署名、失敗時の扱いという別々の役割を持ちます。
このドメインのメールを、どのサービスが送ってよいか宣言します。
v=spf1 include:_spf.google.com ~allGoogle管理画面で2048ビット鍵を生成し、公開鍵だけをTXTへ登録します。実際の鍵は転載しません。
google._domainkey TXT <管理画面が生成した公開鍵>最初は監視だけの p=none で始め、報告を見てから段階的に強くします。
v=DMARC1; p=none; rua=mailto:dmarc@example.comreject へ進めない SPFとDKIMを先に整え、少なくとも1週間はレポートを監視します。正規の送信元がすべて通ると確認してから quarantine、その後 reject を検討します。
外部からの確認
公開DNSと実際の通信を、外部から確かめる。
管理画面での保存だけでは完了としません。公開DNSを問い合わせ、HTTPSでサイトを開き、外部メールボックスへ送信して、受信側の認証結果まで確認します。
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA
Resolve-DnsName www.example.com -Type CNAME
Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Type TXT
Resolve-DnsName _dmarc.example.com -Type TXT- ルートドメインと
wwwの両方がHTTPSで開く - 片方から正規URLへ意図どおり転送される
- 外部メールの「メッセージのソース」でSPF / DKIM / DMARCが
PASS - DMARCレポートが届き、未知の送信元がない
公開してよい情報を分ける
ノウハウは公開する。
認証情報は公開しない。
DNSはそもそも公開情報ですが、管理画面のスクリーンショットには公開不要な情報が混ざります。 解説に必要な「構造」と、本人しか持つべきでない「値」を分けます。
公開してよい
- サービスごとの役割と構成図
- 公開リポジトリのソースコードと変更履歴
- A / AAAA / MXなど公開DNSの一般例
- SPF・DKIM・DMARCの考え方
- 値を伏せた管理画面の手順
- 確認コマンドと判定基準
公開しない
- アカウントID、請求・契約情報
- パスワード、APIキー、二要素認証、復旧コード
- 認証コード、EPP/AuthCode
- GitHub / Googleの実際の確認トークン
- DKIM鍵の実値や管理画面のセッションURL
構築後の定期確認
構築後も続ける
定期運用。
期限と請求を確認
ドメイン、Google Workspace、支払い手段、管理者への通知を確認します。
公開用fileの生成と本番公開を確認
mainへ反映したcommit、GitHub Actionsによる生成（build）、Pagesへの公開（deploy）、本番URLを順に確認します。
DNSを外部確認
レコード変更後は、権威DNSと一般の名前解決の両方を確認します。
DMARCレポートを見る
未知の送信元や認証失敗がないか確認し、方針を強めてよいか判断します。
管理権限を棚卸し
使っていないアカウント、古い回復先、不要なDNSレコードを整理します。
小さく、理解でき、自分で管理できる構成
小さく始め、
構成と担当範囲を把握する。
サービス数の少なさだけが最小構成ではありません。 契約更新、DNS、認証、検証、障害時の連絡先まで把握していれば、必要な変更を自分で判断できます。