【判定】自社の送信ドメインがMicrosoftの高送信量送信者向け認証要件に該当する場合は、SPF・DKIM・DMARCとアラインメントを順に確認してください。550 5.7.515は受信アドレスの変更では解消できず、修正後に受信テストで再確認する必要があります。
自社製品の送信ドメインやDNS認証を管理する開発者は、退信とメールヘッダーから確認箇所を絞れます。
プレリリースや本番公開前にメールを受け入れ確認するQAは、拒否と迷惑メール振り分けを区別できます。
外部の送信サービスを運用する担当者は、自社ドメインの認証設定と署名を確認できます。
最終更新：2026年10月22日。内容はMicrosoftの550 5.7.515に関する説明と高送信量送信者向けの公式要件を照合しています。
Outlook.com 550 5.7.515の調査で最初に見る拒否地点
550 5.7.515は、Outlook.com、Hotmail、Live.comなどのMicrosoft消費者向けメールサービスが返す拒否エラーです。Microsoftはこのエラーを、高送信量送信者に適用される認証要件を満たしていない場合の問題として説明しています。ただし、すべての送信者に同じ適用条件があるとは限りません。対象範囲はMicrosoftのエラー説明と高送信量送信者向けの要件で確認してください。
このエラーは迷惑メール判定とどう違いますか。
拒否の場合、SMTPの送信処理が受け付けられず、送信側に配信不能通知（NDR）が返ります。迷惑メールフォルダーに入る場合は、通常、受信側がメッセージを受け取った後に振り分けています。送信ログ、NDRの全文、対象サービスを確認し、単に「受信トレイで見つからない」と一括りにしないでください。
| 観測した状態 | まず確認する証拠 | 次に進む作業 |
|---|---|---|
| 550 5.7.515を含むNDRが返る | SMTP応答、NDR全文、宛先サービス | 適用範囲と認証設定を確認 |
| SMTPで受理されたが受信トレイに見当たらない | 受信側の迷惑メールフォルダー、メールヘッダー | 受信後の振り分けや認証結果を確認 |
| Outlook.com以外でも未着が起きる | 各受信サービスの応答、送信ログ | 共通する送信設定と個別の受信側要因を分けて調査 |
まず退信を完全な形で保存し、対象がMicrosoftの消費者向けメールサービスかを確かめます。続けて、メッセージに表示された送信元と、自社が意図している送信ドメインを照合してください。エラーコードだけを記録し、NDRの本文やSMTP応答を残さないと、サービス固有の拒否なのか、別の配信失敗なのかを後から判断できません。
高送信量送信者の適用範囲
Microsoftの説明では、Outlook.comの宛先に1日あたり5,000通を超えて送信するドメインが高送信量送信者の対象です。Microsoftの要件で定義と適用範囲を確認し、他のメールサービスの要件をMicrosoftの条件として扱わないようにしてください。
判断時は、宛先の受信サービス、メッセージの5322.Fromドメイン、そしてNDRに記載された拒否理由をセットで見ます。送信サービスの管理画面で「送信成功」と表示されていても、宛先側が受け付けたことを意味するとは限りません。自社が高送信量の条件に該当するか不明なら、送信ログの集計対象とMicrosoft側の定義を照合してから、認証設定の修正に進みます。
SPF・DKIM・DMARCの検証結果とアラインメント
SPFまたはDKIMがpassなのに、DMARCが失敗するのはなぜですか。
認証の成功とDMARCのアラインメントは別の判定です。SPFがpassでも、SPFで検証されたドメインが5322.Fromと一致する関係にないと、SPFによるDMARCのアラインメントは成立しないことがあります。DKIMも同様に、署名の検証が成功しただけでは十分ではありません。署名のd=ドメインが5322.Fromとアラインしているかを確認します。Microsoftのメール認証資料とIETFのDMARC仕様 RFC 9989を参照し、各判定を分けて記録してください。
| 確認対象 | 何を確認するか | よくある見落とし |
|---|---|---|
| SPF | 送信元IPが、SMTPの5321.MailFromやHELOに関係するドメインのSPF評価を通るか | DNSにSPFレコードがあることだけで、実際の送信経路も許可済みと判断する |
| DKIM | メッセージ署名の検証結果と署名ドメインのd=値 | 署名がpassなら、Fromドメインとも整合していると思い込む |
| DMARC | 5322.Fromと、passしたSPFまたはDKIMのドメインが必要な関係にあるか | SPFとDKIMの個別passを、DMARC passと同じ意味に扱う |
メールヘッダーでは、Authentication-ResultsのSPF、DKIM、DMARCの各結果と、5321.MailFrom、5322.From、DKIM署名のd=を照合します。各項目の意味はMicrosoftのメールヘッダー解説で確認できます。DNSにレコードが存在するかだけで終えず、実際に送信されたメッセージの認証結果と、ドメイン間の整合性を突き合わせてください。
第三者の送信サービスを使っている場合は、そのサービスの画面で表示される「認証済み」だけで判断しないでください。自社ドメインを送信元として認めるDNS設定、実際の5321.MailFrom、5322.From、DKIM署名のd=が意図した構成になっているかを確認します。
受け入れ確認のチェックリスト
次の順で記録すると、設定変更と実際の受信結果を結び付けやすくなります。複数の設定を同時に変更すると、どの変更が結果に影響したのか分かりにくくなるため、変更内容と確認証拠は分けて残してください。
- [ ] NDR全文、SMTP応答、送信時刻、宛先サービスを保存する。
- [ ] エラーがOutlook.com、Hotmail、Live.comなどのMicrosoft消費者向け宛先から返ったか確認する。
- [ ] 高送信量送信者の適用条件と、自社の送信実績・対象ドメインを照合する。
- [ ] 実際のメールヘッダーでSPF、DKIM、DMARCの判定を確認する。
- [ ] 5321.MailFrom、5322.From、DKIMのd=を見比べ、DMARCのアラインメントを確かめる。
- [ ] 外部送信サービスを経由する場合、自社ドメインのDNS認証と署名設定をサービス側の構成と照合する。
- [ ] 修正後、管理されたテスト用受信先に自社製品から送信し、SMTP応答、受信の有無、メールヘッダー、NDRの有無を記録する。
- [ ] 退信が再発する場合は同じ証拠を再取得し、設定変更によって解消したと早合点しない。
修正後は、どのように拒否が解消したか確認できますか。
テストまたはプレリリース環境から、管理下にある受信先へ実際の製品メールを送ってください。送信側のSMTP応答だけでなく、受信の有無、メールヘッダーの認証結果、NDRが返ったかを記録します。テスト用受信先でメッセージを確認できれば、実際に届いたメールの内容やヘッダーを調べられますが、発信ドメインの認証設定を修復したり、すべての受信サービスでの配信を保証したりするものではありません。
回帰範囲を証拠に合わせて決める
Microsoft宛てで拒否が再発し、SPF・DKIM・DMARCまたはアラインメントに不整合があるなら、関連する送信経路や外部サービス設定の確認を続けます。Microsoft宛てでは拒否が再発せず、メールヘッダーにも意図した認証結果が記録されている場合は、今回の変更範囲に応じて他の管理下の受信先も追加確認します。
一度の受信成功は、すべての宛先への継続的な配信保証ではありません。設定変更、確認したヘッダー、SMTP応答、未解決の配信事象を別々に記録してください。迷惑メールへの振り分けや遅延が残る場合も、550 5.7.515の拒否が解消したかどうかとは分けて調査します。
認証設定を確かめた後、自社製品のメール本文や実際の受信状態を確認したい場合は、EmailPutの一時受信先をテストに利用できます。登録不要ですぐに使えるため、テスト用メールを個人の受信箱へ流さず確認できます。ただし、受信先を変えてもSPF・DKIM・DMARCの不備は直りません。重要なアカウントの継続受信や返信が必要な用途では、長期管理できるメールアドレスを使ってください。
次の登録では、まず送信元を示す目印を残す
短期の作業には一時メールを使い、長期的な通知が必要なら専用の転送別名で送信元を分けましょう。