Strict アライメント（Strict Alignment）

概要

Strict アライメント は、DMARC のアライメント検証において、認証ドメインとヘッダー From のドメインが完全に一致することを要求するモードです。RFC 7489（2015年）で定義されており、DMARC レコードの aspf=s（SPF 側）または adkim=s（DKIM 側）タグで指定します。

デフォルトの relaxed モードでは組織ドメインレベルの一致（bounce.example.com と example.com は同一組織）を許容しますが、strict モードではサブドメインの違いも fail として扱います。mail.example.com で署名された DKIM や、bounce.example.com をエンベロープ From にした SPF は、ヘッダー From が example.com であれば strict では fail します。

strict モードは金融機関や政府機関など、ドメインの厳密な管理が求められる環境で採用されます。ただし、SaaS メール送信サービスを併用している組織では、サブドメインの不一致により正規メールが fail するリスクがあります。

仕組み

SPF と DKIM それぞれの strict アライメントの判定基準と、DMARC 全体の判定フローを整理します。

SPF の Strict アライメント

SPF の strict アライメント（aspf=s）では、エンベロープ From のドメインとヘッダー From のドメインが完全に一致する必要があります。

エンベロープ From	ヘッダー From	strict 結果	relaxed 結果
example.com	example.com	pass	pass
bounce.example.com	example.com	fail	pass
example.com	mail.example.com	fail	pass
other.com	example.com	fail	fail

relaxed モードで pass するサブドメインの組み合わせが、strict では fail になります。

DKIM の Strict アライメント

DKIM の strict アライメント（adkim=s）では、DKIM 署名の d= タグのドメインとヘッダー From のドメインが完全に一致する必要があります。

DKIM 署名が d=mail.example.com でヘッダー From が user@example.com の場合、relaxed なら組織ドメインが一致するため pass しますが、strict では fail します。

判定フロー

DMARC の判定は、SPF アライメントと DKIM アライメントのどちらか一方が pass すれば全体として pass になります。aspf=s と adkim=s を両方指定した場合でも、DKIM の strict アライメントが pass すれば SPF の strict アライメントが fail していても DMARC pass になります。

ただし、strict モードでは両方のアライメントが fail しやすくなるため、SPF と DKIM の両方が pass する送信インフラを構築してから切り替えます。

設定例

DMARC レコードの aspf と adkim タグで strict モードを指定する代表的なパターンを示します。

SPF と DKIM の両方を strict にする

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.com"

自社メールサーバーだけで送信する環境に適しています。エンベロープ From、DKIM 署名の d=、ヘッダー From のすべてが example.com で統一されている場合に使います。

DKIM のみ strict にする

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; aspf=r; adkim=s; rua=mailto:dmarc@example.com"

SPF はサブドメインの差異を許容しつつ、DKIM 署名のドメインは厳密に管理します。SendGrid や Amazon SES などでカスタムドメインの DKIM 署名を d=example.com で設定している場合に有効です。

確認方法

DMARC レコードのアライメントモードは dig で確認できます。

dig TXT _dmarc.example.com

;; ANSWER SECTION:
_dmarc.example.com.	3600	IN	TXT	"v=DMARC1;p=reject;aspf=s;adkim=s;rua=mailto:dmarc@example.com"

aspf=s が SPF の strict アライメント、adkim=s が DKIM の strict アライメントです。これらのタグが存在しない場合はデフォルトの relaxed（r）が適用されます。

外部の視点からも確認したい場合は、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=s; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.dmarc.record フィールドの aspf= と adkim= の値を確認します。s であれば strict モードです。

よくある問題

strict モードでは relaxed で通過していたメールが fail になるケースが増えるため、移行前の影響調査が欠かせません。

SaaS 送信サービスのサブドメインで fail する

SendGrid や Amazon SES を使う場合、エンベロープ From はサービスが割り当てるサブドメイン（例: em1234.example.com）になることがあります。aspf=s ではヘッダー From の example.com と一致しないため SPF アライメントが fail します。この場合、DKIM アライメントでカバーするか、aspf=r に変更します。

メーリングリスト経由のメールが拒否される

メーリングリストはエンベロープ From を書き換えることがあり、SPF アライメントが fail します。DKIM 署名が維持されていても、リストサーバーが Subject: にプレフィックスを追加するなどヘッダーを改変すると DKIM も fail します。strict モードではこの影響がさらに大きくなります。メーリングリスト経由のメールが多い場合、relaxed モードの方が安全です。

relaxed から strict への移行で正規メールが拒否される

rua レポートを確認せずに strict に切り替えると、relaxed で pass していたサブドメイン経由のメールが突然 fail します。移行前に最低 4 週間分の DMARC 集計レポートを分析し、すべての送信元がサブドメインではなくルートドメインで認証されていることを確認します。