独自ドメインのメールを使っているのに「有効な送信者ではない」「スパムの疑いあり」と判定され、取引先にメールが届かない――そんなトラブルは、技術的な設定と運用ルールをきちんと整えることで、かなりの確率で防ぐことができます。本記事では、SPF・DKIM・DMARC を中心に、具体的な設定例とチェック方法をわかりやすく解説します。
独自ドメインのメールがスパム扱いされる典型パターン
まずは、現場でよく見かける症状を整理します。特に Microsoft 365 / Outlook 環境では、次のようなメッセージが返ってくることがあります。
This message couldn't be delivered because the sending email address was not recognized as a valid sender.あるいは、エラーにはならずに相手側の迷惑メールフォルダへ入ってしまい、相手から「メールが届いていない」と言われて初めて気づくケースも多いです。
| 症状 | よくある表示例 | 送信側で起きていそうなこと |
|---|---|---|
| サーバーで拒否される（バウンス） | 550 5.7.x / 上記のような「valid sender ではない」エラー | SPF・DKIM・DMARC が未設定／誤設定、PTR 不備、ブラックリスト登録など |
| 迷惑メールフォルダ行き | 「このメールにはご注意ください」「なりすましの疑い」などの警告 | 認証は通っているが、スコアがギリギリ・本文や送信パターンがスパム的 |
| 特定のサービスにだけ届かない | Gmail には届くが Outlook.com には届かない など | 主要サービスごとの独自判定（IP の評価・過去の送信ログ）の影響 |
こうした問題の多くは、「送信ドメイン認証」と「DNS 回りの基本設定」が整っていないことが原因です。
主な原因と対応策の全体像
まずは全体像として、代表的な原因と対処の方向性を一覧で押さえておきます。
| 主な原因 | 対応策（概要） | 補足・ポイント |
|---|---|---|
| 送信ドメイン認証の不備・未設定 （SPF・DKIM・DMARC がない／誤っている） | SPF を設定 DNS に TXT レコードを追加 例： v=spf1 include:spf.protection.outlook.com -all DKIM を有効化メールサーバ側で DKIM 署名をオンにし、公開鍵を DNS の TXT（または CNAME）として公開 DMARC を設定 DNS に TXT レコードを追加し、ポリシーを定義 例： v=DMARC1; p=quarantine; rua=mailto:[email protected] | From ヘッダーのドメインと SPF / DKIM のドメインを揃える（Alignment）が重要。DMARC は最初 p=none から始め、問題なければ quarantine → reject へ段階的に強化。 |
| DNS レコード反映待ち | レコード変更後、最大 24〜48 時間は世界中に浸透するまでエラーが続く可能性あり。焦ってレコードを何度も書き換えない。 | nslookup -type=txt yourdomain.com などで、実際にインターネット上からどう見えているかを確認する。 |
| ブラックリスト（RBL）への登録 | RBL チェックツールでドメイン / IP の登録状況を確認し、誤検知であれば解除申請。スパム送信履歴がある場合は原因を根本から除去。 | 解除後も一気に大量送信しない。徐々に送信量を増やしながら、スコアが戻るのを待つ。 |
| 逆引き（PTR）レコード未設定 | 送信用 IP アドレスに対し、正引き FQDN と整合する PTR レコードを、回線事業者・ホスティング業者に依頼して設定してもらう。 | PTR がない送信元は、それだけで信用度が低くなり、大手プロバイダで即ブロックされることもある。 |
| 送信ヘッダー不備 | From: と Return-Path: のドメイン不一致を解消 HTML メールから不要なスクリプト・過度なトラッキングピクセルを削除 | テストメールを自分宛に送り、Outlook などでインターネットヘッダーを確認するのが近道。 |
送信ドメイン認証（SPF・DKIM・DMARC）の基礎と考え方
「正当な送信者かどうか」を判断するために、現在ほぼ必須となっているのが SPF・DKIM・DMARC の 3 つの技術です。それぞれの役割と関係性を整理しておきましょう。
| 技術 | 目的 | どこに設定するか | 主なチェック項目 |
|---|---|---|---|
| SPF | 「このドメインから送信してよい IP / サービス」を宣言する | DNS（TXT レコード） | 送信元 IP が SPF レコードに含まれているか |
| DKIM | メール本文・ヘッダーに電子署名を付け、改ざんされていないことを証明 | メールサーバの署名設定 + DNS（公開鍵の TXT/CNAME） | 署名の検証結果（pass / fail）、署名ドメイン（d=） |
| DMARC | SPF・DKIM 結果と From ドメインの整合性を定義し、「なりすましメールの扱い」をポリシーとして宣言 | DNS（_dmarc.example.com の TXT） | SPF / DKIM の pass / fail と Alignment の可否、適用ポリシー（none / quarantine / reject） |
ポイントは、DMARC が SPF / DKIM の結果を利用して「From ドメインと一致しているか？」まで含めて判断する点です。単に SPF を書いただけでは不十分で、From ヘッダーのドメインと SPF・DKIM のドメインが揃っているかを意識する必要があります。
SPF レコードの設定手順と具体例
SPF は「このドメインのメールを送ってよい送信サーバの一覧」を世界に向けて宣言する仕組みです。
- 自社が利用している送信経路を洗い出す
- Microsoft 365 / Exchange Online
- 自社オンプレミスのメールサーバ
- メール配信サービス（例：メルマガ配信、問い合わせフォームの通知など）
- DNS 管理画面で、対象ドメインの TXT レコードを追加・編集する
- 既に SPF レコードが存在する場合は、「複数作らず 1 つに統合」する
Microsoft 365 でのみ送信しているシンプルな例：
v=spf1 include:spf.protection.outlook.com -all自社 SMTP サーバ（固定 IP）からも送信する場合：
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -allここでのポイントは次の通りです。
- SPF レコードは必ず 1 つにまとめる（TXT レコードを複数作らない）。
-all（厳格）か~all（ソフトフェイル）かは運用の成熟度で決める。迷ったら最初は~allでもよい。- include を大量に重ねると「DNS 参照が 10 件を超える」エラー（permerror）になるので注意。
SPF でよくある設定ミス
- TXT レコードが 2 つ以上存在している（結局 SPF としては無効扱い）。
- 昔使っていたサービスの include が残り続け、不要なホストまで許可してしまっている。
- 新しく導入したメール配信サービスの IP / include を反映し忘れ、メルマガだけがブロックされる。
SPF を修正したあとは、必ず外部の SPF チェックツールで syntax エラーがないことを確認しておきましょう。
DKIM の設定と確認ポイント
DKIM は、メールに「署名」を付けることで、途中で改ざんされていないことを証明する仕組みです。SPF よりも高度ですが、最近の主要サービスでは標準機能として提供されています。
Microsoft 365 / Exchange Online を例にした流れは次の通りです（管理画面の表記は環境により異なります）。
- 管理センターでドメインが「認証済み」になっていることを確認。
- Exchange 管理センターの「メールフロー」や「DKIM」の項目から、対象ドメインの DKIM を有効化。
- 指示された CNAME レコードを DNS に追加し、公開鍵を有効化。
- 有効化後に自分宛てにメールを送り、ヘッダー中の
DKIM-SignatureとAuthentication-Resultsを確認してdkim=passになっているかを見る。
独自のオンプレミスサーバや他社クラウドを利用している場合も、「DKIM（DomainKeys Identified Mail）」の項目を探し、以下を行います。
- サーバ側で秘密鍵を生成し、署名を有効化。
- 公開鍵を DNS（
selector._domainkey.example.comの TXT）に登録。 - テスト送信して
dkim=passになることを確認。
DKIM は、SPF と違って「転送に強い」という特徴もあります。メーリングリストや転送設定を使うことが多い環境では、DKIM をきちんと通すことが到達率向上に効いてきます。
DMARC の設定と段階的な強化
DMARC は、SPF と DKIM の結果を踏まえて「From ドメインと整合しているか」「なりすましっぽいメールをどう扱ってほしいか」を宣言するための仕組みです。
基本のレコードは、ドメインの DNS に次のように TXT で追加します。
ホスト名: _dmarc.example.com
値: v=DMARC1; p=none; rua=mailto:[email protected]主なタグは以下の通りです。
| タグ | 意味 | 例 |
|---|---|---|
v | DMARC のバージョン | v=DMARC1 |
p | ポリシー（受信側への指示） | none / quarantine / reject |
rua | 集計レポートの送り先 | rua=mailto:[email protected] |
aspf, adkim | SPF / DKIM の Alignment（strict / relaxed） | aspf=r; adkim=r など |
導入時のおすすめステップは次の通りです。
- まずは
p=noneで開始し、レポートを収集。 - SPF / DKIM が通っていない legitimate な送信元がないか洗い出す。
- 問題を解消できたら
p=quarantine（疑わしいものは隔離）に引き上げ。 - さらに問題がなければ、最終的に
p=rejectでなりすましメールを完全拒否。
DMARC レポートは XML 形式で届きますが、専用ツールや可視化サービスを使うと、どのサービスからどれだけメールが飛んでいるかが一目で分かるようになります。
DNS レコード反映待ちと確認方法
SPF・DKIM・DMARC を設定しても、「すぐにはエラーが消えない」ことがあります。その多くは DNS レコードの浸透時間が原因です。
- DNS の TTL が長い場合、変更が世界中に行き渡るまで 24〜48 時間程度かかることがある。
- 社内から見える DNS と、外部（インターネット）から見える DNS が異なることもある。
反映状況を確認するには、クライアント PC から次のようなコマンドを実行します。
nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=txt selector1._domainkey.example.com複数の DNS サーバ（8.8.8.8 などのパブリック DNS）を指定して確認すると、どの程度浸透しているかが分かりやすくなります。設定直後にエラーが出ていても、焦って何度も書き換えるのではなく、まずは現在の見え方を冷静に確認しましょう。
ブラックリスト（RBL）登録の有無をチェックする
もし過去にスパム的な送信を行っていたり、ウイルス感染などで大量送信が発生していた場合、送信元 IP やドメインがブラックリスト（RBL）に登録されている可能性があります。
| 状況 | 考えられる原因 | 対応のポイント |
|---|---|---|
| 特定のプロバイダにだけ届かない | そのプロバイダが参照している RBL に登録されている | RBL チェックツールでどのリストに載っているかを特定し、解除申請を行う |
| 大量の NDR（配信不能通知）が返ってくる | 存在しない宛先への大量送信や、スパム判定によるブロック | 送信リストの品質を見直し、バウンスアドレスを継続的にクリーニングする |
| 突然到達率が落ちた | 短期間の送信スパイク、怪しい本文・件名の連続送信 | 送信ログ・本文テンプレート・リンク先 URL を確認し、疑わしい送信を止める |
RBL 解除に成功しても、すぐに信頼が回復するわけではありません。一定期間、以下を意識して運用することが重要です。
- 新規キャンペーンメールは、最初は少量から配信を始める。
- 開封率・クリック率をモニタリングし、極端に低いリストへの送信を控える。
- 配信停止リンクを明確にし、解除要求を無視しない。
逆引き（PTR）レコードと送信 IP の信用
独自サーバから直接メールを送っている場合、特に重要になるのが PTR レコード（逆引き DNS）です。
- 正引き：
mail.example.com → 203.0.113.10 - 逆引き：
203.0.113.10 → mail.example.com
このように、正引きと逆引きが対応している IP は「きちんと管理されているメールサーバらしい」と判断されやすくなります。一方で、逆引きが設定されていない IP からのメールは、スパムとしてスコアがマイナスになるか、そもそも受け付けてもらえない場合があります。
レンタルサーバや VPS を利用している場合は、管理画面やサポート窓口から「メール送信用 IP の PTR を mail.example.com に設定してほしい」と依頼すれば対応してもらえることが多いです。
送信ヘッダーの整合性チェック（From / Return-Path）
技術的な認証に問題がなくても、次のような「ヘッダーの不整合」が原因でエラーやスパム判定が起きることがあります。
From:とReturn-Path:のドメインがまったく別物になっている。- 差出人に存在しないメールアドレス（実在しないユーザー）を設定している。
- 代表アドレスを名乗っているが、実際には別のドメインから送信している。
| 項目 | 望ましい状態 | 要注意な例 |
|---|---|---|
| From | [email protected] | [email protected] と名乗っているのに、実際の送信ドメインがまったく別 |
| Return-Path | [email protected] など、同一ドメイン内のバウンス用アドレス | フリーメールや別会社ドメインを指定している |
| Reply-To | ユーザーが返信してほしいアドレス（From と同じでも可） | 存在しないアドレス・監視されていないアドレス |
特に Microsoft 365 では、「その送信アドレスがテナント内に存在しない」「送信を許可されていないグループアドレスを From に使っている」場合に、valid sender ではない 旨のエラーが発生しやすくなります。
対応としては、次のような点を確認します。
- From に指定しているメールアドレスが、テナント内のユーザー・共有メールボックス・配布グループのいずれかとして登録されているか。
- そのアドレスからの送信が許可されているか（送信者権限・送信者として送信権限）。
- アプリケーションや複合機などから送信している場合は、認証情報と From アドレスの組み合わせが正しいか。
Outlook でインターネットヘッダーを確認する方法
原因調査の第一歩は、「実際に相手側へ届いたメールのヘッダーを確認する」ことです。Outlook の場合は概ね次のような手順になります（バージョンによって名称は異なります）。
- 該当メールを開く（プレビューではなくウィンドウで開く）。
- メニューから「ファイル」→「プロパティ」または「メッセージオプション」を開く。
- 「インターネットヘッダー」欄に、ヘッダー全文が表示される。
Authentication-Resultsを探し、spf=pass,dkim=pass,dmarc=passになっているか確認する。
ここで spf=fail や dkim=fail が出ている場合は、その認証が正しく設定できていないということになります。実際の値を見ながら、DNS レコードと照らし合わせると原因を特定しやすくなります。
実装フロー：ゼロから到達率を改善するステップ
ここまでの要素を、実際の作業フローとしてまとめると次のようになります。
- 現状の診断
- 自分の Gmail / Outlook.com / 個人用アドレスにテスト送信し、ヘッダーの SPF / DKIM / DMARC 結果を確認。
- ブラックリストチェックツールでドメイン・IP の状況を確認。
- DNS レコードの整備
- SPF：送信元をすべて洗い出し、単一の SPF レコードに統合。
- DKIM：利用しているメールプラットフォームごとに署名を有効化し、公開鍵を DNS に登録。
- DMARC：まずは
p=noneで開始し、レポート受信を開始。 - PTR：オンプレ / VPS の場合は、正引きと整合する逆引きを事業者に依頼。
- メールサーバ / Microsoft 365 側の設定
- 送信コネクタの設定（特にアプリケーション送信用のスマートホスト設定）。
- From に使用するアドレスの存在確認と送信権限の設定。
- 不要な古いドメイン・使われていないコネクタの整理。
- テスト送信 & ヘッダー確認
- 主要な受信サービス（Gmail / Outlook.com / 携帯キャリアメールなど）宛てにテスト送信。
- 迷惑メールフォルダに入るかどうかを実際に確認。
- ヘッダーの認証結果と本文の警告表示の有無をチェック。
- DMARC ポリシーの強化
- 一定期間レポートを分析し、正当なメールで認証に失敗しているものを潰していく。
- 問題が解消できたら
p=quarantineに移行し、その後p=rejectを検討。
- 運用ルール整備
- 社内向けに「一斉送信時のルール」「BCC の使い方」「配信停止の扱い」などをガイドライン化。
- 新しい外部サービスを導入する際には、「メール認証の設定担当」を巻き込むフローを決めておく。
- 定期的な監査
- 半年〜1 年に一度、SPF / DKIM / DMARC / PTR / RBL 状況を総点検。
- すでに使っていない送信元が SPF に含まれていないか、DMARC レポートに怪しい送信元がないかを確認。
Microsoft 365 / Outlook 環境で意識したいポイント
「This message couldn’t be delivered because the sending email address was not recognized as a valid sender.」のようなエラーは、Microsoft 365 環境と相性の悪い設定が原因になっていることが多くあります。特に次の点を確認してみてください。
- 送信に利用しているアカウントが、テナント内できちんとライセンス付与・メールボックス作成されているか。
- 共有メールボックスや配布グループのアドレスを From として使っている場合、「代理送信」や「送信者として送信」の権限が付与されているか。
- アプリケーション送信（SMTP AUTH / 送信コネクタ）で、認証に使っているアカウントと From アドレスが極端に異なっていないか。
- テナント全体のアンチスパムポリシーで、社内からの送信に対して厳しすぎる制限をかけていないか。
また、Microsoft 365 を導入したのに、以前のオンプレミスサーバからも並行して送信しているケースでは、SPF に両方の送信経路を正しく記載することが重要です。片方だけを SPF で許可していると、もう片方からのメールが「正当でない送信元」と見なされることがあります。
運用面のベストプラクティス（スパム判定されないための送信マナー）
技術的な設定に加えて、「送り方」そのものも重要です。同じ設定でも、送信の仕方次第でスパム判定されるリスクが大きく変わります。
| やるべきこと | 理由 |
|---|---|
| 配信停止リンクを明示し、ワンクリックで解除できるようにする | ユーザーが「迷惑メール報告」ではなく、正しい手順で解除してくれるようになり、ドメインの評価が落ちにくくなる。 |
| 急な大量配信ではなく、段階的な送信を行う | 急激な送信スパイクはスパム検知システムの警戒を招くため。 |
| 購入リスト・名刺スキャン一括リストへの送信を避ける | 同意のない宛先への一斉送信は、拒否や迷惑メール報告の温床になる。 |
| 件名・本文に過剰な「煽り」表現や装飾を使わない | スパムメールでよく使われる表現・レイアウトは、フィルタに引っかかりやすい。 |
| 社内ユーザーに対して BCC 乱用を控える | 誤送信や内部からのスパム扱いを避けるとともに、配信対象の適正化にもつながる。 |
特にメルマガやキャンペーンメールを送る場合は、以下のような運用ルールを作っておくと安心です。
- 新規の配信リストは、最初は 500 件など小さな単位から送信して反応を見る。
- 連続して 3 回以上開封されていないアドレスは、休眠リストとして別管理する。
- 配信ごとに、開封率・迷惑メール報告率・解除率を集計し、異常値があれば内容を見直す。
まとめ：技術と運用の両輪で「正当な送信者」として認識される
自社ドメインから送信したメールが「有効な送信者ではない」「スパムの疑い」と判定される原因は、SPF・DKIM・DMARC の未設定や誤設定、PTR の欠如、ブラックリスト登録、ヘッダー不整合など、いくつかの要素が複合的に絡んでいることがほとんどです。
逆に言えば、
- SPF / DKIM / DMARC / PTR / ヘッダー整合性をきちんと整える
- Microsoft 365 / Outlook 側の設定と権限を正しく構成する
- 送信量やリスト品質、メール内容の運用ルールを整える
この 3 つを押さえることで、受信側から「正当な送信者」と評価される可能性は確実に高まり、スパム判定や配信エラーを大幅に減らすことができます。技術設定と運用の両輪で、自社メールの信頼性を一段引き上げていきましょう。
コメント