未解決のDNSレコード：その概要とサブドメイン乗っ取りの防止策
by
最終更新日: 10 読了時間：10分
「ダングリングDNSレコード」とは、削除されたクラウドサービス、運用を終了したサーバー、または非アクティブなサードパーティ製プラットフォームなど、もはや存在しないリソースを依然として指し示しているDNSエントリのことです。そのレコードは、背後にある宛先がすでに存在しないにもかかわらず解決され続けており、この不一致こそが攻撃者が狙うポイントです。
ITチームやセキュリティチームにとって、問題となるのは、1つの破損したレコードを見つけること自体ではなく、インフラストラクチャの基盤が変化する中で、ドメイン、サブドメイン、および認証レコード全体にわたって継続的な可視性を維持し続けることです。移行、ベンダーの切り替え、サービスの廃止が行われるたびに、対象となり得るレコードが残されてしまいます。
主なポイント
- ぶら下がったDNSレコードは、存在しない、または廃止されたリソースを指すことにより、ドメインを重大なセキュリティリスクにさらす。
- ダングリングDNSレコードの一般的な原因には、設定ミス、期限切れのサービス、廃止されたホスティングアカウントなどがあります。
- サブドメイン・テイクオーバー攻撃は、DNSレコードのぶら下がりによって引き起こされる可能性があり、攻撃者は侵害されたドメインを通じて悪意のあるコンテンツを制御し、提供することができます。
- 電子メール認証レコードは、特に「ダングリングDNS」の問題に対して脆弱です 。これは、使用されていないドメイン、廃止された送信元、または監視されていないレポート送信先を参照している場合に特に顕著です。
- ダングリングDNSレコードを効果的に検出し、対処するには、手動監査と自動DNS監視ツールの両方が不可欠です。
ダングリングDNSレコードとは？
「ダングリングDNSレコード」とは、もはや存在しない、あるいはアクセスできないリソースを指し示しているDNSエントリのことです。インターネット上のサイバー犯罪者は、情報漏洩のリスクが高いため、常にこのようなDNSエントリを探し求めています。これらのエントリの中には、 機密情報 が含まれている場合があり、脅威アクターにとって利益を得るためのデータの宝庫となります。
DNSのダングリングを引き起こすよくあるシナリオ
DNSの設定ミス。 ドメインネームシステム（DNS）は、アクセスしたいインターネットリソースとは別に設定されます。 DNSに追加されたDNSレコードは、これらのリソースを指し示し、ユーザーがそれらにアクセスできるようにします。場合によっては、以前に設定されたリソースが、そのホストによって設定解除されることがあります。例えば、ドメイン所有者がサーバーのIPアドレスを指すようにDNSレコードを設定していたとします。しかし、そのサーバーは現在使用されていません。このDNSレコードは、もはや存在しないリソースを指していることになり、そのため「ダングリングDNS」エントリと呼ばれることがあります。
有効期限が切れた、または削除されたクラウドリソース。 ドメイン所有者が利用しているクラウドサービスの有効期限が切れたり、削除されたりすると、そのサービスを指すDNSレコードはすべて ダングリング DNSレコードとなります。このDNSレコードは引き続き有効な状態であり、攻撃者はこのリソースを利用して悪意のあるコンテンツを配信することが可能です。
使用中止となるIPアドレス。 企業はサービスを新しいプロバイダーに移行する際、以前のIPアドレスは廃止されます。 チームが古いDNSレコードの更新や削除を忘れると、それらのレコードはサブドメイン乗っ取りの標的となり、容易に悪用される恐れがあります。
サービスの廃止または提供終了。 メールサーバー、ホスティングアカウント、またはサードパーティのサービスプロバイダーが廃止または運用停止されたにもかかわらず、MX、A、CNAMEなどのDNSレコードが依然として有効な状態で設定されたままになっている場合があります。攻撃者は、こうした有効なまま放置されたDNSレコードを悪用し、廃止されたサービスを装うことが可能です。
どのDNSレコードが「ダングリング」状態になるのか、そしてそれぞれがもたらすリスクとは
この脆弱性は、DNS層とリソース層の間のギャップに存在します。レコードの構文が完全に正しくても、その背後にある宛先がもはや所有されていなかったり、プロビジョニングされていなかったりする場合、そのレコードは危険となる可能性があります。以下の表は、レコードの種類ごとにそのギャップを示したものです。
| レコードタイプ | ぶら下がるとどうなるか | 主要リスク | 推奨される対処法 |
|---|---|---|---|
| CNAME | ターゲットエイリアスが削除されたか、ホスティングアカウントが閉鎖されました | 回収されたCDNまたはSaaSアカウントを介したサブドメインの乗っ取り | CNAME を削除するか、ターゲットを再プロビジョニングしてください |
| A / AAAA | IPアドレスが廃止されたか、別の所有者に再割り当てされた | トラフィックの乗っ取りと認証情報の傍受 | 現在のIPアドレスを更新するか、レコードを削除してください |
| MX | DNSのクリーンアップを行わずにメールサーバーを廃止した | メールの傍受および配信失敗 | アクティブなメールホストを削除するか、そのホストへの再設定を行う |
| NS | NSレコードを更新せずにDNSプロバイダーを変更した | ゾーンの乗っ取りとドメイン全体の乗っ取り | NSを現在の権威サーバーに更新する |
| TXT (SPF) | 非推奨のベンダーが、依然としてinclude経由で参照されています： | SPFの失敗とメールのなりすまし | 非推奨のインクルードを削除し、送信者を監査する |
| TXT (DMARC) | 「rua」または「ruf」タグが、非アクティブなメールボックスを指しています | 認証状況の可視性の喪失 | 監視対象の宛先へのリポートの送信 |
| DKIM CNAME | 送信プロバイダーのアカウントが削除され、宛先がなくなりました | DKIM署名の失敗と認証上の不備 | CNAME を削除するか、有効なプロバイダーを使用して再プロビジョニングを行ってください |
| TLS-RPT | 報告先が非アクティブまたは監視対象外である | TLSの障害が検出されずに見過ごされてしまう | rua をアクティブな監視対象アドレスに更新する |
よくある間違い
DNS 検索が成功したことを、そのレコードが正常であることの証拠とみなす。ダングリングレコードは、エントリ自体が有効であるため、通常通り解決される。重要なのは、組織が依然としてその宛先を所有・管理しているかどうかである。所有権を確認せずに解決状況のみを確認することが、こうしたレコードが監査をすり抜けてしまう原因となっている。
ダングリングレコードが最も頻繁に発生する場所
遺産の中には、他の部分に比べてこうした記録がはるかに確実に見つかる部分があります。どの部分かを知っておけば、毎回そのエリア全体をくまなく調べるのではなく、可能性の高い場所から順に監査を行うことができます。
- クラウドストレージのバケットと静的サイトのホスト： バケット名はグローバルに一意であり、自由に再登録できるため、有効なCNAMEを持つ削除済みのバケットは、乗っ取りの標的として最も狙われやすいものの一つです
- CDN および SaaS のバニティサブドメイン： help.example.com、status.example.com、および careers.example.com は通常、サブスクリプションが期限切れになった瞬間にホスト名を解放するサードパーティのプラットフォームを指しています
- マーケティングおよびランディングページツール： キャンペーン用サブドメインは、IT部門以外のチームによって迅速にプロビジョニングされ、廃止プロセスと結びつけられることはほとんどありません
- ステージング環境およびテスト環境： dev、UAT、およびステージングのレコードは、それらを作成したプロジェクトの存続期間を超えて残りますが、実際のトラフィックがこれらに依存していないため、誰も気づきません
- 取得または子ドメイン： 引き継がれたゾーンには、元の所有者が去った後のレコードが含まれており、関連するドキュメントが添付されていることはめったにありません
- 提供を終了したメールおよびサポートベンダー： 昨年利用料金の支払いを停止したプラットフォームのMXレコード、DKIM CNAME、およびSPFインクルード
これらをつなぐ共通点は、「所有権の移行」です。各レコードは、作成権限を持つ人物によって正しく作成されましたが、その存在を正当化していた関係が消滅した後も残ってしまいました。そのため、クリーンアップ作業は、DNSを管理する者ではなく、サービスを廃止する者の責任となります。
DMARC TXTレコード
DMARCレコードはTXTレコードとして公開され、多くの場合、ruaおよびrufタグを通じてレポート送信先が指定されています。これらの送信先が非アクティブまたは監視されていないメールボックスを指している場合、エラーが表面化しないため、チームは認証失敗やなりすまし試行を把握できなくなってしまいます。以下の点について見直してください DMARCレコードの公開方法 方法を見直してください。
SPF TXTレコード
SPFレコードには、IPアドレスを通じて認証された送信サービスがリストアップされており、認証メカニズムも含まれています。SPFレコードが廃止予定のサードパーティサービスや放棄されたドメインを参照している場合、認証の信頼性が低下し、その放棄されたベンダードメインを登録した攻撃者が送信権限を引き継いでしまうことになります。また、SaaS送信者が増加するにつれて、レコードは10回のDNSルックアップ制限を超えてしまうため、 SPFのフラット化 により、上限内に収めることができます。 SPFの詳細については、こちらをご覧ください。
TLS-RPTレコード
TLS-RPTレコードは、SMTPの TLS レポートの送信先を定義します。レポートの送信先が非アクティブ、設定ミス、または監視対象外となっている場合、チームは暗号化されたメールの配信に影響を与える転送セキュリティの障害を見逃してしまいます。詳細については、 TLS-RPT および MTA-STSの詳細については、こちらをご覧ください。
DKIM CNAMEレコード
DKIMレコードは、送信プロバイダーのDKIMホストを指すCNAMEレコードとして公開される場合があります。プロバイダーのアカウントが削除されたり、ターゲットドメインが非アクティブになったりすると、DKIMの署名および検証は黙って機能しなくなります。 たとえば、サブドメイン「mail.domain.com」は、CNAME「info.domain.com」のエイリアスです。したがって、サーバーが「mail.domain.com」を検索すると、「info.domain.com」にルーティングされます。あなたの DKIM 認証システムは、多くの場合、DNS に CNAMEレコードとして追加されることがよくあります。
注：MX、NS、A、AAAA、CNAME、およびTXTレコードは、稼働していないインフラ、廃止されたサービス、または利用されなくなったサードパーティプロバイダーを参照している場合、すべて「ダングリングレコード」となる可能性があります。本記事では、メール認証レコードに焦点を当てています。なぜなら、これらのレコードの不具合は、最も長期間にわたり発見されにくいものだからです。
DNSのダングリングがサブドメインの乗っ取りにつながる仕組み
非表示 DNSの脆弱性 （ダングリングDNSなど）は、ドメインの悪用やサイバー脅威につながる可能性があります。 金融、医療、教育、小売、公共部門などの規制対象業界では、未解決のDNSや認証に関する問題も、セキュリティレビューや監査対応を困難にしています。
この攻撃自体は予測可能な一連の流れをたどっており、制御のどこで連鎖が途切れるかを正確に示してくれるという点で有用である。
- サブドメインの列挙。 攻撃者は、公開されているDNSツール、証明書透明性（CT）ログ、またはブルートフォースによる列挙を用いて、対象ドメイン内のサブドメインをスキャンします。
- 未解決のレコードの特定。 攻撃者は、外部サービスを指すCNAME、A、またはMXレコードを見つけ、そのサービスから「そのようなアカウントはありません」または「未登録」という応答が返される。
- リソースの取得。 攻撃者は、クラウドストレージのバケット、CDNエンドポイント、SaaSサブドメインなど、外部プラットフォーム上で、その同じアカウント、バケット、またはホスト名を登録します。
- トラフィックハイジャック。 DNSレコードが依然としてその場所を指しているため、そのサブドメインへのすべてのリクエストは、現在、攻撃者が制御するインフラを経由してルーティングされるようになっています。
- 受け継がれた信頼の悪用。 その後、この信頼されたサブドメインは、組織のドメイン名の下で、フィッシングページを配信したり、マルウェアをホストしたり、セッションクッキーを盗んだり、なりすましメールを送信したり、認証情報を収集したりします。
サブドメイン乗っ取り攻撃とは何ですか？
攻撃者が、設定が解除されたリソースを指すダングリングDNSエントリを検出した場合、 攻撃者はその放棄されたリソースを乗っ取り、トラフィックを自身が制御するインフラを経由させることができます。 攻撃者は、ダングリングDNSレコードが指す（サブ）ドメインを乗っ取り、それによってトラフィック全体を攻撃者が制御するドメインへルーティングし、そのドメインのコンテンツやリソースへの完全なアクセス権を獲得します。
被害は、ページが改ざんされるだけにとどまりません。攻撃者の手口には、偽のログインページを通じた認証情報の窃取、信頼できるサブドメインにホストされたマルウェア、メールやウェブ上でのブランドなりすまし、セッションクッキーの傍受、ドメインの権威性を悪用したSEOの不正利用、MXレコードやSPFレコードの設定ミスを悪用したメール配信の不正利用、さらにはコンプライアンス審査の過程で後から明らかになる評判の毀損などが含まれます。
ダングリングホスト名とダングリングDNSレコード
この2つの用語は密接に関連しており、互換的に使われることもありますが、それぞれが指すものは異なります。「ダングリングDNSレコード」とは、ゾーンファイルには依然として存在しているものの、削除されたリソースや所有者のいないリソースを指し示しているCNAMEレコードやAレコードそのものを指します。一方、「ダングリングホスト名」とは、組織内の誰ももはや管理していない宛先に解決されるサブドメインのことを指します。
実際には、レコードによってホスト名が生成されます。もし dev.example.com に、プロビジョニングが解除されたホスティングアカウントを指す CNAME レコードが存在する場合、dev.example.com は「ダングリングホスト名」となり、その背後にある CNAME レコードは「ダングリングレコード」となります。この区別が重要なのは、スキャナーがどちらか一方をフラグとして検出する一方で、どちらの場合も必要な是正措置は同じだからです。つまり、対象の所有権を確認した後、レコードを削除するか、参照先を変更する必要があります。
未解決のDNSレコードを検出する方法
プロビジョニングされていないリソースを指しているDNSレコードを早期に特定することで、ブランドの保護につながります。これには、手動と自動の2つの方法があります。
| 基準 | 取扱説明書 | 自動化された |
|---|---|---|
| スケーラビリティ | 大規模なDNSゾーンでは実用的ではない | 数百のドメインおよびサブドメインを管理します |
| 周波数 | 定期的、毎月、または四半期ごと | 連続的、またはほぼリアルタイム |
| 人為的ミスのリスク | 高 | 低 |
| 所有権の検証 | 手動での相互参照が必要 | 一元化された在庫で管理 |
| 注意喚起 | なし | DNSの変更や設定ミスに関するリアルタイムのアラート |
| 特に適しているのは | 移設後または廃止措置後の抜き打ち検査 | 継続的なエンタープライズおよびMSP向けDNSセキュリティ状態の管理 |
手動による検出
手作業による監査は時間がかかりますが、特にクラウドへの移行、ベンダーの変更、サービスの廃止、または送信者の登録後などにおいて、古いDNSレコードを発見するのに役立ちます。
- DNSエントリの監査： DNS管理システム内のすべてのDNSレコードと、環境内の稼働中のリソースとを照合してください。存在しないサービスやIPアドレスを指しているエントリがないか確認してください。
- DNS設定の検証： nslookup や dig などのツールを使用して各レコードを照会し、対応するリソースがプロビジョニングされ、アクティブであることを確認します。 DNSの応答だけでは安全性が保証されるわけではないため、対象が自組織によって所有され、適切に管理されていることを確認してください。
- 孤立したサービスがないか確認する： サードパーティのホスティングサービス、クラウドプラットフォーム、CDNプロバイダーなど、関連するDNSエントリを削除せずにサービスが終了してしまった可能性のあるサービスについて調査してください。
レコードごとの検証を行うには、各エントリを DNSレコードチェッカー にかけ、現在どのホストに解決されるかを確認してから、そのレコードを残すかどうかを判断することもできます。
大規模な環境ではなぜ手動による検知が機能しなくなるのか
手動による方法は徹底的ではありますが、人為的なミスが発生しやすく、DNS設定が大規模または複雑なドメインでは管理が困難になる可能性があります。ゾーンが巨大化するはるか以前から、いくつかの要因によってその信頼性が損なわれてしまうのです。
- チームや部門をまたぐ分散型のDNS管理体制
- 忘れ去られたテスト環境やステージング環境に、依然として本番用のDNSレコードが残っている
- シャドウITおよび追跡されていないサードパーティ製SaaSとの連携
- 有効期限が切れたクラウドリソースは、正式な廃止手続きと一切関連付けられていない
- 買収や子会社ドメインを通じて継承された複数のDNSゾーン
- 現在、所有者がいないレガシーインフラに関する不十分なドキュメント
自動検出
ドメイン、サブドメイン、送信元、クラウドサービスが監査サイクルよりも速いペースで変更されるようになると、自動化された監視が必要となります。定期的なチェックに代わって、一元化されたプラットフォームが、ポートフォリオ全体にわたる非アクティブなレコード、不適切な認証設定、不審な変更を継続的に検知します。
実用的なメリットは、徹底性というよりはむしろタイミングにあります。四半期ごとの監査でも、最終的には同じ記録が見つかるでしょうが、それは1四半期もの間、そのリスクにさらされた後に発見されることになります。継続的な監視を行えば、サービスが廃止されてから次回の点検までの間に生じる「隙間」を塞ぐことができ、そここそが実際に引き継ぎリスクが存在する場所なのです。
未解決のDNSレコードを修正する方法
ダングリングレコードが特定されたら、処理の順序が重要になります。リソースを解放する前にレコードを削除すると、セキュリティ上の脆弱性が生じる可能性があります。また、TTLの処理を省略すると、修正が反映されるまでに数分ではなく数時間かかってしまいます。
- レコードとその対象を特定します。 DNSツールまたは監視プラットフォームを使用して、特定のエントリとその現在の解決先を特定してください。
- 対象の所有権を確認してください。 プロバイダーまたはアカウントレジストリに照会して、組織が依然としてその宛先を管理しているかどうかを確認してください。
- まずTTLを下げてください。 変更を行う前に、TTLを60～300秒の範囲に設定しておくと、変更を実行した際に更新が迅速に反映されます。
- リソースが取得可能な場合は、そのリソースを取得し直してください。 対象が未取得のクラウドバケットまたはCDNエンドポイントである場合は、DNSに手を加える前にそれを取得し、乗っ取りの機会を封じ込めなさい。
- レコードを削除するか、参照先を変更してください。 サービスが廃止された場合は、そのレコードを削除してください。引き続き有効にしておく必要がある場合は、現在所有し、プロビジョニング済みのリソースを参照先として設定してください。
- 伝播の検証を行います。 dig または nslookup を使用して、レコードが正しく解決され、旧宛先がもはや応答していないことを確認してください。
- 変更内容を記録してください。 何が変更されたか、その理由、時期、および変更担当者を記録し、DNSインベントリを更新した上で、継続的な管理責任者を割り当ててください。
ダングリングDNSレコードによるサブドメイン乗っ取りを防ぐ方法
予防策には、DNSの適切な管理と継続的な監視が組み合わされています。以下の対策は、複数のドメインを管理するITチーム、セキュリティチーム、およびMSPにとって最も重要なものです。
- 使用されていないDNSレコードは直ちに削除してください： サービスが廃止された際は、万が一に備えて残しておくのではなく、CNAME、A、AAAA、MX、およびTXTレコードを削除してください
- サードパーティのターゲットを指定する前に、その有効性を確認してください： まず、クラウド、CDN、メール、およびホスティングリソースが稼働しており、かつ貴組織が所有していることを確認してください
- メール認証レコードを監視する： DMARC、SPF、DKIM、MTA-STS、TLS-RPT、およびBIMIを定期的に確認し、無効または誤った参照がないか確認する
- ドキュメントの所有権： ドメイン、サブドメイン、送信者、およびサービス所有者の一覧を作成し、各レコードに担当者を明記する
- DNSのクリーンアップをサービス終了プロセスに組み込む： クラウドサービス、SaaSプラットフォーム、またはホスティングアカウントを廃止する際は、必ずレコードの削除を行うようにする
- 自動アラートの設定： ゾーン内に孤立したサービス、DNSのずれ、および新しいサブドメインが出現していないか監視します
- 定期的なセキュリティ監査を実施する： 複雑さに応じて毎月または四半期ごとに、また移行、プロバイダーの変更、ドメインの取得直後に実施する
古いサブドメインや使われていないサブドメインをどうするか
サブドメインが不要になった場合、その対応は通常、以下の5つの結果のいずれかに分類されます。
- 削除 サブドメインにビジネス上の正当な理由がなくなった場合は、そのレコードを削除する
- 再利用 サブドメインを稼働させたままにし、かつアカウントがまだ取得可能な状態にある場合、放棄された外部リソースを再取得する
- 安全に駐車するには 解決が必要だが何も提供しない場合は、外部プラットフォームではなく、管理された内部リソースを指定してください
- リダイレクト 業務上の理由がある場合にのみリダイレクトを行い、転送先が当該組織の所有であり、かつ稼働中であることを確認する
- 文書 何かを廃止する前に、すべての決定事項を文書化し、責任者を割り当てる
PowerDMARCはどのように役立つか
PowerDMARC は、ドメインおよびメール認証の監視を一元化することで、チームがDMARC、SPF、DKIM、MTA-STS、TLS-RPT、BIMIにわたる問題を、各DNSレコードを手作業で確認することなく検出できるようにします。その目的は、単一の未処理レコードを見つけることではありません。セキュリティ態勢に影響を与えるすべてのドメイン、サブドメイン、および認証レコードを継続的に可視化することにあります。
- 一元化されたダッシュボード： ドメイン、サブドメイン、および認証ステータスを1か所で確認可能
- 問題の迅速な検出： 設定ミスが、セキュリティや配信率に影響を及ぼす前に発見される
- SPF管理の自動化： SaaSプラットフォームの変化に伴い、ルックアップの失敗が減り、送信元がよりクリーンになる
- コンプライアンス対応体制： 金融、医療、教育、小売、公共部門の各チームに対する監査準備支援
- 専門家によるサポート： リスクのあるレコードの調査、検証、および是正を迅速に行うためのグローバルなサポート
サービスプロバイダーにとっては、ドメインの一元的なグループ化とロールベースのアクセス制御により、多数のクライアント環境を同時に監視することが現実的になります。 MSPおよびMSSPプログラムは は、そのワークフローを基盤として構築されています。
現在の姿勢について手短に確認したい場合は、 無料のアナライザーで 無料のアナライザーでドメインを確認してみてください。ドメインを入力し、「今すぐ確認」をクリックするだけで、DNSレコードの設定状況、検出された設定ミス、およびそれらを解決するための実用的なヒントを確認できます。
よくあるご質問
これらは、コンセプトが明確になった後に生じる運用上の疑問について扱ったものです。
未解決のDNSレコードはどのように修正すればよいですか？
古くなったレコードを特定し、対象リソースが依然として自組織の所有物であるかを確認した上で、TTLを下げてください。リソースが回収可能な場合は、まずそれを回収し、その後、レコードを削除またはリポイントし、dig コマンドで伝播が正常に行われたことを確認し、変更内容を記録してください。
「ダングリングホスト名」とは何ですか？
ドメイン所有者がもはや管理していない宛先に解決されるサブドメイン。これは「ダングリングDNSレコード」によって生成されます。たとえば、dev.example.com がプロビジョニングが解除されたクラウドアカウントを指している場合、これは「ダングリングホスト名」となります。
未解決のDNSレコードは、メールのセキュリティに影響を与える可能性がありますか？
はい。DMARC、SPF、DKIM、MTA-STS、およびTLS-RPTレコードは、非アクティブなドメイン、廃止された送信者、または監視対象外のレポート用メールボックスを参照している場合、すべて無効な状態になってしまいます。その結果、認証エラーが発生し、気付かれないまま可視性のギャップが生じることになります。
組織はどのくらいの頻度でDNSレコードの監査を行うべきでしょうか？
サービスの廃止、プロバイダーの移行、ドメインの取得、または送信元の変更が行われるたびに実施します。また、複雑さに応じて毎月または四半期ごとの定期監査を追加し、監査期間中の状況のずれを把握するために継続的な監視を行います。
ダングリングレコードは、必ずしもサブドメインが乗っ取られることを意味するのでしょうか？
いいえ。テイクオーバーを行うには、対象のリソースが他の誰かによって取得可能である必要があります。これは、クラウドバケット、CDNエンドポイント、SaaSサブドメインなどでよく見られるケースです。無効なIPアドレスを指すレコードであっても、サービス停止や通信傍受のリスクを引き起こす可能性があります。
社内でDNSレコードの整理・削除業務は誰が担当すべきでしょうか？
サービスの廃止管理は、DNS管理者だけでなく、その責任を負う者が行うべきです。サービスが廃止された時点でレコードは陳腐化するため、その整理は個別のDNSレビューではなく、オフボーディングのチェックリストに含めるべきです。
ドメインおよびメールセキュリティの専門家（所属： PowerDMARC
ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。
最新記事 by Yunes Tarada(全て見る)
- AppRiver（Zix）メール認証ガイド：SPF、DKIM、およびDMARC - 2026年9月30日
- SPFレコードの構文 - 2026年9月14日
- Oracle メール配信の DKIM、DMARC、および SPF 設定ガイド - 2026年9月14日
