SaaSから送るメールが迷惑メールに入る問題を直す手順：送信元ごとにDKIMとReturn-Pathを確かめる(2026)

「請求書を送ったのに届いていないと言われた」「問い合わせフォームの自動返信が迷惑メールに入る」。この記事は、SaaSから自社ドメインの名前で送るメールを、送信元ごとに確かめて直す手順をまとめました。対象は、中小〜中堅企業の情シス、マーケティング、バックオフィスの担当者です。

最終更新: 2026年9月21日／Google Workspace 管理者ヘルプ(ガイドラインとよくある質問)、Gmail ヘルプ、Microsoft Learn、HubSpot ナレッジベース、RFC 7208・RFC 7489 は同日に原文を取得して確認しています。この記事の要件の基準は、Google の個人用 Gmail 宛ての要件です。Google の要件は Google Workspace アカウント宛て(取引先が Google Workspace を使っている場合の会社アドレスなど)には適用されず、Gmail 以外の受信事業者の要件もこの記事では確認していません。「(編集部)」は、出典に書かれていない jisalab 編集部の判断・解釈・推奨を示します。扱うのは認証の設定が原因の場合で、迷惑メール率など認証以外の原因はFAQで一部だけ補足します。管理画面の名称や要件は変更されることがあるため、作業の前に各社の公式ページもご確認ください。

なぜSaaSのメールは迷惑メールに入るのか

請求管理、問い合わせフォーム、メール配信、採用管理、グループウェア。これらを1つのドメイン（例: example.co.jp）の名前で使うと、受信側から見れば、同じドメインを差出人にしたメールが、別々のサーバーから届いている状態になります。ところがSaaSの初期状態では、自社ドメインで認証されていないことがあります。Microsoft Learn「クラウド ドメインからメールに署名するように DKIM を設定する」は「多くのホストされた電子メール サービスは、サービス ドメインを使用してメッセージに署名し、顧客がドメインの DKIM 署名を構成した後、顧客ドメインを使用してメッセージに再度署名します。」としています。

何を満たせばよいかを、Google のガイドラインとよくある質問から編集部が3層に整理しました。

よくある質問は、DMARC 認証に失敗したメールの扱いを説明するなかで「送信元ドメインに DMARC ポリシーがない場合、メールは拒否されるか、迷惑メールに分類される可能性があります。」としています。2025年11月からは非準拠の送信への措置を強めているともしています。PTRレコード(IPアドレスからホスト名を引く逆引きの設定)とTLS接続(通信の暗号化)は送信サーバー側の設定なので、SaaSから送るメールではSaaS事業者の側の作業です(編集部の整理)。

手順①：自社のドメインから、どこがメールを送っているかを1枚にする

埋める相手は情シスだけでは足りません。営業・マーケティング・人事・経理に「お客様や応募者にメールを送っているツールはありますか」と聞くのが早道です。

手順②：送信元ごとに、いまの認証の結果を確かめる

Gmail のヘルプによると、メールを開いて返信アイコンの横のその他アイコンから［メッセージのソースを表示］を選ぶと、詳細ヘッダーが表示されます。見るのは Authentication-Results の行です。Microsoft Learn の同ページは、この行の例として dkim=pass header.i=@contoso.com や smtp.mailfrom= を含む行を載せています。smtp.mailfrom= は SPF の判定に使われた Return-Path で、@ より後ろがドメインです(RFC 7208 4.1 節による編集部の説明)。読み取りに自信がなければ、Gmail ヘルプのとおり、コピーしたヘッダーを Google 管理者ツールボックスの「メッセージ ヘッダー」で分析できます。

SPF・DKIM・DMARCの結果は、自社のDNSとSaaSの設定で決まります。そのため @gmail.com 宛てのテストで、請求書のように取引先宛てに送るメールの設定の状態も確かめられます(編集部)。同じSaaSでも、請求・通知のメールと配信のメールで送り方が分かれることがあるので、種類ごとに1通ずつ送ります。

一致の判定は組織ドメイン(example.co.jp のような、サブドメインを除いた登録ドメイン)単位です。既定の relaxed モードでは、サブドメインどうしも一致とみなされます(RFC 7489 3.1.1 節・3.1.2 節・6.3 節)。

読み取った2つのドメインを組み合わせると、送信元ごとの次の作業が決まります。

「自社ドメイン」は From と組織ドメインが同じ(サブドメインを含む)という意味です。一括送信者でない場合、From との一致は Google の要件ではなく、DMARC は片方の一致で pass になります。両方での一致は Google の推奨です。一括送信者は、どの行でも「一括送信者に当たる場合だけの作業」の要件(SPF と DKIM の両方の設定など)を確かめます。

手順③：SaaSが求めるレコードを入れ、SPFとDMARCを1本にまとめる

SaaSが求めるレコードを入れる

SPFとDKIMは、SaaSがサブドメイン(bounce.〜、info.〜など)へのレコードを求めれば、そのホスト名に置きます(そのホスト名にSPFがすでにあれば追記します)。

何が要るかはSaaSごとに違います。HubSpotのナレッジベース「メール認証を管理する」の接続手順では、MX・DKIM・SPF・DMARCの4種類のDNSレコードを設定し、DKIMはCNAMEが2つ、SPFとDMARCはTXTが1つずつです。MXのように受信に関わるレコードは、SaaSが指定するホスト名にだけ置き、自社のメールを受けているルートのMXは変えません(編集部)。SaaSがDMARCのレコードを表示しても、組織ドメインの _dmarc にすでにあれば作りません。HubSpot は認証ステータスの注記で「ルート ドメイン レベルでDMARCレコードが設定されている場合、DMARCポリシーの継承により、サブドメインは認証されたとみなされます。」としています。サブドメインに新しく置くと、組織ドメインのポリシーを上書きすることになります(RFC 7489 6.6.3 節)。

HubSpot では、他の目的(ウェブサイトのホスティングなど)に使っているドメインは送信ドメインとして認証できません。自社サイトと同じドメインが当たる可能性があるので(編集部)、HubSpotの画面表示で確かめ、必要なら送信用のサブドメインを検討します(差出人アドレスも変わります)。Microsoft Learn も「直接制御しないメール システムまたはサービスにはサブドメインを使用することをお勧めします。」としています。HubSpotの画面操作は、jisalabのHubSpotレビューで解説しています。

From との一致は、まずDKIMで取ります(編集部)。よくある質問は、一括送信者について「一括送信者は SPF と DKIM の両方の認証を設定する必要がありますが、送信者のアラインメント要件を満たすために必要な設定はいずれか一方のみです。」としています。Return-Path をSaaS側から変えられなくても、DKIMなら自社ドメインで署名できます。Microsoft Learn の同ページも、Return-Path が配信サービスのドメインのままでも、DKIM の署名ドメイン(d=)が From のドメインと一致すれば(例では marketing.contoso.com)DMARC に合格しうる例を挙げています。自社ドメインでのDKIM署名に対応していないSaaSは、差出人をそのSaaSのドメインのままにするか、別のツールに替えるかを検討します。

DKIMの鍵の長さ

Googleのガイドラインは「重要: 個人用 Gmail アカウント宛てに送信するには、1,024 ビット以上の DKIM 鍵が必要です。」とし、ドメイン プロバイダが対応している場合は2,048ビットを推奨しています。Microsoft 365 では、PowerShell で鍵を作る場合の既定が1,024ビットで(Microsoft Learn)、鍵長の変更はキーのローテーションで反映され、新しいキーで署名が始まるまで「4 日間 (96 時間)」かかります。ほかのSaaSの鍵長は、SaaSのヘルプか管理画面のDKIM設定で確かめ、表示が無ければSaaSのサポートに問い合わせます。

SPFはホスト名ごとに1本、問い合わせは10項目まで

SPFを同じホスト名に2本置くと、SPFの評価そのものが “permerror”(設定の誤りによるエラー)になります(RFC 7208 4.5 節)。SaaSが同じホスト名への追記を求めてきたら、既存の1本に足します。HubSpotは v=spf1 include:anotherprovider.com include:123456.spf03.hubspotemail.net -all という例を示し、「SPFバージョンと「-all」フラグがそれぞれ一度だけ含まれていることを確認します。」としています(-all は、記載のない送信元を認めないという意味)。

DNS への問い合わせを起こす項目(include: のほか a・mx・ptr・exists と redirect)は、評価全体で合計10までです。超えると結果は “permerror” になります(RFC 7208 4.6.4 節)。include: の先の include: も同じ10に数え(同4.1 節)、ip4・ip6・all は数えません(同4.6.4 節)。

DMARCは1本、noneから始める

DMARCは一括送信者には要件、それ以外の送信者には Google の推奨です。DMARCのレコードが同じホスト名に2本以上あると、受信側はそのメールにDMARCを適用しません(RFC 7489 6.6.3 節)。記述の例は、RFC 7489 付録 B.2.1 が _dmarc に TXT で "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" を置く形で示しています(rua はレポートの送り先)。Google のガイドラインも、一括送信者の要件について「DMARC 適用ポリシーは none に設定できます。」としています。いきなり reject にすると、設定漏れのSaaSからのメールが止まると考えられます(編集部)。この記事は none までを扱います。

手順④：設定後にもう一度確かめ、SPFを整理し、見続ける

DNSの変更はすぐには反映されません。HubSpotのナレッジベースは「DNSレコードの更新には通常10分から70分かかりますが、場合によっては48時間もかかる場合があります。」とし、Microsoft Learn は「DNS プロバイダーと TTL の設定によっては、DNS 伝達に数分から 48 時間かかることがあります。」としています。レコードの反映は、Microsoft Learn が Microsoft 365 の例として示す nslookup -type=CNAME selector1._domainkey.contoso.com のようなコマンド(セレクター名は各SaaSの表示に置き換え、鍵を TXT で置くSaaSなら -type=TXT にします)か、HubSpotが挙げる MX Toolbox の「SPFレコードチェック」「DKIMレコード検索」、dmarcian の「DMARCレコードチェッカー」で確かめます。

テスト結果の読み方

再テストの結果も、手順②の判定表で読みます。表だけでは直し方が分からない3つの場合を補足します。

• 自社ドメインの署名が dkim=fail: DNSの鍵のレコードが、SaaSの表示どおりのホスト名と値で入っているかを見直します
• DKIMの署名ドメインがまだサービス側: SaaSの管理画面で、自社ドメインの送信設定が有効になっているかを見直します
• Return-Path が自社ドメインなのに spf=pass でない: SaaSが指定するSPFの記述を、Return-Path のドメイン名のSPFに足します。Return-Path を自社のサブドメインにする設定を使った場合は、SaaSの指定どおりのレコードをそのサブドメインに置きます(そのホスト名にSPFがすでにあれば追記します)

SPFの整理

• 使っているSaaSの分: Return-Path がサービス側でも、組織ドメインのSPFに残します。ガイドラインは「ドメインの SPF レコードには、ご使用のドメインのすべてのメール送信元を含める必要があります。」とし、続けて「サードパーティ送信者が SPF レコードに含まれていない場合、この送信者から送信されたメールは、迷惑メールに分類される可能性が高くなります。」としています。10回の上限を超えそうなときだけ、Return-Path がサービス側のSaaSの include: を外す候補にします(SPFの合否には効いていないため。編集部)。ただし外すと、ガイドライン上は迷惑メールに分類されやすくなるおそれを負うので、SaaSのヘルプで要否を確かめてから判断します
• 解約したSaaSの分: 消します。元の事業者の送信サーバーに、自社ドメインの名前での送信を認め続けることになるからです(編集部)。10回の枠も消費し続けます。参照先のドメインが消えると、評価がその include: に達したときに結果は “permerror” になります(RFC 7208 5.2 節・4.3 節)

迷惑メール率とドメインの評価は、Google が送信者向けに提供する Postmaster Tools で確認できます(ガイドライン)。送信ドメインを Postmaster Tools に登録しておきます(登録の手順は Google のヘルプを参照してください)。そのあと四半期ごとに、全送信元の受信テスト(新しく増えた送信元を含む)、DMARCレポート、迷惑メール率の3つを見ます。DMARCレポート(受信側から rua の宛先に届く集計のXMLファイル)に棚卸し表に無い送信元が出ていたら、ガイドラインのいう「ご利用のドメインになりすましている可能性のある送信者」か、漏れていたSaaSです。社内で心当たりを確かめ、使っていない送信元ならSPFやDKIMに足しません。ガイドラインの監視の項は「Postmaster Tools で報告される迷惑メール率を 0.10% 未満に維持し、迷惑メール率が決して 0.30% 以上にならないようにします。」としています。

一括送信者に当たる場合だけの作業

数えるのは個人の Gmail 宛てだけです(よくある質問)。同じプライマリドメインから送ったメールは合算します(よくある質問の例では、solarmora.com と promotions.solarmora.com の件数を足します)。一度当たれば、恒常的に一括送信者とみなされます。

数え方は2段にします(編集部)。まず棚卸し表の各行の「最も多い24時間」の個人の Gmail 宛て件数を、期間が違っても単純に足します。各行の最大が同じ24時間に重なるとは限らないので、この合計は実際の最大と同じか、それより大きくなります。合計が2,500件未満(「5,000件近く」に数値の定義がないので、その半分を十分に離れているとみなす目安。編集部)なら、一括送信者には当たらないと判断します。2,500件以上なら、各ツールの送信ログで同じ24時間にそろえて合算し、その合計も2,500件以上なら一括送信者として扱います(編集部)。送信ログの保存期間より前の送信は数えられないので、過去に大量配信をした覚えがあれば、その分も含めて判断します。

1. DKIMは自社ドメインで: ガイドラインの要件は「ドメインに SPF および DKIM メール認証を設定します」で、別の箇所では「メールを送信するドメインで DKIM を有効にします。」としています。サービス側のドメインの署名で足りるかは明記がないので、自社ドメインで署名させ、対応していないSaaSから個人の Gmail に送るのは見直します(一度一括送信者になれば、同じプライマリドメインから個人の Gmail に送るメールすべてが要件の対象になるため。編集部)
2. SPFもできれば自社ドメインで: サービス側のドメインでの spf=pass で足りるかも、ガイドラインとよくある質問のどちらにも明記がありません(2026年9月21日時点)。ガイドラインが推奨する送信方法は「組織レベルで一致している SPF と DKIM を使用してメールを認証します。」なので、Return-Path を自社のサブドメインにする設定があれば使い、無ければSaaSの対応予定を棚卸し表に記録します(編集部)
3. Postmaster Tools での確認: よくある質問は「一括送信者は、Postmaster Tools を使用して、メールの処理方法がメール送信者のガイドラインに準拠していることを確認する必要があります。」としています
4. ワンクリック登録解除: ガイドラインは一括送信者の要件として、マーケティング目的のメールと配信登録されたメールにワンクリック登録解除を求めています。購読の節では「1 日に 5,000 件を超えるマーケティング目的のメールや配信登録されたメールを送信する場合」とも書いていて表現が揃っていないので、一括送信者に当たるなら、販促メールの件数にかかわらず入れる前提で進めます(編集部)。送信メールに List-Unsubscribe-Post: List-Unsubscribe=One-Click と List-Unsubscribe: の2つのヘッダーを入れ、あわせてメッセージ本文にも登録解除のリンクをわかりやすく表示する必要があります(ガイドライン)。本文のリンクだけではワンクリックの要件を満たしません(よくある質問)。SaaSから送る場合は、ヘッダーを追加するオプションがあるかを確かめます
5. 請求書などの取引メール: よくある質問は、トランザクション メールをワンクリック登録解除の要件から除外し、例に「パスワードの再設定、予約の確認、フォーム送信の確認」を挙げています。ただし「メールの性質は、Google ではなく受信者が判断します。」ともしているので、請求書のメールに販促の内容は混ぜません(ガイドラインも、領収書のメールにプロモーションの内容を含めないよう求めています)
6. 登録解除の反映: よくある質問は48時間以内の対応を「おすすめします」としつつ、措置の表では48時間以内に反映されないことを措置の対象に挙げているので、48時間以内に反映させます

ワンクリック登録解除を満たしていなくても、メールが「自動的に拒否されたり、迷惑メールに分類されたりすることはありません」(よくある質問)。ただし同FAQは、ワンクリック登録解除の無い未承諾メールは迷惑メールとして報告されやすくなるとしています。

初回にかかる時間(試算)

この表の数値はjisalab編集部が置いた作業量の目安で、実測値でも公式資料の数字でもありません。DNSの反映を待つ時間、一括送信者に当たる場合の配信ツール側の確認、1サービスでメールの種類ごとに複数通送る場合の追加分は含めていません。DNSの操作を外部に委託している場合は、依頼と回答の往復ぶんを別に見込んでください。

職種別に、どこから手をつけるか

• 経理・バックオフィス: 請求書と入金案内の送信元を最初に通します。届かないと入金の遅れにつながります
• 人事・採用: 応募者への連絡は個人のアドレス宛てが多くなりがちです(編集部)。届かないまま辞退として処理されると原因が分かりません
• マーケティング: 配信ツールは通数が多く、一括送信者の判定とワンクリック登録解除に直結します
• 情シス: SPFのDNS問い合わせの回数(手順③の対象項目を、入れ子の include: の先まで数えます)と、送信元ごとの確認結果を管理します。手順①の表を共有ドライブに置き、契約の申請とひも付けてください

次に取る行動

よくある質問