オンデマンド出席管理のメール認証ガイド：SPF、DKIM、およびDMARCの設定

主なポイント

SPF、DKIM、DMARCを適切に設定することで、Attendance on Demandから送信される自動レポート、シフトスケジュール、従業員への通知が、スパムフォルダではなく受信トレイに確実に届くようになります。
Attendance on Demand は、公開ドキュメントに汎用的なSPF インクルードやDKIM セレクタを掲載していません。テナント固有の DNS 値を取得するには、パートナーまたはサポート担当者にお問い合わせください。
ドメインにSPF TXTレコードを2つ以上公開しないでください。必ず、ベンダーから提供された仕組みを既存レコードに統合してください。
このプラットフォームでは、DKIMがDMARCアラインメントを実現するための主要な手段として機能することがよくあります。
送信通知に暗号学的署名を行うため、必ず独自のDKIMセレクタを取得してください。
DMARCは段階的に導入すべきです。厳格な適用に移行する前に、まず「p=none」（監視）ポリシーを少なくとも2回の事業サイクルにわたって適用し、頻度の高いメール（月次給与明細など）を捕捉するようにしてください。

組織が「Attendance on Demand」を利用して、企業のドメイン（例：[email protected]）から自動メッセージ（勤怠管理のアラート、例外通知、スケジュールなど）を送信する場合、それらのメールは組織内のメールサーバーではなく、ベンダーのインフラストラクチャから送信されます。

暗号化されたDNS認証がない場合、受信側のメールプロバイダーは、この動作をドメインのなりすましとして検知する可能性が高いです。SPF、DKIM、DMARCを導入することで、この信頼のギャップを埋め、バウンス率を大幅に低減し、ブランドのアイデンティティを保護することができます。

（注：自動送信メッセージが、[email protected] などのデフォルトのベンダーアドレスを使用して送信される場合、認証はベンダー側で自動的に管理されます。以下の手順は、ご自身のドメインに合わせたカスタムの「送信元」アドレスを使用したい場合にのみ適用されます）。

ステップ 1：カスタム DNS 値の申請

「Attendance on Demand」の公開開発者向けドキュメントは、WebサービスとAPIにのみ焦点を当てており、メール認証については扱っていません。このプラットフォームでは顧客ごとに一意の識別子が割り当てられるため、一般的な設定手順を使用したり、他のテナントのレコードをコピーしたりすることはできません。

1. サポートリクエストを送信する：Attendance on Demandのチャネルパートナーまたはサポート担当者に連絡してください。お客様のテナントで「カスタムドメインからの送信」機能を有効にするよう依頼してください。

2. 明示的なDNS値の取得：必要なすべての認証パラメータを要求します：

SPFの場合：正確なReturn-Path（エンベロープ・フロム）のホスト名／宛先、またはお客様のテナント用に生成された特定のinclude:ステートメント。
DKIM の場合：DKIM セレクタ名、想定される署名ドメイン（d= の値）、DNS レコードの種類（CNAME または TXT）、およびターゲット／公開鍵。

3. DNSの変更は控えてください：これらの正確な値を受け取るまでお待ちください。認証メカニズムを推測したり、許可されていないレコードを公開したりすると、セキュリティリスクが高まり、DMARCの失敗の原因となります。

ステップ 2: Attendance on Demand SPF の設定

SPFは、ユーザーに代わってメールを送信することが許可されているインフラストラクチャを検証します。SPF経由でDMARCの検証に合格するには、非表示の「Return-Path」ヘッダーに記載されているドメインが、表示されている「From」アドレスと一致している必要があります。

Warning: Attendance on Demand publishes a list of IP addresses online for firewall configurations (HTTP/HTTPS/SMTP). Do not use these IP ranges to build your own SPF record. Outbound mail may utilize entirely different routing. Only use the specific SPF mechanism provided by your support partner.

オプション A：Return-Path サブドメインの使用（推奨）

パートナーが Return-Path を処理するために専用のサブドメイン（例：notify.yourdomain.com）を用意した場合は、指示通りに CNAME レコードまたは TXT レコードを設定してください。これにより、通常の社内メールに影響を与えることなく、認証用のルーティングを分離することができます。
（構造の例です。プレースホルダーは、発行された値に置き換えてください）：

タイプ: CNAME
ホスト：notify（または委任されたサブドメイン）
Value: <return-path-target-from-aod>

オプション B：インクルード文の統合

パートナーからルートドメインに対する特定の「include:」メカニズムが発行された場合は、それを既存のSPFレコードに組み込む必要があります。決して複数のSPFレコードを作成しないでください。

以前：

v=spf1 include:spf.protection.outlook.com ~all

（例）の後：

v=spf1 include:spf.protection.outlook.com include: ~all

プロのヒント：SPF 10件の検索制限に注意してください。このベンダーを追加することで制限を超えてしまう場合は、PowerDMARCの「Hosted SPF」を利用してレコードを自動的に統合することを検討してください。また、PowerDMARCのSPFチェッカーで現在の設定を確認することもできます。

ステップ3：カスタムDKIMの設定

DKIMは、「Attendance on Demand」において、特に特定の種類の自動アラートでカスタムReturn-Pathルーティングが利用できない場合、最も重要な認証層となることがよくあります。DKIMは、メールの内容が改ざんされていないことを検証するための暗号署名を適用します。

DNS管理コンソールにログインし、パートナーから提供された内容とまったく同じようにレコードを作成してください。

（構造上の例です。プレースホルダーを実際に発行された値に置き換えてください）：

タイプ：CNAME（またはTXT）
Host Record / Name: <selector-provided>._domainkey
Value: <tenant-dkim-target-from-aod>

重要な次の手順：DNSレコードを公開しても、署名プロセスはすぐには開始されません。Attendance on Demandのパートナーに連絡し、パートナー側でDKIM署名を有効化してもらう必要があります。さらに、テストを行うには、まったく新しいメッセージを送信する必要があります。以前に送信されたメールには、遡って新しい署名を付与することはできません。その後、PowerDMARCのDKIMチェッカーを使用して、キーがすでに有効になっているかどうかを確認できます。

ステップ4：DMARCレコードの設定

DMARCは、認証に失敗したメッセージを受信サーバーがどのように処理すべきかを規定しています。DMARCの検証に合格するためには、メッセージに少なくとも1つの「アラインド・パス」が必要です。つまり、SPFまたはDKIMのいずれかが、表示されている「From」アドレスと一致するドメインを使用して認証に合格している必要があります。
PowerDMARCの無料DMARCレコードジェネレーターを使用して、安全にポリシーを作成してください。

1. DNS設定を開き、新しいレコードを作成してください。

2. 正当なメールをブロックすることなく状況を把握するために、監視専用モードで開始します：

タイプTXT
ホスト／名前: _dmarc
値：v=DMARC1; p=none; rua=mailto:[email protected];

3. 新しいTXTレコードを保存します。

ステップ 5: 確認、トラブルシューティング、および適用

設定がトラフィックを確実に保護していることを確認するには、実環境でのテストを実行する必要があります。

テストメッセージの送信

権限によっては、この操作をチャネルパートナーに実行してもらう必要がある場合があります。管理者権限をお持ちの場合は、「グローバル設定」＞「プロセス」に移動し、「Eメールレポート」プロセスを作成または選択して、オペレーターレポートを実行してください（例：スケジュールを「今すぐ実行」に設定し、ご自身が管理する受信箱に送信するように設定するなど）。

ヘッダーの分析

テストメッセージを受信したら、メールヘッダーの生データを手動で確認するか、当社の無料ツール「Email Header Analyzer」を使用して、人間がすぐに理解できる形で情報を即座に把握してください。

SPFを確認する：「spf=pass」と表示されていることを確認してください。smtp.mailfrom（Return-Path）のドメインが、表示されている「From」アドレスと一致していることを確認してください。
DKIMを確認する：「dkim=pass」と表示されているか確認してください。また、「d=」（署名ドメイン）タグが組織のドメインと一致していることを確認してください。
DMARCを確認する：「Authentication-Results」ヘッダーに「dmarc=pass」と記載されているか確認してください。DMARCレコードのエラーをトラブルシューティングするには、PowerDMARCの無料DMARCレコードチェッカーを使用して、エラーの詳細情報を確認してください。

テストに失敗した場合：パートナーに問題をエスカレーションする際は、「DMARCが失敗した」とだけ伝えるのではなく、ルーティングの問題を特定できるよう、メールの生のヘッダー情報全体、UTC送信時刻、受信者アドレス、および失敗の原因となった「Authentication-Results」行の正確な内容をパートナーに提供してください。

執行段階へ移行（p=却下）

p=rejectポリシーへの移行を急がないでください。少なくとも 2 回の完全なビジネスサイクルにわたって、p=none の設定を維持することを強くお勧めします。この待機期間を設けることで、月末の給与明細や四半期ごとのシステムアラートなど、頻度の低い自動送信メッセージが確実にトリガーされる時間を確保でき、厳格なブロックルールを適用する前に、集計レポートでそれらの認証ステータスを確認することができます。

まとめ

メールセキュリティを最大限に強化する準備はできていますか？PowerDMARCチームなら、詳細なXML集計レポートを通じて「Attendance on Demand」のトラフィックを確実に監視し、DMARC適用プロセスを安全に進行させ、ドメインのセキュリティ対策を簡素化するお手伝いをいたします。

今すぐ弊社チームにお問い合わせいただくか、PowerDMARCのデモをご予約いただき、ビジネスコミュニケーションのセキュリティを確保しましょう！

について
最新記事

ユネス・タラダ

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

オンデマンド出席管理のメール認証ガイド：SPF、DKIM、およびDMARC - 2026年9月11日
Greatmail メール認証ガイド：SPF、DKIM、DMARC - 2026年9月11日
BIMI AVPタグとは？アバター設定について解説 - 2026年9月8日

オンデマンド出席管理システムにおけるメール認証ガイド：SPF、DKIM、およびDMARC