> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.onesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# メールドメイン設定のベストプラクティス

> 送信ドメインとウェブプレゼンスを設定するためのベストプラクティス。

ドメインの設定方法は、メールが受信トレイに届くかどうかに直接影響します。これらのステップは、メールプロバイダーが信頼し、受信者が認識し、悪意ある攻撃者がなりすませない送信者アイデンティティの基盤です。

これを正しく行うことで、ブランドを保護し、配信性を向上させ、より広範なメールエコシステムに対して配信する価値のある正当な送信者であることを示します。

<Note>
  OneSignal メールアカウントが検証中に拒否された場合は、以下の[セルフチェック](#self-check)を実行してください。ほとんどの拒否はこれらの領域のいずれかに起因します。変更を行った後、DNS の伝播を待ち(最大 24〜48 時間)、**Settings > Set up Email** に戻って **Verify Account** を再度クリックします。最初の拒否から 1 週間後に再試行できます。
</Note>

***

## セルフチェック

各項目を確認してください。該当するセクションへ移動するにはリンクをクリックしてください。

* [SPF、DKIM、DMARC](#email-authentication-spf-dkim-and-dmarc) がすべて存在し、有効で、`From:` アドレスと整合しています。
* [DNS レコードが正常に解決されます](#dns-configuration-and-health)。A/AAAA レコードや応答するネームサーバーを含む。
* [ドメインと IP が主要なブロックリストに掲載されていません](#check-your-blocklist-status)。これは顧客が確認することを忘れがちな、最も一般的な拒否原因です。
* [SSL/TLS 証明書](#ssltls-and-site-security) がドメインで有効であり、ブラウザの警告がありません。
* [ドメインに組織を代表する実際にアクセス可能なウェブサイトがあります](#domain-and-web-presence)。
* [ドメイン登録が公開されており、ビジネス情報と一貫しています](#building-a-stronger-trust-profile)。

このチェックリストのすべての項目が合格した場合は、検証を再試行する前に[よくある質問](#faq)で追加の考慮事項を確認してください。

***

## メール認証 (SPF、DKIM、DMARC)

認証レコードは、ドメインの送信評判にとって非常に重要です。これらは、受信メールサーバーに対してメールが本当にあなたから送信されていることを伝え、そうでない場合の処理方法に関する明確な指示を与えます。

3 つすべてのレコード([SPF、DKIM、DMARC](./email-dns-configuration))が存在し、相互に整合している必要があります。いずれかのギャップは、全体的な認証態勢を弱め、受信トレイプロバイダーのメールに対する信頼を減らします。

<Card title="メール DNS 設定" icon="globe" href="./email-dns-configuration">
  送信ドメイン用に SPF、DKIM、DMARC レコードを設定します。
</Card>

<Warning>
  レポートアドレスのない `p=none` ポリシーは出発点であり、完成した設定ではありません。DMARC の利点を最大限に活用するには:

  * ポリシーを `quarantine` または `reject` に設定して、ドメインを単に観察するのではなく、積極的に保護します。
  * 認証結果をモニタリングし問題を早期に発見できるよう、アクティブな集約レポートアドレス(`rua` タグ)を含めます。

  M3AAWG を含む業界団体は、送信構成が許す限り早期に監視から強制執行へ移行することを推奨しています。[M3AAWG メール認証推奨ベストプラクティス](https://www.m3aawg.org/sites/default/files/doc_files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)を参照してください。
</Warning>

### 整合性が重要です

`From:` アドレスのドメインは、DKIM 署名ドメインまたは SPF リターンパスと整合している必要があります。不整合(これらが一致しない場合)は、3 つすべてのレコードが正しく設定されていても認証失敗を引き起こし、配信性に直接ダメージを与えます。

たとえば、`From:` アドレスが `team@onesignal.com` であるが、DKIM 署名が `mail.example.com` 用に設定されている場合、受信トレイプロバイダーはその不一致を見て認証を失敗として扱います。両方のレコードがそれぞれ有効であっても、認証を通過するにはドメインが一致する必要があります。

***

## DNS 設定と健全性

健全な DNS 設定は、認証レコードが依存するインフラです。ここでの問題は他のすべてを台無しにする可能性があります。DNS レコードの段階的な設定については、[メール DNS 設定](./email-dns-configuration)ガイドを参照してください。

認証レコードに加えて、確認する価値のあるいくつかの事項があります:

* **A および AAAA レコード**は、ドメインを Web サーバーに接続します。何にも解決されないドメインはウェブプレゼンスがなく、これは受信トレイプロバイダーとスパムフィルターがそれらを評価する方法に影響します。

* **ネームサーバー**は、アクティブで応答している必要があります。ドメインに対する DNS ルックアップが失敗している場合、認証レコードを検証できず、検証できない認証は認証なしと同じように扱われます。

[MXToolbox](https://mxtoolbox.com) や [DNSChecker](https://dnschecker.org) などの無料ツールを使用すると、すべての DNS レコードを迅速に検査し、送信に影響を与える前に設定のギャップを発見できます。

***

## ブロックリストステータスの確認

ドメイン、およびそれに関連する IP アドレスは、あなたとは関係のない理由で 1 つ以上の公開評判ブロックリストに表示される可能性があります。一般的な原因には、ドメインの以前の所有者、共有ホスティングや IP の履歴、または過去の単一のスパム苦情などがあります。受信トレイプロバイダーと検証システムは、リストに掲載されたドメインをより高いリスクとして扱うため、設定の他のすべての部分が正しくても、ブロックリストへの登録が拒否の決定要因となる可能性があります。

主要なリストに対してドメインと IP を確認してください:

* [Spamhaus DBL](https://check.spamhaus.org/) — ドメインブロックリスト
* [SURBL](https://www.surbl.org/surbl-analysis) — URI/ドメインブロックリスト
* [MXToolbox blacklist check](https://mxtoolbox.com/blacklists.aspx) — 一度に 80 以上のリストをチェック

掲載されている場合は、各ブロックリストが独自の削除プロセスを公開しています。削除は無料で、通常は数日以内に完了します。検証を再試行する前にリストを再確認してください。

***

## SSL/TLS とサイトセキュリティ

有効な SSL/TLS 証明書は、受信トレイプロバイダー、スパムフィルター、受信者全員が探す合法性の基本的なシグナルです。期限切れ、欠落、または誤って設定された証明書は、メールが評価される前にドメインに対する信頼を損ないます。

サイトはブラウザのセキュリティ警告なしに HTTPS で読み込まれる必要があります。証明書は最新で、正しく設定され、正しいドメインに発行されている必要があります。Let's Encrypt などのプロバイダーの無料証明書は、有効で適切に設置されている限り、完全に問題ありません。

<Note>
  [SSL Labs](https://www.ssllabs.com/ssltest/) を使用して SSL 設定を監査してください。
</Note>

***

## ドメインとウェブプレゼンス

技術的な設定は、受信トレイプロバイダーにドメインがどのように設定されているかを伝えます。ウェブプレゼンスは、彼らと受信者に、その背後にいるのが誰かを伝えます。

組織を明確に表す、実際にアクセス可能なウェブサイトを持つドメインは、プレースホルダーコンテンツ、デフォルトのホスティングページ、または到達できないサイトを持つドメインよりも強力な送信者です。一貫したウェブプレゼンスはまた、悪意ある攻撃者があなたのブランドを説得力を持って装うことを難しくします。なぜなら、あなたからの正当なコミュニケーションがどのようなものであるかについての確立された参照点があるからです。

非常に最近登録されたドメイン、または失効して再登録された兆候のあるドメインは、受信トレイプロバイダーにとって本来の信頼度が低くなります。ドメインが新しい場合は、送信量を増やす前に信頼が構築される時間を与えてください。

<Card title="メールウォームアップ" icon="sun" href="./email-warm-up">
  OneSignal の Auto Warm Up 機能を使用して、新しいドメインから徐々に送信量を増やします。
</Card>

***

## より強固な信頼プロファイルの構築

基本ラインを超えて、いくつかの追加のステップが、送信者としてのドメインの評判を大きく強化します。

### ドメイン登録を公開する

公開登録、つまり登録レコード、ウェブサイト、および公開ビジネスプロファイル全体で一貫したビジネス情報を持つことは、組織の正当性を示します。これらのソース間の一貫性は、単一のソースよりも重要であり、ドメインを説得力を持って偽装することをはるかに困難にします。

### 組織ドメインをカバーする

サブドメインから送信する場合(例: **mail.yourdomain.com**)、組織ドメインにも有効な SPF、DKIM、DMARC レコードが設定されていることを確認してください。認証レコードのない裸の親ドメインに支えられた送信サブドメインは不完全な設定であり、ブランドを露出させます。

### DMARC を監視から強制執行へ移行

現在の DMARC ポリシーが `p=none` の場合、データを収集していますが、行動を起こしていません。アクティブなレポートアドレスとともに `p=quarantine` または `p=reject` に移行することで、受信者をなりすましメールから保護し、ブランドの評判を守り、受信トレイプロバイダーにドメインを真剣に扱っていることを伝えます。これは M3AAWG と主要な受信トレイプロバイダーの両方によってベストプラクティスと見なされています。

***

## 継続的なメンテナンス

ドメイン設定は一度きりのタスクではありません。インフラが変化するにつれて、メンテナンスを行ってください:

* **DKIM キーを定期的にローテーション**して、キーが侵害された場合の露出を制限します。
* **DMARC レポートを定期的に確認**して、ドメインの不正使用を早期に発見します。
* **DNS レコードを更新**します。メールプロバイダー、ホスティング、またはサブドメインを変更するたびに。
* **期限切れ前に SSL 証明書を更新**し、可能な場合は自動更新を設定します。
* **重大な変更後に再検証**して、送信インフラに後退がないことを確認します。

***

## よくある質問

### なぜアカウントが拒否されたのですか?

OneSignal は、検証を改ざん耐性のあるものに保ち、すべての顧客に対して一貫させるために、第三者のドメイン評判プロバイダーを使用しています。そのシグナルの整合性を保つため、基礎となるスコアや個別アカウントに対して評価された特定の要因を共有しません。

お伝えできること: 検証はドメインに関する公に観察可能なシグナル—認証レコード、DNS の健全性、ブロックリストステータス、SSL 設定、ウェブプレゼンス、登録履歴—に依存しています。上記の[セルフチェック](#self-check)を使用すると、ダウンストリームの受信トレイプロバイダーが使用するのと同じ無料ツールを使って、これらのシグナルそれぞれを検査できます。ほとんどの拒否は、そのチェックリストの 1 つまたは 2 つの項目に起因します。

### セルフチェックを完了しましたが、再度拒否されました。次はどうすればよいですか?

`support@onesignal.com` に以下の要約を添えてお問い合わせください:

* セルフチェックで検証した項目と、使用したツール(例: "MXToolbox はすべての DNS レコードが合格と表示し、Spamhaus は私のドメインが登録されていないと表示しています")。
* 試行間に行った変更。
* 送信ドメイン。

サポートは、一般的な検証カテゴリに対してアカウントをレビューし、基礎となる評判データを共有することはできなくても、何に焦点を当てるべきかについて方向性を示すことができます。

### DNS の変更が適用されるまでにどのくらい時間がかかりますか?

DNS の変更は通常数時間以内に伝播しますが、世界中に適用されるまでに最大 24〜48 時間かかる場合があります。検証を再試行する前に、[MXToolbox](https://mxtoolbox.com) または [DNSChecker](https://dnschecker.org) を使用してレコードが見えることを確認してください。

### いつ検証を再試行できますか?

最初の拒否から 1 週間後に再検証をリクエストできます。セルフチェックで特定された変更を最初に行ってください—変更なしで再試行しても通常は同じ結果になります。

### 有料の SSL 証明書が必要ですか?

いいえ。[Let's Encrypt](https://letsencrypt.org) などのプロバイダーの無料証明書は、有効で、最新で、正しいドメインに発行されている限り、完全に受け入れられます。

### 新しく登録したドメインを使用できますか?

はい、ただし新しく登録されたドメインは受信トレイプロバイダーにとって本来の信頼度が低くなります。ドメインが新しい場合は、このガイドの設定ステップを完了し、送信量を拡大する前に[メールウォームアップ](./email-warm-up)を使用して送信評判を徐々に構築することを検討してください。

***

## 関連ページ

<Columns cols={2}>
  <Card title="メール DNS 設定" icon="globe" href="./email-dns-configuration">
    送信ドメイン用に SPF、DKIM、DMARC レコードを設定します。
  </Card>

  <Card title="メール配信性" icon="inbox" href="./email-deliverability">
    評判、バウンス、スパムトラップ、受信トレイ配置などの主要な概念を理解します。
  </Card>

  <Card title="メール評判のベストプラクティス" icon="shield-check" href="./email-reputation-best-practices">
    健全な送信評判を構築・維持するための実行可能なステップ。
  </Card>

  <Card title="メールウォームアップ" icon="sun" href="./email-warm-up">
    送信量を徐々に増やして受信トレイプロバイダーとの信頼を構築します。
  </Card>
</Columns>