---
title: "DMARCとは？SPF・DKIMとの違い、仕組みとレコードの書き方【RFC 9989対応】"
url: "https://www.issoh.co.jp/column/details/3287/"
published: 2024-08-05
updated: 2026-10-28
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# DMARCとは？SPF・DKIMとの違い、仕組みとレコードの書き方【RFC 9989対応】

DMARC（ディーマーク）は、メールの差出人欄（From）に表示されるドメインと、SPF・DKIMの認証結果を突き合わせ、認証に失敗したメールをどう扱ってほしいかを受信側に伝える仕組みです。あわせて、そのドメインを名乗るメールの認証結果を集計レポートで受け取れます。2026年5月にはDMARCの仕様が[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)として改訂され、使えるタグや組織ドメインの判定方法が変わりました。この記事では、SPF・DKIMとの違い、受信側の判定の流れ、レコードの書き方、実在ドメインのレコードの読み方、レポートの見方、ポリシーの選び方を順に説明します。

## まとめ｜DMARCの要点

- DMARCは「Fromのドメイン」と「SPFまたはDKIMで認証されたドメイン」が一致するか（アライメント）を見る。どちらか一方が一致して認証に通ればDMARCはpass。
- SPFは送信元IPを、DKIMは電子署名を検証するが、どちらも単独ではFromの表示を守れない。DMARCはその穴を埋め、失敗時の扱い（none／quarantine／reject）とレポート先を宣言する。
- レコードは `_dmarc.ドメイン名` のTXTに1本だけ公開する。2本あると両方とも無視される。
- 2026年5月のRFC 9989で、`pct`・`rf`・`ri` が廃止され、`np`・`psd`・`t` が加わった。組織ドメインの判定は公開サフィックスリストからDNSツリーウォークに変わった。
- Gmailは1日5,000件を超える送信者にDMARC（`p=none` で可）を求めている。防御効果が出るのはquarantine以上だが、メーリングリストへ投稿する利用者を抱えるドメインはrejectを公開すべきでないとRFC 9989は書いている。

## DMARCとは｜読み方と、SPF・DKIMだけでは防げないもの

DMARCは Domain-based Message Authentication, Reporting, and Conformance の略で、「ディーマーク」と読みます。メールの受信者が目にするのはFromヘッダのアドレスですが、SPFもDKIMも、このFromのドメインを直接は検証していません。

- SPFが調べるのは、SMTPの封筒の差出人（Return-Path、RFC5321.MailFrom）のドメインです。攻撃者は自分で取得したドメインでSPFを通し、Fromだけを銀行のドメインにできます。
- DKIMが調べるのは署名の `d=` に書かれたドメインです。署名は正しくても、`d=` が攻撃者のドメインならFromの詐称は止まりません。

DMARCはこの2つの結果を「Fromのドメインと一致しているか」という一点で束ね、一致しないメールの扱いをドメイン所有者が宣言できるようにします。従来の仕様RFC 7489は、IETFの作業部会を経ずに出された情報提供（Informational）の文書でした。2026年5月のRFC 9989は標準化過程（Standards Track）の文書で、RFC 7489を置き換えています。集計レポートはRFC 9990、失敗レポートはRFC 9991に分かれました。

## SPF・DKIM・DMARCの違い｜3つの送信ドメイン認証の役割

DMARCはSPFとDKIMの結果を使うため、単独では動きません。3つの違いを先に表で示します。

| 方式    | 検証するもの                          | DNSに置く場所                  | 転送に強いか             |
| ----- | ------------------------------- | ------------------------- | ------------------ |
| SPF   | 送信元IPがReturn-Pathドメインの許可リストにあるか | ドメイン直下のTXT                | 弱い（転送でIPが変わる）      |
| DKIM  | ヘッダと本文の電子署名（d=ドメイン）             | セレクタ.\_domainkey.ドメインのTXT | 強い（改変されなければ残る）     |
| DMARC | Fromドメインとの一致と、失敗時の扱い            | \_dmarc.ドメインのTXT          | アライメントしたDKIMが通れば維持 |

### SPF：送信元IPと許可リストの照合

SPFは、Return-Pathのドメインに公開された `v=spf1` のレコードに、送信元サーバーのIPアドレスが含まれるかを確かめます。`include`・`a`・`mx`・`ptr`・`exists`・`redirect` はDNS参照を伴い、その合計は[RFC 7208の4.6.4節](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4)で、評価中に現れるこれらの項目を合計10個までと定めています（include先の評価も含みます）。メール配信サービスを足すたびに `include` が増え、上限を超えるとSPFはエラー（permerror）になり、SPF経由のDMARC passも失われます。レコードの書き方は[SPFとは？メール認証の仕組み・SPFレコードの書き方と設定の判断基準を解説](/column/details/13466/)で扱っています。

### DKIM：署名ドメインd=とセレクタによる公開鍵の取得

DKIMでは、送信側のサーバーがメールに次のような署名ヘッダを付けます。

```
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2026;
    h=from:to:subject:date:message-id; bh=...; b=...
```

受信側は `s=`（セレクタ）と `d=`（署名ドメイン）から `mail2026._domainkey.example.com` のTXTを引き、そこに公開された鍵で署名を検証します。セレクタを分ければ、配信サービスごとに別の鍵を置けます。鍵が公開されているかは `dig +short txt mail2026._domainkey.example.com` で確かめられ、`v=DKIM1; k=rsa; p=…` が返れば公開済み、`p=` が空なら鍵は失効扱いです。鍵の長さは[RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html)が「RSAは1024ビット以上必須、2048ビット以上を推奨」と定め、rsa-sha1での署名を禁じています。Gmailも1,024ビット以上を必須、2,048ビットを推奨としています。DKIMの署名は、転送の途中で本文と署名対象のヘッダ（件名など）が書き換えられなければ有効なまま残るため、DMARCを転送に強くしたいならDKIMのアライメントを必ず通しておきます。

### DMARC：Fromとのアライメント・処理方針・レポート

DMARCが担うのは、Fromのドメインと認証済みドメインの一致の判定、一致しなかったメールの扱いの宣言（`p=`）、受信側からのレポートの受け取り（`rua=`・`ruf=`）です。SPFとDKIMが「誰が送ったか」を確かめ、DMARCがその結果を表示上の差出人に結び付けます。

## DMARCの仕組み｜受信側の判定フローとアライメント

RFC 9989の5.3節は、受信側の処理を次の順に定めています。

1. FromヘッダからAuthor Domain（表示上の差出人ドメイン）を取り出す。
2. DNSツリーウォークでDMARCレコードを探す。見つからなければDMARCは適用しない。
3. SPFとDKIMの結果から、passした認証済みドメインを集める。
4. そのドメインとFromのドメインのアライメントを確かめる。
5. SPFかDKIMのどちらか1つでもアライメントが取れて通っていればpass、なければfail。
6. failなら、宣言されたポリシーを踏まえて扱いを決める。
7. 結果を保存し、`rua` があれば集計レポートを送る。

最後の扱いは受信側の判断です。RFC 9989の5.4節は「メールの最終的な扱いは常に受信側のローカルポリシー」と書いています。さらに7.4節は、送信側が `p=reject` を公開していることだけを根拠に受信を拒否してはならない（MUST NOT）とし、送信傾向や内容の分析といった他の材料が無ければ、quarantineとして扱わなければならない（MUST）と定めました。DMARCは受信側への依頼であって、命令ではありません。

### アライメントのrelaxedとstrict

アライメントの判定には、組織ドメインが同じなら一致とみなすrelaxed（既定）と、完全一致だけを認めるstrictがあり、DKIMは `adkim`、SPFは `aspf` で切り替えます。

| From             | 認証済みドメイン                | relaxed | strict |
| ---------------- | ----------------------- | ------- | ------ |
| news.example.com | DKIM d=example.com      | 一致      | 不一致    |
| example.com      | SPF bounce.example.com  | 一致      | 不一致    |
| example.com      | SPF mail.esp-vendor.net | 不一致     | 不一致    |

3行目は、メール配信サービスの共用ドメインがReturn-Pathに入っている典型例です。SPFは通っていてもアライメントが取れないので、配信サービス側で独自ドメインのDKIM署名（`d=example.com`）を有効にしないとDMARCは通りません。

### 組織ドメイン判定の変更：PSLからDNSツリーウォークへの移行

relaxedの「組織ドメインが同じ」をどう決めるかは、RFC 7489では公開サフィックスリスト（PSL）頼みで、どのリストを使うかは受信側任せでした。RFC 9989では、ドメインの左端のラベルを削って上位ドメインへたどりながら `_dmarc` のレコードを問い合わせる「DNSツリーウォーク」に置き換わりました。問い合わせは最大8回に抑えられています。新しく加わった `psd=` タグは、このツリーウォークでどこを組織ドメインとみなすかの手がかりになります。古い実装の受信側はPSLで判定し続けるため、両者の結論が食い違う余地があります。RFC 9989の付録C.3は、strictアライメントを使い、メールで使うすべての差出人ドメインに明示的にレコードを置けば、この食い違いは完全に避けられると書いています。

## DMARCレコードの書き方｜タグ一覧とRFC 9989での変更

DMARCレコードは `_dmarc.example.com` のTXTとして公開します。観測から始めるときの例は次のとおりです。

```
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

RFC 9989の4.7節に載るタグは次のとおりです。

| タグ         | 意味                   | 既定・値                   |
| ---------- | -------------------- | ---------------------- |
| v          | バージョン（必須・先頭）         | DMARC1のみ               |
| p          | ドメイン自身のポリシー          | none／quarantine／reject |
| sp         | 実在するサブドメインのポリシー      | 省略時はpを適用               |
| np         | 存在しないサブドメインのポリシー（新規） | 省略時はsp、次にp             |
| rua        | 集計レポートの送付先           | 省略時はレポートなし             |
| ruf        | 失敗レポートの送付先           | 省略時はレポートなし             |
| fo         | 失敗レポートを作る条件          | 0（既定）／1／d／s            |
| adkim・aspf | アライメントの厳しさ           | r（既定）／s                |
| t          | テストモード（新規）           | n（既定）／y                |
| psd        | 公開サフィックスか（新規）        | u（既定）／y／n              |

書くときに押さえる規則は次のとおりです。

- `v=DMARC1` が先頭にないレコードは、全体が無視されます。
- 同じ名前にDMARCレコードが2本あると、両方とも捨てられます（4.10節）。SaaSの手順どおりに2本目を足すと、その名前のレコードは採用されません。ただし、上位ドメインのポリシーが適用される場合があります。
- RFC 9989では、構文が有効なレコードに `p` が無い場合は `p=none` として扱います。ただし旧仕様との互換性を保つため、新規設定では `p` を明記します。
- `sp`・`np` は組織ドメインのレコードに書いたときに効きます。サブドメイン（例：`_dmarc.news.example.com`）に置いたレコードの `sp` は無視されるので、サブドメインだけ扱いを変えたいなら、そのサブドメイン自身のレコードに `p` を書きます。
- レポート先が別ドメイン（例：解析サービスのアドレス）の場合、受け取る側が `example.com._report._dmarc.受け取り側ドメイン` に `v=DMARC1` のTXTを置いていないと、レポートは送られません（[RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html)）。解析サービスを使うなら、この許可レコードが用意されているかを確かめます。RFC 9990ではワイルドカードによる許可も認められているため、ドメイン別レコードの有無だけで判断しないでください。

### 廃止されたpct・rf・riと、代わりのt=y

RFC 9989の付録C.5で、`pct`（一部のメールにだけポリシーを適用する割合）、`rf`（失敗レポートの形式）、`ri`（集計レポートの間隔）が削除されました。付録A.6によると、`pct` は0と100（既定）以外の値が正確に適用されないことが多く、ずれ方も実装ごとにばらばらでした。一方で `pct=0` は、メーリングリストなどの中継者がFromを書き換える合図として使われるようになり、移行判断の材料として役立っていました。その用途を引き継いだのが `t=y` で、「1段階弱いポリシーで扱ってほしい」という依頼になります（`p=reject; t=y` ならquarantine相当）。

ただし、古い仕様で動く受信側も残ります。[GoogleのDMARC設定ヘルプ](https://support.google.com/a/answer/2466563?hl=ja)は2026年10月時点でも、展開時に `pct` を入れることを勧め、BIMIを使うなら `pct=100` にするよう求めています。既存レコードの `pct=100` を急いで消す必要はありません。新しく書くレコードでは `pct` の割合に頼らず、quarantineやrejectへ上げる前のレポート観測で判断します。

## 実在ドメインのDMARCレコードを読む｜2026年10月28日のdig実測

公開されているレコードは誰でも確かめられます。2026年10月28日に `dig +short txt _dmarc.ドメイン` で取得した結果が次の表です（Windowsなら `nslookup -type=TXT _dmarc.ドメイン`）。

| ドメイン        | p          | sp         | その他              |
| ----------- | ---------- | ---------- | ---------------- |
| google.com  | reject     | （pを継承）     | ruaのみ            |
| gmail.com   | none       | quarantine | ruaのみ            |
| outlook.com | none       | quarantine | pct=100・ruf・fo=1 |
| yahoo.co.jp | quarantine | （pを継承）     | ruaのみ            |

読み取れることは2つあります。1つ目は、会社のドメイン（google.com）はrejectでも、一般の利用者が使うフリーメールのドメイン（gmail.com・outlook.com）は本体を `p=none` にとどめている点です。RFC 9989の7.4節は、メーリングリストに投稿する利用者を抱えるドメインは `p=reject` を公開すべきでない（SHOULD NOT）としており、実測値はその考え方と合っています。2つ目は、outlook.comに廃止済みの `pct=100` が残っている点です。`pct=100` は全件適用の意味なので、古い実装の受信側でも新しい実装でも結果は変わりません。既存レコードに廃止タグがあっても、それだけで壊れるわけではありません。

## DMARCの設定手順と確認方法

DNSに1行書く作業より先に、自社のどこからメールが出ているかを洗い出します。次の順で進めます。

1. 送信経路を洗い出す（社内メールサーバー、Google WorkspaceやMicrosoft 365、メール配信サービス、問い合わせフォーム、請求書や予約の通知を出す業務SaaS）。
2. SPFを公開するドメインごとにレコードを1本にまとめ、include先などの再帰評価も含め、DNS参照を伴う項目の評価数を合計10個以内に収める。
3. 各経路で、自社ドメインを `d=` にしたDKIM署名を有効にする。
4. `p=none` と `rua` を入れたDMARCレコードを公開する。
5. 集計レポートを1か月以上集め、正規の経路がすべてpassしているかを確かめる。
6. quarantineへ上げ、同じ期間観測してからrejectを判断する。

メールを送らないドメインやサブドメインは、観測を待たずに `v=DMARC1; p=reject;` を置けます。使っていないドメインの防御は[パークドメインとは？意味・仕組みと危険性、なりすまし対策のDNS設定を解説](/column/details/8175/)で、SPFやMXとあわせて説明しています。DNSやメール経路の設定を外部の目で点検したい場合は、[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)の範囲に含めて確認する方法もあります。

### 受信メールのヘッダによるDMARC認証結果の確認

公開したレコードが効いているかは、実際に届いたメールのヘッダで判断します。受信側は判定結果を `Authentication-Results` ヘッダに書き込みます。

```
Authentication-Results: mx.example.net;
    dkim=pass header.d=example.com header.s=mail2026;
    spf=pass smtp.mailfrom=bounce.example.com;
    dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
```

Gmailならメールの「メッセージのソースを表示」で、SPF・DKIM・DMARCそれぞれのPASS／FAILが冒頭にまとめて表示されます。Outlookではメッセージのインターネットヘッダーを開き、同じ `Authentication-Results` を探します。`dmarc=fail` のときは、同じヘッダの `header.d`（記載がなければ認証に通ったDKIM署名の `d=`）と `smtp.mailfrom` をFromのドメインと比べると、どちらのアライメントが外れたかが分かります。

## DMARCレポート（rua・ruf）の読み方

`rua` に届く集計レポートは、受信側ごとに1日単位などでまとめたXMLです。RFC 9990の付録Bの例を短くすると、中身は次の形をしています。

```
<policy_published>
  <domain>example.com</domain><p>quarantine</p><sp>none</sp>
  <discovery_method>treewalk</discovery_method>
</policy_published>
<record>
  <row>
    <source_ip>192.0.2.123</source_ip><count>123</count>
    <policy_evaluated><disposition>pass</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results><dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim></auth_results>
</record>
```

1つの `record` が「この送信元IPから、このFromドメインで、何通届き、どう判定されたか」を表します。見る順番は次のとおりです。

- `source_ip` と `count`：自社の把握している送信経路のIPか。知らないIPから大量に来ていれば、なりすましか、棚卸しから漏れた正規の経路。
- `policy_evaluated` の `dkim`・`spf`：アライメントを含めた結果。上の例はSPFが外れてもDKIMで通っており、転送経由でよく見る形。
- `disposition`：受信側が実際に取った扱い。RFC 9990では none・pass・quarantine・reject の4値で、`pass` はポリシーを強制している状態でDMARCに通ったことを表す。
- `auth_results` の `selector`：RFC 9990でDKIMのセレクタの記載が必須になった。どの配信サービスの鍵で署名されたかを特定できる。

`ruf` の失敗レポートはRFC 9991で定義され、個々のメールの情報を含みます。RFC 9989の10.2節が指摘するように特定の利用者の情報が入り得るため、送らない受信側もあります。運用の中心は集計レポートになります。

## none・quarantine・rejectの選び方と、rejectにしないほうがよい場面

`p=none` は観測専用です。RFC 9989の5.4節は、`p=none` を見つけた受信側は既存のメール処理を変えてはならない（MUST NOT）と定めています。DMARCを理由に扱いが変わることはなく、なりすましメールを止めるのは受信側の通常の迷惑メール対策だけになります。防御として効くのはquarantine（疑わしいメールとして迷惑メールフォルダなどへ）とreject（受け取り拒否の依頼）です。

それでも、すべてのドメインがrejectを目指すべきではありません。RFC 9989の7.4節は次の2点をはっきり書いています。

- `p=reject` を公開するドメインは、DMARCのpassをSPFだけに頼ってはならず（MUST NOT）、有効なDKIM署名を付けなければならない。転送でSPFは崩れるためです。
- メーリングリストに投稿する利用者を抱えるドメインは `p=reject` を公開すべきでない（SHOULD NOT）。どうしても公開するなら、`p=none` を少なくとも1か月、続けて `p=quarantine` を同じ期間公開し、レポートで影響を比べてから上げる。

取引先や顧客に通知メールを送るだけの業務ドメインや送信専用のサブドメインは、正規の全経路でアライメントしたDKIMが通ることをレポートで確かめたうえで、rejectまで上げるべきです。一方、社員が外部のメーリングリストや学会・業界団体のリストに日常的に投稿しているドメインは、quarantineで止めるか、投稿用のアドレスを別ドメインに分けてから検討します。日本企業の設定状況とrejectへの移行手順は[DMARCのquarantineとrejectの違い｜日経225企業の設定率69.8%とドメイン保護率18.5%](/tech/details/12267/)で、数値つきで解説しています。

## Gmail・Yahoo・Microsoftの送信者要件と国内の動き

大手メールサービスの送信者要件により、大量に送る企業にとってDMARCは事実上の前提条件になりました。

| 受信側          | 開始        | 対象             | DMARCの要件                   |
| ------------ | --------- | -------------- | -------------------------- |
| Gmail        | 2024年2月1日 | 1日5,000件超の送信者  | 公開必須（p=noneで可）＋Fromのアライメント |
| Yahoo（米国）    | －         | 大量送信者（通数は非公表）  | 公開とpass（p=noneで可）          |
| Outlook.com等 | 2025年5月5日 | 1日5,000通超のドメイン | 最低p=none＋SPFかDKIMで一致       |

[Gmailのメール送信者のガイドライン](https://support.google.com/a/answer/81126?hl=ja)は2段構えです。すべての送信者にSPFまたはDKIMを求め、1日5,000件を超える送信者にはSPFとDKIMの両方、DMARCの公開、FromのドメインとSPFまたはDKIMのドメインの一致を求めます。認証されていないメールは迷惑メールに分類されるか、5.7.26エラーで拒否されることがあると明記しています。5,000件未満の送信者もSPFかDKIMは必須なので、「小規模だから関係ない」とはなりません。[GmailのFAQ](https://support.google.com/mail/answer/14229414?hl=ja)によると、大量送信者は、同じ主ドメインから個人のGmailアカウント宛てに24時間で5,000件近く以上を送る送信者で、サブドメインからの送信も主ドメインの分として合算され、一度大量送信者に分類されると分類は続きます。2025年11月からは、要件を満たさないメールへの対応（一時的な拒否と恒久的な拒否を含む）を強めると告知しています。

米国Yahooの[送信者向けベストプラクティス](https://senders.yahooinc.com/best-practices/)も、大量送信者にSPFとDKIM、少なくとも `p=none` のDMARCの公開とDMARCのpassを求めています。Yahooは大量送信者の通数の閾値を公表しないとしています。

Microsoftは[2025年4月2日の発表](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)で、hotmail.com・live.com・outlook.comの個人向けアドレスに1日5,000通を超えて送るドメインへ、SPF・DKIMの合格と、最低 `p=none` でSPFかDKIMのどちらかと一致するDMARCを求めました。当初は迷惑メールフォルダへ振り分ける予定でしたが、4月29日の更新で、満たさないメールは「550; 5.7.515」で拒否する方針に変わっています。法人向けのExchange Onlineではなく、個人向けサービスが対象です。

国内では、フィッシング対策協議会のガイドライン2026年度版がDMARCを `p=reject` まで上げることを推奨に加えました。改訂の中身と移行手順は[フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順](/tech/details/12369/)にまとめています。

## よくある質問

### DMARCを設定しないとどうなりますか？

自社ドメインを名乗るなりすましメールを、受信側が判断する材料が減ります。加えて、Gmailに1日5,000件を超えて送る場合はDMARCの公開が要件なので、未設定だと迷惑メール扱いや拒否の対象になり得ます。5,000件未満でも、Gmail宛てにはSPFかDKIMの設定が必要です。

### SPFとDKIMを設定していればDMARCは不要ですか？

不要ではありません。SPFはReturn-Pathのドメイン、DKIMは署名の `d=` のドメインを検証するだけで、受信者が見るFromのドメインとは結び付きません。Fromとの一致を確かめ、失敗時の扱いとレポート先を宣言するのはDMARCだけです。

### p=noneのままでも意味はありますか？

なりすましを止める効果はありません。RFC 9989は、p=noneでは受信側の処理を変えないよう定めています。意味があるのは、集計レポートで自社の送信経路となりすましの実態を把握できることと、Gmailなどの送信者要件を満たせることです。

### DMARCが普及しない理由は何ですか？

レコード自体は1行でも、正規の送信経路をすべて洗い出してSPFとDKIMを通すまでが大仕事だからです。部署ごとに契約したメール配信サービスや業務SaaSが漏れていると、quarantineやrejectに上げた時点で自社の正規メールが届かなくなります。このため、送信経路の確認が終わるまでは `p=none` で観測を続ける必要があり、強制ポリシーへ上げるまでに時間がかかります。

### DMARCの導入に費用はかかりますか？

DNSにTXTレコードを追加するだけなので、仕様上の費用はかかりません。費用が出やすいのは、集計レポートのXMLを可視化する解析サービスと、配信サービス側で独自ドメインのDKIM署名を有効にするための上位プランです。

## 関連記事

- [SPFとは？メール認証の仕組み・SPFレコードの書き方と設定の判断基準を解説](/column/details/13466/)
- [DMARCのquarantineとrejectの違い｜日経225企業の設定率69.8%とドメイン保護率18.5%](/tech/details/12267/)
- [フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順](/tech/details/12369/)
- [BIMIとは？Exchange Online・Outlookの対応状況とMicrosoft 365環境での設定手順](/tech/details/8350/)
- [フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説](/column/details/13262/)

---

出典: [DMARCとは？SPF・DKIMとの違い、仕組みとレコードの書き方【RFC 9989対応】](<https://www.issoh.co.jp/column/details/3287/>)（株式会社一創）