DMARC（ディーマーク）

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、メールの送信ドメイン認証の仕組み。ドメイン所有者が _dmarc.<ドメイン> にTXTレコードを公開し、受信側はそれを見て「SPF／DKIMの認証に通らなかったメールをどう扱うか」を決める。

• 認証の土台はSPFとDKIM: SPFは「このドメインのメールを送ってよいサーバー」の一覧、DKIMは送信サーバーが付ける電子署名。DMARCはこの2つの結果と、差出人（From）ドメインとの一致（アラインメント）を組み合わせて合否を出す。
• ポリシー（pタグ）: none（監視のみ）、quarantine（迷惑メールフォルダへ）、reject（受信拒否）の3段階。
• レポート（ruaタグ）: 受信側から「誰があなたのドメインを名乗って送っていたか」の集計レポートが届く。正規の送信経路を洗い出し、なりすましを見つける唯一の手段。

2024年2月、GmailとYahoo!が大量送信者向けガイドラインの適用を始め、SPF・DKIM・DMARCの設定とアラインメントは事実上の必須条件になった。認証を通らないメールは迷惑メール判定や受信拒否の対象になり、ECでは注文確認メールや、新しいお客様アカウントのワンタイムコードが「届かない」という形で表面化する。

Shopifyストアでは、Shopifyが代理送信する通知メールに対して送信ドメインの認証（Shopify側が指定するDKIM／リターンパス用DNSレコードの追加）を済ませないと、差出人がストアのドメインではなくShopify側のドメインにフォールバックし、ブランドドメインとしての認証が成立しない。さらにKlaviyoやDotdigitalなどのMAツール、ResendやSendGridのような外部送信基盤、課金・決済系サービスなど、同じドメイン名で送信する経路が増えるほど、それぞれのSPF／DKIMをそろえて一本のポリシー配下に収める運用が必要になる。

2026年5月には約10年ぶりの改訂版（DMARCbis）が、RFC 9989（本体）・RFC 9990（集計レポート）・RFC 9991（失敗レポート）として公開された。既存のレコードはそのまま有効だが、組織ドメインの判定がPublic Suffix ListからDNSを上位へたどる「DNS Tree Walk」に変わり、ほとんど無視されていたpctタグが廃止されてt（テスト）タグに置き換わり、存在しないサブドメイン向けのポリシーを宣言するnpタグが標準化された。導入手順は変わらず、「p=noneで監視 → 正規の送信元をすべて認証 → quarantine／rejectへ」が基本になる。

自社ドメインとクライアントストアのDMARC整備を、案件横断で進めている。新規構築や新しいお客様アカウントへの移行案件では、Shopifyの送信ドメイン認証とDMARCの状態確認をプロジェクトのスコープに必ず含め、外部送信基盤を併用する場合は経路ごとのSPF／DKIMアラインメントと迷惑メール判定の事前テストまで確認する。既存ドメインでは、SPFのDNSルックアップ上限（10回）の超過や、レコードの分割といった見落としやすい不備の診断も行う。導入後はGoogle Postmaster ToolsとDMARC集計レポートでモニタリングし、p=noneから段階的にポリシーを強める。DNS変更は必ずコーポレートITに通知する運用ルールを敷いている。