SPF アライメント（SPF Alignment）
概要
SPF アライメント（SPF Alignment） は、DMARC の検証プロセスにおいて、SPF が認証したドメイン（エンベロープ From のドメイン）とメールクライアントに表示されるヘッダー From のドメインが一致するかを確認する仕組みです。RFC 7489（2015年）の DMARC 仕様で定義されています。
SPF 単体は、エンベロープ From のドメインに対して送信元 IP が許可されているかを検証します。しかし、エンベロープ From とヘッダー From は独立したフィールドであり、SPF が pass していてもヘッダー From のドメインが正当かどうかは分かりません。攻撃者はエンベロープ From に自分が管理するドメインを設定して SPF を pass させつつ、ヘッダー From に正規ドメインを偽装できます。SPF アライメントはこのギャップを検出します。
DMARC レコードの aspf タグで、照合の厳密さを relaxed（デフォルト）または strict に設定します。DMARC が pass するには「SPF pass かつ SPF アライメント pass」または「DKIM pass かつ DKIM アライメント pass」のいずれかが必要です。SPF アライメントが fail でも、DKIM アライメントが pass すれば DMARC 全体は pass します。
仕組み
SPF アライメントは、SPF が pass した場合にのみエンベロープ From とヘッダー From のドメインを照合し、relaxed または strict のルールで判定します。
判定フロー
受信サーバーが SPF アライメントを評価する流れは次の通りです。
- SPF 検証を実行し、エンベロープ From（
MAIL FROM）のドメインに対する認証結果を得る - SPF が pass でなければ、SPF アライメントの評価は行わない（SPF 自体が fail のため対象外）
- SPF が pass した場合、そのドメインとヘッダー From（
RFC5322.From）のドメインを照合する aspfタグの設定に従い、relaxed または strict のルールで一致を判定する
SPF が softfail、fail、neutral、permerror などの場合は、SPF アライメントの判定自体に進みません。SPF が pass した場合にのみ、アライメントの照合が行われます。
relaxed モード（デフォルト）
aspf=r または aspf タグを省略した場合に適用されます。組織ドメイン（Organizational Domain）レベルでの一致を許容します。
組織ドメインとは、Public Suffix List に基づく登録可能ドメインです。bounce.example.com の組織ドメインは example.com、mail.corp.example.co.jp の組織ドメインは example.co.jp です。
| エンベロープ From | ヘッダー From | 組織ドメイン | 結果 |
|---|---|---|---|
bounce.example.com | news@example.com | どちらも example.com | pass |
em.sendgrid.net | info@example.com | sendgrid.net vs example.com | fail |
mail.example.co.jp | info@example.co.jp | どちらも example.co.jp | pass |
relaxed モードのメリットは、サブドメインを使ったバウンス処理やメール配信の柔軟性を維持しながらアライメントを確保できる点です。
strict モード
aspf=s を指定した場合に適用されます。エンベロープ From のドメインとヘッダー From のドメインが完全一致する必要があります。サブドメインの差異は許容しません。
| エンベロープ From | ヘッダー From | 結果 |
|---|---|---|
example.com | info@example.com | pass |
bounce.example.com | info@example.com | fail |
example.com | info@mail.example.com | fail |
strict モードは、フィッシング攻撃がサブドメインを使って正規ドメインになりすますリスクを遮断します。ただし、正規のサブドメインからの送信も fail になるため、送信インフラの完全な管理下にあるドメインでのみ使用します。
組織ドメインの判定
relaxed モードの照合で使われる組織ドメインの判定は、Public Suffix List（PSL）に依存します。PSL は Mozilla が管理するドメインリストで、.com、.co.jp、.github.io などの公開サフィックスを定義しています。
.co.jp は公開サフィックスなので、example.co.jp が組織ドメインになります。一方、.com の下では example.com が組織ドメインです。PSL の判定がプロバイダー間で異なるケースはまれですが、新しい TLD やプライベートサフィックスでは判定が揺れることがあります。
設定例
DMARC レコードで aspf タグを指定します。
relaxed モード（デフォルトと同じ。明示的に書く場合）:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; aspf=r; adkim=r; rua=mailto:dmarc@example.com"strict モードで運用する場合:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.com"aspf と adkim は独立して設定できます。SPF アライメントだけ strict にして、DKIM アライメントは relaxed のままという組み合わせも有効です。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=r; rua=mailto:dmarc@example.com"この設定は「エンベロープ From は厳密に管理するが、DKIM 署名はサブドメインからも許容する」という運用ポリシーを表現します。
SaaS 利用時のカスタムドメイン設定
メール配信サービスを使う場合、SPF アライメントを成立させるにはエンベロープ From のドメインを自社ドメイン配下にする必要があります。
SendGrid の場合、Domain Authentication 機能でカスタムドメインを設定すると、エンベロープ From が em1234.example.com のようにサブドメイン形式になります。relaxed モードであれば example.com との組織ドメインが一致するため、SPF アライメントは pass します。
Amazon SES の場合、Custom MAIL FROM Domain を設定します。
mail.example.com. IN MX 10 feedback-smtp.us-east-1.amazonses.com.
mail.example.com. IN TXT "v=spf1 include:amazonses.com ~all"エンベロープ From が bounce@mail.example.com になり、relaxed モードで example.com とのアライメントが成立します。
確認方法
DMARC レコードの aspf タグは dig で確認できます。
dig TXT _dmarc.example.com出力に aspf=s が含まれていれば strict モード、aspf=r または aspf タグ自体が存在しなければ relaxed モードです。
実際にアライメントが成立しているかは、DMARC の集計レポート（rua 宛に届く XML）で確認します。XML 内の <policy_evaluated> セクションに SPF アライメントの結果が記録されています。
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated><spf>fail</spf> は SPF アライメントが fail していることを示します。<auth_results> の <spf> とは異なり、<policy_evaluated> の <spf> はアライメント込みの結果です。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
"dkim": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": {
"record": "v=DMARC1; p=reject; aspf=s; adkim=r; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.dmarc.record フィールドにレコード全体が返ります。aspf= の値を確認することでアライメントモードを把握できます。タグが存在しない場合はデフォルトの relaxed です。
よくある問題
SPF アライメントの fail は、SaaS 送信時のエンベロープ From 不一致、strict モードへの移行ミス、メール転送によるドメイン書き換えが主な原因です。
SaaS 経由の送信で SPF アライメントが fail する
メール配信サービス（SendGrid、Mailchimp、HubSpot 等）を利用している場合、デフォルト設定ではエンベロープ From がサービス側のドメイン（例: bounces.sendgrid.net）になります。ヘッダー From は自社ドメイン（@example.com）のため、組織ドメインが異なり SPF アライメントは fail します。
対処法は 2 通りあります。
1 つ目は、カスタムドメインでエンベロープ From を自社ドメイン配下にする方法です。SendGrid では Domain Authentication、Amazon SES では Custom MAIL FROM Domain、Mailchimp では Custom Return-Path の設定がこれにあたります。relaxed モードであれば、bounce.example.com と example.com の組織ドメインが一致して pass します。
2 つ目は、DKIM アライメントで代替する方法です。DMARC は SPF と DKIM のどちらか一方のアライメントが pass すれば全体として pass になります。多くの送信サービスは自社ドメインでの DKIM 署名をサポートしているため、DKIM 側でアライメントを確保する運用も現実的です。
strict モードに変更したら正規メールが拒否された
aspf=s に変更すると、サブドメインからの送信がアライメント fail になります。例えば、エンベロープ From が bounce.example.com でヘッダー From が @example.com の場合、relaxed では pass していたメールが strict では fail になります。
変更前に rua レポートで現在の送信状況を確認し、エンベロープ From にサブドメインを使っている送信経路がないかを洗い出します。strict モードへの移行は、全送信経路のエンベロープ From ドメインがヘッダー From と完全一致していることを確認してから行います。
転送メールで SPF アライメントが fail する
メーリングリストや転送サービスを経由したメールは、エンベロープ From が転送サーバーのドメインに書き換えられます。元のドメインの SPF レコードは転送サーバーの IP を含んでいないため、SPF 自体が fail し、SPF アライメントも成立しません。
この場合は DKIM アライメントで対処します。DKIM 署名はメール転送で通常保持されるため、DKIM が pass し、d= タグのドメインがヘッダー From と一致していれば DMARC は pass します。転送先でヘッダーが改変される場合（Subject にプレフィックスを追加するなど）は DKIM も fail するため、ARC（Authenticated Received Chain）の導入を検討します。
rua レポートの <spf> フィールドを誤読する
DMARC 集計レポートの XML には <auth_results> 内の <spf> と <policy_evaluated> 内の <spf> の 2 箇所に SPF の結果が記載されます。<auth_results> の <spf> は純粋な SPF 認証結果（pass/fail）で、<policy_evaluated> の <spf> はアライメント込みの評価結果です。
SPF が pass でも SPF アライメントが fail するケースは珍しくありません。SaaS 経由の送信では、サービス側の SPF レコードで認証は pass しますが、組織ドメインが異なるためアライメントが fail します。レポートを確認する際は <policy_evaluated> の値で判断します。