SPF マクロ %{i} %{d} の仕組みと例
目次
この記事でわかること
- SPF マクロとは何か、どんな場面で使われるか
- 主要 6 マクロ（
%{i}%{d}%{s}%{l}%{h}%{ir}）の意味 exists:ディレクティブと組み合わせた動的 SPF の設定例- サイト運営者ではほぼ使わない理由と、ハマりどころ
SPF マクロとは
SPF マクロは、SPF レコードの中で 送信元 IP やメールアドレスなどの値を動的に展開できる機能です。RFC 7208 Section 7 で定義されており、%{...} の形式で記述します。
通常の SPF レコードは、include: や ip4: で送信元を静的に列挙します。これに対しマクロを使うと「送信元 IP が DNS 上に登録されていれば pass」「ドメインごとに異なる SPF を引く」といった、レコードを書き換えずに認可範囲を切り替える設計が可能になります。
SPF の基本構造を未確認の方は、先にSPF レコードの書き方をご覧ください。
主要 6 マクロの意味
実務で目にする可能性があるのは次の 6 種です。
| マクロ | 展開される値 | 例 |
|---|---|---|
%{i} |
送信元 IP アドレス | 203.0.113.45 |
%{d} |
評価対象の From ドメイン | example.co.jp |
%{s} |
送信者メールアドレス | [email protected] |
%{l} |
送信者のローカルパート | info |
%{h} |
HELO/EHLO ホスト名 | mta01.example.co.jp |
%{ir} |
送信元 IP の逆順表記 | 45.113.0.203 |
これらは大文字（%{I} 等）にすると URL エスケープされた値が返ります。たとえば @ は %40 に変換されます。exists: で DNS 名として使うときに必要になる仕様です。
exists とマクロの組み合わせ
マクロが本領を発揮するのは exists: ディレクティブとの組み合わせです。exists: は指定した DNS 名の A レコードが存在すれば pass、存在しなければスキップ、という挙動をします。
設定例 1: IP ホワイトリストを DNS 化
v=spf1 exists:%{ir}.spf.example.co.jp -all
このレコードは、送信元 IP の逆順を spf.example.co.jp のサブドメインとして DNS に問い合わせます。たとえば送信元が 203.0.113.45 なら、45.113.0.203.spf.example.co.jp の A レコードを引き、存在すれば pass。認可済み IP の登録・削除は DNS への A レコード追加だけで完結します。
設定例 2: ドメインごとに別 SPF を適用
v=spf1 redirect=%{d}.spf-policy.example.net
example1.com と example2.com で別々の SPF を当てたいときに、ドメインごとに異なる redirect 先を引けます。SaaS ベンダーが顧客ごとの SPF を一元管理する用途で使われます。
どんな組織が使うのか
マクロを実装するメリットがあるのは、おおむね次のような組織です。
- 数百〜数千 IP からメール送信するクラウドサービス事業者
- 顧客ごとに認可 IP を動的に切り替える SaaS ベンダー
- グループ会社で SPF ポリシーを一元管理したい大企業
逆に 中小企業の通常運用ではほぼ不要です。送信元が Google Workspace と SendGrid 程度の構成なら、include: を並べるだけで十分カバーできます。マクロを使うと DNS 設計が複雑化し、引き継ぎコストも跳ね上がるため、必要性がはっきりしないなら採用しないのが安全です。
ハマりやすいポイント
マクロを使う場合、次の落とし穴に注意してください。
- 構文ミスは即 Permerror:
%{i}を%(i)のように書くと SPF 全体が無効化されます。括弧の種類を間違えただけで Permerror になり、迷惑メール判定の対象になります - 大文字/小文字の取り違え:
%{i}と%{I}は別物。URL エスケープが必要な場面でしか大文字を使ってはいけません - DNS 設計の負債化:
exists:で動的に DNS を引く設計は、運用者が交代すると挙動を追えなくなります。設計書を残さない限り保守不能になります - ルックアップ枠を消費:
exists:は 1 個につき 1 ルックアップを消費します。include の入れ子と組み合わせると 10 上限を超えやすく、詳細はSPF include 入れ子と10ルックアップ計上を参照してください
設定前のチェックリスト
Web 担当者がそれでもマクロ導入を検討する場合、最低限次を確認してから着手してください。
- 送信元 IP の追加・削除が 月に 5 回以上発生するか（それ以下なら静的レコードで十分）
- DNS の TTL を短くしても問題ない運用体制か
- マクロ構文の検証を行うステージング環境があるか
- DMARC レポートで
spf=pass比率を毎日確認できる体制か
これらが揃わない状態でのマクロ導入はリスクの方が大きく、結果的にメール配信が止まるケースを散見します。
参考: RFC 7208 の関連セクション
仕様レベルで踏み込みたい方は、RFC 7208 の以下のセクションを併読すると理解が深まります。
- Section 7.1 Formal Specification … マクロの ABNF 定義
- Section 7.2 Macro Definitions … 各マクロが返す値の正規定義
- Section 7.3 Macro Expansion Examples … 公式の展開例
公式仕様は英文ですが、マクロを本番投入する前に一度は原典に目を通すことをおすすめします。日本語の二次情報だけで設計すると、URL エスケープの仕様や %% のリテラル扱いなど、細部で誤読しやすい論点があります。
導入後は DMARC レポートで spf=pass 比率の推移を最低 2 週間は監視し、想定通りに認証が通っているかを必ず検証してください。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。