ドメインを認証する

[アーティクル]
10/11/2023

ドメイン認証が重要な理由には、多くの理由があります。

マーケティング電子メールメッセージの場合、ドメイン認証により、受信者の電子メールサーバーは、各メッセージに表示される送信元アドレスが組織に属していることを確認できます。認証では、組織が Dynamics 365 Customer Insights - Journeys が組織の代わりにメッセージを送信することを承認していることも確認します。このテストに合格しなかったメッセージはスパムとしてフィルターで除外される可能性が高くなり、これが配信率に劇的な影響を与える可能性があります。
外部でホストされたフォームの場合、ドメイン認証により、このドメインを所有していること、ドメインとの信頼関係が強化されていることを確認します。信頼関係の強化により、埋め込んだマーケティングフォームが有効になり、既知の取引先担当者データを使用して事前入力することが可能になります。
ドメイン認証は、DKIM (DomainKeys Identified Mail)、SPF (Sender Policy Framework) 保護も可能にし、From と Return-Path アドレスの整合性を確保し、メールでのブランド表現を向上させます。

電子メールドメイン認証の主な目的は、SPF と DKIMを有効にすることで、スパム、フィッシング、詐欺などの電子メールを使用した潜在的な不正行為から送信者と受信者の両方を保護することです。

DomainKeys Identified Mail (DKIM) によって、電子メールのコンテンツとヘッダーの保護が円滑化できます。これは公開鍵/秘密鍵の暗号化と、送信者ドメインの公開 DNS レコードを使用した署名検証をベースにしています。このタイプの暗号化は、電子メールが確認済みの送信者から送信されたという貴重なフィードバックを受信者に提供します。そして、その内容は転送の段階でも変更されていません。

SPF は、送信者ドメイン所有者が設定した信頼できる送信元 (IPアドレス) からメールが送信されたことを保証する、もう一つの保護および認証の一種です。

マーケティング電子メールメッセージのエラーチェックをしたり、ライブに移行したりすると、検証システムでは、組織のために登録され確認された認証済みドメインを指定する送信元アドレスをメッセージが使用する必要があります。未登録のドメインからの送信元アドレスを含むメッセージを送信しようとすると、エラーが発生します。

マーケティング電子メールと配信率の詳細については、電子メールマーケティングのベストプラクティスを参照してください。埋め込みフォームおよび事前に入力の詳細については、「外部 Web サイトのランディングページと統合する」を参照してください。

既定で認証されているドメイン

既定では、すべての新しい Dynamics 365 Customer Insights - Journeys インストールには、-dyn365mktg.com で終わる事前認証済みの送信ドメインが用意されています。事前認証済みのドメインとは、認証済みのメールの送信をすぐに開始できることを意味します。このドメインは、メールレピュテーションを持たず、組織とは関係がないため、初期機能のテストやデモ目的でのみ設計されています。認証されたメッセージには、受信者が自分の組織から来たと認識できる送信元アドレスが表示されるため、すぐにでも自分の実際の送信ドメインを認証する必要があります。独自のドメインを認証すると、送信レピュテーションを管理できるようになり、ブランドの認知度と配信可能性の結果が向上します。

ユーザーが新しい電子メールを作成すると、送信元アドレスは、ユーザーの Dynamics 365 Customer Insights - Journeys ユーザーアカウントに登録された電子メールアドレスに自動設定されます。ただし、そのメールアドレスが DKIM を使用して認証されていないドメインを使用している場合は、認証済みドメインを使用するように最初の 送信元アドレス が変更されます (電子メールアドレスはアカウント名*@*ドメイン名の形式を使用します)。結果としての 送信元アドレス にはメッセージを作成しているユーザーのアカウント名が引き続き表示されますが、Customer Insights - Journeys インスタンスに登録された DKIM 認証済みドメイン名が表示されるようになります (たとえば MyName@contoso.s01.dyn365mktg.com)。これは配信率において利点をもたらしますが、有効な返信アドレスではない場合があります。

どのドメインを認証するべきか

マーケティング電子メールで使用するすべての送信元アドレスをカバーするために必要な数の認証済みドメイン、および、事前入力が有効化された埋め込みフォームをサポートしようとしている場合のすべてのドメインおよびサブドメインを設定してください。

電子メール用のドメインを認証する場合は、お客様の電子メールの返信アドレスに表示させるため、フルドメイン名を使用してください。メールアドレスは <MailAccount>@<domain> という形式になるため、メールアドレスが lamar.ferrari@contoso.com の場合、認証する必要があるドメインは contoso.com です (www.contoso.com やその他のサブドメインではありません)。
ドメインを認証して、事前入力をサポートする場合、各サブドメインを個々に認証する必要があります。したがってもし、contoso.com、www.contoso.com、events.contoso.com の形式の場合は、それぞれに別々のドメイン認証レコードを設定して、完全なサブドメインを毎回指定する必要があります。

重要

フォームを事前入力するには、ホストしているページが、HTTPS (HTTP ではない) 形式である必要があります。

フォームの事前入力は、アウトバウンドマーケティングフォームでのみサポートされています。

注意

すべての新規インスタンスと試用版は、インスタンスのドメインを DKIM と SPF で自動的に認証し、そのドメインをインスタンスの既定の送信ドメインとして設定します。そのため、通常はすべての新規インスタンスに対して、最低でも 1 つの認証済みのドメインがすでに設定されています。初期のテスト目的でのみ設計されているため、本番の電子メール送信目的には使用しないでください。ライブに移行する前に、必ず独自のドメインを認証してください。

認証されていないドメインからの電子メールの送信を防止する

ドメイン印象を利用するには、送信する各メッセージの差出人アドレスに、以前認証したドメインが反映されている必要があります。 Microsoftは、ユーザーが電子メールを最大限に活用できるよう支援することに注力しています。ドメインの設定の見落としや、誤操作を防止できるよう以下の機能を追加しました:

いずれのドメインにも関連付けがされていない送信者アドレスを持つ電子メールメッセージで本稼働をしようとすると、電子メールメッセージのエラーチェックによって警告が表示されます。
ドメインで認証される既定の送信ドメインを設定することをお勧めします。この設定を行うと、新規メールの作成または、送信元 フィールドに表示されるユーザーを変更するたびに、すべての電子メールメッセージの送信元アドレスが自動的に調整され、選択した既定のドメイン (初期設定で認証されていないドメインをが設定されている場合) が表示されます。詳細: 既定のマーケティングの設定と送信者と受信者のオプションを設定する
すべての新しいインスタンスとトライアルは、SPF/DKIM を有効にしたデフォルトのインスタンスドメインを自動的に認証し、そのドメインをインスタンスの既定の送信ドメインとして設定します。

ドメインの認証

Dynamics 365 Customer Insights - Journeys で認証済みドメインをセットアップするには、ドメインの DNS コントロールパネルにアクセスして、ドメイン認証プロセスを進めるときに新しいレコードを追加できるようにする必要があります。

ドメインの認証方法:

設定 > 電子メールマーケティング > ドメイン認証 にアクセスします。既存の認証されたドメインの一覧が開きます。

アクティブなドメイン

コマンドバーの新規を選択して、新しいドメインを追加します。ウィザードは、ドメイン認証プロセス全体を順を追って説明します。最初のステップでは、認証するドメイン名を入力し、それをフォームのホスティング機能と電子メール送信機能に使用するかどうかを選択する必要があります。

新しいドメインの構成

次のステップでは、最初の DNS レコードを追加するように求められます。これにより、ドメインの所有権がチェックされ、確認されます。 [コピー] ボタンを使用して TXT レコードの値を正確にコピーし、タイプミスを防ぎます。

ドメインの所有権の検証

次の 2 つの手順では、DKIM 保護機能を意味する CNAME レコード (CNAME1 および CNAME2) のセットアッププロセスを説明します。

電子メール送信の有効化

ドメインを構成する

次のステップは、最後に必要な CNAME DNS レコードを意味します。これは、Envelope-From (Return-Path) ドメインアライメントと SPF 保護機能用です。

送信元のエンベロープ

最後のステップでは、公開された DNS レコードを確認して確認できるようになります。チェックが終了したら、確認を選択します。システムは公開されたすべての DNS レコードをチェックして検証し、ダッシュボードに結果の概要を表示します。 DNS レコードに問題がある場合は、ダッシュボードで正確にどのレコードが失敗したかを確認できます。

DNS で公開されている TXT 所有権キーが見つからなかったことを示すエラーメッセージの例を次に示します。これは、レコードがまだ公開されていないか、間違いやタイプミスがあることを意味します。

レビューして終了する

すべてが完了すると、各 DNS レコードの横に緑色のチェックマークが表示され、ダッシュボードに [確認済み] ステータスが表示されます。これは、ドメイン認証の準備が整ったことを意味します。

ドメイン認証の終了

注意

選択した複数のドメインまたはサブドメインを認証できます。
www.yourdomain.com と yourdomain.com は 2 つの異なるドメインであるため、個別に追加する必要があります。技術的には www.yourdomain.com を追加してメール送信に使用することも可能ですが、From のメールアドレスが marketing@yourdomain.com ではなく markreting@www.yourdomain.com のようになるため、お勧めしません。

既存の有効な CNAME レコードが既に公開されているため、DNS の制限によりドメインまたはサブドメインに TXT レコードを追加できないという既知の問題があります。

そのような場合、ドメインの所有権を確認する別の方法を使用できます。ドメイン/サブドメインのルートに TXT レコードを追加する代わりに、サブドメインdynmktown.yourdomain.com の TXT レコードを作成する必要があります。

これにより、ドメイン yourdomain.com の所有権が検証されます。

サブドメインでも同じシナリオが機能します。たとえば、ドメイン mail.yourdomain.com を検証するには、TXT レコードを dynmktown.mail.yourdomain.com に追加する必要があります。

ドメインの SPF レコードを更新する

上で説明したドメイン認証ウィザードは、RFC 標準に従って必要なすべての構成を提供します。ただし、RFC に従わず、SPF レコードを使用して差出人アドレスを検証することによって、受信したメールを検証するメールプロバイダーがいくつかあります。これらのメールプロバイダーからのメールのバウンスを防ぐには、ドメイン内の SPF レコードを更新して、Customer Insights - Journeys ドメインを含めることができます。これを行うには、include: <dynamicssendingdomain> を追加して既存の SPF レコードを更新します。ここで、<dynamicssendingdomain> は Envelope-From の登録で取得した値です (上記のスクリーンショットの ind.pb-dynmktga.com) 。

Share via