Sender Policy Framework (SPF) レコードを使用したメール配信を有効にして SN メールサーバーを許可Issue 会社が未知の IP アドレスからのメール配信を防止している場合や、IP アドレスに基づいてスパムをフィルタリングするサービスを使用している場合は、ServiceNow の Sender Policy Framework (SPF) レコードを使用してそれらのサービスを設定できます。ServiceNow は、なりすまし防止やスパム検出を支援する SPF レコードを提供しています。会社のメールインフラストラクチャが、後述する業界標準に沿って設定されていることを確認してください。これにより、ServiceNow インスタンスから会社のメールサービスへのメール配信が中断されることなく継続されます。 送信者ポリシーフレームワークはRFC4408の下で標準化されています。詳細については、OpenSPFのWebサイトをご覧ください。http://www.openspf.org/FAQhttp://www.ietf.org/rfc/rfc4408.txt ServiceNow メールサーバーの IP は、インスタンスが送信メールに ServiceNow 提供の SMTP アカウントを使用している場合にのみ使用されます。インスタンスが代わりにカスタム SMTP を使用している場合は、[VPN なしの顧客ネットワークへの統合に使用されるソースアドレス] の下にリストされているノード IP が使用されます。IP アドレス情報 - アクセスと統合 一方、インスタンスからの送信メールの 99.9% はその地域のメールサーバーを使用し (つまり、EMEA インスタンスは c.spf を使用します)、ServiceNow のメールサーバーは相互にバックアップします。つまり、1 つのデータセンターでキャパシティ/接続の問題がある場合、メールは別の DC 経由でルーティングされます (つまり、EMEA インスタンスは一時的に b.spf または d.spf を使用します)。 これは内部通知または公開通知なしに行われ、単一のインスタンス/顧客に対してこれを無効にする方法はありません。お客様は、SPFレコード 3つすべて を許可リストに登録することをお勧めします。IP は頻繁に削除されるか、許可リストに追加される場合があります。リストを検査する必要がある場合は、dig コマンドを使用して、次の結果を使用します。 dig b.spf.service-now.com dig c.spf.service-now.com dig d.spf.service-now.com 管理者が Windows を使用しているために dig コマンドにアクセスできない場合、URL http://mxtoolbox.com/spf.aspx で dig <domain> TXT +short と同じ出力を提供できます。ResolutionServiceNow では、SPF レコードを自動的に取得するメールサーバーの機能を使用して、SPF レコードを動的に使用するようにメールシステムを構成することを強くお勧めします。ServiceNow がインスタンスを別のデータセンターに移動しても、メールサーバーは引き続きインスタンスからメールを受信できます。 SPF TXTレコードの長さに関して問題が発生した場合は、 https://repost.aws/knowledge-center/route-53-configure-long-spf-txt-records 以下を確認してください。 代替ソリューション SPF レコードを動的に使用するようメールサーバーを構成できない場合は、メール管理者またはシステム管理者と協力して一連の dig ターミナルコマンドを使用し、手動で SPF レコードデータを収集して、許可リストを作成する必要があります。 必要なスキル： SPF レコード形式に関する知識dig または同様のDNSツール。 警告：ServiceNow は、SPF レコード構造と返されるホストまたは IP を変更する権利を留保します。これにより、実行しなければならないコマンドに影響が出たり、時間の経過とともに許可リストが古くなり、メールの問題が発生したりする可能性があります。 このような更新が行われることはめったにありませんが、可能性がないわけではありません。定期的な手動または自動プロセスを実装し、収集した SPF データを許可リストと照合する必要があります。メールの問題を回避するため、定期的に許可リストを更新してください。 例： この例では、最初に dig コマンドを発行し、応答の構造に応じて追加のクエリを発行して、ホストと IP を特定します。 警告：これはコマンドと戻り値の一例に過ぎません。システムメール管理者と協力して初期クエリを実行し、この KB 記事を読んだときと同様に SPF レコードデータに従って IP アドレスを収集します。 現在の SPF レコード TXT レコードに対する service-now.com ドメインの初期クエリから開始します。 dig service-now.com TXT +short この KB 記事の執筆時点で、このコマンドは 3 つの a: レコードを含む次のデータを返しました。 "v=spf1 a:b.spf.service-now.com a:c.spf.service-now.com a:d.spf.service-now.com" 応答内の太字の項目は、それぞれメールサーバーのグループを示します (サーバーの場所に基づいています)。 b.spf.service-now.com - Canada DCsc.spf.service-now.com - US/Europe DCsd.spf.service-now.com - all other DCs service-now.com ドメインのメールサーバーの IP アドレスリストは、上記の各ドメインの DNS A レコードで利用できます。そのため、dig コマンドを使用してそれらをリストアップするには、次のように実行します。 dig A b.spf.service-now.com +short # Canada DCsdig A c.spf.service-now.com +short # US/Europe DCsdig A d.spf.service-now.com +short # all other DCsインスタンスの場所にかかわらず、許可リストで 3 つの結果すべてを使用 してください。ServiceNow は、任意のデータセンターを介してメールトラフィックを再ルーティングする場合があります。 SPF クエリツール： SPFレコードをテストするためのツールは、 http://www.kitterman.com/spf/validate.htmlなど、数多くあります。 「Is this SPF record valid - syntactically correct? (この SPF レコードは有効ですか、構文的に正しいですか)」セクションでは、新しい SPF レコードが構文的に正しいかどうか、および (実際に DNS に公開する前に) 10 回以上の DNS ルックアップを必要とするかどうかをテストできます。 2 番目の代替ソリューション SPF レコードを動的に使用するようにメールサーバーを構成できず、ServiceNow SPF レコードのクエリに必要なツールを使用できない場合は、次の DNS クエリを実行し、結果の IP を使用して、許可リストで ServiceNow メールサーバーの IP アドレスを静的に定義してください。ServiceNow は今後、これらのレコードに IP アドレスを追加または削除する可能性があることに注意してください。 最新の IP アドレスリストを取得するには、dig コマンドを使用します。 dig A b.spf.service-now.com +short # Canada DCsdig A c.spf.service-now.com +short # US/Europe DCsdig A d.spf.service-now.com +short # all other DCs *インスタンスの場所に関係なく、許可リストにある 3 つのレコードのすべての IP を使用してください。ServiceNow は、可用性を維持するために 任意のデータセンターを介してメールトラフィックを再ルーティングする場合があります。 特別なケース - ハイブリッド シンガポールのお客様のみ: シンガポールのハイブリッドインスタンスでは、送信 SMTP アカウントに @service-now.com ではなく、 @sg.service-now.comを設定する必要があります。 sg.service-now.com には別のSPFレコードがあります。 "v=spf1 a:spf.sg.service-now.com -all" 注:これは service-now.com SPFレコードとは異なります。 $ host spf.sg.service-now.com spf.sg.service-now.com has address 149.96.220.3 spf.sg.service-now.com has address 149.96.221.3 これらのIPアドレスが変更された場合、その変更はSPFレコードに反映されますが、IPが変更される可能性は低いです。 注:データセンターで変更が行われた後も古い SPF レコードを引き続き使用している場合、ServiceNow は一切の責任を負いません。