ServiceNowのメール送受信機能の基本的な動きと、メールサーバやメールセキュリティといったインフラ面での詳細、またメール送受信を管理するための各種テーブルについて説明します。メール送信の設定を行うNotificationについては、範囲外とします。
メール送受信の基本
まずは、標準設定の場合のメール送受信の流れを説明します。仕組みとしては、SMTP/POP3を用いた一般的なものです。
メール送信の流れ
メール送信の流れは次の通りです。
- Emailテーブルへのレコード作成
Notification（通知）などの各種機能でメール送信が必要になると、Emailテーブルにメールの受信者やタイトル、本文の情報を含むレコードが送信待ち状態で生成されます。 - Emailレコードの内容をもとにメールを送信
インスタンスは定期的にEmailテーブルをチェックし、送信待ちになっているレコードがあれば、その内容をもとにServiceNowのメールサーバを用いてメールを送信します。 - 送信先(受信側)のメールサーバへ転送
ServiceNowのメールサーバは送信先（受信側）のメールサーバへメールを転送します。 - メールクライアントがメールを受信
Outlookなどのメールクライアントが送信先（受信側）のメールサーバに問合せを行い、メールを受信します。
メール受信の流れ
メール受信の流れは次の通りです。送信時と逆の流れになっているだけです。
- メールクライアントからメールを送信
Outlook等のメールクライアントから、送信元のメールサーバを用いてメールが送信されます。 - ServiceNowのメールサーバへ転送
送信元のメールサーバはServiceNowのメールサーバへメールを転送します。 - 当該インスタンス宛てのメールを受信
インスタンスは定期的にメールサーバに問合せ、当該インスタンス宛てのメールを受信します。 - Emailテーブルへのレコード作成
らメールが受信されると、Emailテーブルにメールの送信元やタイトル、本文などの情報を含むレコードが作成されます。
Emailテーブル作成されたレコードは、フィルタリングが行われ後、Inbound Email Actionなどの各種機能によって利用されます。
メール送受信に関わるインフラ側のアーキテクチャ詳細
ここからは、ServiceNow側のメール送受信に関するアーキテクチャの詳細を説明します。まずは、インフラ回りを見ていきます。
メールサーバ
標準設定の場合、メールの送受信にはServiceNowのメールサーバが利用でき、ユーザ側でメールサーバを立てる必要はありません。
社外（顧客）向けにServiceNowからメールを送信することがあり、その際に自社ドメインのメールアドレスを使いたいといった場合には、ユーザ側で指定したメールサーバを利用してメールの送受信を行うこともできます。
ServiceNowのメールサーバを利用する（標準設定の）場合
ServiceNowのメールサーバを用いる場合、@service-now.comドメインで固定で、メールアドレスは<インスタンス名>@service-now.comとなります。
なお、以前は個人Developerインスタンス（PDI）でもメールが利用できましたが、 2023年4月現在、Developerインスタンスのメール送受信は無効化されているようです（参考: CHANGES TO SENDING EMAILS FROM PDIS）。スパムメールの送信に利用されてしまったためとのことですが、物議をかもしており、本記事公開後仕様が変更になる可能性があるため最新の情報をご確認ください。
ユーザ側で指定したメールサーバを利用する場合
インスタンスに利用するメールサーバのSMTP/POP3/IMAPアカウントを登録しておくことで、ユーザ側で指定したメールサーバを利用するように設定できます。
送信の場合を例にすると、この場合の流れは下図の通りです。
処理の流れは特に変わりませんが、受信者から見たときの送信元アドレスをユーザ企業のドメインのアドレスにすることができます。
ServiceNowは社内システムとして利用されることが多いですが、Customer Service Management (CSM)モジュールなどで社外（顧客）向けに利用される場合は、標準設定だと@service-now.comという謎のドメインからメールが送信されることになり、顧客への説明や迷惑メールに分類されないようにするための設定依頼が必要になるため、既に社外（顧客）向けのメールに利用しているドメインを使いたいという場合があるでしょう（私がこの設定を実際に使った経験が無いため、有識者の方がいれば利用目的についてコメントをいただければと思います）。
また、標準設定の場合は送信先(受信側)メールサーバでServiceNowドメインからのメール受信を許可するだけでよいのに対し、ユーザ指定のメールサーバを利用する場合は指定のサーバのアカウントをインスタンスに登録する必要があり、またServiceNowからそのアカウントを用いてメールサーバに直接アクセスされることになるため、この設定を採用する場合はセキュリティ面での考慮も必要でしょう。
メールセキュリティ
ServiceNowのメールサーバを利用する（標準設定の）場合を前提として、適用されている/適用可能なメールセキュリティを説明します。なお、多くの設定はメールサーバに依存するため、ユーザ側で指定したメールサーバを利用する場合はそのサーバの管理者に相談してください。
暗号化（STARTTLS、S/MIME）
ServiceNowでは、メール通信路を暗号化するSTARTTLS及びメール自体を暗号化するS/MIMEに対応しています。
通信路の暗号化（STARTTLS）
DOCSの記載を参考にすると、opportunistic TLS（日和見TLS）、つまり受信側のメールサーバが対応していれば通信の暗号化を行うSTARTTLSに標準で対応していると考えられます。
Encrypt mail with opportunistic TLS (Transport Layer Security) if supported by your mail servers.If your internal mail servers send and receive messages via a TLS-encrypted channel, ServiceNow mail servers support that communication.
ServiceNow DOCS: Basic email setup
メール自体の暗号化（S/MIME）
メール自体を公開鍵暗号方式で暗号化・電子署名するS/MIMEにも対応しています。2023年Utahバージョン時点では標準で有効化されていないため、S/MIME Email (com.glide.email.smime)プラグインを有効化した上で、予めキーペアをインスタンスにインポートしておく必要があります。
受信メールのスパムチェック、ウイルスチェック
ServiceNowが受信するメールは、受信時にスパム・ウイルスチェックが行われ、その結果がメールヘッダに付加されます。例えば、スパムメールとして判定された場合、”X-ServiceNow-Spam-Flag:YES”というヘッダが付加されます。
一点注意すべきなのは、スパムやウイルスに感染していると判定されたとしても、メールはメールサーバでブロックされるわけではなくインスタンスに送信され、後述のフィルタリング機能によってJunk(迷惑メール)に移動されるなどの処置が行われるという点です。
参考: KB0549426: Email Spam Scoring and Filtering
ドメイン認証（SPF、DKIM）
ServiceNowでは、なりすましメール対策として、メールの送信ドメイン認証を行うSPF及びDKIMに対応しています。
SPF (Sender Policy Framework)
ServiceNowから送信されるメールについては、ServiceNowのDNSサーバはが標準でSPFレコードを公開しているため、受信メールサーバで設定を行うことでSPFによるドメイン認証を行うことができます。
参考: KB1080516: SPF レコードを使用したメール配信の有効化による SN メールサーバーの許可
参考: KB0535456: Enabling email delivery using SPF records to allow SN mail servers
ServiceNowが受信するメールについては、上述のスパムチェックにおいてSPFレコードの検証が行われ、ドメイン認証が失敗した場合スパムとしてフラグが立てられます。
参考: KB0755173: SPF が原因でスパムとしてマークされた受信メールが失敗する
参考: KB0755173: Incoming emails marked as SPAM because of SPF fail on them
DKIM (Domainkeys Identified Mail)
ServiceNowから送信されるメールについては、DKIMを有効化することで、電子署名を用いたなりすまし防止・改ざん検知を行うことができます。
参考: KB0695182: Using DKIM for Emails from the service-now.com Domain
送受信ドメイン制限、メールのフィルタリング
メールの送信元や、送信先（受信元）ドメインや、受信メールのタイトルや本文等によるフィルタリングを行うことも可能です。こちらはインスタンス側の設定となるため、インスタンス側のアーキテクチャの章で後述します。
メール送受信に関わるインスタンス側のアーキテクチャ詳細
ここでは、ServiceNow側のインスタンス内のアーキテクチャを見ていきます。
メール送受信に関わるテーブル構造とMailbox(メールボックス)
メール送受信に関わる主なテーブルは、インスタンスが送受信する全てのメールを格納するEmail[sys_emai]テーブルと、添付ファイルを管理するEmail Attachment[sys_email_attachment]です。データモデルは下図のようになっています。なお、Attachment[sys_attachment]テーブルは、メールに限らず、レコードに関する添付ファイルなども含めた添付ファイル全般を格納するためのテーブルであり、メール送受信機能のためだけのテーブルではありません。
ここで、メールを分類するためのフォルダやメールボックスの概念を表すテーブルは存在しないの？と思われるかもしれません。ServiceNowでは、EmailテーブルのMailbox、State、Type項目の値によって、メールが分類されます。ひとまずはMailboxだけ覚えておけばよく、EmailレコードのMailbox(メールボックス)項目の値によって、そのメールが受信箱にあるのか、迷惑メールに分類されたのか、送信済みなのか、が表されます。イメージを下図に示します。
標準では、次の7つのメールボックスが用意されています。
| 区分 | メールボックス | メールの状態 |
|---|---|---|
| Inbound(受信) | Inbox(受信箱) | メールが受信されたが未処理の状態 |
| Inbound(受信) | Received(受信済み) | メールが受信された後、何らかの処理が試みられた状態 次のいずれかの場合にこの状態になります ・Inbound email action(受信メールアクション)などにより処理が完了した場合 ・そのメールを処理するアクションが存在せず処理されなかった場合 ・フィルタによって処理しないと判定された場合 |
| Inbound(受信) | Junk(迷惑メール) | メールが受信された後、フィルタや処理の中で迷惑メールと判定された状態 |
| Outbound(送信) | Outbox(送信箱) | メールが作成され、送信待ちの状態 |
| Outbound(送信) | Sent(送信済み) | 作成されたメールがメールサーバから正常に送信された状態 ※ 宛先まで正常に届いたかは保証していません |
| Outbound(送信) | Skipped(スキップ) | インスタンスによって作成されたメールが送信不可/不要と判断され、未送信となった状態 |
| Outbound(送信) | Failed(失敗) | 作成されたメールがメールサーバによって送信される際にエラーが発生し、未送信となった状態 |
各メールボックスには、メニュー > System Mailboxes (システムメールボックス) > Inbound (インバウンド)またはメニュー > System Mailboxes (システムメールボックス) > Outbound (アウトバウンド)配下のメニューからアクセスできます。メールの一覧にアクセスするための各メニューからは、異なるView（ビュー）とFilter（フィルタ）の組み合わせでEmailテーブルのリストが開かれるように設定されています。
一つのテーブルで異なる見せ方を実現するためのViewについては下記の記事で詳しく説明していますので、あわせてご覧ください。
メールのライフサイクル（処理フロー）
メールの送受信時に、ServiceNowの中でどのような処理が行われるかを見ていきます。
送信メールのライフサイクル
送信メールのライフサイクルについてはDOCS等に完全な記載がないため、各種情報や検証結果をもとに恐らくこうだろうというフローを示します。
Notification（通知）機能などによってメール送信が必要になったとき、まずOutbox(送信箱)に新規のEmailレコードが作成されます。その後、インスタンス側で送信判断が行われ、メール送信対象ユーザのメールアドレスが設定されていない場合など問題があると送信不要/不可と判断され、Skipped(スキップ)に移動されます。送信対象と判断されたメールはメールサーバに送信され、メールサーバ側で正常に送信が完了すればSent(送信済み)へ、失敗すればFailed(失敗)に移動します。
Sent(送信済み)とFailed(失敗)について、私が検証した限りでは、メールサーバからの送信が成功しさえすれば、メールが宛先まで届かずUnreachableやUndeliveredになった場合であってもSentに移動されます。Failed(失敗)に移動するのは、メールサーバにおけるメール送信処理中にエラーがあった場合で、例えば次のKBで示されているようなケースが該当します。
参考: KB0819414: Email send-failed with error string Illegal semicolon, not in group
ServiceNowの仕組み上、メールサーバに送信されるメールはインスタンス側での送信判断の上、Emailレコードをもとに自動で作成されるため、送信失敗になることはめったになく、Outbox(送信箱)のメールは基本的にSent(送信済み)かSkipped(スキップ)に移動します。
Sent(送信済み)だがメールが宛先まで正常に到達しなかった場合は、UnreachableやUndeliveredの自動返信メールがインスタンスに返された結果、受信側のJunk(迷惑メール)にそれらのメールが入っている場合があります。
受信メールのライフサイクル
メールサーバに届いたメールがインスタンスによって引き出されると、まずInbox(受信箱)にEmailレコードが生成されます。その後、メールのフィルタリングやInbound email action(受信メールアクション)等による処理が行われ、Received(受信済み)またはJunk(迷惑メール)に移動します。
Junk(迷惑メール)に分類されるのは、スパムチェック、ウイルスチェックで問題が検出された場合や、ユーザが設定したドメインやメールの内容によるフィルタを通過しなかった場合、メール自体は問題なくてもメールの送信元と同一のメールアドレスを持つユーザがロックアウトや非アクティブの場合などです。詳細は下記のKBを参照ください。
参考: KB0744905: Email moved to Junk folder
受信メールのコンテキスト判定（返信、転送、新規）
ServiceNowがメールを受信した際、そのメールが過去ServiceNowから送信されたメールに対する返信なのか、転送されたものなのか、送信元が新規で送信してきたものなのかを判定する仕組みが存在します。詳細な判定ロジックについては公式ドキュメントに詳細なプロセスフローが載っていたので、こちらを参照ください。
参考: DOCS Criteria for matching email to inbound actions
一般的なシステム用語とは別の意味で使われている、Watermark（透かし）という概念について補足しておきます。標準の設定ではServiceNowから送信されるメールの本文にはWatermark（透かし）と呼ばれる文字列（例: MSG0006027_9lTWgdwmtAIbkwNaVUoL）が付加されます。このとき、Email Watermark[sys_watermark]テーブルにWatermarkとそのメールに紐づくレコードとの対応関係が保持されます。このメールに対して返信が行われると、インスタンスはWatermarkをもとにどのレコードに対するメールかを判定することができます。Watermarkは、付加しないようにすることや、ユーザが誤って消さないようにHTMLメールに埋め込みユーザには見えないようにすることもできます。
参考: DOCS Watermarks on notification emails
メール受信時の送信元ユーザの判定と自動ユーザ作成
ServiceNowがメールを受信した際、メールの送信元アドレスとUserテーブルのEmail（メールアドレス）項目を照合して、送信元のユーザを特定しようとします。
さらに、送信元ユーザの特定に失敗した場合に、ユーザを自動で作成するように設定することができます。この設定を行う場合、ユーザを自動で作成することを許可する送信元ドメインも同時に設定する必要があります。
メールの自動アーカイブと削除
メールの送受信を長期的に運用していくと、インスタンスに保持されるメールの件数が膨大になり、データ容量を圧迫した結果パフォーマンスに影響を与える可能性があります。これを避けるために、メールを自動でアーカイブしたり、古いアーカイブを自動削除する機能が存在します。
2023年4月Uhtaバージョン現在は標準で次のルールが入っているようです。
- 90日以上前に作成され、Type(タイプ)がreceived-ignoredかsent-ignoredのメールをアーカイブ
※ Typeがreceived-ignoredのメールはJunk(迷惑メール)へ、sent-ignoredはSkipped(スキップ)へ分類されるので、迷惑メールや未送信のメールは90日経ったらアーカイブするということです
- 365日以上前に作成されたメールをアーカイブ
- 365日以上前にアーカイブされたメールを削除
まとめると、迷惑メールや未送信のメールは90日、その他のメールは1年経ったらアーカイブされ、さらに、アーカイブ後1年経ったら削除されるということです。
正常に処理されたメールは2年間インスタンスに保持されますが、監査要件等によりより長い期間保持が必要な場合は、アーカイブ設定を変更するか、外部ストレージに定期的に移動しておく必要があります。
なお、この自動アーカイブと削除はメール送受信のための機能ではなく、ServiceNowのプラットフォームの標準機能で、他のテーブルに対しても設定されています。
メール送受信に関わる各種設定
インスタンス上でメール送受信に関わる様々な設定を行うことができます。上記で機能を紹介したものも含め代表的な設定箇所を説明します。
メール送受信可否設定を含む各種メールプロパティ
メニュー > System Mailboxes(システムメールボックス) > Administration(アドミニストレーション) > Email Property(メールプロパティ)からメール送受信可否を含む各種プロパティの設定ができます。代表的なプロパティを紹介します。
ハマりやすい”glide.email.test.user”プロパティ（設定画面で”Send all email to this test email address (non-production testing)”と説明されている設定）について補足しておきます。“glide.email.test.user”プロパティにメールアドレスを設定すると、インスタンスから送信される全てのメールの宛先がこのメールアドレスに書き換わります。Emailテーブル上ではNotification等に設定された（本来送信されるはずの）宛先が設定されていますが、インスタンスからメールサーバに送信されるタイミングで宛先が書き換わるという点に注意が必要です。
なお、複数のメールアドレスを設定する場合は、カンマ区切りで指定します。
Email Account（利用するメールサーバのSMTP/POP3アカウント）
メール送受信時に用いるメールサーバ及びメールサーバSMTP/POP3アカウントの設定はメニュー > System Mailboxes(システムメールボックス) > Administration(アドミニストレーション) > Email Accountsから行います。
標準では、ServiceNowのメールサーバのSMTPおよびPOP3アカウントが登録されています。ユーザ指定のメールサーバを用いる場合は、新たなEmail Accountレコードを作成し、サーバ名、SMTP/POP3/IMAPユーザ名、パスワード、ポート番号などを設定します。
ServiceNowのメールサーバを用いる場合、当然サーバ名やアカウント名を変更することはできませんが、標準で登録されているSMTPアカウントのフォームから、メール受信者がOutlook等のメールクライアントで見るメール送信元を変更することができます。標準では”IT Service Desk”となっているため、変更するのが一般的です。
Filter（送受信メールのフィルタリング）
ServiceNowが送受信するメールに対してフィルタリングを行うことができます。メールのフィルタは、送信元や送信先(受信側)のメールアドレスのドメインによるフィルタ（以下、ドメインベースのフィルタと呼ぶ）と、タイトルや本文に特定の文字が含まれるかといった条件によるフィルタ（以下、条件ベースのフィルタと呼ぶ）が利用できます。
ドメインベースのフィルタ（送信、受信どちらも適用可能）
ドメインベースのフィルタはSystem Maiboxes(システムメールボックス) > Administration(アドミニストレーション) > Email Address Filters(メールアドレスのフィルター)及びSystem Maiboxes(システムメールボックス) > Administration(アドミニストレーション) > System Address Filters(システムアドレスフィルター)から設定できます。
Email Address Filters(メールアドレスのフィルター)で各種ドメインを許可するか拒否するかを指定し、System Address Filters(システムアドレスフィルター)でどのEmail Address Filtersを受信または送信メールに適用するかなどを設定します。標準の受信メールに対する設定を下図に示します。
条件ベースのフィルタ（受信の場合に適用可能）
条件ベースのフィルタは、メニュー > System Maiblxoes(システムメールボックス) > Administration(アドミニストレーション) > Filters(フィルター)から設定ができます。
条件ベースのフィルタの設定は比較的シンプルで、条件と、それに当てはまった場合に無視する(Mark as ignored)か、迷惑メールボックスに送るか(move to Junk)を指定します。標準で設定されているフィルタの一つを下図に示します。
なお、無視する(Mark as ignored)とした場合は、ステータスがIgnoredの状態でReceived(受信済み)に移動されます。
メール本文の最大サイズ、添付ファイルの最大数、添付ファイルの最大サイズの制限
メール本文の最大サイズ、添付ファイルの最大数、添付ファイルの最大サイズを制限するプロパティも存在します。詳細は下記DOCSを参照ください。
これらのプロパティは上述のEmail Propertyのメニューからは設定できないため、下記の記事で解説している方法で設定します。
添付ファイルの最大サイズを制限するプロパティは、メールの添付ファイルのサイズを最大制限するglide.email.inbound.max_total_attachment_size_bytes, glide.email.outbound.max_total_attachment_size_bytesに加え、インスタンス共通で添付ファイルの最大サイズを制限するcom.glide.attachment.max_sizeというプロパティが存在し、こちらがより優先されることに注意が必要です。
メール送受信に関するトラブルシューティング
これまで説明してきたように、メール送受信機能には様々なコンポーネントが関わっているため、様々な原因でメールが想定通り送受信できないことがあります。とはいえ、ServiceNowで送受信されるメールは全てEmailテーブルに格納されるため、メールが想定通り送受信されていない場合は、まずEmailテーブルを確認し、原因を特定していきましょう。
その上で、下記のKB記事にメールに関する各種問題に対する対応方法がまとまっていますので、参照ください。
参考: KB0538136 Troubleshooting email issues with ServiceNow
参考: KB0538135 Troubleshooting email notification failures in ServiceNow
参考: KB0524472 Inbound Email Troubleshooting
また、私の経験上、メール送受信に関する課題はほとんどの場合下記のいずれかが原因ですので、まずはこれらを確認してみるのもよいと思います。
- (送信)Notification(通知)の設定が誤っており、そもそもメールが作られていない
⇒ Emailテーブルにレコードが作成されているかを確認しましょう。レコードが作成されていない場合、Notification(通知)の設定が間違っている可能性が高いです。特に多いのが、Send to event creatorの設定ミスです。Notification(通知)のフォームをAdvanced viewで開いたときのWho will receiveタブから確認できるSend to event creator項目にチェックが入っていない場合、そのメールのトリガ条件になったイベントを発生させた本人宛てのメールは作成されません。この設定が想定通りかを確認しましょう。 - (送信/受信)異なるメールボックスを見ている
⇒ 全てのメールボックスを確認してみましょう - (送信/受信)メールの送受信がOffになっている
⇒ 特にクローンやアップグレード直後は要確認 - (受信)ユーザのメールアドレスが設定されていない
⇒ メールの送信対象のユーザのメールアドレスの設定を確認しましょう
以上です。その他メールに関して追記したほうがよい論点があればコメントいただければと思います。
コメント