SPFレコードの設定手順とサービス別の構成例

SPFレコードの設定は、受信メールサーバーが行う認証の一つです。SPFは必ず最初に確認されるわけではなく、唯一の検査でもありません。設定ミスは拒否につながることがありますが、SMTPエラー550 5.7.26だけでSPFが原因とは判断できません。2024年二月からGoogleとYahooの認証要件が導入されており、適用範囲は送信量や受信サービスなどによって異なります。

よくある問題は、レコードの重複、DNS問い合わせを伴う項目の上限10個の超過、末尾の修飾子の選択ミスです。配送に影響し、何日も気付かない場合があります。バウンスメールだけでは原因がはっきりしない場合もあります。

このガイドでは、SPFの構文、TrekMailのManaged SMTPとBYOの設定例、DNSへの公開、コマンドラインでの確認を説明します。ドメインのメール設定がまだなら、先に独自ドメインでメールを設定する方法を読み、その後に認証を追加してください。

SPFの役割

SPF（Sender Policy Framework）は、ドメインからの送信を許可するサーバーをDNS TXTレコードで公開する仕組みです。受信サーバーは送信元IPとそのポリシーを照合できます。一致しない場合のSPF結果は修飾子によって決まり、受信するかどうかは受信側が判断します。RFC 7208で定義されているとおり、SPFが確認するのはMAIL FROM、つまりエンベロープ送信者であり、画面に表示されるFromヘッダーではありません。

SPFがなければ、エンベロープ送信者に対する公開された許可情報を受信側が参照できません。ただし、ほかの検査は可能です。適用される場合はHELOの識別名もSPFの対象になり、ポリシーがないだけで拒否が義務付けられるわけではありません。一般的なDMARC検査では、SPFが成功するかDKIM署名が有効で、そのドメインが表示されるFromと整合すれば足ります。SPFだけではあらゆる偽装の防止や受信トレイへの到達を保証できません。

SPFレコードは一つにまとめる

同じDNS名にはSPFのTXTリソースレコードを一つだけ公開できます。v=spf1で始まる独立したリソースレコードが二つあるとPermErrorになります。一つのレコードに含まれる複数の引用符付き文字列は、連結して扱われます。PermErrorで受信側が拒否する可能性はありますが、全メールの拒否は必然ではありません。プロバイダーの切り替えやツールの追加時は重複に注意してください。

既存のSPFレコードを編集し、必要な許可を統合してください。置き換えの準備ができる前に削除すると、公開ポリシーに空白期間が生じるおそれがあります。

手順1：送信するすべてのサービスを洗い出す

DNSを変更する前に、@yourdomain.comとして送信するサービスをすべて挙げます。見落としたサービスがそのドメインをMAIL FROMに使っていると、-allの公開後にSPF Failになる可能性があります。五分で洗い出すというのは計画例で、所要時間の約束ではありません。丁寧な確認で後の調査を何時間も減らせる場合もありますが、最終的な拒否は受信側のポリシー次第です。

確認したい主な送信元：

• 社内メール：TrekMail、Google Workspace、Microsoft 365
• トランザクションメール：Amazon SES、SendGrid、Mailgun、Postmark
• マーケティング：Mailchimp、HubSpot、Klaviyo、Brevo
• SaaSツール：Zendesk、Freshdesk、Shopify、Intercom

bounce.mailchimp.comのような独自のReturn-Pathドメインを使うサービスは、その場合、自社ドメインのSPFに含める必要がないことがあります。一方、DMARCアライメントのために自社ドメインのエンベロープ送信者を使うサービスもあります。プロバイダーの資料とアカウントの実際の設定を確認してください。

手順2：SPFレコードを組み立てる

SPFはDNS TXTリソースレコードで、必要に応じて内部の文字列を連結して評価します。基本構造は共通で、メカニズムを送信経路に合わせて選びます。次のアドレス範囲は文書用の例であり、実際の送信サーバーを表していません。各要素の役割は次のとおりです。

手順3：プロバイダー別のSPF設定

自分の構成に合うシナリオを選びます。以下は設定例なので、公開前に最新のプロバイダー資料とアカウント設定を照合してください。複数のプロバイダーを使う場合は、includeメカニズムを一つのレコードに統合します。

シナリオA：TrekMail Managed SMTP（StarterとAgencyプラン）

現在のTrekMailプランにManaged SMTPが含まれ、対象のエンベロープドメインで送信するサービスがそれだけなら、レコードは次のような形になります。

v=spf1 include:spf.trekmail.net -all

TrekMailが公開する送信ポリシーを参照します。ほかの送信サービスも忘れずに含めてください。

シナリオB：TrekMail BYO SMTP（無料プランまたは独自構成）

TrekMailを受信用に使い、送信には自分のSMTPプロバイダーを接続する場合、そのプロバイダーの資料に従って許可します。重要なのは、最終的な配送を行うサーバーのIPと実際のエンベロープ送信者ドメインです。

# Amazon SES
v=spf1 include:amazonses.com -all

# SendGrid
v=spf1 include:sendgrid.net -all

シナリオC：Google Workspace

v=spf1 include:_spf.google.com -all

シナリオD：Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

シナリオE：TrekMailとマーケティングサービスの併用

社内メールにTrekMail、キャンペーンにHubSpotを使う場合、両方が同じエンベロープドメインで送信するなら、一つのレコードにまとめます。

v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -all

HubSpotのinclude値はポータルごとに異なります。例の番号をコピーせず、HubSpotのDNS設定画面から取得してください。

手順4：DNSに公開する

ドメインのDNSプロバイダーで、ポリシーをTXTレコードとして公開します。Cloudflare、Namecheap、GoDaddy、Route 53など、DNSを管理しているサービスにログインしてください。

1. 種類：TXT
2. ホスト/名前：@（プロバイダーによっては空欄）
3. 値：完全なSPF文字列。例：v=spf1 include:spf.trekmail.net -all
4. TTL：3600（1時間）

既存のSPFレコードがあれば、二つ目を追加せず更新します。必要な許可を残し、先に削除して空白期間を作らないようにしてください。更新後はSPFレコードが一つだけであることを確認します。

手順5：SPFレコードを検証する

公開結果をコマンドラインで確認します。表示されるのは使用中のDNSリゾルバーの応答であり、キャッシュの内容が返る場合もあります。コマンドラインやTTLの設定で、すべてのDNSキャッシュを回避できるわけではありません。

# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com

# Linux/Mac alternative
dig txt yourdomain.com +short

確認するのは次の三点です。

• v=spf1で始まるTXTレコードが一つだけある
• 必要なincludeメカニズムがすべて含まれている
• 選んだポリシーに応じて-allまたは~allで終わっている

v=spf1で始まる独立したリソースレコードなのか、一つのレコード内の文字列が分かれて表示されているだけなのかを確認します。本当の重複は必要な許可を統合してから削除してください。再帰的な評価と実際のメールも検証します。DNSへの公開だけでは、SPFの成功、DMARCアライメント、受信トレイへの到達は確認できません。

よくあるSPFエラーの調べ方

次の三つの問題から調査対象を絞れます。原因を決めつける前に、SMTPの完全な応答と認証結果も確認してください。

1. DNS問い合わせの上限10個（PermError）

SPFでは、評価時にDNS問い合わせを伴う項目は10個までです。include、a、mx、exists、ptr、redirectや、参照先での再帰的な評価に含まれる項目も数えられます。単純なDNSパケットの総数ではありません。10個を超えるとPermErrorとなり、受信側が拒否することがあります。

症状：検証ツールがPermErrorまたは「too many DNS lookups」を返す。

対処：MailchimpやZendeskなど、適したサービスをsupport.yourdomain.comのようなサブドメインへ移します。サブドメインには独立した上限10個がありますが、実際のMAIL FROMにそのサブドメインを使い、SPFも正しく設定して初めて役立ちます。これによりメインドメインのポリシーを簡潔にできます。

2. Microsoftの個人向けメール（550 5.7.515）

550 5.7.515が表示されたら、Microsoftのエラー全文を確認してください。SPFが正しい、またはIP評価が原因だとは即断できません。個人向けHotmailやOutlook.comへの対象となる大量送信では、SPFとDKIMの両方が成功し、成功した仕組みの少なくとも一方がFromと整合してDMARCにも合格する必要があります。それでも受信トレイへの到達は保証されません。設定についてはビジネスメールのセキュリティ基礎を参照してください。

3. SoftFail（~all）とHardFail（-all）

~allはSoftFail、?allは許可について判断を示さないNeutralを返します。すべての正当な送信経路を確認してから-allへ切り替えてください。DKIM、DMARC、受信側のポリシーも引き続き重要です。

TrekMailでSPFを設定する

DNSの管理やSMTPエラーの調査には時間がかかります。現在のTrekMail構成でSPF/DKIM/DMARCウィザードが利用できる場合、Managed SMTPやBYOの設定に役立ちます。表示された値が自分のドメイン用であることを確認してください。

多数の顧客ドメインを管理する代理店には、統一した設定手順が有効です。マルチドメインダッシュボードは想定するDNSレコードの確認に役立ちますが、その表示は実際のメールの暗号学的認証、アライメント、受信トレイへの到達を測るものではありません。運用の流れは複数ドメインのメールホスティングと独自ドメインのメールを作成する方法をご覧ください。

元のプラン概要には、Managed SMTPを含むStarterが月額$3.50、BYO SMTPを使うNanoがプラン料金無料でクレジットカード不要かつ試用期限なし、有料プランがクレジットカード必須の14日間試用と記載されています。説明したNanoの構成では、返信を含むすべての送信に自分のSMTPプロバイダーが必要です。Managed SMTPの利用権限を持つ有料プラン全体の要件ではありません。料金、提供状況、条件は変わる可能性があるため、最新の案内をご確認ください。TrekMailを試す。

SPF設定の最終チェックリスト

完了前に次の七項目を確認します。簡単な設定なら15分未満で準備できることもありますが、DNSキャッシュや複雑な送信経路には追加の時間が必要です。

1. ドメインを使って送信するすべてのサービスを洗い出した
2. 既存SPFレコードがゼロまたは一つであり、二つではないことを確認した
3. 必要なすべてのプロバイダーを含む一つのv=spf1文字列を作成した
4. @にTXTレコードとして公開し、TTLを3600にした
5. 公開の空白期間を作らず既存レコードを更新し、統合後に重複を削除した
6. dig txt yourdomain.com +shortで確認した
7. v=spf1で始まり、選択した-allで終わるレコードが一つだけあると確認した

DNS設定をもっと手軽に。TrekMailで送信を始める。