Google Workspaceから送信したメールの信頼性を高めるうえで、SPFは基本となる設定の一つです。ただし、Google Workspace用の値をそのまま追加すればよいとは限りません。すでに別のメール配信サービスを使っている場合、既存のSPFレコードを上書きしたり、2つ目のSPFレコードを作ったりすると、かえって認証に失敗する可能性があります。
結論から言うと、最初に「自社ドメインからメールを送るサービス」と「現在のSPFレコード」を確認し、必要な送信元を1つのSPFレコードへまとめることが重要です。
この記事で分かること
- SPFが確認していること
- 設定前に調べる項目
- Google Workspaceだけを使う場合の設定例
- 既存のSPFレコードがある場合の考え方
- 設定後に認証結果を確認する方法
- うまくいかない場合の確認項目と戻し方
SPFとは
SPF（Sender Policy Framework）は、そのドメインからメールを送信してよいサーバーを、DNSに公開する仕組みです。
受信側のメールサーバーは、送信元ドメインのSPFレコードと、実際にメールを送ったサーバーを照合します。正しい送信元として登録されていれば、SPFの確認に通りやすくなります。
ただし、SPFを設定しただけで、すべてのメールが必ず受信トレイへ届くわけではありません。受信側は、DKIM、DMARC、送信内容、送信量、迷惑メール報告など、複数の情報から配送先を判断します。
SPFは、メール本文を暗号化する設定でも、受信メールを制御する設定でもありません。主に「このサーバーは、そのドメインを使って送信することを許可されているか」を確認するための設定です。
設定前に確認する4つの項目
DNSを変更する前に、次の4点を整理します。
1. DNSを管理しているサービス
ドメインを購入した会社と、DNSを管理している会社が同じとは限りません。まず、実際にDNSレコードを変更できる管理画面を確認します。
変更する場所を間違えると、画面上では登録できても、インターネット上のDNSへ反映されません。
2. 現在のSPFレコード
DNS管理画面で、対象ドメインのTXTレコードを確認します。v=spf1から始まる値があれば、それが現在のSPFレコードです。
コマンドを使える場合は、次のように確認できます。
nslookup -type=txt example.comexample.comは、自社のドメインへ置き換えてください。DNS管理画面の表示と、外部から取得できる値の両方を記録しておくと、変更後の比較や切り戻しに役立ちます。
3. 自社ドメインからメールを送るすべてのサービス
Google Workspace以外にも、次のようなサービスが自社ドメインを使ってメールを送信することがあります。
- Webサイトのお問い合わせフォーム
- メールマガジンや一斉配信サービス
- CRMや営業支援ツール
- 請求書、予約、通知などを送る業務システム
- 障害通知や監視サービス
Google Workspaceだけを登録し、ほかの正規の送信元を含めないと、そのサービスから送ったメールがSPF認証に失敗する可能性があります。
4. 変更前の値と戻し方
現在のTXTレコードを、文字列だけでなく、ホスト名、TTL、登録日時とともに記録します。問題が起きた場合に誰が元へ戻すかも決めておきます。
DNSは変更後すぐに世界中へ反映されるとは限りません。そのため、元の値へ戻しても、利用者によって反映時刻が異なる場合があります。
Google Workspaceだけを使う場合の設定例
Googleの公式情報では、そのドメインからメールを送るサービスがGoogle Workspaceだけの場合、次のSPFレコードが例として示されています。
v=spf1 include:_spf.google.com ~allこれはあくまで構成例です。DNS管理サービスによって、ホスト名に@を入力する、空欄にする、ドメイン名を入力するといった違いがあります。TXTレコードの入力方法は、利用中のDNSサービスの案内も確認してください。
すでにv=spf1から始まるレコードがある場合は、この例を2つ目のSPFレコードとして追加しません。既存の設定内容を確認し、Google Workspaceとほかの送信サービスを1つのSPFレコードへ統合します。
既存のSPFレコードがある場合
たとえば、Webサイトやメール配信サービスがすでにSPFへ登録されている場合、そのサービスを消さずにGoogle Workspaceを含める必要があります。
具体的な記述方法は、利用しているサービスによって異なります。各サービスの公式案内で、SPFへ追加するincludeなどの指定を確認してください。
ここで重要なのは、次の3点です。
- 同じドメインに、独立したSPFレコードを複数作らない
- 既存の送信サービスを、確認せず削除しない
- SPFのDNS参照回数を確認する
SPFでは、評価時に行われるDNS参照は最大10回です。includeだけでなく、aやmx、参照先からさらに行われる参照も数に含まれます。複数の配信サービスを追加している場合は、見た目のinclude数だけで判断しないようにします。
統合後のレコードに不安がある場合は、DNSを変更する前に、Google Workspaceの販売店、DNS事業者、各メール配信サービスのサポートへ確認してください。
SPFレコードをDNSへ登録する手順
1. 変更前の状態を保存する
対象ドメインのA、MX、TXTなど、現在のDNSレコードを記録します。今回変更しないレコードも、前後比較ができるように残しておくと安全です。
2. TXTレコードを追加または更新する
DNS管理画面で、対象ドメインのTXTレコードを登録します。
- SPFレコードがない場合：必要な送信元を含むレコードを新規登録する
- SPFレコードがある場合：既存レコードへ必要な送信元を統合する
引用符を自分で入力する必要があるかどうかは、DNS管理サービスによって異なります。不要な空白や入力ミスがないかも確認します。
3. DNSの反映を待つ
Googleの公式情報では、SPF認証が機能し始めるまで最大48時間かかる場合があると案内されています。DNS管理画面で保存できたことだけで、反映完了とは判断しません。
4. 外部からTXTレコードを確認する
DNS確認ツールやnslookupを使い、外部から意図したTXTレコードを取得できるか確認します。
確認できない場合は、変更したDNSサービスが正しいか、ホスト名の入力方法に誤りがないかを見直します。
テストメールでSPFの結果を確認する
DNSへ値が反映されたら、自社ドメインのGoogle Workspaceアカウントから、別の受信アカウントへテストメールを送ります。
Gmailで受信した場合は、メールの詳細メニューから「メッセージのソースを表示」を開きます。表示されたヘッダーのAuthentication-Resultsで、SPFの結果を確認します。
spf=passpassであれば、そのテストメールについてはSPF認証に成功しています。
一方、fail、softfail、neutralなどが表示された場合は、送信元がSPFレコードに含まれているか、DNSの値が反映されているかを確認します。テストしたメールが、Google Workspaceではなく別の配信サービスから送られていないかも確認してください。
SPFが通らないときの確認項目
| 症状 | 確認すること | 次の対応 |
|---|---|---|
| TXTレコードが取得できない | DNSの管理先、ホスト名、反映時間 | 正しいDNSで登録し、反映を待つ |
| SPFレコードが複数ある | v=spf1で始まるTXTが複数ないか | 必要な送信元を1つへ統合する |
| Google Workspaceは通るが別サービスは通らない | 別サービスの送信元を含めたか | そのサービスの公式指定を追加する |
permerrorになる | 構文、重複、DNS参照回数 | 不要な参照を整理し、構文を見直す |
| 変更後に正規のメールが失敗する | 変更時に削除した送信元がないか | 記録した変更前の値と比較する |
問題が広がっている場合は、新しい値を継ぎ足し続けないことが大切です。変更履歴を確認し、必要に応じて保存しておいた変更前の状態へ戻します。
SPFだけで終わらせない
Googleは、メール送信元の認証としてSPF、DKIM、DMARCを組み合わせることを推奨しています。
SPFは送信サーバーを確認し、DKIMはメールに付けられた電子署名を確認します。DMARCは、SPFとDKIMの結果をもとに、認証に失敗したメールの扱いとレポートの受け取り方を定めます。
SPFを設定した後は、DKIMを設定し、認証結果を確認したうえで、DMARCを段階的に導入する流れを検討します。
独自ドメインとDNS設定の全体像は、Google Workspaceで独自ドメインを設定する方法もあわせてご覧ください。
まとめ
Google WorkspaceのSPF設定では、Googleの設定例を追加する前の確認が重要です。
- 現在のSPFレコードを確認する
- 自社ドメインから送るすべてのサービスを洗い出す
- SPFレコードを複数作らず、必要な送信元を1つへ統合する
- DNS反映後に、実際のテストメールで
spf=passを確認する - 問題が起きた場合に備え、変更前の値と戻し方を残す
自社の送信元を把握できていない状態では、SPFレコードを変更しないほうが安全です。先に関係者と利用サービスを確認し、変更範囲を決めてから作業を進めましょう。
Google Workspaceの設定を自社だけで判断できない場合
SPFの変更では、Google Workspaceだけでなく、Webサイト、メール配信サービス、CRM、業務システムなど、自社ドメインを使うすべての送信元を確認する必要があります。
「現在のDNS設定が分からない」「どのサービスがメールを送っているか整理できない」「変更による影響が心配」という場合は、値を追加する前に専門家へ相談する方法もあります。
コエドテックでは、Google Workspaceを含むIT環境や利用ツールの整理、導入・運用に関する相談を受け付けています。まず状況を整理したい場合は、コエドテックのサービス・相談窓口をご確認ください。
