DMARCレコード無料 チェッカー

DMARCとは何か、そして2026年に重要な理由

DMARC(Domain-based Message Authentication, Reporting & Conformance)は、SPFとDKIMを結びつけるポリシー層です。SPFは、あなたのドメインに対してメール送信が許可されているIPを受信サーバーに伝えます。DKIMは各メッセージに暗号署名を行い、改ざんされていないことを受信者が検証できるようにします。DMARCは取扱説明書のようなもので、Gmail、Outlook、Yahoo、その他すべての受信プロバイダーに対して、あなたのドメインを名乗るメッセージがいずれか(または両方)のチェックに失敗したときの処理方法を伝えます。DMARCがなければ、攻撃者はFromアドレスを偽装し、あなたのレピュテーションを利用して顧客の受信箱に直接侵入できてしまいます。

2026年において、これはもはや任意ではありません。2024年2月以降、そして2025年・2026年を通じて段階的に厳格化されてきた要件として、GmailとYahooは1日5,000通を超えるメールを送信するすべての送信者に有効なDMARCレコードを義務付けています。Microsoft 365も大量送信者向けに同様の強制を実施しています。DMARCのないドメインでは、大量メールがバウンスされるか直接迷惑メールに振り分けられ、ブランドなりすましのフィッシング率はDMARCがない場合およそ2倍になります。

DMARCレコードの構造

DMARCレコードは、_dmarc.yourdomain.comに公開する単一のTXTレコードです。セミコロン区切りのタグのリストで構成されます。典型的なレコードと各要素の役割は以下のとおりです。

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r;

• v=DMARC1 — 必須のバージョンタグ。正確にDMARC1である必要があります(大文字小文字を区別)。そうでなければレコード全体が無視されます。
• p= — ポリシー本体。p=noneは監視のみで、失敗したメールも配信されます。p=quarantineは失敗メールを迷惑メールフォルダに送ります。p=rejectはSMTPの境界でメッセージを完全にブロックします。
• rua= — 集計レポートの送信先メールボックス。受信側は、あなたのドメインを使ってメール送信したIPと、何件のメッセージが認証を通過/失敗したかをまとめた日次のXMLレポートを送ってきます。形式:rua=mailto:dmarc-reports@yourdomain.com。
• ruf= — フォレンジック(失敗)レポートの送信先メールボックス。ヘッダーと(時には黒塗りされた)本文を含む、メッセージごとの失敗サンプルです。プライバシー上の理由から、ほとんどのプロバイダーは現在これを送信していないため、実用上はruaのほうがはるかに有用です。
• pct= — ポリシーを適用する失敗メールの割合(1〜100)。段階的なロールアウトを可能にします。pct=25とp=quarantineを組み合わせると、失敗のうち4分の1だけが隔離され、75%は配信されます。
• aspf= / adkim= — アライメントモード。aspf=s/rとadkim=s/rは、SPF/DKIMのドメインマッチングをstrict(完全一致)にするかrelaxed(サブドメインを許可)にするかを制御します。デフォルトはrelaxedで、ほとんどの場合これが望ましい設定です。

DMARCのよくある5つのエラーと修正方法

エラー:DMARCレコードが見つからない

最も一般的な失敗パターンです。dig TXT _dmarc.yourdomain.comを実行して何も返ってこない場合、レコードが存在しません。3つ確認してください。(1)ルートドメインではなく、サブドメインの_dmarcにTXTレコードを公開したか。(2)ホストフィールドが正確に_dmarc(先頭にアンダースコア付き)になっているか(一部のDNS UIではアンダースコアを削除します)。(3)伝播を待ったか。TTLは通常300〜3600秒ですが、CloudflareとRoute53は通常1分以内に反映されます。大文字の_DMARCは避けてください——DNSラベルは大文字小文字を区別しませんが、一部のバリデータは厳格です。

エラー:複数のDMARCレコード

_dmarcに2つ以上のTXTレコードが存在する場合、RFC 7489は受信側にすべてを無視するよう要求しているため、あなたのドメインはポリシーなしの状態になります。これは、マーケティングツールや移行スクリプトが既存のレコードを削除せずに2つ目を公開したときによく発生します。dig +short TXT _dmarc.yourdomain.comを実行し、v=DMARC1の行が複数表示される場合は、古いものや弱いものを削除してください。必要なすべてのタグ(p、rua、ruf、pct、aspf、adkim)を含む単一のレコードに統合します。

エラー:構文が無効

DMARCのパーサーは厳格です。最もよくある5つの構文エラー:(1)タグ間のセミコロン抜け——タグペアは必ず;で終わる必要があります。(2)mailto URIの中で適切にエンコードされていない=記号を使用。(3)Word文書からコピペしたスマートクォートを通常のASCIIクォートの代わりに使用。(4)p=quarentineやp=rejctのようなタイプミス。(5)DNS UIが既にクォートを追加しているのに、レコード全体を余分なクォートで囲む。上記のチェッカーで検証してください——タグごとに解析し、どのトークンが失敗したかを正確に教えてくれます。

エラー:SPF/DKIMアライメントの失敗

DMARCがパスするのは、SPFまたはDKIMの少なくとも一方が認証され、Fromドメインとアライメントしている場合のみです。よくある落とし穴:あなたのESP(例:Mailchimp)はbounces.mcsv.netのような独自のreturn-pathで認証するため、SPFはパスしますがyourdomain.comとアライメントしません。修正するには、ESPで自ドメインによるDKIM署名を有効にしてください——DKIMアライメントはSPFアライメントよりも簡単です。DKIM署名のd=タグをルートドメインと一致させられるからです。サブドメインの場合は、aspf=rとadkim=r(relaxed、デフォルト)を設定して、サブドメインメールがルートとアライメントするようにします。

DMARC設定の5ステップ手順

1. 現在の認証状況を監査する — DMARCを公開する前に、SPFとDKIMを修正します。送信に使用するすべてのドメインとサブドメインに対してSPFチェッカーとDKIMチェッカーを実行してください。SPFが10回のDNSルックアップ制限内で-allまたは~allで終わっていることを確認します。DKIMが2048ビットの鍵で署名され、Fromドメインとアライメントしていることを確認します。
2. 監視用レコード(p=none)を公開する — ホスト_dmarcに次のTXTレコードを追加します:v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r。p=noneはメールフローに影響しません——受信側は、何も隔離・拒否することなく集計レポートを送り始めます。これがデータ収集フェーズです。生のXMLは大規模では読めないため、専用のメールボックスかDMARCアナライザツールを使ってください。
3. 集計レポートを収集する — 24時間以内に、主要な受信側から日次のXMLレポートが届き始めるはずです。これを解析して、あなたのドメインを使ってメール送信しているIPとプラットフォームをすべて特定します。期待される送信者(Google Workspace、Mailchimp、SendGrid)はパスするはずです。予期しない送信者はシャドーITか偽装者のいずれかなので、ポリシーを厳格化する前に調査してください。
4. pct=25でquarantineに進む — 正規メールの95%以上がSPFとDKIMの両方をアライメント付きでパスするようになったら、v=DMARC1; p=quarantine; pct=25; rua=...;に厳格化します。これで失敗メールの25%が迷惑メールに送られます。誤検知についてレポートとヘルプデスクのチケットを観察してください。2週間問題なければ、pctを50に、その後100に上げます。
5. p=rejectに到達する — 最終形態:v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100;。失敗メールはSMTPの境界でバウンスされ、フィッシャーはあなたのドメインを偽装できなくなります。これがブランドを完全に保護する唯一の設定です。ほとんどのドメインは、p=noneから開始して8週間以内にrejectに到達します。

DMARCロールアウトのフェーズ(4〜8週間)

安全なDMARCロールアウトでは、配信性に悪影響を及ぼす前に設定ミスを検出できるよう、パーセンテージベースの段階的な進行を取ります。最低限実用的なタイムラインは4週間ですが、多くの送信プラットフォームを持つ組織にとっては8週間のほうが安全です。

• 週1〜2:監視(p=none) — rua=レポートを伴うp=noneを公開します。集計レポートを収集し、すべての正規送信者を特定し、SPF/DKIMのギャップを修正します。ITが把握していないシャドーESPが少なくとも1つ見つかると思っておきましょう。
• 週3〜4:Quarantine pct=25 — p=quarantine; pct=25に切り替えます。未認証メールの4分の1が迷惑メールに振り分けられるようになります。正規メールに予想外の落ち込みがないか、レポートを毎日監視してください。送信者が壊れたら、p=noneに戻し、修正してから再試行します。
• 週5〜6:Quarantine pct=100 — p=quarantine; pct=100まで引き上げます。失敗メールはすべて迷惑メールに送られます。この時点で、レポートは既知の送信者からのパス率99%以上を示すはずです。あなたのドメインを偽装するメールは、受信者の受信箱で無効化されます。
• 週7〜8:Reject — p=reject; pct=100に進みます。失敗メールはSMTPトランザクションでバウンスされ、受信者にはまったく届きません。これが目的地の状態です。レポート(rua=)はオンのままにしておき、新しいESPが追加されたときに後退を発見できるようにします。

GmailとYahoo 2026年要件

GmailまたはYahooのアドレスに1日5,000通を超えるメッセージを送信する場合、DMARCは必須です。最低限受け入れられるレコードはp=noneですが、Google自身のガイダンスでは現在p=quarantineまたはそれ以上を推奨しています。有効なDMARCレコードがない場合、大量送信者は5.7.26「authentication email is not accepted」でメッセージがバウンスされるか、内容に関係なく直接迷惑メールに振り分けられます。2026年のその他の要件も加わります:ヘッダーでのワンクリック登録解除、迷惑メール苦情率0.3%未満、SMTPでのTLS。DMARCはこれらの中で最も実装が安価で——通常はTXTレコード1つと30分の作業——、トランザクションメールとマーケティングメールの配信性に最も大きく寄与します。