DMARCの要件とは？ グローバルなルール、ポリシー、およびコンプライアンス

DMARCの要件は、もはや単なる技術的な推奨事項ではありません。現在では、世界的な規制、業界のコンプライアンス・フレームワーク、メールボックスプロバイダーのルールなどが相まって、その形が定まりつつあります。多くの地域の政府や公的機関は、公的ドメインを保護するための正式な要件としてDMARCを定めており、PCI DSSなどの規格においても、 電子メール認証 を、より広範なセキュリティコンプライアンスの一環として扱うようになっています。同時に、Google、Yahoo、Microsoftなどのプロバイダーは、送信者、特に大規模に送信を行う送信者に対して、より強力な認証を期待するようになっています。

この変化により、DMARCはもはや なりすましを防ぐことだけにとどまりません。現在では、メールの配信率、ブランド保護、顧客の信頼、そして規制への対応において、直接的な役割を果たしています。多くの組織にとって、DMARCの要件を満たせないことは、メールの配信拒否、フィッシングリスクの増大、そして無視し難いコンプライアンス上の不備につながる可能性があります。

2026年5月にDMARCbisがIETFの公式標準（RFC 9989、9990、および9991）として公開されたことは、この変化をさらに裏付けるものです。DMARCは、情報提供を目的としたRFCから「提案標準」へと移行し、電子メール業界がこれをもはやオプションのレイヤーではなく、基盤となるインフラとして位置づけていることを示しています。

本ガイドでは、こうした広い視点からDMARCの要件について解説します。ここでは、導入を推進する世界的な規則や義務、送信者が満たすべきプロバイダーレベルの要件、および以下の技術的基盤について取り上げます。 SPF、 DKIM、アラインメントなど、コンプライアンスを支援するために必要な技術的基盤についても解説します。

DMARCの要件とは何ですか？

DMARC要件とは、ドメイン所有者が「ドメインベースのメッセージ認証、報告、および適合性（Domain-based Message Authentication, Reporting, and Conformance）」を適切に実装するために満たさなければならない技術的およびポリシー上の基準を指します。

これらは、規制上の義務、プロバイダーの要件、そしてDMARCを正しく実装するために必要な技術基準という3つの層にまたがって存在しています。

DMARCは、その根本において 電子メール認証プロトコル であり、Sender Policy Framework（SPF）およびDomainKeys Identified Mail（DKIM）を基盤として、送信されるメッセージが、そのメッセージが代表すると主張するドメインから真正に発信されたものであることを検証します。

メッセージがこれらの認証チェックに失敗した場合、DMARCポリシーに基づき、受信メールサーバーはそのメッセージに対してどのような処理を行うべきかが指示されます。

ドメインが以下の条件を満たす場合、DMARCの要件を満たしています：

• 送信ドメインに対してSPFおよびDKIMが正しく設定されています
• 有効なDMARC DNS TXTレコードが公開されました
• SPFまたはDKIMの少なくとも一方が有効であり、かつFromヘッダーのドメインと一致している
• DMARCレポートは積極的に監視されています

変化したのは、その重要度です。現在、DMARCの要件は、世界中の多くの国や規制枠組みにおいて義務付けられ、または強制されています。また、 Google、Yahoo、 Microsoft、および PCI DSS、そしてコンプライアンス違反は、メールの配信率、ブランドの信頼性、および規制上の立場に直接的な影響を及ぼします。

DMARC要件の種類

DMARCの要件は、以下の3つのカテゴリーに分類できます：

• 規制要件： 政府や、CISA（米国）、NCSC（英国）、NIS2（EU）などのコンプライアンス機関による義務付け。これらは、より広範なサイバーセキュリティ基準の一環として、組織に対しDMARCの導入と実施を義務付けています。
• プロバイダーの要件： Google、Yahoo、Microsoftなどのメールボックスプロバイダーによる適用ルール。特に大量送信者については、認証とポリシーの遵守がメールの配信率に直接影響します。
• 技術要件： DMARCを正しく実装するために必要な基本的な設定。これには、SPF、DKIM、DMARCポリシー、および適切なドメインの整合性が含まれます。

これらのレイヤーがどのように連携して機能するかを理解することは、DMARCへの完全な準拠を達成し、維持するために不可欠です。

地域別のグローバルDMARC要件

DMARCは現在、多くの国や規制枠組みにおいて義務化または適用が求められており、安全な電子メールインフラの必須要件となっています。以下に、主要な義務化の現状をまとめます。

米国

米国連邦政府は、国家レベルでDMARCの導入を義務付けた最初の機関の一つである。2017年、国土安全保障省は 「拘束力のある運用指令18-01（BOD 18-01）」を発行し、すべての連邦行政機関に対し、1年以内にp=rejectを最低基準とするポリシーでDMARCを導入するよう義務付けました。

CISA（サイバーセキュリティ・インフラセキュリティ庁）は引き続きこれらの基準の監督と施行を行っており、この指令はすべての.govドメインに対して有効です。BOD 18-01は世界的な先例となり、その後、他の政府もこれに倣っています。

イギリス

英国の 英国の国家サイバーセキュリティセンター（NCSC）は は、すべての中央省庁および公共部門の組織に対し、DMARCの導入を義務付けています。NCSCは、最低限のポリシーとして「p=reject」を推奨しており、組織に対してこれを確実に適用するよう求める具体的なガイダンスを公表しています。

英国政府はまた、公共機関が電子メールの認証体制を監視・改善できるよう支援する「Mail Check」サービスも運営しています。

欧州連合

The NIS2指令は、2024年10月にEU加盟国全域で発効し、エネルギー、金融、医療、デジタルインフラなどの重要インフラ分野に対して、法的拘束力のあるサイバーセキュリティ要件を定めています。

DMARCを含む電子メールセキュリティ対策は、組織がコンプライアンスを証明するために実施しなければならない基本的な技術的措置として挙げられています。

NIS2ではすべての条項においてDMARCを明示的に言及しているわけではないが、いくつかの加盟国の監督当局は、監査の際に必要な管理措置としてDMARCを参照し始めている。

オーストラリア

オーストラリア・サイバーセキュリティ・センター（ACSC） オーストラリア・サイバーセキュリティセンター（ACSC）は、オーストラリア信号局（ASD）の管轄下で運営されており、オーストラリア政府のドメインに対してDMARCの導入を義務付けており、すべての民間組織に対してもその導入を強く推奨しています。

その ACSCの サイバーセキュリティインシデントを軽減するための戦略 フレームワーク では、電子メール認証が優先的な対策として挙げられており、政府機関はこれの完全な実施が求められている。

カナダ

カナダ財務省 カナダ財務委員会事務局 は、電子メールセキュリティに関する指針の一環として、連邦政府機関全体でのDMARC導入を義務付けています。カナダの連邦政府ドメインは、国際基準に沿ったDMARCポリシーを公開し、実施することが求められています。

その他の運用委託案件

Google、Yahoo、およびMicrosoftのDMARC要件

規制当局の義務に加え、メールボックスプロバイダーは現在、特に大量送信者に対して、受信トレイへの配信要件としてDMARCの適用を義務付けています。貴社が大量送信者に該当する場合、これらの要件はすでに適用されています。

どのような場合が大量送信者とみなされますか？

大量メール送信者とは、Gmailアカウントに対して1日あたり5,000通以上のメールを送信する者を指します。Yahoo!も同様の基準を採用しています。Microsoftは独自の基準で大量メールを分類していますが、同等の認証基準を適用しています。

要件の概要

詳細については、 GoogleおよびYahooのメール認証要件 の更新記事に記載されています。また、 Googleの送信者ガイドライン を直接ご確認いただけます。

執行のスケジュール

2026年5月現在、主要な3社すべてにおいて、この措置が完全に実施されています：

• Google/Gmail：2024年2月より一時的な配信保留（421エラー）を開始しました。2025年11月には恒久的な配信拒否（550エラー）へと移行しました。現在、規定に準拠していない大量送信者に対しては、恒久的な配信失敗が発生しています。
• Yahoo：Gmailと同様の認証要件を採用し、同等の厳格さで適用しています。
• Microsoft/Outlook：要件は2025年5月に発表されました。警告は2025年8月から開始されました。完全な拒否措置（エラーコード 550 5.7.515）は2025年11月から適用されています。

Microsoftのコンプライアンスに関する詳細なガイダンスについては、以下を参照してください： MicrosoftのOutlookにおけるDMARC要件

規定に違反すると、Gmail、Yahoo、および Outlook アカウントの顧客への配信に重大な影響を及ぼす可能性があります。これらの要件を満たせない組織は、一時的および恒久的なメールの受信拒否に直面することになるため、これらの要件に先んじて対応することが不可欠です。

DMARCbis：新しいDMARC規格（RFC 9989、9990、9991）

2026年5月21日、IETFはDMARCbis仕様を3つの新しいRFCとして正式に公開し、元のDMARC仕様（RFC 7489）に取って代わりました：

• RFC 9989: DMARCbisのコア仕様。DMARCのアライメント、ポリシーの処理、およびドメイン検証ルールを更新する。
• RFC 9990：相互運用性と明確性を向上させるための集計報告基準の更新。
• RFC 9991：セキュリティに関する指針を強化し、障害報告の基準を更新しました。

最も大きな変更点は、DMARCが情報提供を目的としたRFCから「提案標準」へと格上げされたことです。これは、このプロトコルが正式にインターネット標準として認められ、電子メールエコシステム全体において、より厳格な実装が求められるようになったことを意味します。

DMARCbisがコンプライアンスに与える影響

• 整合性の要件が厳格化されたことで、SPFおよびDKIMが「From」ヘッダーのドメインと適切に整合していることを確認することが、これまで以上に重要になっています。
• レポート基準の改善により、認証失敗の状況がより明確になり、問題の診断と修正が容易になります。
• 更新された標準では、パブリックサフィックスリストの代わりにDNSツリー探索アルゴリズムを採用しており、ドメイン検索の精度が向上しています。
• 既存のDMARC要件をすでに満たしている組織は有利な立場にあります。DMARCbisは、コアプロトコルを置き換えるのではなく、それを改良するものです。

詳細はこちら： DMARCbisの解説 – 変更点と準備方法

PCI DSS準拠のためのDMARC要件

決済カードデータを扱う組織にとって、DMARCは規制上の要件です。

ペイメント・カード・インダストリー・セキュリティ・スタンダード・カウンシル（PCI SSC）は、PCIデータセキュリティ基準の一環としてDMARCの導入を義務付けました。この義務付けが行われた背景には、電子メール詐欺、ドメインのなりすまし、およびビジネスメール詐欺が、決済エコシステムにおける組織を標的とする主な攻撃経路となっていることがあります。

2025年3月31日をもって、PCI DSS v4.0の「将来適用」とされていた全51項目の要件が完全に義務化されました。これには、DMARC、SPF、DKIMなどの自動化されたフィッシング対策メカニズムを義務付けるセクション5.4.1も含まれます。2026年に実施されるすべてのPCI DSSアセスメントは、PCI DSS v4.0.1に基づいて評価され、これらの管理措置については猶予期間は一切設けられません。

コンプライアンス違反が決済事業者にとって意味すること：

• 決済カード取引の取扱権の喪失
• 顧客やパートナーを標的としたブランドなりすまし攻撃への曝露
• ビジネスメール詐欺やフィッシングメールに対する脆弱性が高まっている
• 違反があった場合、1か月につき5,000ドルから100,000ドルの罰金が科される可能性があります

PCI DSS以外にも、DMARCは電子メールセキュリティの基盤となる対策として、他の規制枠組みにおいてますます重視されるようになっています。連邦政府のコンプライアンス要件の対象となる組織は、DMARCが自社のより広範な義務にどのように適合するかを検討すべきです。

関連情報： PCI DSS メールコンプライアンス：バージョン4.0に向けたDMARC戦略

DMARCの要件を満たさない場合、どうなるのか

DMARCの要件を満たさないことによるリスクは、具体的かつ差し迫ったものであり、場合によってはその影響を元に戻すのが極めて困難です。

配信率への影響

評判への影響

DMARCポリシーを設定していないと、あなたのドメインが、あたかもあなたの組織から直接送信されたかのように見せかけるフィッシングメールや悪意のあるメッセージの送信に悪用される恐れがあります。

DMARCの要件を満たしていない企業は、ブランドを装った詐欺や不正行為に頻繁に直面し、特に顧客が信頼できるドメインから送信されたように見える詐欺メールをすでに受け取っている場合、その被害からの回復が困難になることが多い。

最近の業界データによると、2026年初頭時点で有効なDMARCの導入は93万7,000ドメイン以上に達しましたが、強制レベル（隔離または拒否）のポリシーを設定しているのは、そのうち約41万2,000ドメインにとどまっています。このギャップにより、DMARCレコードを設定しているにもかかわらず、実際にはなりすましから保護されていないドメインが数十万件存在することになります。

規制上の影響

PCI DSSの適用対象となる組織については PCI DSSの対象となる組織において、DMARCを導入しない場合、決済処理の権利を失う可能性があります。これは、現行の基準における非準拠に対する明確な結果です。

必須の前提条件：SPFとDKIM

DMARCは、これなしでは機能しません SPF とDKIMが導入されていなければ機能しません。これら2つのメール認証方式はDMARCの基盤となるものであり、DMARCレコードを公開する前に、両方が正しく設定されている必要があります。

DMARCを導入する前に、SPFとDKIMを少なくとも48時間は有効にしておくことをお勧めします。そうすることで、失敗時に動作するポリシーを導入する前に、両方のメカニズムが正しく機能していることを確認する時間を確保できます。

送信者ポリシーフレームワーク（SPF

SPFとは DNSのTXTレコード であり、ドメインに代わってメールを送信する権限を持つすべてのIPアドレスを列挙します。受信サーバーが受信メールを受け取ると、送信元のIPアドレスがSPFレコードに記載されているかどうかを確認します。

注意すべき2つの一般的なSPFに関する問題：

• SPFの無効なルックアップ： DNS 検索が過剰に行われるレコードは、認証を静かに失敗させ、予期せぬ障害の最も一般的な原因の一つとなっています。詳細については SPFの無効なルックアップ とその修正方法について詳しくご覧ください。
• 複雑な送信インフラ： 多数の承認済み送信者を管理する組織は、 SPFマクロ を使用することで、 ルックアップ制限。

SPFレコードがRFC 7208で規定されている10回のDNSルックアップ制限を超過した場合、 PermErrorが返され、DMARCではこれを失敗として扱います。送信設定が複雑な組織は、 SPFフラット化 または PowerSPF を検討し、制限値を超えないようにする必要があります。

DomainKeys Identified Mail (DKIM)

DKIM 送信メッセージに暗号化されたデジタル署名を付加し、受信サーバーがメッセージ本文やヘッダーが転送中に改ざんされていないことを確認できるようにします。

DMARCにおけるDKIMの整合性確認では、Fromヘッダーのドメインが、DKIM署名のd=タグで指定されたドメインと一致している必要があります。技術的には有効であっても、Fromドメインと一致しないDKIM署名は、DMARCの検証に失敗します。

DMARCの設定手順ガイド

SPFとDKIMの設定が完了し、検証に合格したら、DMARCレコードを公開できます。レコードに誤りがあると、ドメインが保護されない状態になるか、正当なメールの認証に失敗する可能性があるため、この設定を正しく行うことが極めて重要です。

セットアップの手順

1. SPFとDKIMが有効になっていることを確認してください かつ、少なくとも48時間稼働していることを確認してください
2. DNSのTXTレコードを作成する で _dmarc.yourdomain.com
3. まずは「p=none」ポリシーから始める 配信に影響を与えずにデータを収集するために
4. レポート送信先アドレスを含める これにより、DMARCレポートがすぐに送信されるようになります
5. レコードを確認してください を使用して DMARC検索ツール 公開後に

DMARCレコードの構造

すべてのDMARC文字列は、 v=DMARC1で始まります。基本的な初期レコードは次のようになります：

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected];

DNSに関する追加要件

DMARCレコードそのものに加え、メール送信者は、有効なフォワードおよびリバース DNS PTRレコードを確保する必要があります。

受信サーバーは、PTRレコードを使用して、メッセージの送信元IPアドレスが送信ドメインと一致していることを確認します。PTRレコードの欠落や不一致は、認証失敗のよくある原因ですが、見過ごされがちなものです。

DMARCを導入するには、送信元ドメインごとにSPFおよびDKIMレコードを設定する必要があります。地域、製品、または事業部門ごとに複数のドメインを運用している組織は、すべてのドメインで認証レコードを適切に設定する必要があります。

DMARCポリシーレベルの解説

あなたの DMARCポリシー は、メールが認証チェックに失敗した際の処理を決定します。導入の各段階で適切なポリシーを選択することが、スムーズな導入と、意図せず正当なメールをブロックしてしまう事態との分かれ目となります。

ポリシー	その機能	使用タイミング
p=none	すべてのメールを配信し、レポートのみを生成します	まずは、送信者の監査から
p=quarantine	送信に失敗したメールをスパムフォルダに振り分ける	すべての正当な送信者を認証した後
p=reject	メールの受信を完全にブロックする	DMARCの完全適用段階

推奨される導入アプローチ

• メールの配信率に影響を与えずに監査を行うには、p=none から開始してください。これにより、適用前にすべての正当な送信者を特定するためのデータが得られます。
• すべての正当な送信者の認証が完了し、一貫して通過していることが確認でき次第、p=quarantine に移行する。
• ドメインのなりすましや不正なメッセージから完全に保護するには、p=reject に移行してください。

監視フェーズを完了せずに急いで「拒否」を選択することは、組織が誤って自社の正当なメールをブロックしてしまう最も一般的な原因の一つです。

2026年に「強制措置」への移行が重要となる理由の詳細については、以下をご覧ください： なぜ2026年にDMARCが重要なのか？

大規模な環境におけるDMARCの監視と管理方法

DMARCの要件を満たすことは、継続的な取り組みです。一貫した監視、明確な報告、そして適切なインフラこそが、コンプライアンスを維持し続ける組織と、再び脆弱な状態に陥ってしまう組織とを分ける要因となります。

DMARCレポートの理解

DMARC を使用すると、どのサーバーが貴社に代わってメールを送信しているか、またそれらのメッセージのうち認証に合格したものと不合格となったものの割合を把握することができます。このデータは、以下の 2 種類のレポートを通じて提供されます：

PowerDMARCの DMARCレポートツール は、生のXMLレポートデータを、見やすく実用的なダッシュボードに変換します。これにより、複雑なファイルを手作業で解析することなく、すべての送信ドメインにわたる成果を監視することができます。

サードパーティの送信者の管理

導入における最も一般的な課題の一つは、自社に代わってメールを送信するすべてのサードパーティの送信者を特定し、その認証を行うことです。

マーケティングプラットフォーム、CRM、ヘルプデスクツール、その他のサービスはすべて、お客様のドメインを使用してメッセージを送信します。これらを安全に隔離または拒否するには、それぞれを適切に認証する必要があります。

DMARCマネージドサービス 組織がこれらの送信者を特定し、すべてのメールチャネルで適切な認証が実施されていることを確認し、完全なコンプライアンス達成に必要な時間とリソースを削減するのに役立ちます。

複数のドメインにわたる拡張

組織が複数のドメインを運用するケースが増えているため、一元的な管理が不可欠となっています。多数のドメインにわたってDMARCレコードを手作業で管理することは、ミスが起きやすく、多大なリソースを要します。

ホスト型DMARCソリューション これにより、組織はレコードを一元的に管理し、ポリシー変更をすべてのドメインに同時に反映させ、単一のインターフェースからメールインフラ全体を可視化することができます。

大規模にクライアントのドメインを管理するMSPおよびMSSP向けに、PowerDMARCの マルチテナントプラットフォーム は、ホワイトラベル対応のダッシュボード、PSAとの連携、および11言語への対応を提供します。

社内の専門知識を構築する

管理型ツールと並行して社内のノウハウを蓄積したいチームのために、 PowerDMARCのトレーニングコースは は、長期的にメール認証を効果的に管理するために必要な専門知識を養うのに役立ちます。

さらに、認証失敗の最も多い原因である設定ミスを防ぐため、チームを支援しています。

完全な施行によって何が可能になるか

p=reject になると、DMARCは BIMI （Brand Indicators for Message Identification）への道を開きます。これにより、受信者の受信トレイにブランドロゴが直接表示されます。

BIMIは、DMARCの導入プロセスを適切に完了したことで得られる最も目に見える成果の一つであり、大量のメールを送信する送信者にとって強力な信頼の証となります。

電子メールインフラのセキュリティをさらに強化したい組織向けに、 MTA-STS は受信メールに対してTLS暗号化を強制し、DMARCが提供する保護機能に加えて、さらなる保護層を追加します。

PowerDMARCでDMARC要件を満たす

DMARCの要件はますます厳格化しています。Google、Yahoo、Microsoft、そしてPCI DSSはいずれも明確な基準を設けており、これに準拠していない組織は、すでにメールの配信拒否、送信者のレピュテーションの低下、ドメインの公開といった影響を被っています。

DMARCに完全に準拠するためには、すべての送信元を認証し、レポートを正確に解釈し、複数のドメインを管理し、正当なメールの配信を妨げることなくポリシーの段階を進めていく必要があります。これらを手作業で管理するのは非常に負担が大きいものです。

PowerDMARCは、最初のDNS TXTレコードの設定から「p=reject」の適用、さらにはその先までの全プロセスを簡素化します。

ホスト型DMARC、自動レポート機能、マネージドサービス、そして大規模な可視化を実現するために構築されたプラットフォームを備えたPowerDMARCは、現在の要件を満たし、今後の動向に先んじて対応するために必要なすべてを提供します。

今すぐPowerDMARCを使い始めましょう 今すぐ

よくあるご質問

1. DMARCを導入するには何が必要ですか？

DMARCでは、SPFまたはDKIM（できれば両方）を設定し、ドメインと整合させる必要があります。DNSに「p=none」で始まるDMARCポリシーを公開し、認証レポートを受信するためのレポート先アドレスを設定する必要があります。

2. DMARCは現在必須となっていますか？

2024年2月より、GmailおよびYahoo!メールへの大量送信者（1日あたり5,000通以上）にはDMARCが必須となります、また2025年5月からはMicrosoft Outlook.comへの送信においても必須となります。また、多くの国の政府機関もDMARCを義務付けています。普遍的に必須というわけではありませんが、メールを送信するすべての組織に対して強く推奨されています。

3. DMARCにはDKIMが必要ですか？

DMARCでは、アライメントに合格するためにSPFまたはDKIMのいずれかが必要ですが、両方の導入が推奨されます。技術的にはSPFのみでもDMARCを実装することは可能ですが、Google、Yahoo、Microsoft は大量送信者に対してDKIMを必須としているため、実際には両方の導入が必要となります。

4. DMARCはいつから必須となったのですか？

DMARCの要件は、2017年に米国の連邦政府機関から導入されました（BOD 18-01）。GoogleとYahooは、2024年2月に大量送信者向けの要件を導入しました。 Microsoftはこれに続き、2025年5月から適用を開始しました。PCI DSS v4.0では、2025年3月31日をもってDMARC関連のフィッシング対策が義務化されました。 2020年から2025年にかけて、多くの国でDMARC要件が導入され、その適用範囲は世界的に拡大し続けています。

5. DMARCの導入にはどのくらいの時間がかかりますか？

DMARCの導入には、その複雑さにもよりますが、通常4～12週間かかります。初期設定は数日で完了しますが、メールの配信率に悪影響が出ないよう、適切な監視、分析、および段階的なポリシーの適用を行うには、数週間を要します。

6. DMARCを導入しなかった場合、どうなるのでしょうか？

DMARCがない場合、Gmail、Yahoo、およびMicrosoftへの への一斉送信メールは、拒否されたりスパムとしてマークされたりする可能性があります。ドメインはなりすまし攻撃に対して脆弱なままとなり、規制産業ではコンプライアンス上の問題に直面する恐れがあります。メールの配信率や送信者のレピュテーションも悪化するでしょう。

7. DMARCbisとは何ですか？また、DMARCの要件は変更されますか？

DMARCbisは、2026年5月にRFC 9989、9990、および9991として公開されたDMARC仕様の更新版であり、元のRFC 7489に取って代わるものです。これにより、DMARCは「提案標準（Proposed Standard）」へと格上げされ、整合性ルールが強化され、レポート機能が改善されました。DMARCを実装するという基本的な要件に変更はありませんが、これは電子メール業界がDMARCを正式なインフラとして扱うようになったことを示しています。 既存の要件にすでに準拠している組織は、DMARCbisへの対応において有利な立場にあります。

8. マイクロソフトは現在、大量送信者に対してDMARCを義務付けていますか？

はい。2025年5月5日以降、Microsoftは、Outlook.com、Hotmail.com、およびLive.com宛てに1日あたり5,000通以上のメールを送信するすべてのドメインに対し、SPF、DKIM、およびDMARC（最低でもp=none）の適用を義務付けています。2025年11月より、非準拠のメールは完全に拒否される措置が実施されています。準拠していないメールには、エラーコード550 5.7.515が返されます。