新しいドメインのメール設定：20分で完了する SPF、DKIM、DMARC チェックリスト（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

新しいドメインには最初のメールを送る前に4つのことが必要だ：ベースラインスキャン、実際のプロバイダーを指定する SPF レコード1つ、カスタムドメイン DKIM 署名、そして初日から reporting ありの DMARC レコード。ほとんどのドメインはそこに到達しない — Defaults.Exposed センサス（2026-06-29 時点）によると、46.4%（261,086,232 採点済みドメインのうち 121,145,609）は SPF が全くない。

すべてを公開するのに約20分かかる：ベースラインのスキャン、SPF レコード1つの追加、プロバイダーのカスタムドメイン DKIM のオン、reporting アドレス付きの DMARC p=none の公開、オプションで MTA-STS の追加、その後再スキャンとレポート保管。より時間がかかるのは、どのチェックリストも急かせないこと — DNS 伝播と送信レピュテーション — であり、このガイドは両方について正直に述べる。

本当に20分で十分か？

レコードを公開するだけなら、はい — 以下のすべてのステップは DNS エントリとプロバイダーの管理コンソールでのクリック数回だ。2つのことにはより時間がかかり、そうでないふりをするのが新ドメインがスパムに入る理由だ：

伝播。 新しいレコードは通常数分以内に解決するが、リゾルバーは TTL に従ってキャッシュし、新しく委任されたドメインは一貫して応答するまで数時間かかることがある。dig で確認する；キャッシュが追いつく間にパニックで編集しない。
ウォームアップ。 新しいドメインには送信レピュテーションがゼロで、認証はレピュテーションの前提条件であり代替ではない。人間的なスケールの低ボリュームから始め、数週間かけて徐々に増やす。

正直な主張：20分で正しく公開された認証を買える。その後数週間の常識的な送信で配信性を買える。

20分チェックリスト

まず defaults.exposed で無料スキャンを実行する。 DNS に触れる前に新ドメインをスキャンする。採点済みの「何も設定されていない」ベースラインは数秒でキャプチャでき、アフターレポートを意味のあるものにする — ビフォーアフターのペアが欲しくなる（ステップ6）。
実際のプロバイダーの SPF レコードを1つ公開する。 プロバイダーの include を含む v=spf1 で始まる TXT レコードをちょうど1つ — 例えば Google Workspace なら v=spf1 include:_spf.google.com ~all、Microsoft 365 なら include:spf.protection.outlook.com；DNS がレジストラパネルにある場合は GoDaddy ウォークスルーが UI の癖をカバーしている。レコードは1つだけ：v=spf1 レコードが2つあると SPF を完全に無効にする永続的エラーになる — SPF を試みているドメインのおよそ 138 分の1の 1,013,416 ドメインが陥っている状態（2026-06-29 時点のセンサス）で、通常は移行の残骸だ。「念のため」include を追加しない：SPF は DNS ルックアップを10に制限しており、少なくとも 797,263 ドメインがその上限を超えてレコードを無効化している。そして SPF が実際に何をチェックするかを知っておく：受信側は受信者が見る From ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメイン — バウンスアドレス — に対して評価する。
カスタムドメイン DKIM 署名をオンにする。 プロバイダーはどちらにしてもメールに署名する；問題は署名がどのドメインを指定するかだ。このステップを完了するまで、Google Workspace はデフォルトの gappssmtp.com で、Microsoft 365 は onmicrosoft.com で署名する — DKIM は合格するがドメインにアライメントされないため DMARC は失敗し続ける。管理コンソールでキーを生成し、プロバイダーが提供するものを公開する：Google は 2048 ビット TXT レコード、Microsoft 365 は2つの CNAME（selector1/selector2）。レコードが DNS パネルに収まらない場合は DKIM の修正を参照 — UI によって長いキーが壊れるのはよくあることだ。
初日から DMARC を公開する — reporting アドレス付きの p=none。 _dmarc.yourdomain.com に TXT レコード1つ：v=DMARC1; p=none; rua=mailto:[email protected]。これが何をするかを明確にする：p=none はまだ何も保護しない — 監視モードだ。しかし費用はゼロで、集計レポートは最初のメッセージから domain の送信履歴をカバーする。確立されたドメインは忘れていた送信者を見つけるだけで数週間のレポートを費やす；あなたはその可視性をゼロ日目から無料で買っている。レコードの構造は DMARC の修正を参照。
オプションだが新ドメインでは安い：MTA-STS と TLS-RPT。 MTA-STS は送信サーバーにこのドメインの受信メールが TLS を必要とすることを伝える（DNS レコードと小さなホスト済みポリシーファイル）；TLS-RPT は配信の暗号化失敗を報告する。確立されたドメインではこれらには注意が必要；メールプロバイダーが1つの新ドメインでは壊すものが何もなく、mode: testing は本質的にリスクなしだ。今設定するかスキップするか — しかし流れに任せず決める。
再スキャンしてレポートを保管する。 スキャンを再実行する — SPF、DKIM、DMARC がすべて緑になるはずだ。採点済みレポートを保存する：ローンチ時点のドメインの状態の日付入りの証拠であり、保険会社やクライアントアンケートが求めるまさにそれだ。

実際に何ドメインがこのチェックリストを完了するか？

非常に少なく、ほとんどは最初のハードルで転ぶ。Defaults.Exposed センサス（2026-06-29 時点）で採点された 261,086,232 ドメインのうち：

チェックリストのマイルストーン	センサスの現実（2026-06-29 時点、261,086,232 採点済みドメインのうち）
ステップ2 — 何らかの SPF レコードを公開する	46.4% は決してしない：121,145,609 ドメインは SPF が全くない
ステップ4以降 — 適用ポリシーで DMARC	10.59%（27,640,987 ドメイン）；89.41% は適用ポリシーなし
完全なトライアド — SPF + DKIM + 適用 DMARC	3.87%（10,092,481 ドメイン）

このページで説明する20分で、ブランド新ドメインは完全なトライアドでインターネットの約 96% より先を行くことになる。SPF 採用成熟度モデルがそのラダーのすべての段階を詳細に説明している。

新ドメインが p=reject に到達するにはどれくらいかかるか？

数ヶ月ではなく数週間 — 新規スタートの本当の利点だ。確立されたドメインで DMARC 適用が遅くなるのはレガシーのせいだ：忘れられた CRM コネクター、2019年に誰かが繋いだ請求ツール、誰も文書化していないニュースレタープラットフォーム。ポリシーを締める前にレポートで各ツールを見つけて修正しなければならない — だから通常何ヶ月にも及ぶロールアウトになる。

新ドメインにはレガシー送信者がない：今週自分ですべての送信元を設定し、ステップ4のレポートがそれを確認する。2〜4週間の実際の送信で p=none を実行し、レポートが実際に使っているもの全て（メールボックス、請求書、レシート、ウェブサイトの問い合わせフォーム）をカバーしていることを確認し、クリーンに流れたら p=quarantine に移り p=reject へ進む。段階的なメカニズム — pct ランプ、サブドメインポリシー、監視すべきもの — は p=none から p=reject へにある；新ドメインではそれを素早く進め、採点済みドメインのわずか 10.59% が到達した場所へ。

置き換える古いドメインはどうする？

この新ドメインがリブランドの一環なら、後に残すドメインは今あなたの最大のメールリスクだ：まだあなたのもので、取引先に信頼されているが、もう監視されていない。放棄しない — 明示的にロックダウンする。それ自体は短い作業だ：リブランドの古いドメインは開けたままの扉だ。

よくある質問

メールプロバイダーを選ぶ前にこれらのレコードを公開できるか？ DMARC はできる — rua 付きの p=none はプロバイダー非依存なので、登録した日に公開する。SPF はプロバイダーの include が必要；選ぶまでは v=spf1 -all（送信を許可するものは何もない）を公開し、ステップ2で置き換える。それは 121,145,609 ドメインが陥っているレコードなし状態（46.4% of 261,086,232 graded、2026-06-29 時点）より厳密によい。

SPF がすでに合格するなら DKIM は必要か？ はい。SPF は設計上転送で壊れ、多くのツールではあなたのものでない Return-Path ドメインを検証する — アライメントされた DKIM は両方を生き残る足だ。採点済みドメインのわずか 3.87% だけが完全な SPF+DKIM+適用 DMARC トライアドを完了している（2026-06-29 時点のセンサス）；DKIM はほとんどの脱落者がスキップするステップだ。スキャンがフラグを立てたら DKIM の修正から始める。

新ドメインは ~all と -all どちらを使うべきか？ 確立されたドメインでは、忘れた送信者を見つける間 ~all が慎重な選択だ。新ドメインには見つけるものがない：プロバイダーの include が入り DKIM が署名したら、-all はずっと早く安全だ。念には念を入れたい？まず2週間クリーンな DMARC レポートで確認する。

3つのレコードすべてが合格 — なぜメールがまだスパムに入るのか？ 認証とレピュテーションは別物だからだ：合格するレコードは受信者がそれがあなたのものと確認できることを意味し、まだあなたを信頼することを意味しない。新ドメインは一貫した、望まれた、低ボリュームのメールを送り徐々に増やすことで信頼を得る。メールがチェックに失敗しているのかスパムに入るだけなのかは、SPF の修正から始めてスキャン結果を確認する。

オーナーにレポートを送る

このドメインをクライアントのために設定しているなら、証拠で仕事を締める。ステップ6後に無料スキャンを再実行し、採点済みレポートをビジネスオーナーに転送する：SPF、DKIM、DMARC が合格、平易な言葉で、ローンチ時点の日付で。保険会社やクライアントアンケートが求めるアーティファクトであり、ドメインがインターネットの 96% が決してできない方法でスタートしたことを証明する。

ドメインをチェックする → · 正規メールを失わずに p=none から p=reject へ → · 集計データのみ使用。データは EU 内で保存・処理。