# DMARC とは？アライメント、ポリシー、2026年のRFC URL: https://notificationharbor.com/ja/journal/dmarc-to-wa Type: blog Locale: ja Published: 2026-09-29 Updated: 2026-09-29 --- > DMARCはアライメント失敗時の対処方法を受信側に指示します。レコード、ポリシー、レポート、そして2026年の変更について説明します。 DMARC とはメールサーバーに指示を与えるDNSレコードです。送信者が自分のドメインをFromヘッダーで宣言しているのに、実際にはメール認証に失敗している場合、受信側サーバーはどのような対応をすればよいか、そしてその結果をどこに報告するかを指定するものです。DMARC自体は認証機能を持ちません。SPFまたはDKIMが成功し、その認証に使用されたドメインが送信者が主張するドメインと一致しているかをチェックするだけです。 この一致をアライメント（alignment）と呼びます。そしてアライメントの理解不足が最も多い失敗原因です。メールがSPFに合格し、DKIMにも合格していながら、DMARCには不合格となることがあります。 ## DMARCはSPFとDKIMの上に構築されたポリシーレイヤーです SPFは、あるドメインの代わりにメールを送信できるIPアドレスを指定します。DKIMはメッセージに署名をして、受信側が改ざんされていないことを確認でき、また署名ドメインがこのメッセージを送信することを承認していることを証明します。どちらも送信者が人間に見える形で指定するFromアドレスを検証しません。 DMARCはこのギャップを埋めます。単純な問いを立てます。送信者が人間に見える形で指定するFromヘッダーのドメインは、SPFまたはDKIMで検証されたドメインと一致しているか。Yes であれば、メッセージは合格です。No であれば、受信側はあなたが設定したポリシーを適用します。 ![エンジニアがノートパソコンの端末でDNSレコードを確認しています](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) DMARCレコードは `_dmarc.yourdomain.com` というDNS TXTレコードとして存在します。最小限で有効なレコードは次のようになります： `_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"`実装に必須のタグは3つです。`p` がポリシー、`rua` は集約レポートの送信先、そして `adkim` / `aspf` はアライメントのチェック方法を指定します。その他のタグはすべてオプショナルです。 ## アライメント失敗はよい設定でも起こります SPFはエンベロープ送信者、Return-Pathドメインを認証します。DKIMは署名の `d=` タグに指定されたドメインを認証します。DMARCはこれらのうち少なくとも一つが Fromドメインと一致していることが必要です。完全一致（strict）で、あるいは組織レベルで一致（relaxed、デフォルト）するかのいずれかです。 これが現実で最もよく見かける失敗パターンです。チームが外部のメール送信プロバイダを通じてメールを送り、プロバイダが自社ドメイン（`d=provider-mail.net`）で署名をして、自社のバウンスドメインを使用しています。SPFに合格し、DKIMにも合格します。しかしDMARCには不合格になります。どちらのドメインも `example.com` と一致していないからです。 解決策は、カスタム送信ドメインを使うことです。自社ドメインの配下にDKIMキーを公開し、理想的には自社のサブドメインでカスタムリターンパスを設定します。どの主要なプロバイダもこれをサポートしています。ただし、デフォルトで有効になっていることは稀です。 ## 3つのポリシー：none、quarantine、reject `p` タグには3つの値があり、これらはスケジュールに沿って段階的に上げるステップではありません。 - **`p=none`**: 受信側は通常通り配信し、レポートを送信します。最初の2〜4週間はこれを使用して、送信者をリストアップしましょう。 - **`p=quarantine`**: 受信側は不合格のメールをスパムやジャンク箱に移動させます。すべての正当な送信者がアライメント済みであることがレポートで確認されたら使用します。 - **`p=reject`**: 受信側はSMTPステージで不合格メールを拒否します。quarantine ポリシーが1度の送信サイクルを通して問題なく稼働したら使用します。 `p=none` は保護ではなくモニタリングです。2年間 none のままにされているドメインは、コンプライアンスチェックボックスは満たしていますが、なりすまし対策には何ら効果がありません。「何も破壊されないから」という理由でそこに留めておく誘惑を避けましょう。 `p=reject` は、あなたが管理するメール送信のみを行うドメイン向けの最終地点です。メーリングリストのトラフィックが多いドメインやレガシーフォワーダーを使用するドメインは、フォワーディングがSPFを破壊することが多く、本文を編集するとDKIMも破壊される可能性があるため、より慎重な対応が必要です。 ## GmailとYahooのルール変更がこれを急務にしました 2024年2月以降、[Googleのメール送信ガイドライン](https://support.google.com/mail/answer/81126?hl=en)では、Gmail アカウントに1日5,000件以上のメールを送信するすべての送信者に、DMARCレコード、SPF、DKIMを発行することを要求しています。ポリシーは `none` でもかまいません。Googleはまた、バルク送信者に対して、Postmaster Tools での送信者報告スパムレートを0.30%以下に保つことを推奨し、0.10%未満を目指すよう奨励しています。 [Yahoo Sender Hub](https://senders.yahooinc.com/best-practices/) は同じ基本的な要件を述べています：有効なDMARC ポリシー（少なくとも `p=none`）の発行、FromドメインはSPFまたはDKIMドメインと一致している必要があります。relaxed アライメントで問題ありません。 これらのルールに何が含まれ、何が含まれていないかに注意してください。要件は、レコードを発行すること、そしてアライメントが成功することです。ポリシーの強制（enforcement）ではありません。これはベースラインです。終了地点ではありません。 ![夕暮れ時のコンテナターミナルで下げられた税関バリア](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## 集約レポートが製品で、ポリシーがスイッチです `rua` アドレスには、DMARCを認識するすべての受信側からの日次XMLレポートが届きます。各レポートには、送信元IP、メッセージ数、SPFとDKIMの結果、そしてアライメント成功の有無がリストされています。これが、忘れられていた送信者を発見する方法です：古いCRMエクスポート、誰かが2022年に配線した課金ツール、誰も所有していないサブドメイン上のマーケティングフォーム。 生のXMLは大量にあると読み込めません。`rua` をパーサーが処理できるメールボックスに送るか、ホスト型DMARC レポートサービスに送り、送信元でグループ化されたデータを見ます。目指すべき状態は：すべての正当な送信者が100%アライメント済みで表示されること、そしてそれ以外はすべて明確に「未知」と表示されることです。 実践的なロールアウト順序は以下の通りです： - `p=none` と `rua` アドレスを発行します。 - 2〜4週間のレポートを収集します。送信者インベントリを作成します。 - アライメント失敗している正当な送信者ごとに、カスタムDKIMドメインまたはリターンパスで対応します。 - `p=quarantine` に移動します。メール遅延についてのサポートチケットを監視します。 - quarantine が正当な失敗を示さないようになったら `p=reject` に移動します。 各ステップを分けて実施してください。ポリシー変更と新しい送信プロバイダを同じ週に追加することは、いかなる後退原因の特定も不可能にします。 ## DMARCbis はタグを変更しますが、あなたのレコードはそのままです 2026年、IETF は RFC 9989、RFC 9990、RFC 9991 を発行し、RFC 7489 を廃止しました。[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) がDMARC コアスペックです。集約レポートと失敗レポートはそれぞれ独立したドキュメントに移動されました。 レコード所有者にとって実践的な変更は小さいものです： - `pct`、`rf`、`ri` は削除されました。 - `t`（テストモード）が `pct` に置き換わります。`t=y` はレポートをしますが、ポリシーは強制しません。 - `np` は存在しないサブドメインのポリシーを設定し、`abc123.example.com` のようなアドレスになりすましを防ぎます。 - `psd` はパブリックサフィックスドメインをマークします。DNS ツリーウォークが古いPublic Suffix List ルックアップに置き換わります。 既存の `v=DMARC1` レコードは有効なままです。今日何も変更しないなら何も壊れません。新しいタグのプロバイダサポートはばらばらにロールアウトするため、何もしていないように見えるタグは、通常、受信側がまだ実装していないことを意味しています。 `np` タグはアーリーアダプターの価値があります。`p` がまだ `none` のままで `np=reject` を設定すれば、メール全体を強制対象に含めることなく、偽のサブドメインインチデント経路を閉じることができます。 ## サブドメイン、そしてデフォルトが継承される理由 組織ドメイン上のDMARC レコードはサブドメインにも適用されます（ `sp` で上書きしない限り）。この継承は便利ですが、罠にもなります。 マーケティング部門が `news.example.com` から別のプロバイダを通じてメール送信をしている場合、親のポリシーを継承します。そのプロバイダがアライメント済みのDKIMを用意する前に親を `p=reject` に移動させれば、ニュースレターが床に着地してしまいます。サブドメインが独自の送信者フレート，独自のロールアウトペースを持つ場合は、`_dmarc.news.example.com` に個別のDMARC レコードを公開します。 クリーンなアーキテクチャは最初からストリームをサブドメインで分離します。トランザクショナルメールを1つに、ライフサイクルメールを別の1つに、人的なメール処理をルートドメインに。それぞれが独自のDKIMキー、独自のレピュテーション、独自のDMARC レコードを持ちます。 ## Authentication-Results ヘッダーを読んでから推測してください メッセージが失敗した場合、受信側サーバーは理由を記録します。Gmailでは「メッセージのソースを表示」で `Authentication-Results` ヘッダーが公開されます。これはどのダッシュボードよりも多くの情報を示しています。 `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.provider-mail.net; dkim=pass header.d=provider-mail.net; dmarc=fail (p=NONE) header.from=example.com`左から右に読んでください。SPFは `bounce.provider-mail.net` で合格しました。DKIMは `provider-mail.net` で合格しました。DMARCは失敗しました。なぜならFromヘッダーは `example.com` を言っているのに、どちらの合格ドメインも一致していないからです。 `(p=NONE)` という記述は、受信側が見たポリシーを示しています。`none` では、このメッセージは実際に配信されました。`reject` なら、SMTP ステージで拒否されて、送信者は顧客から知らされていたでしょう。 2つのチェックがほとんどのケースを捉えます。DKIM 結果の `header.d` 値が自分のドメインであることを確認してください。次に `smtp.mailfrom` ドメインが自分のドメインまたはそのサブドメインであることを確認します。 ## SPFはルックアップ制限があり、DMARCがそれを露呈させます SPFは1回のSPF評価で10回のDNS ルックアップを許可しています。プロバイダごとの `include:` タグはそれぞれルックアップ予算を消費し、ネストされたinclude はさらに消費します。10回を超えると、SPF は永続的エラーを返します。これは失敗としてカウントされます。 5個から6個の送信ツールを持つチームは、SPF 失敗が見えなかったため、気づかずにこれに達するかもしれません。`rua` レポートが到着し始めると、パターンは明白です：1つの送信元が突然すべての受信側でSPF失敗し始めたのは、誰かが別の `include:` を追加した日からです。 この理由からも、DKIM アライメントを第一義的な成功パスとして頼ることが重要です。DKIMはほとんどのフォワーディング環境で有効に機能し、ルックアップ予算がなく、メッセージに結び付けられています。SPFを有効に保ち、しかしDMARC 成功をSPFだけに依存しないようにしてください。 ## DMARCができないこと DMARCは正確なドメインなりすましを防ぎます。ルックアライクドメイン（`examp1e.com`）は防ぎません。コンテンツを判断することもしません。悪い送信者レピュテーションを修正することもありません。完璧にアライメントされたドメインが購入リストに送信していれば、それでもスパムランドに落ちてしまいます。 また、モニタリングも替わりません。アライメントはサイレントに破壊されることがあります：DNSの変更がDKIM セレクタを削除する、プロバイダがキーをローテーションする、新しいツールが知らない間に送信を開始する。レポートは、ユーザーが知る前に発見する方法です。 DMARCレコードは他の製造コンフィグと同じように扱いましょう。バージョン管理に属し、変更はレビューを通します。そして `rua` メールボックスには所有者がいます。 ![赤いシーリングワックスで封筒を封印しています](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## レコード発行前にチェックすること これを一度走し抜いてください。単一のドメインなら1時間以下です。 - あなたのドメインの代わりにメール送信を行うすべてのシステムをリストアップ：プロダクト、課金、サポートデスク、CRM、マーケティング、カレンダー招待。 - それぞれがベンダーのドメインではなく、自分のドメインでDKIMに署名していることを確認してください。 - プロバイダがサポートしている場所では、カスタムリターンパスを設定してください。 - `rua` 送信先を誰かが読むメールボックスに指定してください。 - `p=none` で開始し、レビュー予定日をカレンダーに入れてください。 - ロールアウト中、毎週Google Postmaster Tools でスパムレートを確認してください。 ## ここから先へ レポートを見たことがないなら、`p=none` と `rua` アドレス付きで発行して、2週間後に届いたレポートを読んでください。最初のレポートはほぼ確実に、誰も思い出さなかった送信者を少なくとも1つ名前上げます。次の具体的なステップは、それらのどれを保つか決めることです。 ## FAQ ### DMARCは必須ですか？ バルク送信者にとっては実質的にはい。Googleは1日5,000件以上のメッセージをGmailに送信する送信者にDMARCレコードを要求し、Yahooは少なくともp=noneの有効なポリシーを要求しています。強制は必須ではありませんが、レコードとアライメントは必須です。 ### DMARCでp=noneとは何を意味しますか？ それはモニタリングのみを意味します。受信側は不合格メールを通常通り配信し、レポートを送信します。GmailとYahooの最小要件を満たしていますが、なりすまし対策には何も提供しません。 ### メールがSPFとDKIMに合格してもなおDMARCに失敗する可能性はありますか？ はい。DMARCではSPFまたはDKIMで検証されたドメインがFromヘッダードメインと一致している必要があります。プロバイダを通じて送信され、プロバイダが独自のドメインで署名するメールは両方の確認に合格し、アライメント失敗になります。 ### p=noneにはどのくらいの期間留まるべきですか？ 通常は2〜4週間の集約レポート。低量の送信者を含む、すべての正当な送信者が表示されるのに十分な期間です。合法的な送信元それぞれがアライメント済みと表示されたら先に進みます。 ### DMARCは配信性に影響しますか？ 間接的に影響します。公開されたアライメント済みレコードはGmailとYahooでのベースライン要件で、アライメント失敗は強制ポリシー配下ではメール削除やスパム送信のトリガーになります。悪い送信者レピュテーションや高い苦情率は修正しません。 ### DMARCbisとRFC 9989では何が変わりましたか？ RFC 9989はRFC 7489を廃止します。pct、rf、riを削除し、t、np、psdを追加し、Public Suffix Listルックアップを DNS ツリーウォークで置き換えます。既存のv=DMARC1レコードは有効なままです。