DMARCが失敗する理由：原因、解決策、および確認方法

なぜあなたのドメインでDMARCが失敗しているのでしょうか？ほとんどの場合、その原因は次の2つのいずれかに帰着します。SPFまたはDKIMが、メールの「From」アドレスと一致していないか、サードパーティの送信者がまだ承認されていないかのいずれかです。このガイドでは、これら2つの原因について解説するほか、Google、Yahoo、Microsoftによる最近の適用方針の変更がDMARC失敗の真の原因であるかどうかを判断する方法、および変更を行う前に自分で失敗の原因を確認する方法についても説明します。

なぜDMARCは機能しないのか？ その簡潔な答え

SPFもDKIMもメッセージの認証に失敗し、かつ表示されている「From」ドメインと一致しない場合、DMARCは失敗となります。DMARCに合格するためには、SPFまたはDKIMのいずれかがドメインの一致要件を満たす必要があります。どちらも一致しない場合、自動的にDMARCの失敗がトリガーされます。場合によっては、ドメインがDMARCとともにSPFまたはDKIMのいずれか一方のみ（両方ではない）で設定されている場合、たとえ認証に合格していても、そのメッセージのSPF/DKIMの一致が失敗すると、DMARCは失敗となります。

DMARC失敗とは何を意味するのか？

DMARCの失敗とは、メール自体がDMARCチェックを通過できなかった場合に発生します。これは、SPFもDKIMも、そのメールがあなたのドメインから正当に送信されたものであることを、整合性のある形で検証できない場合に起こります。ここで「検証」と「整合性」はそれぞれ異なる役割を担っており、これらを混同することが、多くの混乱の元となっています。

SPFは合格してもDMARCは不合格になることがある――その理由とは

たとえば、あるマーケティングプラットフォームが、独自の返信先ドメイン「mail.esp-provider.com」を使用してメールを送信しているとします。SPFはそのドメインを確認し、合格判定を下します。つまり、送信元のIPアドレスは「mail.esp-provider.com」に代わってメールを送信する権限が認められていることになります。 しかし、受信者に表示される「From」アドレスはyourdomain.com です。DMARC は、単にどこかで SPF チェックに合格したかどうかを確認するだけでなく、SPF チェックに合格したドメインが、受信者に表示される「From」ドメインと一致しているかどうかも確認します。mail.esp-provider.com は yourdomain.comと一致しません。したがって、SPF チェックは合格したものの、DMARC チェックは依然として失敗します。

DKIMについても同様の理屈が当てはまります。 メッセージには、有効で暗号的に検証済みのDKIM署名が含まれている場合でも、その署名内の「d=」ドメイン（署名ドメイン）が、表示されている「From」ドメインと一致しない場合、DMARCはそれを「不整合」とみなしてチェックに失敗します。これは、「SPFとDKIMの両方が『合格』と判定している」という混乱の最も一般的な原因であり、そのため、認証だけでなく整合性を真っ先に確認する必要があるのです。

DMARC失敗の一般的な原因

DMARCの失敗のほとんどは、実際の攻撃ではなく、送信インフラのどこかに設定ミスがあることが原因です。SPFやDKIMの失敗がDMARCにどのような影響を与えるか、その内訳は以下の通りです：

1. SPFの失敗

SPFが失敗するのは、ごく一部の、十分に文書化されている特定の理由によるものです：

• DNS 照会が 10 回という制限を超過：SPF では、1回のチェックにつきDNS 照会は最大10 回までと制限されています。1つのドメインから、それぞれ独自のインクルード機構を持つ複数のプラットフォーム（たとえば、CRM、メールマーケティングツール、社内メールサーバーなど）を経由してメールが送信されると、この制限はすぐに達してしまいます。制限を超過すると、SPF は即座に失敗し、メールがバウンスし始めるまで明確な警告が表示されないことがよくあります。
• 送信サービス用のインクルードの欠落：新しい送信プラットフォームを追加する際、そのSPFインクルードを追加し忘れると、そのプラットフォームからのメールは毎回SPF検証に失敗します。
• 1つのドメインに複数のSPFレコードが存在する場合：DNSでは、1つのドメインにつき1つのSPFレコードしか許可されていません。2つ存在する場合、ほとんどの受信サーバーはどちらを信頼すべきか判断できず、検証に失敗します。
• 構文エラー：余分なスペース、構文の不備、またはレコードの順序が間違っていると、全体が無効になってしまう可能性があります。

SPFが機能しない理由について詳しく知る。

2. DKIM 失敗

DKIMの失敗は、通常、次の3つの原因のいずれかに帰着します：

• DNSで更新されなかった、有効期限が切れた、またはローテーションされた鍵：DKIM鍵は永続的なものではありません。送信側で鍵のローテーションが行われたにもかかわらず、新しい公開鍵がDNSに公開されていない場合、すべての署名は誤った鍵に対して検証され、失敗します。
• セレクタの欠落または誤り：セレクタは、受信サーバーに対し、特定の署名に対応する公開鍵がどのDNSレコードに格納されているかを示します。セレクタを間違えると、鍵自体に問題がなくても、DKIMの検証に失敗します。
• 署名後にメッセージが変更された場合、署名は無効になります：DKIMは特定のヘッダーおよび本文の内容に署名を行います。署名対象となる部分が署名後に変更されると、署名は無効になります。

DKIMの設定方法に関するガイドや、DKIMが失敗する理由についての詳細な解説をご覧いただければ、特定のDKIM失敗シナリオやエラーのトラブルシューティングに役立ちます。

3. 許可されていない第三者送信者（CRM、ESP、ヘルプデスク）

多くの企業では、マーケティングオートメーションツール、CRM、ヘルプデスクソフトウェア、トランザクションメールサービスを通じてメールを送信しています。これらのプラットフォームが、自社のドメインに代わってメールを送信する適切な権限を持っていない場合、それらから送信されるすべてのメッセージがDMARCの失敗を引き起こす可能性があります。

たとえば、Google Workspace や Microsoft 365 では、カスタム設定を行わない限り、送信メールにはそれぞれのデフォルトのDKIM セレクタが署名として付加されます。つまり、これらのサービスを通じて送信されたメールは、受信者には「via provider.com」というラベルが付いた状態で表示される可能性があります。そのプラットフォーム内で自身のドメインに対するカスタム DKIM 署名を明示的に設定していない限り、署名ドメインが「From」フィールドに表示されるドメインと一致しないため、これらのメッセージはアライメントに失敗する可能性があります。

4. メールの転送とメーリングリスト

メールが転送されると、転送サーバーのIPアドレスは元の送信者のSPFレコードに含まれていないため、SPFの整合性が損なわれます。また、この過程で「エンベロープFrom」アドレスやヘッダーが変更されることもあります。

メーリングリストもこれと関連していますが、まったく同じというわけではありません。メーリングリストでは、メッセージ本文やヘッダーを直接変更し、購読解除用のフッターを追加したり件名を書き換えたりすることがよくありますが、これにより、単なる転送だけではDKIM署名が破綻しないような状況であっても、署名が破綻してしまうことがあります。ARC（Authenticated Received Chain）は、中間サーバーが元の認証結果の検証可能な記録を添付できるようにすることで、この問題を軽減するために特別に存在します。しかし、その機能は今後発表されるDKIM2仕様に組み込まれることになり、ARCはまもなく廃止される可能性があります。

5. サブドメインの不整合

DMARCポリシーが「yourdomain.com」を対象としているにもかかわらず、独自のアラインメント設定がない「mail.yourdomain.com」からメールが送信された場合、それらのメールはDMARCチェックに失敗する可能性があります。複数のサブドメインでメール運用を行っている組織では、ルートドメインだけでなく、すべてのサブドメインにわたって一貫した認証を行う必要があります。

6. DNSの伝播遅延（断続的な障害）

DNSレコードが変更されたばかりの場合、一部の受信サーバーは依然としてキャッシュされた古いバージョンを参照している一方で、他のサーバーはすでに新しいバージョンを反映していることがあります。この不一致により、まったく同じタイミングで一部の受信者ではDMARCが「合格」となり、別の受信者では「不合格」となる現象が発生します。伝播遅延が原因であることを知らなければ、これは実に不可解な現象に見えます。 最近SPF、DKIM、またはDMARCレコードを編集し、失敗が全面的なものではなく不規則に見られる場合は、他の問題があると判断する前に、しばらく時間（レコードのTTLにもよりますが、多くの場合24～48時間程度）を置いてみてください。

DNSの伝播状況をリアルタイムで確認するhttps://powerdmarc.com/dns-propagation-checker/

7. ドメインスプーフィング（DMARCが意図したとおりに機能している）

もし誰かがあなたのドメインを偽装してフィッシングメールやスパムメールを送信している場合、そのメッセージは当然ながらDMARCの検証に失敗します。なぜなら、その不正な送信元は、あなたのドメインに紐付けられたSPFやDKIMの検証を通過できないからです。これは、このリストの中で唯一、設定ミスが原因ではないケースです。これはDMARCが本来の目的通りに機能している証拠であり、あなたのドメインが積極的に標的にされていることを示すシグナルでもあります。したがって、DMARCレポートを注意深く監視しておく価値があります。

8. 特定のバウンスメッセージやエラーコードが表示されていますか？

特定のエラーメッセージを検索してこのページにたどり着いた場合、以下に挙げるものはすべて、各プラットフォーム独自の表現で表示されたDMARCまたはアライメントの失敗に過ぎません。根本的な原因と解決策については、すべて前述の内容で網羅されています。

Mimecastの「DNS認証：DMARC失敗」

これは、Mimecastが、受信または送信メッセージがDMARC評価に失敗したことを示す独自の方法であり、通常は前述のSPF/DKIMの整合性に関する理由によるものです。

SendGridの配信エラー

DMARCに関連するエラーは、通常、SendGrid自身の送信ドメイン、またはSendGridを経由して送信される顧客の「From」ドメインが適切に整合されていないことを意味します。多くの場合、これは送信ドメインに対するカスタムDKIM/SPFの設定が完了していないことが原因です。

GmailのSMTPコード

421-4.7.26 は一時的なエラーであり、メッセージが認証されていない（SPF または DKIM の検証に合格していない）ことを意味します。Gmail では、2025 年後半以降、継続的な非準拠に対して、これらを一時的なエラーから恒久的な550-5.7.26拒否へとより積極的にエスカレーションするようになっています。 関連するコードである 550-5.7.1 は、具体的には、メッセージが送信ドメイン自身が公開している DMARC ポリシーに違反したことを意味します。

Microsoft 550 5.7.515

これは、マイクロソフトが2025年5月5日より導入する、同社の認証要件を満たさない大量送信者（Outlook、Hotmail、またはLive.comのアドレス宛てに1日あたり5,000通以上のメールを送信する者）に対する「ハードリジェクション」です。

なぜDMARCが突然失敗するようになったのか？

ドメインがDMARCの検証に合格していたのに、最近不合格になった場合は、何か不具合が発生したと決めつける前に、以下のリストを確認してください：

• SPFやDKIMの設定を更新せずに、新しいマーケティングツール、CRM、またはヘルプデスクプラットフォームが追加されました。
• 最近、DNSレコードが編集された結果、構文エラーが発生したり、誤ってSPFレコードが重複してしまったりしています。
• DKIMキーの更新または有効期限切れが行われたものの、新しいキーがDNSに公開されていませんでした。
• あるサブドメインが、独自のSPF、DKIM、DMARCの設定を行わないままメールの送信を開始しました。
• Google、Yahoo、Microsoftは、自社側での取り締まりを強化した。

Google、Yahoo、Microsoftは、これまで以上に厳格にDMARCを適用している

GoogleとYahoo!の一括送信者向け要件は2023年後半に発表され、2024年2月に大量送信者に対して適用が開始され、2024年4月までに全面的に施行されました。それ以来、Gmailは、要件を満たさないドメインに対して、一時的な配信保留を恒久的な配信拒否へと転換する基準を引き続き厳格化しており、この傾向は2025年後半にかけて著しく厳しくなっています。

マイクロソフトもこれに続き、Outlook、Hotmail、およびLive.comのアドレスについて独自の要件を策定しました。この要件の適用は2025年5月5日から開始され、要件を満たさない大量メール（1日あたり5,000通以上）は、単にスパムフォルダに振り分けられるのではなく、エラーコード「550 5.7.515」が表示され、即座に拒否されるようになりました。

もし、お客様のドメインからこれらのプロバイダーのいずれかに1日あたり5,000通以上のメールを送信しており、最近DMARCの失敗頻度が増えているのであれば、この規制強化がその原因である可能性が高いです。いずれの場合も対処法は同じです。すべての送信元を特定し、SPFとDKIMを適切に整合させ、DMARCレコードが正しいことを確認してください。プロバイダーごとの詳細な要件については、当社の「大量メール送信者向け要件ガイド」をご覧ください。

DMARCの失敗を確認する方法

変更を加える前に、実際に何が起きているのかを確認してください：

1.Gmail、Outlook、Yahoo!にテストメッセージを送信し、Authentication-Resultsヘッダーを開きます。

Gmailでは、メッセージを開き、「オリジナルを表示」を選択します。Outlookでは、「メッセージの詳細を表示」を使用します。spf=、dkim=、dmarc=の結果を探し、合格したドメインが表示されている「差出人」アドレスと一致しているか確認してください。

2.失敗した送信元IPアドレスを、DMARC集計（RUA）レポートと照合してください。

これらのレポートには、お客様のドメインを名乗ってメールを送信しているすべてのIPアドレスと、それぞれがDMARC検証に合格したか不合格だったかが表示されます。これは通常、不正な送信元や設定ミスを発見するための最も手っ取り早い方法です。生のXML形式に慣れていない場合は、DMARCレポートの読み方に関するガイドをご覧ください。

3.ドメインを無料のDMARCチェッカーでチェックする

レコードの現在の状態を確認してください。公開時点では正しく見えたレコードでも、時間の経過とともに構文上の問題、重複、または伝播の不備が生じる可能性があるためです。当社のDMARCレコードチェッカーなら、1回の処理でこれらをすべてチェックできます。

DMARCが失敗すると何が起こるのか？

結果は、ドメインに設定されたDMARCポリシーに完全に依存します。このポリシーは、認証に合格しなかったメールを、受信メールサーバーがどのように処理すべきかを指定するものであり、各レベルによって異なる結果が生じます。

p=none: 監視のみ

DMARCポリシーをp=noneに設定した場合、DMARCの検証に失敗したメールも配信されますが、受信トレイではなくスパムフォルダに振り分けられることがよくあります。このポリシーは監視を目的として設計されています。これにより、メールの配信を妨げることなく、DMARCレポートを収集し、認証上の問題を特定することができます。安全な出発点ではありますが、p=noneを長期的に維持すると、不正な送信者を積極的にブロックしないため、ドメインが脆弱な状態にさらされてしまいます。

p=quarantine: スパムとして送信

p=quarantine の DMARC ポリシーでは、配信に失敗したメールは受信者のスパムフォルダに振り分けられます。これにより、正当なメールが迷惑メールに埋もれてしまう可能性があるため、可視性やユーザーのエンゲージメントが低下します。このポリシーは p=none よりも高い保護効果を提供しますが、実際のなりすましではなく設定ミスによって正当なメールの配信に失敗している場合、ビジネスに悪影響を及ぼす可能性があります。

p=reject: 完全にブロック

DMARCポリシーを「p=reject」に設定すると、受信サーバーはそのメールを完全にブロックし、受信者に届くことを一切防ぎます。これは最も厳格で安全なポリシーです。フィッシングやスプーフィングの試みを未然に防ぎます。ただし、SPFやDKIMが適切に設定されていない場合、「p=reject」ポリシーは自社の正当なメールもブロックしてしまうため、業務上のコミュニケーションに深刻な支障をきたす可能性があります。

DMARC失敗がビジネスに与える影響

DMARCの失敗は、コミュニケーション手段として電子メールに依存している企業にとって大きな課題となります。ここでは、DMARCの失敗が組織にどのような影響を与えるかについて解説します。

メール配信率の低下

DMARCの検証に失敗すると、正当なメールが受信プロバイダーによってブロックされたり拒否されたりし、ビジネス上のコミュニケーションに支障をきたす可能性があります。メールがスパムフォルダに振り分けられるにせよ、完全に拒否されるにせよ、結果は同じです。つまり、メッセージが本来届くべき相手に届かなくなってしまうのです。営業、マーケティング、カスタマーサポート、あるいは取引関連の連絡にメールを頼っている企業にとって、これは直接的にビジネスチャンスの喪失につながります。

送信者の評判が損なわれている

DMARCの失敗が繰り返されると、ドメインの送信者レピュテーションが損なわれ、認証済みのメールでさえ受信トレイに届くのが難しくなる可能性があります。GoogleやMicrosoftなどのメールプロバイダーは、ドメインの認証履歴を追跡しています。DMARCの失敗が繰り返し発生していることが確認されると、これらのプロバイダーは当該ドメインの信頼性を低く評価し始めます。その結果、適切に設定されたメールであっても、時間の経過とともに配信に問題が生じるようになる可能性があります。

開封率と顧客エンゲージメントの低下

DMARCの検証に失敗すると、メールがスパムフォルダに振り分けられ、開封率や顧客エンゲージメントの低下を招く可能性があります。マーケティングキャンペーン、請求書、注文確認メール、あるいは重要なビジネス関連のお知らせなどが、常にスパムフォルダに振り分けられてしまう場合、対象となるユーザーはそれらを目にする機会が失われ、結果として収益の機会を逃し、顧客の不満を招くことになります。

フィッシングおよびなりすましのリスク増加

DMARCの失敗率が高くなると、フィッシング攻撃やドメインなりすましのリスクが高まり、顧客の信頼が損なわれます。ドメインがなりすまされている場合、不正な送信元はDMARCチェックに失敗しますが、厳格な適用ポリシーがなければ、それらのなりすましメールは依然として受信者に届く可能性があり、顧客、パートナー、従業員が、貴社のブランド名を騙った詐欺メールに騙されるリスクにさらされることになります。

長期的な配信可能性への悪影響

DMARCの認証失敗は、メールボックスプロバイダーに対してそのドメインが信頼できないことを示唆する可能性があり、これはメールの配信率に長期的な影響を及ぼす恐れがあります。傷ついた送信者の評判を回復させるには、多大な時間と労力が必要です。認証が正常に戻った後は、体系的なIPウォームアップを行い、送信量を毎日段階的に増やし、実際の受信者から肯定的なエンゲージメントシグナルを引き出すことで、受信トレイからの信頼を徐々に回復させていくことが、配信率が実際にどれほど早く回復するかを左右する要因となることがよくあります。

DMARC失敗の修正方法

DMARCの失敗を修正するには、失敗の原因を把握し、メール認証の設定を適切に調整する必要があります。

ステップ1: 緩やかなDMARCポリシー（p=none）から開始する

「ノーポリシー」を採用すれば、まずDMARC（RUA）集計レポートを用いてドメインを監視し、送受信されるメールを注意深く見守ることで、配信上の問題が深刻化する前に対処することができます。
これにより、たとえDMARCの検証に失敗したとしても、正当なメッセージは引き続き受信者に届くようになります。ただし、その間、フィッシングやスプーフィングの攻撃に対して無防備な状態になってしまう点には注意が必要です。

ステップ2：適切なSPFとDKIMのアライメントを確保する

DNSレコードにエラーがないか確認し、SPFまたはDKIMに合格しているドメインが、実際にメールの「差出人」アドレスと一致していることを確認してください。この仕組みについては、このガイドの前半で詳しく説明しました。当社の無料DMARCチェッカーツールを使用すれば、余分なスペースやスペルミスを含め、DMARCの構文やDNSレコードの形式に関するエラーを検出できます。

DKIMとSPFを併用することで、多層的なアプローチが可能になります。DKIMはメッセージが改ざんされていないことを検証し、SPFは送信サーバーの身元を検証します。これらを組み合わせることで、メールの送信元に対する信頼を確立し、なりすましや不正なメール活動のリスクを低減することができます。

ステップ3：エンフォースメントでディフェンスを強化する

正当な送信者が確認され、照合が完了したら、強制ポリシー（p=隔離、その後 p=拒否）に移行し、ドメインなりすましやフィッシング攻撃に対する確実な保護を確保します。

ステップ4：AI主導の脅威検知による保護

悪意のあるIPアドレスを特定し、DMARCプラットフォームから直接報告することで、今後のなりすまし攻撃を未然に防ぎましょう。可能であれば、脅威インテリジェンスツールを活用してください。

ステップ5：障害レポートを活用して継続的に最適化を行う

DMARC（RUF）失敗レポートを有効にすると、DMARCに失敗した特定のメールに関する詳細情報を取得できるため、問題の根本原因を特定し、より迅速に解決することができます。

PowerDMARCでDMARCエラーを修正する

DMARCの失敗に対処するのは複雑な場合があります。特に、複数の送信サービス、サードパーティプラットフォーム、進化するメールインフラを管理している場合にはなおさらです。PowerDMARCは、初期設定から継続的な監視、脅威の検出に至るまでのプロセス全体を簡素化します。

当社は、段階的なガイダンスと自動化ツールを提供することで、組織がDMARCを正しく導入するお手伝いをします。これにより、DMARCレコード、SPF、DKIM認証が初日から適切に設定され、整合性が保たれます。これにより、DMARCの失敗につながる設定ミスリスクを低減し、ドメインを完全な施行への道筋に迅速に乗せることができます。

DMARCが設定されると、PowerDMARCはメール通信を継続的に監視し、DMARC失敗が検出されるたびにリアルタイムのレポートとアラートを生成します。

当社が他社と一線を画す点は以下の通りです：

• AI駆動の脅威インテリジェンスと自動アラートにより、フィッシングやなりすまし攻撃をリアルタイムで検知
• DMARC、SPF、DKIMを初日から正しく運用するための段階的な導入と実装サポート
• 複雑なXMLデータを明確な洞察に置き換えた、人間が理解しやすく実行可能なレポート
• 世界中の5,000以上の組織から信頼され、DMARCエラーの修正と予防を実現

よくあるご質問

1. DMARCは何の略ですか？

DMARCは、ドメインベースのメッセージ認証、報告、準拠（Domain-Based Message Authentication, Reporting, and Conformance）の略称です。これは、メールが正当な送信元から送信されたことを検証することで、メールのなりすまし、フィッシング、その他のサイバー攻撃からドメインを保護するメール認証プロトコルです。

2. DMARC認証を通過する方法

DMARC認証に合格するには、メールがSPFまたはDKIMのいずれかの認証に合格し、「From」アドレスに表示されているドメインと一致している必要があります。これを実現するには、送信元IPアドレスがSPFで承認されていること、DKIMが適切に署名されていること、およびDMARCレコードがDNSに正しく公開されていることを確認してください。

3. DMARC保護が機能しない場合の修正方法

DMARCによる保護が不十分な状態を解消するには、ドメインのDNSにDMARCレコードを登録してください。まずは監視ポリシー（p=none）を設定してレポートを収集し、すべての正当なメール送信元が認証されていることを確認した後、徐々に厳格な適用（p=quarantine または p=reject）に移行してください。

4. DMARC失敗エラーの修正方法

DMARCの失敗エラーを修正するには、まずメッセージが認証に失敗した原因を確認してください。SPFとDKIMが正しく設定され、送信ドメインと整合していることを確認した上で、ドメインのDMARCポリシーがDNSに正しく公開されており、実際のメール送信方法と一致しているかを確認してください。すべてが整合したら、DMARCレポートを監視して、問題が解決したことを確認してください。

5. DMARC違反とは何ですか？

DMARC違反とは、DMARCチェックに合格しなかったメッセージを指す別の表現です。これは、メッセージが不正なもの（誰かがあなたのドメインをなりすましている）であるか、正当な送信者が適切に設定されていないことが原因です。その後の処理は、設定したポリシーによって異なります。p=noneの場合はログに記録され、p=quarantineの場合はスパムフォルダに振り分けられ、p=rejectの場合は即座にブロックされます。

6. SPFとDKIMの両方が合格しても、DMARCは不合格になることがありますか？

その通りです。これは、最もよくある誤解の一つです。SPFとDKIMは、技術的にはそれぞれ独自のチェックを通過しても、DMARCのチェックには失敗することがあります。これは、どちらのチェックを通過したドメインも、メッセージの「From」アドレスとして表示されているドメインと一致していない場合です。例えば、mail.esp-provider.comからのメッセージがSPFチェックを問題なく通過しても、表示されている「From」ドメインがyourdomain.comである場合は、DMARCチェックに失敗します。なぜなら、DMARCが実際にチェックしているのは認証だけでなく、ドメインの一致（アラインメント）だからです。

• について
• 最新記事

マイサム・アル・ラワティ

サイバーセキュリティの専門家、CEO（ PowerDMARCのCEO

マイサムは技術起業家であり、サイバーセキュリティの専門家であり、15年以上の業界経験を持つPowerDMARCのCEO兼創設者である。Maithamはマンチェスター大学でグローバルMBAを取得し、CISSP、CISM、CRISC、ISC2 CCSPなど様々な専門資格を持つ。

最新記事 by Maitham Al Lawati(全て見る)

• DMARCポリシーとは？「なし」、「隔離」、「拒否」 - 2026年7月27日
• Dmarcコンプライアンス：その概要、重要性、および確認方法 - 2026年7月21日
• DMARCの設定方法：完全なステップバイステップ設定ガイド（2026年） - 2026年6月20日