お客様またはお客様の組織が制限的なファイアウォールまたはプロキシサーバー設定を使用している場合、お客様またはネットワーク管理者は、Adobe Marketo Engage が期待通りに動作するように、特定のドメインおよび IP アドレス範囲を許可する必要が生じる場合があります。
以下のプロトコルの実装に関しては、この記事を IT 部門と共有してください。 を使用して Web アクセスを制限する場合許可リストに加えるは、次のドメイン(アスタリスクを含む)を追加して、すべてのMarketoリソースおよび Web ソケットを許可してください。
*.marketo.com
*.marketodesigner.com
*.mktoweb.com
*.experience.adobe.com
*.adobe.net
トラッキングリンク CNAME
マーケティングチームから、新しい CNAME レコードに関する 2 件のリクエストが送信されているはずです。1 件目はランディングページの URL 用です。これにより、ランディングページは、Marketo(実際のホスト)ではなく、顧客のドメインを反映した URL で表示されます。2 件目は、Marketo から送信されるメールに含まれるトラッキングリンク用です。
1
ランディングページ用の CNAME の追加
[YourLandingPageCNAME]
が Marketo のランディングページに割り当てられた一意のアカウント文字列を指すように、DNS レコードに送信したランディングページ CNAME を追加します。ドメイン登録機関のサイトにログインし、ランディングページの CNAME とアカウント文字列を入力します。通常、これには 3 つのフィールドが含まれます。
[YourLandingPageCNAME]
と入力します(マーケティングから提供)。[MunchkinID].mktoweb.com
と入力します(マーケティングから提供)。2
メールトラッキングリンク用の CNAME の追加
[YourEmailCNAME]
が Marketo が割り当てたデフォルトのトラッキングリンク [MktoTrackingLink] を以下の形式で指すように、送信されたメール CNAME マーケティングを追加します。
[YourEmailCNAME].[YourDomain].com
CNAME 内 [MktoTrackingLink]
例:
pages.abc.com IN CNAME mkto-a0244.com
[MktoTrackingLink]
は、デフォルトのブランディングドメインである必要があります。
3
マーケティングチームに通知する
このプロセスが完了したら、マーケティングチームに通知します。
4
SSL 証明書のプロビジョニングプロセスを開始するには、Marketo サポートにお問い合わせください。
プロセスが完了するまでに最大で 3 営業日かかります。
Marketo を使用してテストメールを送信する(メールの破棄を送信する前のベストプラクティス)と、メールが有効であることを検証するために送信者の IP アドレスに依存するスパム対策システムによってテストメールがブロックされる場合があります。これらのテスト用のメールが届くようにするには、許可リストに Marketo を追加します。
以下の IP アドレスを会社の許可リストに追加します。
94.236.119.0/26
103.237.104.0/22
130.248.172.0/24
130.248.173.0/24
130.248.244.88/29
185.28.196.0/22
192.28.144.0/20
192.28.160.0/19
199.15.212.0/22
一部のスパム対策システムでは、許可リストの IP アドレスの代わりにメールの Return-Path フィールドを使用します。Marketo は複数のメールボックスサブドメインを使用するので、このような場合の最善の方法は「*.mktomail.com」を許可リストに追加することです。その他のスパム対策システムは送信元アドレスに基づいて許可リストに登録します。このような状況では、マーケティンググループがユーザーやリードとの通信に使用するすべての送信(「From」)ドメインを必ず含めてください。
Postini は独自のテクノロジーを採用しており、IP 範囲を許可リストに加えることが必要です。Postini での許可リストへの登録を参照してください。
また、DNS リソースレコード(以下にも示す)に追加する DKIM(ドメインキー識別メール)情報もマーケティングチームから送信されている必要があります。 次の手順に従って DKIM および SPF(Sender Policy Framework) を正しく設定し、更新されたことをマーケティングチームに通知します。
SPF を設定するには、DNS エントリに以下の行を追加します。
[CompanyDomain]
IN TXT v=spf1 mx ip4:[CorpIP]
include: mktomail.com ~all
DNS エントリに既に SPF レコードが存在する場合は、以下のコードを追加します。
include: mktomail.com
CompanyDomain を Web サイトのメインドメイン(例:(company.com/)
)で置き換え、CorpIP を会社のメールサーバーの IP アドレス(例:255.255.255.255)で置き換えます。Marketo を通じて複数のドメインからメールを送信する場合は、IT スタッフに各ドメインに対してこの行を(1 行で)追加してもらう必要があります。
DKIM の場合は、設定するドメインごとに DNS リソースレコードを作成します。 署名する各ドメインのホストレコードと TXT 値を以下に示します。
[DKIMDomain1]
:ホストレコードが [HostRecord1]
で、TXT 値が [TXTValue1]
です。
[DKIMDomain2]
:ホストレコードが [HostRecord2]
で、TXT 値が [TXTValue2]
です。
設定した DKIMDomain ごとに HostRecord と TXTValue をコピーします。 こちらの説明. IT スタッフがこの手順を完了したら、必ず管理者/メール/DKIM で各ドメインを確認してください。
DMARC(Domain-based Message Authentication, Reporting & Conformance) は、組織がドメインを不正使用から保護するのに役立つ認証プロトコルです。 DMARC は、SPF や DKIM などの既存の認証プロトコルを拡張し、ドメインで認証に失敗した場合に受信者が実行するアクションを受信者サーバーに通知します。 DMARC は現在オプションですが、組織のブランドとレピュテーションをより良く保護するため、強くお勧めします。 Googleや Yahoo などの主なプロバイダーは、2024 年 2 月以降、一括送信者に対して DMARC を使用する必要があります。
DMARC が機能するには、次の DNS TXT レコードの少なくとも 1 つが必要です。
さらに、FROM: Domain に対して DMARC 固有の DNS TXT レコードが必要です。 必要に応じて、選択した電子メールアドレスを定義して、組織内で DMARC レポートを配置する場所を指定し、レポートを監視できます。
ベストプラクティスとして、DMARC ポリシーを p=none から p=quarantine にエスカレートし、p=reject にエスカレートして DMARC の潜在的な影響を理解し、DMARC ポリシーを SPF と DKIM に緩和的に連携するように設定することを、DMARC の実装を徐々に展開することをお勧めます。
DMARC レポートを受け取るように設定されている場合は、次の操作を行う必要があります。
I.受信および使用するフィードバックおよびレポート (p=none) を分析します。これは、受信者に対して、認証に失敗したメッセージに対して何も実行せず、まだ送信者に電子メールレポートを送信するように指示します。
2. 正当なメッセージが認証に失敗する場合は、SPF/DKIM の問題を確認および修正します。
三。 SPF または DKIM が整列し、すべての正当な E メールに認証を渡しているかどうかを確認します。
四位 レポートをレビューして、SPF/DKIM ポリシーに基づいて期待される結果であることを確認します。
ポリシーを (p=quarantine) に調整します。これは、受信側の E メールサーバーに対し、認証に失敗した E メールを強制隔離するよう伝えます(これは通常、これらのメッセージをスパムフォルダーに配置することを意味します)。
I.レポートをレビューし、期待通りの結果が得られるかを確認します。
p=quarantine レベルでのメッセージの動作に満足している場合は、(p=reject) にポリシーを調整できます。 p=reject ポリシーは、認証に失敗したドメインの E メールを受信者に対して完全に拒否(バウンス)するように指示します。 このポリシーを有効にすると、ドメインで 100%認証された電子メールのみがインボックスに配置される機会を得ることができます。
このポリシーを使用する際は慎重に行い、組織に適しているかどうかを判断してください。
DMARC は、SPF/DKIM に失敗した E メールに関するレポートを受け取る機能を備えています。 送信者が DMARC ポリシーの RUA/RUF タグを通じて受信できる認証プロセスの一環として、ISP サービス担当者が生成する 2 つの異なるレポートがあります。
集計レポート (RUA):GDPR(一般データ保護規則)の影響を受けやすい PII(個人を特定できる情報)が含まれていません。
フォレンジックレポート (RUF):GDPR に影響を受ける電子メールアドレスが含まれます。 を利用する前に、GDPR に準拠する必要がある情報の処理方法を内部で確認することをお勧めします。
これらのレポートの主な使用方法は、スプーフィングを試行した電子メールの概要を受け取ることです。 これらは、サードパーティのツールを通じて最もよく消化される、非常に技術的なレポートです。
最小レコード数: v=DMARC1; p=none
レポートを受け取る電子メールアドレスにリダイレクトするレコード: v=DMARC1; p=none; rua=mailto:emaill@domain.com; ruf=mailto:email@domain.com
DMARC レコードには、DMARC タグと呼ばれる複数のコンポーネントが含まれます。 各タグには、DMARC の特定の側面を指定する値が含まれます。
タグ名 | 必須/オプション | 機能 | 例 | デフォルト値 |
---|---|---|---|---|
v | 必須 | この DMARC タグは、バージョンを指定します。 現時点では 1 つのバージョンのみなので、v=DMARC1 の固定値になります。 | V=DMARC1 DMARC1 | DMARC1 |
p | 必須 | 選択された DMARC ポリシーを表示し、認証チェックに失敗したメールをレポート、強制隔離、または拒否するよう受信者に指示します。 | p=なし、強制隔離または却下 | - |
~に対して | 任意 | ドメイン所有者がレポートオプションを指定できるようにします。 | 0:すべてが失敗した場合にレポートを生成
1:何か失敗した場合にレポートを生成 d:DKIM が失敗した場合にレポートを生成 s:SPF に失敗した場合にレポートを生成する |
1 (DMARC レポートに推奨) |
pct | 任意 | フィルタリングの対象となるメッセージの割合を示します。 | pct=20 | 100 |
rua | オプション(推奨) | 集計レポートが配信される場所を識別します。 | rua=mailto:aggrep@example.com | - |
ruf | オプション(推奨) | 法医学レポートがどこに配信されるかを識別します。 | ruf=mailto:authfail@example.com | - |
sp | 任意 | 親ドメインのサブドメインに対して DMARC ポリシーを指定します。 | sp=reject | - |
アドキム | 任意 | Strict (s) または Relaxed ®のいずれかです。 緩和された整列とは、DKIM 署名で使用されるドメインが「送信者」アドレスのサブドメインになる可能性があることを意味します。 厳密に整列させると、DKIM 署名で使用されるドメインは、送信元アドレスで使用されるドメインと完全に一致する必要があります。 | adkim=r | r |
aspf | 任意 | Strict (s) または Relaxed ®のいずれかです。 緩和された配置とは、ReturnPath ドメインが From Address のサブドメインになることを意味します。 厳密に整列すると、Return-Path ドメインは From アドレスと完全に一致する必要があります。 | aspf=r | r |
DMARC とそのすべてのオプションについて詳しくは、 https://dmarc.org/.
DMARC には、DKIM の調整と SPF の調整の 2 種類があります。
Marketoの DKIM と SPF で DMARC の連携を行うことをお勧めします。
DKIM-aligned DMARC - DKIM aligned DMARC を設定するには、次の操作を行う必要があります。
DMARC-aligned SPF — ブランドの Return Path を使用して DMARC aligned SPF を設定するには、次の手順を実行する必要があります。
ブランドの Return-Path ドメインの設定
ブランドの Return-Path ドメイン用の DMARC の設定
専用の IP 経由でMarketoからメールを送信する場合で、ブランドのリターンパスをまだ実装していない場合、または既に実装しているかどうかわからない場合は、 Marketoサポート.
Marketoから IP の共有プールを通じてメールを送信する場合は、次の方法で信頼済み IP に該当するかどうかを確認できます。 ここに適用. Marketoの信頼済み IP から送信されるユーザーには、ブランド化された Return Path が無料で提供されます。 このプログラムが承認された場合は、Marketoサポートに連絡して、ブランドの Return Path を設定してください。
Marketoから共有 IP 経由でメールを送信する場合で、信頼済み IP の条件を満たさず、1 ヶ月に 10 万件を超えるメッセージを送信する場合は、Adobeアカウントチーム(アカウントマネージャー)に連絡して専用 IP を購入する必要があります。
Marketo内では、厳密な SPF 調整はサポートされておらず、推奨もされていません。
MX レコードを使用すると、返信や自動返信を処理するために、メールを送信するドメインにメールを受け取ることができます。会社ドメインから送信する場合は、既にこの設定が完了している可能性があります。そうでない場合は、通常、会社ドメインの MX レコードにマッピングするように設定できます。
アウトバウンド接続とは、Marketo Engage がお客様に代わってインターネット上のサーバーに接続するものです。取引先のパートナー/ベンダー、またはご自身の IT 組織では、サーバーへのアクセスを制限するために許可リストを使用する場合があります。その場合、Marketo Engage のアウトバウンド IP アドレスブロックを提供し、許可リストに追加してもらう必要があります。
Webhook
スマートキャンペーンの一環として、Marketo Engage Webhook are an outbound integration mechanism. When a Call Webhook フローアクションが実行されると、外部 web サービスに HTTP リクエストが行われます。Web サービス公開者が、外部の web サービスが存在するネットワークのファイアウォールで許可リストを使用している場合、公開者は以下に示す IP アドレスブロックを許可リストに追加する必要があります。
CRM 同期
Marketo Engage Salesforce CRM 同期 and Microsoft Dynamics Syncは、CRM ベンダーによって公開された API に対して送信 HTTP リクエストを行う統合メカニズムです。お客様の IT 組織が、以下の IP アドレスブロックのいずれからも CRM ベンダーの API へのアクセスをブロックしていないことを確認する必要があります。
Marketo Engage アウトバウンド IP アドレスブロック
以下の表は、アウトバウンドコールを行うすべての Marketo Engage サーバーを対象としています。IP 許可リスト、サーバー、ファイアウォール、アクセス制御リスト、セキュリティグループ、またはサードパーティサービスが Marketo Engage からの発信接続を受信するように設定している場合は、以下のリストを使用します。
IP ブロック(CIDR 表記) |
---|
94.236.119.0/26 |
103.237.104.0/22 |
130.248.172.0/24 |
130.248.173.0/24 |
130.248.244.88/29 |
185.28.196.0/22 |
192.28.144.0/20 |
192.28.160.0/19 |
199.15.212.0/22 |
個別の IP アドレス |
---|
13.237.155.207 |
13.55.192.247 |
18.200.201.81 |
34.247.24.245 |
35.165.244.220 |
44.235.171.179 |
52.20.211.99 |
52.64.109.86 |
54.160.246.246 |
54.212.167.17 |
54.220.138.65 |
54.237.141.197 |
130.248.168.16 |
130.248.168.17 |