ポリシー厳格化の際はご注意を：メール不達時のPostfixのログ調査とDKIM設定
課題 (Situation / Task)
近年、GoogleやMicrosoftなどの主要プロバイダによるメール送信者への認証要件が厳格化されています。 その影響で、自社サービス（ユーザーが独自ドメインとDNSを持ち込んで運用する形態）から、メールがバウンス（不達）になる事象が多発するようになりました。
特に、SPFレコードは設定されているものの、その他の認証が不足しているケースで弾かれる傾向が見られます。迅速に原因を特定し、ユーザーへの案内と根本的なシステム対応を行うよう努めています。
解決策 (Action)
1. エラーメールとPostfixログの調査
お問い合わせがあった際は、まずはユーザーにエラーメールの全文（Diagnostic-Code: や Status: の行）の共有を依頼しつつ、サーバーサイドでPostfixのログ調査を行います。
Postfixのログは、1通のメールに対する処理が複数行に分かれて出力されるため、特定の宛先やバウンスしたメールの全貌を追うには少し工夫が必要です。 トラブル発生時、送信元アドレスは把握できていることが多いため、送信元アドレスから調べたい場合は例えば以下のような手順を取ることがあります。
送信元アドレスからQueue IDを特定し、単一メールを詳しく調査する
# まず送信元のログを出力してQueue IDを特定する
sudo grep "from=<差出元のメールアドレス>" /var/log/maillog | tail -n 10
# 見つけたQueue ID（例: 3AF5D43781XXX）で全体を検索する
sudo grep "3AF5D43781XXX" /var/log/maillog
今回は特にMicrosoft系（Hotmail、Live、Outlookなど）のメールアドレス宛てに送信したメールがバウンス（不達）になるとのことでしたので、以下のようなコマンドを活用してQueue IDを特定し、関連ログを抽出しました。
特定ドメイン宛のバウンスログからQueue IDを一括抽出して追跡する
sudo grep -iE "to=<[^>]+@(hotmail|live|outlook)\.(com|co\.jp)>" /var/log/maillog | \
grep "status=bounced" | tail -n 5 | awk '{print $6}' | tr -d ':' | \
while read qid; do sudo grep "$qid" /var/log/maillog; echo "-----------------------"; done
上記のコマンドを実行すると、以下のように詳細原因を含むバウンスログを見やすくまとめて取得することができます。 （上記のサンプルの場合は対象のログから直近の5件を取得します。）
-----------------------
Apr 23 10:50:04 (サーバ名) （postfix名）/pickup[3352596]: 3158611332A1: uid=xxx from=<xxxxxx@sample.com>
Apr 23 10:50:04 (サーバ名) （postfix名）/cleanup[3354921]: 3158611332A1: message-id=<message-id-00000000@senderdomain.com>
Apr 23 10:50:04 (サーバ名) （postfix名）/qmgr[2530888]: 3158611332A1: from=<xxx@sample.com>, size=3063, nrcpt=1 (queue active)
Apr 23 10:50:14 (サーバ名) （postfix名）/smtp[3354962]: 3158611332A1: to=<xxxxxxxxx@hotmail.com>, relay=hotmail-com.olc.protection.outlook.com[xxx.xxx.xxx.xxx]:25, delay=10, delays=0/3.5/1.9/4.9, dsn=5.7.515, status=bounced (host hotmail-com.olc.protection.outlook.com[xxx.xxx.xxx.xxx] said: 550 5.7.515 Access denied, sending domain XXXX doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= Pass [TYCPR01MXXXX.jpnprd01.prod.outlook.com 2026-04-23T01:50:14.254Z 08DEB6C11XXXX] [AM0PR02CXXXX.eurprd02.prod.outlook.com 2026-04-23T01:50:14.341Z 08DEB6F90XXXX] [AMS0EPF00XXXXX.eurprd05.prod.outlook.com 2026-04-23T01:50:14.365Z 08DEB719XXXX] (in reply to end of DATA command))
Apr 23 10:50:14 (サーバ名) （postfix名）/bounce[3354964]: 3158611332A1: sender non-delivery notification: XXXXX
Apr 23 10:50:14 (サーバ名) （postfix名）/qmgr[2530888]: 3158611332A1: removed
-----------------------2. エラー原因の特定とDKIM対応
抽出したログから、Microsoft側のサーバーが返している以下のエラーログが特定できます。
said: 550 5.7.515 Access denied... Spf= Pass , Dkim= Fail , DMARC= Pass
このログから、「SPFはPassしているが、DKIMがFail（署名がない、または不正）であるため、認証要件を満たしていない」として受信拒否されていることが明確になりました。
解決策として、対象ドメイン用のDKIMキー（公開鍵・秘密鍵）を生成し、ユーザーへDNSのTXTレコードへの公開鍵の追加を依頼することで、無事にメールが到達するようになりました。
【補足】DMARCレコードがFailだった場合の対応と運用上の注意点
今回のケースではエラーログに DMARC= Pass と出力されていましたが、もしここが DMARC= Fail となっていた場合は、DKIMだけでなくDMARCのDNSレコード追加も必要になります 。
【推奨するDMARCレコードの例】
サブドメイン: `_dmarc`
種別: `TXT`
内容: `v=DMARC1; p=none; rua=mailto:（レポートを受信できるメールアドレス）;` DMARC運用における「ruaタグ」とポリシー引き上げの罠
DMARCレコードを設定する際、rua タグに指定したメールアドレス宛には、認証結果をまとめた機械的なXML形式のレポートが毎日大量に送られてきます。
運用体制によっては、このレポートの解析が担当者にとって大きな負担となるケースがあるため、意図的に rua を記載しない設定を見かけることもあります。実際のところ、rua タグが無くてもDMARCの文法エラーにはなりません。
しかし、将来的に「なりすましメールを完全にブロックしたい」と考え、DMARCのポリシー（p= の部分）を p=quarantine（隔離）や p=reject（拒否）に引き上げようとする場合は注意が必要です。rua レポートを受信して現状のメール配信状況を分析せずにポリシーを厳格化してしまうと、本来届いてほしい正規のメールまでブロックしてしまう事故に繋がる危険性があります。導入を開始する際のほか、インフラの構成変更、DNSレコードの見直しなどいろいろなタイミングでメールのブロックが発生しうるため、ツールなどを利用して定期的に解析することをお勧めします。
具体的には、今回例示したメール不達の状況（Spf= Pass, Dkim= Fail, DMARC= Pass）も、こうした配信状況の調査・監視がが不十分なDMARC設定の影響を受けていた可能性が考えられます。まずは p=none（何もしない）と rua レポートの組み合わせで現状を正しく把握していくことが、安全なメール運用の第一歩となります。
結果と今後の展望 (Result)
このような調査のうえで、上記の例では不足していたDKIM署名を適切に設定することで、Microsoft宛のメール不達問題を解決することができました。
さらに、今後も類似の問い合わせが増加することが予想されたため、手作業での対応を減らすべくDKIMキーの生成と設定を行うシェルスクリプトを作成し、作業の自動化を行いました。
次のステップとして、このスクリプトをサービスの管理画面（バックエンド）に組み込み、ユーザー自身がボタン一つでDKIMキーを自動生成・確認できるセルフサービス化の機能実装を進める予定です。 将来的には調査部分もぜひ自動化していきたいですね。