DMARC fail は、表示上の From に対応する認証成功が得られなかったことを示します。p=reject では拒否、p=quarantine では疑わしいメールとしての処理を要求しますが、最終判断は受信側です。構成を確認しつつ、他の配信要因も調べます。全体の構築は小規模事業者向けビジネスメールが参考になります。
よくある原因はアライメント不備、転送後の SPF 失敗、不完全な DKIM 署名、SPF 評価の問題です。DNS を推測で増やすのではなく、信頼できる受信ヘッダーでドメインを比較し、該当する送信経路を修正します。
以下に初期調査の表、確認手順、考えられる DNS 変更例を示します。その後の変更もテストが必要で、単発の修正が永久に効く保証はありません。
DMARC fail の正確な意味
認証成功と表示上の From アライメントを同時に満たす結果がありません。SPF や DKIM が他のドメインで成功していても、DMARC の成功につながらない場合があります。
仕様では SPF または DKIM が成功し、かつ RFC5322 From ドメインに対応する必要があります。どちらか一方で両条件を満たせば十分です。RFC 7489 を参照してください。
| 状況 | SPF | DKIM | DMARC | 考えられる意味 | 確認事項 |
|---|---|---|---|---|---|
| 両認証が失敗 | Fail | Fail | Fail | 構成不備、転送変更、未許可の送信など | 送信元、IP、DNS、署名を確認する |
| アライメント不足 | Pass, unaligned | Pass, unaligned | Fail | 認証には成功しても From に対応しない | 適切な Return-Path と対応する DKIM を設定する |
| 転送メール | Fail | Pass, aligned | Pass | 通常の転送でも起こり得る | 有効でアライメントを満たす署名を確認する |
| 転送と内容変更 | Fail | Fail | Fail | 変更は原因のひとつになり得る | 署名と経路をテストする。ARC はローカルな例外判断を助け得る |
| SPF PermError | PermError | Fail or none | Fail | 評価上限や構文の問題が考えられる | SPF 評価と実際の送信ドメインを確認する |
ステップ 1：最初にアライメントを確認する
正規の送信でも、サービス自身のドメインを認証し、自社の From に対応していない場合があります。成功したかだけでなく、どのドメインで成功したかが重要です。
例です。
Header From：
support@yourdomain.com
Return-Path：bounces.vendor.net
DKIM：d=vendor.net
spf=pass と dkim=pass があっても、vendor.net は yourdomain.com に対応しないため、DMARC は失敗し得ます。
マーケティング、CRM、サポート、予備 SMTP では、ドメイン認証、独自 Return-Path やバウンスドメイン、対応する DKIM を確認します。リンクのブランド化やトラッキングドメインだけではエンベロープ送信者は変わりません。
次は DNS の構造例です。値と有効化手順は実際の提供元から取得します。
Type: CNAME
Host: bounces
Value: yourvendor.example.net
Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net
Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.netTrekMail はドメイン追加時に必要な DNS 設定を示す場合があります。ドメインの追加と必須 DNS レコードが参考になります。実際の MAILFROM ドメインに有効な単一 SPF を設定し、提供元の構成を有効化して実メールをテストします。DNS 公開だけでは有効化されません。
ステップ 2：受信ヘッダーを分析する
該当メールの完全なヘッダーを開き、Authentication-Results、Return-Path、DKIM d= を探します。送信者が任意に付けたものではなく、信頼できる受信サーバー自身の結果を使用してください。
確認する項目は次のとおりです。
- 表示上の From ドメインを特定する。
- SPF の結果を確認する。
- SPF が実際に確認したドメインを特定する。
- DKIM の結果を確認する。
- 有効な DKIM 署名のドメインを特定する。
- 成功した認証と From を比較する。
アライメント不足の例です。
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dmarc=fail (p=reject) header.from=yourdomain.com次の違いに注意します。
SPF はエンベロープにある sendgrid.net のサブドメインを確認しています。header.i の sendgrid.net だけでは DMARC に使う DKIM ドメインは決まらず、有効な署名の d= を確認します。表示された結果には、From yourdomain.com に対応する成功経路がありません。
送信経路ごとに検証を繰り返します。トランザクションメールの成功はマーケティング、サポート、転送エイリアスの成功を証明しません。独自ドメインメールの設定も参考になります。
ステップ 3：転送を別の問題として調べる
転送では新しいサーバーの IP が元のエンベロープドメインで許可されず、SPF が失敗し得ます。それでも有効でアライメントを満たす DKIM が保持されれば、DMARC は成功します。
Google Groups、Outlook 転送、卒業生や大学の転送でも起こり得ます。SPF 失敗だけでは DMARC を判断できず、成功して対応する DKIM があれば十分です。
RFC 7960 は、元のエンベロープを保つと新しいサーバーで SPF が失敗し得ると説明します。SRS などの書き換えは新アドレスでの SPF を助けますが、元の From アライメントを保証しません。RFC 7960 を参照してください。
SPF の許可を推測で増やしても、一般的な解決にはなりません。代わりに次を検討します。
- 対応する送信経路で DKIM を有効化してテストする。
- 検証した厳密要件がなければ緩和アライメントを検討する。
- メーリングリストでの署名変更と具体的な受信判断を調べる。
重要な転送にはメール転送の設定とドメインメールの Gmail 転送が参考になります。TrekMail はプランに応じて転送や管理された SMTP を提供できます。署名対象が正規化規則のもとで保持される必要があり、全経路での成功は保証されません。
ステップ 4：SPF の PermError を調べる
DNS を必要とするメカニズムと修飾子の評価が十の上限を超えたり、構成が無効だったりすると SPF PermError になり得ます。入れ子も含む評価上限であり、全 DNS パケット数ではありません。成功して対応する DKIM があれば DMARC は成功し得ます。
複数の提供元を含む例です。
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all見える文字列だけでは上限超過を判断できません。入れ子の include と redirect の評価も調べます。
まず DNS 値を取得します。
dig +short txt yourdomain.com
nslookup -type=txt yourdomain.comこの検索だけでは PermError を証明できません。全評価と現用送信元を確認します。六か月前に使わなくなったサービスも、まれな送信が残っていないと確認してから許可を削除します。分けるドメインの例です。
marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com別の SPF 評価枠が使えるのは、送信側が実際に該当エンベロープドメインを使用し設定を有効化した場合です。サブドメイン公開だけでは分割されず、From アライメントもテストします。
TrekMail の資料は重複 SPF の回避と適切な値の統合を説明しています。DNS ステータスの確認を参照してください。
ステップ 5：悪用の可能性と構成不備を区別する
すべての DMARC fail を許可する必要はありません。未許可のメールもあれば、正規の経路に設定不備やメール変更がある場合もあります。
未知の IP と両認証の失敗だけでは判断できません。一覧、ログ、転送経路を照合し、無条件に許可や遮断をしないでください。p=quarantine と p=reject は処理要求であり、具体的な動作の保証ではありません。
調査の順序は次のとおりです。
- 一覧、ログ、転送経路から未知の送信元を特定する。
- 正規送信者なら実際の基盤とドメイン有効化を確認する。
- 署名がなければ対応する DKIM を設定してテストする。
- 成功とアライメントを満たせなければ、有効化した適切な送信ドメインや管理した代替サービスを計画する。
認証やアライメントの失敗でポリシーは制限を要求できます。受信側は ARC を考慮するなどローカルな例外を適用できますが、元の DMARC fail が pass になるわけではありません。適用条件は Google の送信者ガイドにあります。
送信システム別によくある問題
システムの種類は手掛かりであり、個別メールの検証を置き換えません。
| システム | 考えられる原因 | 検証する修正 |
|---|---|---|
| マーケティング基盤 | DKIM または Return-Path の不一致 | 独自 DKIM と適切な Return-Path を有効化する |
| サポートや CRM | 外部の From や認証ドメイン | ドメイン認証を完了してテストする |
| メールボックス転送 | 新サーバーでの SPF 失敗 | 有効で対応する DKIM と全経路を確認する |
| メーリングリスト | 転送で署名データが変わる | 変更を調べる。ARC はローカルな受信判断を助け得る |
| 混在する企業メール | SPF 評価上限や不完全な DNS | 必要な送信経路を確認し実際のエンベロープを設定する |
| 多数のドメインを扱う代理店 | 顧客構成の不統一 | 記録した DNS テンプレートとテストを統一する |
多数のドメインの DMARC 問題を管理する
顧客ごとに Google Workspace、cPanel、SendGrid、Gmail 転送が混在する場合があります。最新資料がなければ認証エラーの特定が難しくなります。
DNS、移行、ドメイン状態、転送、SMTP の共通手順が役立ちます。ただし実際の送信経路は別々に検証します。
TrekMail の有料プランの価格目安は月額 $3.50 からで、14 日間試用が提供されています。独自 SMTP の無料オプションもあります。プランに応じてドメイン、IMAP メールボックス、キャッチオール、転送、IMAP 取り込み、API をまとめられます。最新機能と上限を確認してください。IMAP はメールをコピーし、MX やアプリの切り替えを代替しません。
顧客ドメインの管理にはマルチドメインメールホスティングの運用例を、現在の DNS 保守と比較できます。
DMARC fail の短いチェックリスト
失敗メールから認証したドメインを特定して From と比較し、画面表示だけでなく不足する具体的な認証経路を調べます。
- 受信サーバーの信頼できる
Authentication-Resultsを読む。 - SPF 成功と実際のエンベロープドメインを確認する。
- DKIM 成功と
d=を確認する。 - 成功した認証と Header From を比較する。
- 成功して対応する経路がなければ該当ドメイン設定を修正する。
- 転送では署名の有効性と署名対象の保持をテストする。
- SPF 評価と現用提供元を調べ、有効化したエンベロープ設定でのみドメインを分割する。
- SPF と DKIM が失敗する未知の送信元を、自動的になりすましとみなさず調査する。
検証可能な結果と計画的な変更が手順の中心です。
まとめ：実際に失敗した経路を修正する
DMARC fail はアライメント、転送変更、SPF PermError、未許可の送信などで起こります。結果だけでは原因を証明できません。
該当する層を検証し、的を絞った変更をテストします。TrekMail はプランに応じて共有容量、定額マルチドメインホスティング、Nano の独自 SMTP、管理された SMTP、IMAP 取り込みを提供できます。TrekMail と https://trekmail.net/pricing で最新条件と上限を確認してください。
