新規登録ドメインのメール認証を設定する方法

by

最終更新日:
10 読了時間:10分
新規登録ドメインのメール認証を設定する方法

主なポイント

  • 新規登録されたドメインにはSPF、DKIM、DMARCが設定されていないため、登録初日からなりすましの標的となりかねない
  • レコードを正しい順序で設定してください:SPFを最初に、次にDKIM、その次にDMARC
  • 適用する前に状況を把握するため、DMARCの設定は常に「p=none」から始めてください
  • DNSの反映が完了した後、PowerDMARCの無料チェックツールを使用して、3つのレコードすべてを確認してください
  • より厳格なポリシーの適用に移行する前に、DMARCの集計レポートを確認してください

ドメインが登録された瞬間、たとえ1通のメールも送信されていなくても、そのドメインはなりすましの標的となります。SPF、DKIM、DMARCが導入されていない場合、誰でもあなたのドメインから送信されたように見えるメールを送ることができ、受信サーバーにはそれを検知する技術的な手段がありません。このガイドでは、実際のDNSレコードの例や検証手順、そして設定が稼働した後に監視すべき事項を交えながら、メール認証を正しい順序で設定する方法について解説します。

なぜ新しいドメインは特に脆弱なのか

新しいドメインには、認証レコードがないだけでなく、送信履歴も、レピュテーションも、設定の基盤となる過去の設定も一切ありません。こうした要因が重なることで特有のリスクが生じ、既存のドメインで認証を設定する場合とは異なる設定アプローチが必要となります。

なぜ新しいドメインは特に脆弱なのか--

1. 送信者の評価はまだありません

メール受信プロバイダーは、送信履歴に基づいて受信メールの取り扱い方法を決定します。これまで一度もメールを送信したことのないドメインには実績がないため、受信サーバーは、レピュテーション情報だけでは、正当な新規送信者となりすまし送信者を区別することができません。

メール認証はこの課題を解決します。SPF、DKIM、DMARCは、レピュテーションが蓄積される前から、送信者がドメインを管理しており、正当な送信者を承認するように設定していることを、受信プロバイダーに技術的なシグナルとして伝えます。新しいドメインからのメールは、正しく認証されていても最初はスパムフォルダに振り分けられる可能性がありますが、認証を行わない場合、プロバイダーが送信者を評価する際に利用できる最後の信頼性シグナルを失うことになります。

2. 新しいドメインはなりすましの格好の標的となる

攻撃者は、新規または登録されたばかりのドメインを特に狙います。なぜなら、こうしたドメインには認証レコードが設定されていないことがほとんどだからです。SPF、DKIM、DMARCがなければ、どのサーバーでもあなたのドメインから送信していると主張し、それを実現できてしまうからです。

このリスクには、いくつかの脅威の種類が含まれます。ブランドなりすまし攻撃では、貴社が顧客やパートナーとまだ関係を築いていない段階で、貴社のドメインを使用して連絡が取られます。 フィッシング攻撃は、新規ドメインが「白紙の状態」であることを悪用します。悪評がないため、スパムフィルターに引っかかりにくいのです。ビジネスメール詐欺(BEC)は、偽造されたメールアドレスを使用して、ベンダーや社内チームを標的にすることがあります。オースティンのカスタムソフトウェア開発会社のように、プロジェクトの進捗報告、請求書、または顧客へのメールを送信する企業は、認証体制が整うまでリスクにさらされています。

3. 対応すべき過去の記録がない

この点において、新規ドメインは既存のドメインに対して明確な優位性を持っています。古いドメインでは、時間の経過とともにDNS関連の問題が蓄積されていきます。例えば、数年前に置き換えられたプラットフォームの重複したSPFレコード、もはやそのプロバイダーに代わってメールを送信していないメールプロバイダーに紐付けられたDKIMセレクター、あるいは一度も見直されたことのないまま「p=none」のまま放置されたDMARCポリシーなどが挙げられます。

一から始めるということは、最初からすべてを正しく設定することを意味します。過去の記録を検証する必要もなく、既存のメール配信フローが中断されるリスクもなく、引き継がれた設定ミスを解消する必要もありません。設定はよりシンプルで、迅速かつ、確認も容易です。

4. コールドスタートに関する考慮事項

認証とドメインのウォームアップは関連していますが、別々のプロセスです。認証レコードは、受信サーバーに対して、そのメールが正当なものであることを伝えます。一方、ウォームアップとは、送信量を少なく始め、時間をかけて徐々に増やしていくことで、良好な送信履歴を築くプロセスです。

認証が最優先です。認証チェックに失敗したドメインをウォームアップすることはできません。SPF、DKIM、DMARCが稼働し、検証が完了したら、まずは送信量を限定して開始し、DMARCレポートが蓄積されるのを待ってから、ポリシーの強化や送信量の拡大に進んでください。

電子メールを認証するには?

始める前に必要なもの

  • ドメインのDNSパネルへのアクセス

SPF、DKIM、DMARCレコードはすべて、DNS内のTXTレコードとして公開されます。DNS管理画面は、ドメイン登録業者(Namecheap、GoDaddy、Cloudflareなど)またはホスティングプロバイダーのサイト内にある場合があります。新しいレコードを追加するには書き込み権限が必要です。読み取り専用権限では不十分です。

  • メール配信プラットフォーム

DKIMキーは、メール送信プラットフォームによって生成されるものであり、手動で作成するものではありません。DKIMレコードを公開する前に、ご利用のプラットフォーム(Google Workspace、Microsoft 365、カスタムSMTPサービスなど)内でDKIMの設定手順を完了する必要があります。プラットフォームが鍵ペアを生成し、DNSに公開するための正確なレコード名と値を通知します。送信プラットフォームとは独立して、有効なDKIMレコードを作成することはできません。

お客様のドメインからメールを送信するプラットフォームが複数ある場合は、今すぐそれらをすべて特定してください。それぞれのプラットフォームをSPFレコードでカバーする必要があり、また、それぞれに独自のDKIMセレクタが必要になる場合があります。

  • DMARCレポート用のメールアドレス

DMARCの集計レポートは、DMARCレコードのruaタグで指定したアドレス宛てに送信されます。このアドレスは、監視対象の受信箱であれば何でも構いません。例えば、[email protected]のような専用アドレス、チームで共有する受信箱、あるいはDMARCレポートプラットフォームが提供するアドレスなどが該当します。重要なのは、そのアドレスが存在し、定期的に確認されていることです。有効なruaアドレスが設定されていない場合、DMARC設定の監視フェーズでは実用的な情報が得られません。

ステップ1 – SPFレコードの設定

SPF(Sender Policy Framework)は、受信側のメールサーバーに対し、どのIPアドレスがあなたのドメインを代表してメールを送信する権限を持っているかを通知します。まずはSPFを設定してください。これは、DKIMやDMARCの基盤となるものです。

SPFは、許可された送信元を記載した単一のDNS TXTレコードを通じて機能します。受信サーバーがあなたのドメインからメッセージを受信すると、送信元のIPアドレスをSPFレコードと照合します。リストに記載されているIPアドレスは通過し、記載されていないIPアドレスは拒否されます。

v=spf1 include:_spf.google.com ~all

v=spf1→ これはSPFレコードであることを示しています

include:…→ Googleのメールインフラストラクチャ内のすべてのIPアドレスを許可する

~all→ 明示的にリストされていない送信者はすべてソフトフェイルとなる

SPFレコードの追加方法

  1. DNSプロバイダーにログインしてください
  2. 新しいTXTレコードを作成する
  3. ホスト/名前」フィールドに「@」(ルートドメインを表す)を設定してください
  4. ご利用のメールプラットフォームから提供されたSPF値を貼り付けてください
  5. レコードを保存する
タイプ ホスト 価値
TXT @ v=spf1 include:_spf.google.com ~all

複数のプラットフォームからメールを送信する場合は、すべての送信元を1つのSPFレコードにまとめます。ルートドメインに2つのSPF TXTレコードを公開すると、SPFの検証に失敗します。評価されるのは1つだけであり、その結果は予測不能となります。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

新規ドメインにおけるSPF設定のよくある間違い

  • 2つのSPFレコード– ドメインごとに有効なSPF TXTレコードは1つだけです。2つ公開すると、どちらも無効になります。すべての送信元を1つのレコードに統合してください。
  • -all オプションを早すぎる段階で使用しないこと– ハードフェイルでは、リストにない送信元からのメールは即座に拒否されます。送信元リストが完全に確認されるまでは、まずは ~all(ソフトフェイル)を使用してください。
  • 送信元のプラットフォームが登録されていない– SPFに指定されていないドメインから送信を行うプラットフォームは、すべて認証に失敗します。レコードを保存する前に、すべての送信元を登録してください。

ステップ 2 – DKIM レコードを生成して公開する

DKIM(DomainKeys Identified Mail)は、送信メールに暗号署名を付加します。受信サーバーは、DNSに登録された公開鍵を使用して、そのメッセージが送信者のドメインから送信されたものであり、送信中に改ざんされていないことを確認します。

DKIMキーは、メール送信プラットフォーム内で生成されるものであり、手動で作成する必要はありません。プラットフォームの「DKIM」「ドメイン認証」、または「メール設定」のセクションに移動し、表示される手順に従ってください。プラットフォームは、秘密鍵(送信メールの署名に使用)と公開鍵(受信サーバーが署名を検証できるようDNSに登録される)からなる鍵ペアを生成します。

各プラットフォームは、セレクタを割り当てます。これはレコード名に含まれるラベルであり、これにより同一ドメイン上で複数のDKIMキーを共存させることができます。2つの送信プラットフォームを使用する場合、それぞれに独自のセレクタとDNSレコードが割り当てられます。セレクタ「google」を使用したレコード名の例:

google._domainkey.yourdomain.com

DKIMレコードの公開方法

  1. メールプラットフォームの「DKIM」セクションを開いてください
  2. TXTレコード名(例:google._domainkey)をコピーしてください
  3. TXTレコードの値(公開鍵の文字列)をコピーします
  4. DNSパネルを開き、新しいTXTレコードを作成してください
  5. 名前と値を、表示されているとおりに正確に貼り付けてください
  6. 保存してから、プラットフォームに戻り、認証を実行してください
タイプ ホスト 価値
TXT google._domainkey v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9…

一部のプラットフォームでは、DNSも管理している場合、DKIMレコードを自動的に公開できることがあります。手動で追加する前に、ご利用のプラットフォームの設定ガイドをご確認ください。

DKIMが有効になっているか確認する方法

PowerDMARC DKIMチェッカー
ドメインとセレクターを貼り付けると、DKIMレコードが有効で、正しい形式であり、検証に合格しているかどうかを即座に確認できます。

DNSの反映は通常、数時間以内に完了しますが、最大で48時間かかる場合があります。その期間を経ても確認に失敗する場合は、値に余分なスペースが含まれていないか、ホスト名が間違っていないか、またはキーが切り捨てられていないかを確認してください。

ステップ3 – DMARCレコードを作成する

DMARC(Domain-based Message Authentication, Reporting and Conformance)はポリシー層に位置付けられます。SPFやDKIMが認証チェックを行うのに対し、DMARCは、それらのチェックに失敗したメッセージに対して受信サーバーがどのように対応すべきかを指示します。また、集計レポートを提供することで、どの送信者があなたのドメインを使用してメールを送信しているかを正確に把握できるようにします。

新しいドメインに適したDMARCポリシー

必ずp=none から始めてください。

「監視のみ」のポリシーでは、配信に失敗したメッセージも引き続き配信され、何もブロックされません。これは、正当な送信元がすべて正しく認証されているかどうかをまだ確認できていないため、新しいドメインにとって適切な出発点となります。レポートを確認する前にいきなり「p=reject」に設定してしまうと、設定し忘れた送信元からの正当なメールが、気付かないうちにブロックされてしまう可能性があります。

方針 効果
p=none 監視のみ – 配信には影響ありません
p=quarantine 失敗したメッセージはスパムフォルダに送信されます
p=reject エラーメッセージはサーバー側で拒否されます

決まったスケジュールではなく、レポートの結果に基づいて各レベルを進んでください。

DMARCレコードの作成と公開方法

PowerDMARC DMARCレコード生成ツール
数秒で正しい形式のDMARCレコードを作成できます。ポリシーを選択し、RUAアドレスを追加して、公開可能なTXTレコードをコピーしてください。

_dmarc.yourdomain.comに TXT レコードとして設定してください

最低開始記録:

v=DMARC1; p=none; rua=mailto:[email protected]

v=DMARC1→ これがDMARCレコードであることを示す

p=none→ 監視モード(メッセージはブロックされない)

rua=mailto:→ 集計レポートの送信先アドレス

タイプ ホスト 価値
TXT _dmarc v=DMARC1; p=none; rua=mailto:[email protected]

ruaタグの機能

ruaタグは、DMARCの集計レポートが送信される場所です。これらのレポートは、受信メールサーバーから毎日送信され、どのIPアドレスがあなたのドメインを使用してメールを送信したか、それらのメッセージがSPFおよびDKIMを通過したかどうか、そしてあなたが認識していない送信元があなたを装って送信していないかどうかの情報を記載しています。ruaタグがない場合、DMARCレコードはポリシーを適用しますが、データは生成されません。p=noneの設定下では、レポートが唯一の出力となります。したがって、このタグを省略すると、監視フェーズ全体が無意味になってしまいます。

ステップ4 – 記録が反映されていることを確認する

3つのレコードをすべて公開した後、検証を実行する前にDNSの伝播が完了するまで時間を置いてください。ほとんどのレコードは数時間以内に伝播しますが、検証に失敗した場合、伝播の遅延ではなく実際の問題であると判断するには、最大48時間かかる可能性があることを念頭に置いてください。

SPF、DKIM、DMARCを確認するためのツール

  • PowerDMARC SPFチェッカー– SPFレコードが存在し、構文が正しく、適切な送信者がリストされていることを確認します
  • PowerDMARC DKIMチェッカー– 正しいセレクターとドメインでDKIMレコードが有効になっているかを確認します
  • PowerDMARC DMARCチェッカー– _dmarcにDMARCレコードが存在し、有効なポリシータグが設定されていることを確認します
  • PowerDMARC DNS 伝播チェッカー– レコードが世界中のDNSサーバーに反映されているかどうかを確認します。レコードを公開した直後にチェッカーで「見つかりません」と表示される場合に役立ちます
  • PowerDMARC Domain Analyzer– SPF、DKIM、DMARC、BIMI、MTA-STS、TLS-RPT を1つの画面で包括的にスキャンするため、本番運用前にメール認証の全体的な状況を把握できます

レコードの検証に失敗した場合の対処法

まずは基本から確認しましょう。レコードの種類が「TXT」であることを確認してください(A、CNAME、MXではありません)。ホスト名がツールで指定されているものと一致しているか確認してください。SPFの場合は「@」、DMARCの場合は「_dmarc」、DKIMの場合は「selector._domainkey」です。コピー&ペーストによるよくあるミスがないか確認してください。余分なスペース、セミコロンが抜けていないか、DNS管理画面から引用符がそのまま残っていないか、レコード名の末尾にドットが付いていないかなどをチェックしましょう。

DNSの設定に問題がないようであれば、設定ミスの可能性を想定する前に、DNSプロパゲーションチェッカーを使用して、レコードが完全に反映されているかどうかを確認してください。

ステップ5 – 報告書と執行に向けた進捗状況を監視する

認証レコードの公開はプロセスの始まりに過ぎず、終わりではありません。p=noneフェーズは、アクティブな監視を行うために存在します。これにより、強制措置を適用する前に、正当なメールが認証を通過していることを確認するためのデータが得られます。

DMARCの集計レポートはXMLファイルとして送信されますが、これは手動で読むことを想定した形式ではありません。PowerDMARCはこれらをダッシュボードに変換し、送信元ごとに以下の情報を表示します:

  • どのIPアドレスから、あなたのドメイン名を使ってメールが送信されましたか
  • メッセージがSPFを通過したか、失敗したか
  • メッセージがDKIMの検証に合格したか、不合格だったか
  • あなたのドメインから、未承認の送信元による送信が行われていないか

このデータにより、設定が想定通りに機能しているかを確認できるほか、SPFやDKIMの設定時に見落としていた送信プラットフォームを特定することができます。

p=none から p=reject へ切り替えるタイミング

レポートの結果に基づいてスケジュールを決定してください。正当な送信元がすべてSPFまたはDKIMの検証に合格していることがレポートで一貫して確認できたら、設定を「p=quarantine」に変更します。その後、数週間は状況を監視してください。正当なメールが失敗していないと確信できたら、「p=reject」に切り替えます。これには決まった日数はありません。適用基準を厳格化する適切なタイミングは、レポートの結果が準備が整ったことを示したときです。

新しいドメインの認証を行う際のよくある間違い

  • SPFレコードを1つではなく2つ公開すると、SPF検証が完全に失敗します。すべての送信者を1つのレコードに統合してください。
  • DKIMを省略する– DMARCの整合性を確保するにはSPFだけでは不十分であり、メールの転送後も有効な検証はDKIMのみである
  • 監視を開始する前にDMARCの設定をp=rejectにすること――まだ認証していない送信者からの正当なメールがブロックされるリスクがあります
  • rua=タグを省略すると、監視フェーズ中のすべての可視性が削除され、集計レポートは送信されなくなります
  • プロパゲーション後にレコードを確認しないこと――DNS管理画面上では正しく見えるレコードでも、検証ツールでしか検出できない書式上の誤りが含まれている可能性があります

結論

順序が重要です。SPFを最初に、DKIMを2番目に、DMARCを3番目に設定します。新しいドメインの場合、p=noneから開始することで、強制適用を行う前に設定が正しく機能しているかを確認できます。これにより、ドメインの評価を築き上げる前に、その評判を守ることができます。

記録の確認、ドメイン全体のスキャン実行、または見やすいダッシュボードでの集計レポートの確認を行うには、PowerDMARCを無料でお試しください。大規模なメール配信を開始する前に、認証体制を整えておきましょう。

よくあるご質問

ドメインを新規に取得した場合、メール認証は必要ですか?

はい。メールを1通も送信する前に設定を完了させてください。認証レコードがない新しいドメインは、なりすましの格好の標的となります。また、初期のDMARCレポートからは、まだ何も送信していない段階で、すでに不正な活動が行われていることが判明する可能性があります。

SPF、DKIM、DMARCを設定する際の正しい順序はどのようなものでしょうか?

まずはSPF、次にDKIM、そしてDMARCです。DMARCはSPFとDKIMの検証結果を評価するため、DMARCの適用が意味を持つには、両方が正常に機能している必要があります。

認証レコードを追加した後、DNSの反映にはどのくらい時間がかかりますか?

ほとんどのレコードは数時間以内に反映されます。最大48時間ほどかかる場合もありますので、反映が完了したと決めつけずに、DNSプロパゲーションチェッカーを使用して確認してください。

新しいドメインには、どのようなDMARCポリシーを設定すべきですか?

まずp=none から開始します。集計レポートを確認し、正当な送信者すべてが認証を通過していることを確認した後、p=quarantine に移行し、最終的にはp=reject へと移行します。この移行は、固定されたスケジュールではなく、レポートのデータに基づいて行う必要があります。

メールの送信を開始する前に、DMARCを設定することはできますか?

その通りです。そして、これはぜひ実施すべきことです。DMARCレポートには、ドメインにおける送信前のあらゆる活動――すでに発生している可能性のある不正利用も含め――が記録されます。最初の送信を行う前に、Domain Analyzerを使用して、ドメインの認証状況を徹底的にスキャンしてください。

メールの受信のみを行い、送信はしない場合、認証は必要ですか?

SPFとDKIMは主に送信メールに関連するものですが、受信専用ドメインであってもDMARCレコードの設定は推奨されます。これがない場合、誰でもあなたのドメインアドレスを偽装して、連絡先や顧客、パートナーにフィッシングメールを送信できてしまうからです。

CTA