Eコマースビジネスは信頼できるメールに依存しています。

顧客は注文確認、パスワードリセットリンク、配送状況の更新、返金通知、アカウントアラート、支払い通知、サポートメッセージ、マーケティングキャンペーンを受け取ります。攻撃者がこれらのメッセージを偽装したり、ストアになりすましたり、脆弱なメール認証を悪用したりできる場合、顧客の信頼を損ない、回避可能なセキュリティリスクを生み出すことになります。

ShopifyとWooCommerceのマーチャントにとって、メールセキュリティは配信可能性の問題だけではありません。

それは、支払い、アカウントアクセス、購入後のコミュニケーションに関する顧客ジャーニーを保護する一部です。

PCI DSSは、DMARC、SPF、またはDKIMを独立した必須プロトコルとして指定していません。しかし、PCI DSS v4.0.1要件5.4.1は、フィッシング攻撃から担当者を検出し保護するためのプロセスと自動化メカニズムを要求しています。メール認証は、より広範なセキュリティとコンプライアンスプログラムの一部として、そのフィッシング対策目的をサポートできます。

適切な枠組みはシンプルです:

DMARC単独でEコマースビジネスがPCI DSSに準拠するわけではありません。しかし、DMARC、SPF、DKIM、MTA-STS、TLS-RPTは、ドメインスプーフィングの削減、送信者の可視性の向上、メール認証が監視され維持されているという証拠の提供に役立ちます。

Eコマースマーチャントにとって、これは重要です。

偽の注文通知、返金リクエスト、請求書の更新、またはパスワードリセットメールは、顧客、スタッフ、または支払いワークフローに対するより広範な攻撃の始まりとなる可能性があります。

I. なぜメール認証がEコマースにとって重要なのか

注文詐欺や決済詐欺を含む、Eコマース企業を標的とする10種類の一般的なメール脅威のチェックリスト。

Eコマースのメールは信頼を運びます。

顧客はあなたのストアからのメッセージが正当であることを期待します。サポート担当者は内部アラートが信頼できることを期待します。財務チームは請求メールが既知のシステムから送信されることを期待します。ストアオーナーはサードパーティアプリが安全にメッセージを送信することを期待します。

攻撃者はその信頼を悪用します。

一般的なEコマースのメール脅威には以下が含まれます:

  • 偽の注文確認メール
  • 返金およびチャージバックフィッシング
  • パスワードリセットのなりすまし
  • 偽の配送通知
  • ベンダー支払い詐欺
  • カスタマーサポートのなりすまし
  • ストア管理者フィッシング
  • カート放棄フィッシング
  • 類似ドメインの悪用
  • 正確なドメインのスプーフィング

DMARCは、特定だが重要なリスクに対処するのに役立ちます:攻撃者があなたの実際のドメインから送信されたように見えるメールを送信するリスクです。

適切に実装されると、DMARCは受信メールサーバーが、あなたのドメインから送信されたと主張するメッセージが認証され、整合性があるかどうかを評価できるようにします。

これにより、顧客がFromアドレスで見る可視ドメインを保護できます。

II. PCI DSSのコンテキスト:メール認証がサポートするもの

DMARC、SPF、DKIM を補完的なセキュリティ対策として活用する、フィッシング対策に関する PCI DSS 要件 5.4.1 を示した統計カード。

PCI DSSはカード会員データの保護と安全な支払い環境の維持に焦点を当てています。

メール認証は、保存されたカード会員データを直接保護するものではありません。ペイメントゲートウェイ制御、安全なチェックアウト構成、アクセス制御、脆弱性管理、またはマルウェア対策保護を置き換えるものではありません。

しかし、いくつかの実用的な方法でPCI DSSのセキュリティ目標をサポートできます。

フィッシング対策制御

PCI DSS v4.0.1要件5.4.1は、フィッシング攻撃から担当者を検出し保護するためのプロセスと自動化メカニズムに焦点を当てています。

DMARC、SPF、DKIMは、攻撃者が信頼できるストアドメインをメールでなりすます能力を減らすことによってこれをサポートできます。

アクセス保護

パスワードリセットメール、管理者アラート、アカウント確認メッセージは、Eコマースプラットフォームのアクセスワークフローの一部であることがよくあります。

これらのメールが偽装できる場合、攻撃者はスタッフや顧客を騙して偽のページで認証情報を入力させる可能性があります。

ベンダーとサードパーティのリスク

Shopifyアプリ、WooCommerceプラグイン、CRM、サポートツール、レビュープラットフォーム、メールマーケティングサービス、トランザクションメールプロバイダーはすべて、ストアに代わってメールを送信する可能性があります。

DMARCレポートは、どのサービスが送信しているか、どれが適切に整合しているか、どれが修正を必要としているかを特定するのに役立ちます。

監視と証拠

DMARCレポートは、組織がメール認証を監視し、未承認のソースを特定し、強制に向かって進んでいるという証拠を提供できます。

その証拠は、セキュリティレビュー、内部監査、ベンダー評価、コンプライアンス文書をサポートできます。

III. ShopifyとWooCommerce:異なる責任

ShopifyとWooCommerceは異なる運用モデルを持っています。

これはマーチャントがメール認証にアプローチする方法に影響します。

IV. Shopifyのメールセキュリティ責任

Shopifyはホスト型コマースプラットフォームを提供します。これによりマーチャントのインフラストラクチャ責任は軽減されますが、ドメインレベルのメール認証を管理する必要性が無くなるわけではありません。

Shopifyマーチャントは依然として以下を理解する必要があります:

  • 顧客向けメールに使用されるドメイン
  • Shopifyがドメインに代わって送信する権限があるかどうか
  • サードパーティのShopifyアプリがメールを送信するかどうか
  • マーケティングプラットフォームが同じドメインを使用するかどうか
  • サポートツールがストアドメインから送信するかどうか
  • DMARCレポートが監視されているかどうか
  • ドメインが強制に向かって進んでいるかどうか

Shopifyは多くのプラットフォームレベルの制御を処理しますが、ドメインIDはあなたの責任のままです。

顧客が[email protected]からメールを受け取る場合、そのドメインは保護されなければなりません。

V. WooCommerceのメールセキュリティ責任

Shopify のホスト型プラットフォームと自己管理型 WooCommerce ストアにおけるメールセキュリティの責任範囲を比較した表。

WooCommerceは通常、WordPressホスティングと接続されたプラグインを通じて自己管理されます。

これにより柔軟性が生まれますが、責任も増えます。

WooCommerceマーチャントは以下を管理する必要があります:

  • WordPressメール構成
  • SMTPプロバイダーの選択
  • プラグインで生成されたメール
  • ホスティングメールの動作
  • トランザクションメール配信
  • DNS認証レコード
  • DKIM構成
  • SPF承認
  • DMARCレポート
  • サードパーティメールサービス
  • 管理者とプラグインアクセスのセキュリティ

WooCommerceストアは、重要なトランザクションメールにデフォルトのPHPメールに依存することを避けるべきです。SPF、DKIM、DMARCサポートを持つ専用のSMTPまたはトランザクションメールプロバイダーは、通常、より安全で信頼性の高いアプローチです。

VI. ステップ1:すべてのEコマースメールフローをマッピングする

DNSレコードを変更する前に、ストアのメールを送信するすべてのソースをマッピングします。

顧客向け、スタッフ向け、ベンダー向けのメッセージを含めます。

一般的なソースには以下が含まれます:

  • Shopifyトランザクションメール
  • WooCommerce注文メール
  • WordPressシステムメール
  • SMTPプロバイダー
  • マーケティングプラットフォーム
  • カート放棄ツール
  • レビューリクエストアプリ
  • ヘルプデスクとチケットツール
  • CRMプラットフォーム
  • 配送および履行ツール
  • サブスクリプションプラットフォーム
  • マーケットプレイスプラグイン
  • 請求書および会計システム
  • 支払い通知システム
  • セキュリティアラートツール
  • スタッフメールボックスプロバイダー

各送信者について、以下を文書化します:

  • 送信プラットフォーム
  • ビジネスオーナー
  • メッセージタイプ
  • 送信ドメイン
  • Return-Pathドメイン
  • DKIM署名ドメイン
  • SPF承認
  • DMARC整合性ステータス
  • メッセージボリューム
  • ビジネスの重要度
  • ベンダーサポート連絡先

このインベントリは、安全な強制の基礎です。

これがなければ、マーチャントは誤って正当な注文確認、パスワードリセット、またはサポートメールをブロックする可能性があります。

VII. ステップ2:SPFを慎重に構成する

SPFは、ドメインのメールを送信する権限があるサーバーを特定します。

簡略化された例は次のようになります:

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

これは例に過ぎません。マーチャントは盲目的にこれをコピーすべきではありません。

正しいSPFレコードは、ドメインのメールを実際に送信するサービスに依存します。

重要なSPFガイダンス:

  • 承認された送信者のみを含める。
  • 不要なincludeを避ける。
  • 10 DNS検索制限内に留まる。
  • もはやメールを送信していない古いベンダーを削除する。
  • DMARCのためにSPF単独に依存しない。
  • 正当な送信者が特定され、テストされた後にのみ-allに移行する。

SPFは、Return-Pathドメインと送信IPに依存するため、脆弱になる可能性があります。また、転送シナリオで壊れる可能性もあります。

だからこそ、DKIMがDMARC整合性の長期的な基盤としてしばしばより良い選択肢となります。

VIII. ステップ3:すべての主要な送信者でDKIMを有効にする

DKIMは、送信メールに暗号署名を追加します。

DMARCの場合、重要なポイントは整合性です。

DKIM署名ドメインは、可能な限り可視Fromドメインと整合する必要があります。

Shopifyマーチャントの場合、Shopifyと接続されたアプリまたは外部プラットフォームがあなたのドメインの認証された送信をサポートしていることを確認してください。

WooCommerceマーチャントの場合、SMTPまたはトランザクションメールプロバイダーを通じてDKIMを構成します。ほとんどのプロフェッショナルプロバイダーは、ドメインに追加する必要があるDNSレコードを生成します。

一般的なDKIMチェック:

  • DKIMは有効か?
  • どのセレクタが使用されているか?
  • DKIM d=ドメインはFromドメインと整合しているか?
  • サードパーティの送信者はあなたのドメインまたは自分のドメインで署名しているか?
  • DKIMキーは現在のプロバイダー基準に対して十分に強力か?
  • 文書化されたローテーションプロセスはあるか?
  • もはや使用されていない古いセレクタは削除されているか?

サードパーティプラットフォームは自分のドメインで署名する可能性があります。それはベンダーを認証するかもしれませんが、DKIMドメインがあなたの可視Fromドメインと整合しない限り、DMARCの結果には役立たないかもしれません。

IX. ステップ4:DMARC監視を開始する

DMARCは、SPFとDKIM認証を可視Fromドメインに戻します。

次のいずれかが真である場合、メッセージはDMARCをパスします:

  • SPFがパスし、SPF認証ドメインが可視Fromドメインと整合している。
  • DKIMがパスし、DKIM署名ドメインが可視Fromドメインと整合している。

強制の前に監視から始めます。

従来の静的DMARC監視レコードは次のようになります:

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

このレコードは機能しますが、レポートが積極的に受信、解析、分析、実行される場合のみです。

ほとんどのマーチャントにとって、生のDMARC XMLレポートを手動で管理することは困難です。

より良いアプローチは、Skysnagを通じてDMARC監視を開始し、ドメイン用の無料DMARCレコードを生成することです:

Skysnagは、マーチャントが正当な送信者を特定し、未承認のソースを検出し、認証ギャップを修正し、自信を持って強制に向かうのを支援します。

デフォルトでruf=を通じてフォレンジックレポートを有効にすることは避けてください。障害レポートはプライバシーと保持の懸念を生み出す可能性があり、主要な受信者の採用は限られています。プライバシー、法律、セキュリティレビュー後にのみ使用してください。

X. ステップ5:Shopifyのメール認証を構成する

Shopifyマーチャントは、ストアコミュニケーションに使用されるドメインを確認することから始めるべきです。

Shopify管理画面で、ドメイン設定を確認し、顧客向けメールに使用されるドメインを確認します。

主なタスクには以下が含まれます:

  • カスタムドメインの所有権を確認する。
  • Shopifyがドメインのメールを送信する権限があることを確認する。
  • Shopifyが推奨するDNSレコードを確認する。
  • ShopifyメールがSPFまたはDKIM整合性をパスするかどうかを確認する。
  • 個別にメールを送信するShopifyアプリを特定する。
  • マーケティングおよびサポートツールが送信者インベントリに含まれていることを確認する。
  • DNS変更後にDMARCレポートを監視する。

Shopifyアプリは特別な注意が必要です。

メールを送信する可能性のある一般的なアプリカテゴリには以下が含まれます:

  • カート放棄アプリ
  • レビューリクエストアプリ
  • ロイヤルティプラットフォーム
  • サブスクリプションツール
  • カスタマーサポートアプリ
  • 配送通知ツール
  • 請求書ツール
  • マーケットプレイスまたは卸売アプリ

各アプリは、ストアドメインと整合する認証されたドメインから送信するか、適切な場合は独自の明確にブランド化されたドメインを使用する必要があります。

すべてのアプリが自動的にShopifyの認証を継承すると仮定しないでください。

XI. ステップ6:WooCommerceのメール認証を構成する

WooCommerceマーチャントは、認証されていないホスティングメールまたはデフォルトのPHPメールを通じて重要なメールを送信することを避けるべきです。

より良いアプローチは、専用のSMTPまたはトランザクションメールプロバイダーを使用することです。

一般的なWooCommerceメールプロバイダーには以下が含まれます:

  • Amazon SES
  • SendGrid
  • Mailgun
  • Postmark
  • SMTP.com
  • Brevo
  • MailerSend
  • Google Workspace SMTP
  • Microsoft 365 SMTP

構成手順:

  • SPF、DKIM、カスタムドメイン認証をサポートするプロバイダーを選択する。
  • 信頼できるSMTPプラグインをインストールして構成する。
  • Fromアドレスをあなたが管理するドメインに設定する。
  • プロバイダーのSPFおよびDKIM DNSレコードを追加する。
  • Gmail、Outlook、その他のプロバイダーにテストメッセージを送信する。
  • SPF、DKIM、DMARC整合性を確認する。
  • WooCommerceおよびプラグインで生成されたメールのDMARCレポートを監視する。

WooCommerce SMTPプロバイダーのSPFレコードの例:

v=spf1 include:spf.yourprovider.example ~all

DKIMレコード形式の例:

selector._domainkey.yourstore.com TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"

これらの例はプレースホルダーです。メールプロバイダーが提供する正確なレコードを使用してください。

XII. ステップ7:Eコマースメールコンテンツを保護する

メール認証はドメインIDを保護しますが、マーチャントはメール内の機密データの露出も減らすべきです。

良い慣行には以下が含まれます:

  • メールに完全なカード番号を含めない。
  • 不要な支払い詳細を公開しない。
  • 必要に応じてマスクされた支払い参照を使用する。
  • 機密性の高いアカウントアクションのために顧客を安全なポータルに誘導する。
  • 疑わしいまたは一貫性のないログインリンクを避ける。
  • 一貫したブランディングと送信者アドレスを使用する。
  • 注文および返金メールを明確かつ予測可能に保つ。
  • プラグイン変更後にメールテンプレートを確認する。
  • テンプレートから不要な顧客データを削除する。
  • 内部アラートに機密性の高い管理者詳細を含めることを避ける。

PCI DSSの整合性のために、メールは機密性の高い支払いデータが不必要に公開されるチャネルになるべきではありません。

XIII. ステップ8:DMARC強制に向けて進む

監視は最終目標ではありません。

正当な送信者が特定され整合したら、ストアは強制に向かって進むべきです。

実用的な道筋:

  1. DMARC監視から始める。
  2. すべての正当な送信者を特定する。
  3. SPFおよびDKIM整合性ギャップを修正する。
  4. Shopifyアプリ、WooCommerceプラグイン、サードパーティツールを確認する。
  5. リスクの低いサブドメインをp=quarantineに移行する。
  6. 影響を監視する。
  7. 準備ができたらメインドメインをp=quarantineに移行する。
  8. 持続的な信頼の後に成熟したドメインをp=rejectに移行する。

強制の前に確認する:

  • 注文確認がDMARCをパスする。
  • パスワードリセットメールがDMARCをパスする。
  • カスタマーサポートメールがDMARCをパスする。
  • マーケティングメールがDMARCをパスするか、別の認証されたドメインを使用する。
  • サードパーティアプリが文書化されている。
  • ベンダーが整合している。
  • ロールバック手順が存在する。
  • DMARCレポートが積極的に監視されている。

主要な戦略としてパーセンテージベースのロールアウトに依存することは避けてください。現在のDMARC対応プログラムは、ドメイン、サブドメイン、送信者グループ、ビジネス機能によって強制をステージングする必要があります。

XIV. ステップ9:MTA-STSとTLS-RPTを追加する

DMARCは送信者認証を保護します。メールサーバー間の暗号化されたトランスポートを強制するものではありません。

MTA-STSとTLS-RPTは、トランスポート層を強化するのに役立ちます。

MTA-STSにより、ドメインは、ドメインへのメールを配信する際にサポートするメールサーバーがTLSを使用することを要求するポリシーを公開できます。

TLS-RPTは、TLS配信の問題に関するレポートを提供します。

Eコマースマーチャントにとって、これらの制御は、アカウント、サポート、注文、および運用コミュニケーションのためのより強力なメール信頼態勢をサポートできます。

MTA-STSポリシーの例:

version: STSv1
mode: enforce
mx: mail.yourstore.com
max_age: 86400

TLS-RPTレコードの例:

_smtp._tls.yourstore.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

これらは慎重に実装し、強制前にテストする必要があります。

XV. ステップ10:PCI DSS証拠を維持する

メール認証は、より広範なセキュリティプログラムの一部として文書化されるべきです。

有用な証拠には以下が含まれる場合があります:

  • ドメインインベントリ
  • 送信者インベントリ
  • SPF、DKIM、DMARCレコード
  • MTA-STSおよびTLS-RPTレコード
  • DMARC監視レポート
  • 認証パス/失敗トレンド
  • 未承認送信者の調査
  • サードパーティ送信者レビュー
  • DNS変更記録
  • インシデント対応手順
  • メールセキュリティテスト結果
  • ベンダー文書
  • セキュリティ意識とフィッシング保護証拠
  • 強制ポリシー履歴

PCI DSSの議論のために、最も安全な表現は次のとおりです:

「メール認証は、組織のより広範なPCI DSSセキュリティプログラム内でフィッシング対策、ドメイン保護、コミュニケーションの整合性制御をサポートします。」

DMARC単独でPCI DSSを満たすと主張することは避けてください。

XVI. 監視とレビュースケジュール

Eコマース環境は絶えず変化します。

新しいアプリがインストールされます。マーケティングプラットフォームが変更されます。プラグインが更新されます。SMTPプロバイダーがインフラストラクチャをローテーションします。エージェンシーがキャンペーンを開始します。スタッフが新しいツールを接続します。

レビュースケジュールは、ドリフトを防ぐのに役立ちます。

毎週

  • DMARC認証失敗を確認する。
  • 未知の送信ソースをチェックする。
  • 注文とパスワードリセットメールの配信問題を確認する。
  • 送信量の突然の変化を調査する。

毎月

  • メールを送信するサードパーティアプリとプラグインを確認する。
  • SPF includeを検証し、使用されていないサービスを削除する。
  • 主要な送信者のDKIM整合性を確認する。
  • DMARC強制準備状況を確認する。

四半期ごと

  • DNSレコードを検証する。
  • ベンダーアクセスと送信者インベントリを確認する。
  • 重要なメールフローをテストする。
  • インシデント対応手順を確認する。
  • コンプライアンス文書を更新する。

年1回

  • メールセキュリティリスクを再評価する。
  • PCI DSS証拠を確認する。
  • すべてのドメインとサブドメインを検証する。
  • データ保持とレポート処理を確認する。
  • 強制態勢が適切なままであることを確認する。

XVII. 避けるべき一般的な間違い

Eコマースマーチャントはしばしば同じ間違いを犯します。

これらを避けてください:

  • DMARCを公開してもレポートを確認しない。
  • 無期限にp=noneを使用する。
  • プライバシーレビューなしにruf=を有効にする。
  • ShopifyアプリがShopify認証を継承すると仮定する。
  • WooCommerceプラグインが認証されたSMTPをバイパスすることを許可する。
  • SPF includeを追加しすぎて検索制限を超える。
  • 古いキャンペーンまたは地域ドメインを忘れる。
  • セグメンテーションなしにすべてのトランザクションおよびマーケティングメールに同じドメインを使用する。
  • パスワードリセットと注文メールが整合する前に強制に移行する。
  • DMARCを配信可能性の修正のみとして扱う。
  • DMARC単独でPCI DSSを満たすと主張する。

これらの間違いは不必要なリスクを生み出します。

XVIII. Skysnag ProtectがEコマースマーチャントをどのように助けるか

Skysnag Protectは、Eコマースビジネスが複雑な送信環境全体でDMARC、SPF、DKIM、MTA-STS、TLS-RPT、強制準備状況を管理するのを支援します。

ShopifyおよびWooCommerceマーチャントに対して、Skysnag Protectは以下をサポートします:

  • DMARC監視
  • 無料DMARCレコード生成
  • 送信者発見
  • 未承認送信者検出
  • SPFおよびDKIM整合性の可視性
  • サードパーティアプリとベンダーレビュー
  • サブドメインの可視性
  • 強制準備状況追跡
  • MTA-STSおよびTLS-RPTサポート
  • コンプライアンス向けレポート
  • セキュリティレビューと監査の証拠

XMLレポートを手動で解析したり、どのベンダーがメールを送信しているかを推測したりする代わりに、マーチャントはどのソースが正当で、どれが失敗しており、どのドメインが強制の準備ができているかを確認できます。

Skysnagを使用してDMARC監視を開始し、無料DMARCレコードを取得してください:

Skysnag Protectの詳細については、こちらをご覧ください:

プロテクト

XIX. 実装チェックリスト

この実用的な出発点としてこのチェックリストを使用してください。

  • [ ] ストアで使用されるすべてのドメインとサブドメインをインベントリする。
  • [ ] メールを送信するすべてのShopifyアプリ、WooCommerceプラグイン、サードパーティプラットフォームを特定する。
  • [ ] 各送信者のビジネスオーナー、メッセージタイプ、重要度を文書化する。
  • [ ] 承認された送信者のみのSPFを構成する。
  • [ ] SPF DNS検索制限を確認する。
  • [ ] Shopify、WooCommerce SMTPプロバイダー、サードパーティ送信者のDKIMを有効にする。
  • [ ] 少なくとも1つの認証方法が可視Fromドメインと整合していることを確認する。
  • [ ] Skysnagまたはその他の監視されたレポート宛先を通じてDMARC監視を開始する。
  • [ ] プライバシー、法律、セキュリティチームが承認しない限り、フォレンジックレポートを避ける。
  • [ ] 注文確認、パスワードリセット、返金、サポートメールを確認する。
  • [ ] DMARCに失敗する正当な送信者を修正する。
  • [ ] 成熟したドメインをp=quarantineに向けて移行する。
  • [ ] 正当なメールが一貫して整合したらp=rejectに移行する。
  • [ ] 適切な場合にMTA-STSおよびTLS-RPTを実装する。
  • [ ] PCI DSSセキュリティレビューのための文書を維持する。
  • [ ] 認証態勢を定期的に確認する。

XX. 主要なポイント

ShopifyとWooCommerceのマーチャントは、注文確認、アカウントアクセス、サポート、返金、配送更新、顧客コミュニケーションのために信頼できるメールに依存しています。

PCI DSSはDMARC、SPF、またはDKIMを名前で義務付けていませんが、メール認証は、より広範なPCI DSSセキュリティプログラム内でフィッシング対策、ドメイン保護、ベンダー監視、コミュニケーションの整合性目標をサポートできます。

Shopifyマーチャントは、カスタムドメイン認証とサードパーティアプリの送信動作を確認する必要があります。

WooCommerceマーチャントは、認証されたSMTPまたはトランザクションメールプロバイダーを使用し、重要な顧客コミュニケーションのためにデフォルトのWordPressメールに依存することを避けるべきです。

DMARC監視は、最終状態ではなく、出発点であるべきです。

重要なストアドメインの長期的な目標は、正当な送信者が整合したら、p=quarantineまたはp=rejectを通じた強制であるべきです。

Eコマースビジネスにとって、メール認証は単なる技術的なDNSタスクではありません。それは、支払い体験に関する顧客の信頼を保護することの一部です。

Skysnagを使用してDMARC監視を開始し、無料DMARCレコードを取得してください: