SPFレコードの書き方完全ガイド｜記述例・よくある間違い・DNSルックアップ制限まで解説
メールはビジネスや個人としても使われる有用な連絡手段のひとつです。一方で、なりすましが横行し、詐欺やウイルスメールが増えているなど、注意が必要な部分もあります。そのため、メールのセキュリティ対策は非常に重要です。
迷惑メールを除外するシステムとしてフィルターが存在していますが、しばしば正規のメールもフィルターに引っかかってしまうことがあります。送ったメールが迷惑メールとみなされて受信フォルダに届かないと、スムーズなやりとりができません。
また、スパムやフィッシング詐欺から守るためには、送信者の信頼性を確認する仕組みが欠かせません。ここで重要な役割を果たすのが、SPF（Sender Policy Framework）レコードです。SPFレコードは、メールの送信元が正当であることを確認し、不正なメール送信を防ぐための技術です。しかし、SPFレコードの設定は一見シンプルに見えますが、実際には誤った設定が多く見られます。
本記事では、まずSPFレコードとは何か、その基本的な仕組みについて詳しく解説します。その他にも、SPFレコードの基本的な書き方から、FQDN（ホスト＋ドメイン名）での書き方、ネットワーク指定での書き方、サブドメインへの個別指定での書き方、メールを送信しない場合の書き方、さらには複数のSPFレコードを登録する方法まで、詳細に解説します。
メール送信をする際のおすすめのシステムもご紹介するのでぜひ最後までご覧ください。
目次
SPFレコードとは
SPFとは（Sender Policy Framework）の頭文字をとった略語で、SPFレコードはメール送信元のドメインを認証する技術のひとつです。IPアドレスを比較して送信元の実態を確認し、なりすましを防ぐことを目的としています。
送信ドメインを認証するシステムは複数ありますが、よく利用されているのがSPFレコードです。SPFレコードを使うと、サイバー攻撃やウイルスからサーバーを守れます。また、本来受信する必要のあるメールと迷惑メールが混ざらず、煩雑な状態になるのを防げます。
SPFの概要については以下の記事で詳しく解説していますので参考にしてください。
SPFレコードの仕組み
まず、送信元のSPFレコードをDNSサーバーに登録します。SPFレコードはDNSのTXTレコードとして設定され、受信メールサーバーは送信メールのヘッダー情報をもとに、送信元ドメインのDNSを参照します。
ここで、SPFレコードに記載されたIPアドレスやドメイン名が一致すれば、正しい送信者として認められ、一致しなければなりすましと判断される仕組みです。
DKIMとの違い
電子メールのセキュリティ対策には、SPFの他にもDKIM（DomainKeys Identified Mail）があります。どちらも、なりすましメールやスパムメールを防ぐために使用されますが認証方法や目的などに違いがあります。
認証方法
- SPF：送信元のIPアドレスを確認することでメールの信頼性を判断します。
- DKIM：メールの内容にデジタル署名を追加し、その署名の検証によってメールの信頼性を判断します。
目的
- SPF：送信元IPアドレスの偽装を防ぎます。送信者の身元確認に重点を置いています。
- DKIM：メールの内容が改ざんされていないことを保証します。送信中にメールが変更されていないことの確認に重点を置いています。
その他、DKIMについては以下の記事で詳しく解説していますので併せてご確認ください。
SPFレコードを設定すべき理由と設定しないリスク
SPFレコードの設定は、いまやメール配信を行う全ての送信者にとって避けて通れない要件となっています。ここでは、なぜ今SPFレコードの設定が必要なのか、そして設定しないとどのようなリスクがあるのかを整理します。
Gmail・Yahoo!メールの送信者ガイドラインによる実質的な必須化
2024年2月、Googleが適用を開始したGmailの「メール送信者のガイドライン」により、SPFレコードの設定は事実上の必須要件となりました。ガイドラインが定める要件は以下のとおりです。
- 個人用Gmailアカウント宛にメールを送る全ての送信者は、SPFまたはDKIMのいずれかを設定すること
- 1日あたり5,000通に近い、またはそれ以上のメールを送信する送信者は、SPF・DKIM・DMARCの全てを設定すること
- 送信元ドメインまたはIPに、有効な正引きおよび逆引きDNSレコードが存在すること
- メールの送信にTLS接続を使用すること
Yahoo!メールもほぼ同等の要件を課しており、国内の主要メールサービスはいずれも送信ドメイン認証の未対応メールを迷惑メール扱いする方向へ動いています。
SPF未設定・設定不備で発生する3つのリスク
SPFレコードを設定しない、または設定に不備がある場合、以下のような事態が発生します。
メールの不達
GmailやYahoo!メールなど主要なメールサービスは、SPFが未設定または認証失敗のメールを迷惑メールフォルダに振り分けます。場合によっては受信拒否となり、相手に一切届かないケースもあります。
なりすましメールの被害拡大
SPFが設定されていないドメインは、第三者が自由に差出人を詐称してメールを送れる状態です。顧客や取引先がフィッシング詐欺に遭うリスクが高まり、自社のブランド毀損につながります。
DMARCポリシーの機能不全
DMARCはSPFまたはDKIMの認証結果をもとに動作するため、SPFが正しく設定されていないとDMARCによるなりすまし対策も機能しません。
2025年11月以降の違反措置強化について
Googleは2025年11月以降、Gmail送信者ガイドラインに準拠していないメールに対する措置をさらに強化しています。非準拠の送信元からのメールは、一時的な拒否や永続的な拒否といった厳しい対応が取られるようになりました。
これまで「迷惑メールフォルダ行き」で済んでいたメールが、そもそも配信されずにエラーとなるケースが増えています。SPFレコードの設定は、もはや「推奨事項」ではなく、メール配信を継続するための前提条件です。まだ設定が済んでいない場合、または設定内容に不安がある場合は、速やかな見直しをおすすめします。
SPFレコードの構成要素
SPFレコードは、メール送信元の信頼性を確認するために使用されるDNSレコードです。SPFレコードの正しい設定は、なりすましやスパムメールの防止に役立ちます。
SPFレコードは複数の要素から構成されています。具体的には「バージョン番号」「機構」「限定子」「修飾子」とがあり、それぞれの組み合わせでメールの定義づけができるほか、応用すると別の機能を加えることも可能です。
バージョン番号
バージョン番号から始まるのが、SPFレコードの特徴です。
バージョン番号は「v=spf1」と指定します。バージョン番号は1のみであり、spf2やspf1.0と記すことはありません。1以外の番号で書かれたものは不正となります。
バージョン番号はSPFの仕様を示し、他の要素と区別するために重要です。
機構（mechanism）
機構はさまざまな情報を定義して、送られてきたメールのIPアドレスと照合するものです。以下のようなものが挙げられます。
- all
すべてのIPアドレスと適合させます。allより後に書かれた機構は無視されるため、通常は一番最後に置かれます。一致しないアドレスは定義されたデフォルトの結果（Pass、Fail、SoftFail、Neutral）が適用されます。 - a
指定されたドメインのAレコードに含まれるIPアドレスを照合します。送信元のIPアドレスがAレコードに含まれるIPアドレスと一致すれば許可され、一致しなかった場合の処理を限定子によって定義します。 - include
別のドメインを指定し、そのドメインのSPFレコードを参照します。includeで指定されたドメインがSPFレコードで認証された場合、メールを認証します。includeを使用すると、複数のドメインの認証条件を組み合わせることができます。 - ip4
送信元のIPアドレスが指定したipv4アドレスに含まれている、もしくは一致する場合は許可されます。 - ip6
送信元のIPアドレスが指定したipv6アドレスに含まれている、もしくは一致する場合は許可されます。 - mx
指定されたドメインのMXレコードに含まれるIPアドレスと送信元のIPアドレスを比較し、一致する場合に許可します。これにより、指定されたドメインのメールサーバーからのメールが許可されます。 - ptr
送信元のIPアドレスからドメイン名を逆引きするPTRレコードを使用します。このPTRレコードに基づいて、指定されたドメインのAレコードを照合します。ただし、PTRは信頼性が低いため、一般的には使用が推奨されていません。
限定子
照合する処理のルールを決めるシステムとして、限定子があります。正規のIPアドレスと送信者のIPアドレスを照らし合わせ、一致した場合、以下の処理を施します。
- +
Passの結果となります。送信元のIPアドレスが指定された条件と一致した場合、認証が成功し、メールを受け取れます。この限定子は省略可能であり、省略された場合のデフォルト値です。 - –
認証の失敗を意味するFailです。送信元のIPアドレスが指定された条件と一致しなかった場合、認証が失敗し、メールは拒否されます。認証に失敗したメールは不正メールと見なされ、受信者に届きません。 - ~
SoftFailの結果となります。メールボックスにメールは受信するものの、認証成功とまでは言えず、迷惑メールとして取り扱われます。正しい送信元のメールであっても、SoftFail扱いされる可能性もあるため、注意が必要です。 - ?
?はNeutralの結果となり、認証の成功とも失敗ともなりません。アクションは実行されず、メールはそのまま受信されます。
修飾子
修飾子はSPFレコードに追加の情報や動作を指定するための要素です。=で区切られた値か、もしくは名前のペアを用いて詳しい情報を示します。レコードの文末に記述し、最大2つまで書けることが特徴です。
SPFレコード内の修飾子に特定の数の制限はありませんが、レコード全体の長さに制限があるため、適切に管理することが重要です。
- redirect
他のドメインのSPFレコードを参照する際に使用します。2つ以上のドメインで同じSPFレコードを利用するときは、redirect修飾子を使って任せます。redirect修飾子を使用する場合、参照先のドメインが有効なSPFレコードを持っていることを確認する必要があります。 - exp
Fail限定子が含まれる場合、エラーを詳細に説明するために利用されるのがexp修飾子です。SPFログに記録され、問い合わせの失敗時にエラーメッセージを表示します。exp修飾子を使用する場合、指定されたURLが正しく設定されていることを確認する必要があります。
SPFレコードの書き方
SPFレコードを構成する要素を学んだところで、続いては書き方について見ていきましょう。SPFレコードの基本的な書き方から、用途別の書き方まで紹介します。
SPFレコードの基本的な書き方
SPFレコードの基本的な書き方は、以下のようになります。
ドメイン IN TXT “【バージョン番号】【限定子】【機構】【IPアドレス】”
例えば、以下のような記述になります。
example.jp IN TXT "v=spf1 +ip4:192.0.2.1 -all"この例では、example.jpというドメインからのIPアドレス192.0.2.1のメールのみを受信するというレコードです。それ以外のメールはすべて受信拒否となります。
FQDN（ホスト＋ドメイン名）での書き方
example.jp IN TXT "v=spf1 a:www.example.jp -all"v=spf1の後に続くIPアドレスを、FQDN（ホスト＋ドメイン名）に変えると、指定されたホストのAレコードに基づいて受信設定を行うことができます。この例では、www.example.jpのAレコードに含まれるIPアドレスからのメールのみを受信します。
ネットワーク指定での書き方
example.jp IN TXT "v=spf1 ip4:192.0.2.0/24 -all"CIDR（Classless Inter-Domain Routing）方式を用いて、ホストが所属するネットワークを指定する方法です。この例では、192.0.2.0から192.0.2.255までのIPアドレスからのメールを受信します。
サブドメインへの個別指定での書き方
sub.example.jp IN TXT "v=spf1 +ip4:192.0.2.1 -all"メインのドメインにSPFレコードで指定をして受信設定を行っても、サブドメインには適用されません。サブドメインに対して個別にSPFレコードを設定する必要があります。この例では、sub.example.jpからのIPアドレス192.0.2.1のメールのみを受信します。
メールを送信しない場合の書き方
example.jp IN TXT "v=spf1 -all"メールを送信しないドメインの場合、このように設定します。例えば、ホームページ専用のドメインや受信専用のドメインに対して設定することで、不正なメール送信を防ぐことができます。
複数のSPFレコードを登録する書き方
example.jp IN TXT "v=spf1 include:yyyy.com include:zzz.com -all"1つのドメインに対して複数のSPFレコードを書く場合、、全ての条件を1つのレコードにまとめて記載します。並べて一行のレコードにする・各レコードを別々のレコードとして記載する手法で登録すると、正常に動作しません。
この例では、yyyy.comおよびzzz.comのSPFレコードも含めて認証を行い、それ以外のメールはすべて拒否します。
よくあるSPFレコードの間違った書き方
間違った文法でSPFレコードを書くと、無効となり機能しません。正しい文法でSPFレコードを書いて、メールを定義どおり受信できるようにしましょう。
なお、書いたSPFレコードが正しいかどうかの確認方法もいくつかあります。オンラインツールにドメインを入力して確認する方法や、送信したメールのヘッダを確認してもらう方法、コマンドラインを使っての確認も可能です。
バージョンが間違っている
バージョンは「v=spf1」が正しい形式です。「v=spf2.0」といったバージョンは存在せず、誤りです。「1.0や2」など、誤ったバージョン番号を使用すると、SPFレコードは無効になるため、注意が必要です。
機構が省略されている
機構を省略していると、正しく機能しません。例えば、FQDN（完全修飾ドメイン名）を使用する場合、「a:」の後にドメイン名を省略せずに記載する必要があります。ip4、ip6、mxなど、他の機構も省略せずに正確に記載する必要があります。
1つのドメインに対しSPFレコードが複数行存在している
1つのドメインには、同じバージョンのレコードを1つだけ設定できます。複数のSPFレコードを同じドメインに設定すると、応答が不安定になり、エラーが発生する可能性があります。複数の条件を1つのSPFレコードにまとめて記載することで、正確に機能させることができます。
タイプミスしている
シンプルにタイプミスをしてしまっている可能性もあります。機能しない場合はどこかタイプミスをしていないかチェックしてみましょう。
勘違いからスペルミスをしているときも、同じようにエラーとなります。例えば「=」と「:」の勘違いはよくあるミスです。なかにはレコードの作成時に使ったツールが「~」を文字化けさせるといったケースもあります。
必要な空白文字が抜けている
SPFレコードを書くにあたって、スペース（空白文字）は必要不可欠です。スペースが入ることでそこが区切りとなり、システムが機能します。
スペースが入らずに文字列が続いていたり、二重引用符で区切られてスペースがないものとされていたりすると、エラーになります。前の文字列の後ろ、または後ろの文字列の前には必ずスペースを入れましょう。
redirectやincludeの先がない
redirectやincludeをを使用しても、参照先が存在しない場合、SPFレコードは無効となります。書いていた当初は存在していたドメインでも、その後参照先が変わって不通となった場合は、エラーとなり使えないレコードになります。そのため、定期的に参照先の有効性を確認することが重要です。
redirectやincludeがループしている
redirectやincludeに同じドメインを書くと、延々とお互いを参照してしまいそれ以上進まないケースがあります。これにより、認証が完了せずエラーが発生します。
includeの参照回数が10回を超えると、自動的にエラーとなります。特にincludeの使用時には、参照回数が10回を超えないように注意しましょう。
DNSルックアップ10回制限とSPF PermErrorの対策
「SPFレコードが正しく書かれているように見えるのに認証が失敗する」その主な原因が、RFC 7208で定められたDNSルックアップ10回制限です。ここではこの制限の仕組みと、発生時の対処法を解説します。
DNSルックアップ10回制限の仕組み
SPFレコードの評価時、受信サーバーはSPFレコードに記述された情報を確認するためにDNSへの問い合わせ（ルックアップ）を行います。このDNSルックアップは、1回のSPFチェックで最大10回までに制限されています。DNSルックアップの対象となるメカニズムと修飾子は以下のとおりです。
- include
- a
- mx
- ptr
- exists
- redirect
一方、ip4・ip6・allの3つはDNSルックアップを必要としないため、この制限にカウントされません。つまり、includeやa・mx・ptrを多用するSPFレコードほど、ルックアップ回数が嵩みやすい構造になっています。
なお、includeで参照されたSPFレコードの中でさらにincludeが使われている場合、その分もカウントされます。外部のメール配信サービスを複数併用していると、10回の上限に到達しやすくなる点に注意が必要です。
PermErrorが発生する原因
DNSルックアップが10回を超えた場合、受信サーバーはPermError（永続的エラー）を返してSPF認証を失敗と判定します。PermErrorが発生すると、認証失敗のメールとして扱われるため、迷惑メールフォルダへの振り分けや受信拒否のリスクが高まります。PermErrorの主な発生原因は次のとおりです。
- 複数のメール配信サービスをincludeで参照し、合計ルックアップ数が10回を超過
- 1つのドメインに複数のSPFレコードを設定
- 構文エラー（タイプミスや無効なメカニズムの記述）
- Voidルックアップ（参照先が存在しない）が2回を超過
- フラット化したSPFレコードが255文字を超過
特に注意すべきは、Google Workspace・Microsoft 365・各種CRMツール・マーケティングオートメーションツールなど、外部サービスを複数利用している企業のSPFレコードです。includeの連鎖によって気づかないうちに10回制限を超えているケースが少なくありません。
SPFフラット化による解決方法
DNSルックアップ10回制限を超えてしまった場合の対策として代表的なのが、SPFフラット化と呼ばれる手法です。SPFフラット化とは、includeで参照しているメカニズムを、実際のIPアドレス（ip4・ip6）に置き換えてSPFレコードを書き直すことを指します。
例えば、以下のようなSPFレコードがあったとします。
example.jp IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"これをフラット化すると、参照先のIPアドレスを展開して記述する形になります。
example.jp IN TXT "v=spf1 ip4:209.85.128.0/17 ip4:40.92.0.0/15 ip4:40.107.0.0/16 -all"ただし、SPFフラット化には運用上の注意点があります。参照先サービスのIPアドレスが変更された場合、フラット化したSPFレコードを手動で更新しないと、正規のメールが認証失敗になるリスクがあります。SPFフラット化を選択する場合は、専用の自動更新ツールの利用や定期的な棚卸しを組み合わせることが推奨されます。
現実的な対処として、使っていないメール配信サービスのincludeを削除する、不要になった外部サービスのSPFエントリを整理する、といったシンプルな見直しが最優先です。SPFフラット化はその上で、なお制限を超える場合の最終手段として検討します。
Voidルックアップ（2回制限）にも注意
DNSルックアップ10回制限に加えて、Voidルックアップという制限も存在します。Voidルックアップとは、SPFレコード内のメカニズムや修飾子で参照するDNSホストが存在しない場合のルックアップのことです。
1回のSPFチェック内でVoidルックアップが2回を超えると、10回の通常ルックアップ制限と同様にPermErrorが発生します。includeやredirectの参照先が廃止されたサービスのままになっていると、このエラーが起こりやすくなります。
SPFレコードを見直す際は、10回制限だけでなくVoidルックアップの発生有無も併せて確認しましょう。
SPFレコードの確認方法
SPFレコードは設定して終わりではなく、設定後に正しく反映されているか、意図した内容になっているかを確認することが重要です。ここでは実務で使える4つの確認方法を紹介します。
digコマンドで確認する方法
Mac・Linux環境で最も一般的な確認方法が、digコマンドによるTXTレコードの取得です。ターミナルを開いて以下のコマンドを実行します。
dig -t TXT example.jp「example.jp」の部分には確認したい自社ドメインを指定します。正しく設定されている場合、ANSWER SECTIONに「v=spf1〜」から始まるテキストが表示されます。includeを使っている場合は、参照先のドメインに対しても同じコマンドを実行し、連鎖を追いかけることができます。
nslookupコマンドで確認する方法（Windows）
Windows環境ではnslookupコマンドを使います。コマンドプロンプトまたはPowerShellを起動し、以下のコマンドを実行します。
nslookup -type=TXT example.jpdigコマンドと同様に、表示されたTXTレコードの中に「v=spf1〜」という記述があれば、SPFレコードが設定されていることが確認できます。PowerShell環境では以下のコマンドも利用可能です。
Resolve-DnsName -Type TXT example.jpオンラインツールで確認する方法
コマンド操作に慣れていない場合、Webブラウザから利用できるオンラインツールが便利です。代表的なツールにMxToolBoxのSPF Record Lookupや、DmarcianのSPF Surveyorがあります。これらのツールはドメインを入力するだけで、SPFレコードの内容に加えてDNSルックアップ回数も可視化してくれます。
特にDNSルックアップ10回制限の超過をチェックしたい場合、オンラインツールの利用が最も効率的です。PermErrorの原因となるincludeの連鎖も、視覚的に把握できます。
受信したメールのヘッダから確認する方法
最終的に受信側でSPFがPASSしているかは、実際に送ったメールのヘッダ情報から確認できます。Gmail宛にテストメールを送り、以下の手順で確認しましょう。
- Gmailで対象のメールを開く
- メール右上のメニューから「メッセージのソースを表示」をクリック
- 概要欄の「SPF」「DKIM」「DMARC」の項目を確認
「PASS」と表示されていれば認証成功、「FAIL」となっている場合は設定に不備があります。認証結果が表示されない場合は、そもそもSPFレコード自体が設定されていない可能性が高いため、DNSの設定を見直してください。
SPFだけでは不十分｜DKIM・DMARCとの併用
SPFレコードの設定はメール認証の出発点ですが、それだけでなりすまし対策が完結するわけではありません。現在のメールセキュリティ基準では、SPF・DKIM・DMARCの3つを組み合わせた対応が標準です。
SPF・DKIM・DMARCそれぞれの役割
SPF・DKIM・DMARCは、それぞれ異なる観点でメールの正当性を検証する技術です。
SPF
送信元IPアドレスの認証を行う技術で、送信元のドメインが許可したIPアドレスからメールが送信されているかを確認します。ただし、メール本文やヘッダの改ざんは検知できません。
DKIM
電子署名を使ってメール本文の改ざん検知と送信者認証を行う技術です。送信側が秘密鍵でメールに署名を付与し、受信側が公開鍵（DNSレコードで公開）で検証します。SPFと異なり、メール転送時にも認証を維持しやすい特長があります。
DMARC
SPFとDKIMの認証結果を利用し、認証失敗時の処理方針（受信拒否・隔離・何もしない）を送信側が指定する仕組みです。加えて、認証状況のレポートを受信サーバーから受け取ることができ、なりすましの試みを把握できます。
これら3つを組み合わせることで、送信元IPの認証（SPF）・メール内容の改ざん検知（DKIM）・認証失敗時の処理（DMARC）という多層的ななりすまし対策が完成します。
Gmail送信者ガイドラインにおける要件
Googleが定めるメール送信者のガイドラインでは、送信規模に応じて求められる認証レベルが明確に分かれています。
個人用Gmailアカウントにメールを送る全ての送信者には、SPFとDKIMのいずれか1つの導入が求められます。一方、1日あたり5,000通に近い、またはそれ以上を送信する一括送信者には、SPF・DKIM・DMARCの全てと、DMARCアライメントへの準拠が義務付けられています。
ここで重要なのが、DMARCアライメントの要件です。DMARCアライメントとは、メールのFromヘッダドメインが、SPFまたはDKIMで認証されたドメインと一致している必要があるという条件です。SPFは設定されていてもアライメントが取れていないケースは意外と多く、DMARCレポートの定期的な確認が欠かせません。
将来的にはSPFとDKIMの両方に対するDMARCアライメントが必須になる可能性も示唆されています。今のうちから3点セットでの対応を進めておくことが、長期的なメール配信の安定につながります。
SPFが設定できるメール配信システムの活用
本記事の冒頭で記載したようにメールのセキュリティは日を追うごとに強化されています。例えば、Gmailでは2024年2月にメール送信者ガイドラインを更新し、以下のような内容が明記されました。
- 送信メールを認証すること
- 未承諾のメールまたは迷惑メールを送信しないこと
- 受信者がメールの配信登録を容易に解除できるようにすること
つまり、送信元の正当性を正しく認証した上で、ユーザーが迷惑がらないようにメールを送信することがメール送信者には求められています。このガイドラインの要件を満たせていないメールは迷惑メールに割り振られてしまったり、受信を拒否されることがあります。
その中でも、「送信メールを認証すること」は今後もメール関連のセキュリティが強化されていくことが想定できるため必須と言えるでしょう。
そのため、メール配信システムを活用してメール配信を行う場合は、「SPFやDKIMが設定できる」などのメール認証ができるシステムを選ぶようにしましょう。
おすすめのシステムは以下で紹介します。
API連携・SMTPリレーサービス「ブラストエンジン(blastengine)」
SPFやDKIMなどGmail送信者ガイドライン対応しており、API連携・SMTPリレーが可能なメール配信システムです。
ブラストエンジンは、SMTPリレーサーバーを使用して、簡単に大量のメールを高速配信することが可能です。さらに、メールサーバーを必要とせず、API経由でメールを送信する仕組みも提供しています。
ブラストエンジンは、サーバーの運用やメンテナンスを行っているため、常に高いIPレピュテーションを維持しながら、安全にメールを送ることができます。
以下のような課題がある場合は、ブラストエンジンの利用を検討してみることをおすすめします。
- 自社のIPアドレスやドメインがブラックリストに登録されていて、メールが届かない場合
- 国内キャリアにメールが届かず、対応方法がわからない場合
- 自社でメールサーバーを管理・運用したくない場合
また、ブラストエンジンは各メールプロバイダーや携帯キャリアのドメインに最適化されており、大規模なネットワークを経由してメール配信を行うことで、日本国内での到達率を圧倒的に高めています。
利用料金は月額3,000円からとコストパフォーマンスにも優れており、メールだけでなく、日本語での電話サポートにも対応しています。
メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。
シェア1位のメール配信システム「ブラストメール」
SPFやDKIMなどGmail送信者ガイドライン対応（standardプラン以上）しており、シンプルで使いやすいメール一斉配信システムです。
ブラストメールは、15年連続で顧客導入シェア1位を獲得している信頼性の高いメール配信システムです。ブラストエンジンとは異なり、メルマガなどのメール一斉送信に利用することができます。
このメール配信システムの特徴は、使いやすさとコストパフォーマンスの高さです。さまざまな業種や官公庁でも利用されており、定番のメール配信システムとして広く知られています。
迷惑メール対策機能はもちろん、セグメント配信や効果測定、HTMLメールエディタなど、基本的な機能がすべて揃っています。最も安いプランでも、月額4,000円以下で導入することができます。
シンプルで安価なため、初めてメール配信システムを利用してみたい方にもおすすめです。無料トライアルも用意されているので、まずは試してみることをお勧めします。
FAQ
- Q：SPFレコードは必ず設定しないといけませんか？
- A：Gmailへメールを送る全ての送信者にSPFまたはDKIMの設定が必須です。2024年2月のGmail送信者ガイドライン以降、個人用Gmailアカウント宛にメールを送る場合はSPFまたはDKIMのいずれかが必要とされており、2025年11月以降は非準拠メールへの違反措置が強化されています。1日5,000通以上送信する場合はSPF・DKIM・DMARCの全てが必要です。
- Q：1つのドメインに複数のSPFレコードを設定できますか？
- A：できません。1ドメインにつきSPFレコードは1つのみで、複数設定するとPermErrorとなり認証に失敗します。複数のメール配信サービスを利用する場合は、includeメカニズムを使って1つのレコード内にまとめて記述してください。
- Q：SPFレコードのDNSルックアップ10回制限とは何ですか？
- A：RFC 7208で定められたSPF評価時のDNS参照回数の上限です。include・a・mx・ptr・exists・redirectはDNSルックアップを発生させ、1回のSPFチェックで合計10回を超えるとPermErrorとなり認証失敗します。複数のメール配信サービスをincludeしている場合に超過しやすいため、SPFフラット化などで対処します。
- Q：SPFレコードが正しく設定されているか確認する方法は？
- A：digコマンド（Mac/Linux）やnslookupコマンド（Windows）でDNSのTXTレコードを取得する方法、Gmailで受信したメールのヘッダを確認する方法、MxToolBoxやDmarcian SPF Surveyorなどのオンラインツールを使う方法があります。オンラインツールを使えばDNSルックアップ回数も可視化できます。
- Q：SPFレコードを設定すれば、なりすましメールは完全に防げますか？
- A：SPFだけでは不十分です。SPFは送信元IPアドレスの認証のみを行うため、メール本文の改ざん検知はできません。なりすまし対策を万全にするには、SPFに加えてDKIM（電子署名による改ざん検知）とDMARC（認証失敗時の処理ポリシー）を併せて設定することが推奨されます。
まとめ
SPFレコードでメールを定義し分類することは、なりすましによる詐欺やウイルスの被害を防ぐことにつながります。またメールが迷惑メールフォルダに振り分けられ、正しく受信できないといったトラブルも抑えられるでしょう。
なりすましによる詐欺に引っかかると、個人情報をはじめとした重要な情報が漏れるかもしれません。またメールを正しく受信ができていないと、信用問題に関わることもありえるでしょう。
このような問題を防ぐために、SPFレコードでドメインごとに定義づけを行い、受信の精度を高めることが重要です。その際には正しい文法で書き、正確に分類されるかの確認も忘れずに行います。メールセキュリティを強化して、なりすまし対策を万全にし、無用な心配がないように運用しましょう。
