SiteGroundのSPF・DKIM・DMARC設定。
レジストラだけのサービスと違い、SiteGroundはこの作業の大半を代行しようとします。ドメインがSiteGroundのネームサーバーとメールサービスを利用していれば、Webサイトのプロビジョニングと同時にSPF、DKIM、DMARCがすべて自動的に作成されます。そのためSiteGroundでの作業は、「3つのレコードを一から追加する」ことよりも、「SiteGroundがレコードをどこに置いたかを把握し、有効であることを確認して、他に利用している送信サービスをレコードにまとめる」ことが中心です。注意点は、SiteGroundの設定が2つの場所と2つの画面に分かれていることです。SPFとDKIMはSite Tools内の専用ツールEmail > Authenticationにあり、DMARCはDNS Zone Editorで編集する素のTXTレコードとしてのみ存在します。このガイドでは、正確なメニューパス、SiteGroundのデフォルトのレコード形式、そしてすべての前提となる唯一の条件（SiteGroundが実際にDNSを管理していること）とあわせて、両方の手順を説明します。
SiteGroundを認証すべき理由
認証は今や受信トレイに届くための前提条件であり、あれば望ましいという程度のものではありません。GoogleとYahooの送信者ガイドラインでは、すべての送信者にFromドメインとアライメントが一致したSPFまたはDKIMの少なくとも一方が必要で、大量送信者（Gmail宛てに1日5,000通超）にはSPF、DKIM、DMARCポリシーが必要です。SiteGroundは膨大な数のWordPressサイトをホストしているため、そのサーバーは注文確認、パスワードリセット、問い合わせフォームの返信といったトランザクションメールを、お使いのドメインとして大量に送信します。これらのレコードがないと、メールはなりすましされやすく、すぐに迷惑メールに振り分けられます。未認証メールを送るドメインというレピュテーションがつくと、担当者が手で送る返信も含め、送信するすべてのメールに悪影響が及びます。
SiteGroundにおけるSPFの実情
SiteGroundはSPFレコードを自動的に公開します。デフォルトの形式は`v=spf1 +a +mx include:_spf.mailspamprotection.com ~all`です。それぞれに役割があります。`include:_spf.mailspamprotection.com`はSiteGroundの送信メールリレーを許可します（mailspamprotection.comはSiteGroundのメールフィルタリング基盤で、ネストされたincludeのない少数のip4範囲に解決されるため、DNSルックアップは1回です）。`+a +mx`はホスティングアカウント自身のIPとMXレコードを許可し、WordPressの通知、PHPのmail()、問い合わせフォームなど、サーバー自体が生成するメールもSPFに成功するようにします。DNSルックアップの10回制限に注意してください。この標準のレコードだけで、他の送信元を追加する前に10回のうち3回（`+a`、`+mx`、includeで各1回）を消費しています。すべてのメールをSiteGroundから送信しているなら、このレコードはそのままにしてください。Google Workspace、Microsoft 365、SendGridやBrevoなどのメール配信サービス（ESP）、SiteGround自身のEmail Marketingといった別の送信元を追加する場合は、その送信元の`include:`を必ずこの1つのレコードにまとめ、2つ目のSPFのTXTレコードとしては公開しないでください。また、MXをGoogleやMicrosoftに移し、SiteGround経由の送信をやめている場合、`+a +mx include:_spf.mailspamprotection.com`は使っていないサーバーを許可している可能性があるため、削ることを検討してください。SiteGroundから送るメールにはこのincludeが推奨される方法なので、実際にSiteGround経由の送信をやめた場合を除き、残しておいてください。
設定手順
- 1
SiteGroundが実際にDNSを管理しているか確認
自動作成されるレコードとAuthenticationツールのすべての切り替えが実際のDNSに反映されるのは、ドメインがSiteGroundのネームサーバーまたはSiteGround管理のDNSを利用している場合だけです。ネームサーバーがCloudflare、レジストラ、または別のホストを指している場合、権威を持つゾーンはそちらにあり、Site Toolsでの設定は何も効きません。そのサービスのエディターで、SPF、DKIM、DMARCのレコードを作成し直す必要があります。何よりも先にネームサーバーを確認してください。これが、SiteGroundのレコードが「機能しない」最も多い原因です。
- 2
Email Authenticationツールを開く
SiteGroundがSPFとDKIMのために用意した専用パネルで、2つのタブに分かれています。ドメインがSiteGroundのDNSとメールボックスを利用している場合、どちらもデフォルトで有効なので、このツールは主にステータスの確認とカスタマイズに使います。ここにDMARCはない点に注意してください。AuthenticationツールにDMARCの切り替えはなく、このレコードはDNS Zone Editorで別途編集します。
- 3
デフォルトのSPFレコードを確認
SiteGroundの標準レコードは`v=spf1 +a +mx include:_spf.mailspamprotection.com ~all`です。SPFタブでは、許可するAレコードやMXサーバーの追加、特定のIPアドレスのブロック、includeリストの管理、末尾のall修飾子の調整ができます。すべてのメールをSiteGroundから送信しているなら、このままにしてください。`~all`はsoftfail（受け入れるがフラグを付ける）で、すべての正規の送信元を記載するまでの安全なデフォルトです。
- 4
他の送信サービスを1つのSPFレコードにまとめる
Google Workspace（`include:_spf.google.com`）、Microsoft 365、ESP、またはSiteGround Email Marketingからも送信する場合は、それぞれのincludeをこの1つのレコードにまとめます。1つのドメインで公開できるSPFのTXTレコードは1つだけで、2つ目があるとSPF全体が機能しなくなります。includeはAuthenticationツールのincludeリストから追加するか、DNS Zone EditorでSPFのTXTを直接編集します。SPFレコード作成ツールを使えば、includeと修飾子が正しい順序に並んだ有効な文字列を1つ作成できます。送信元を追加する際は、DNSルックアップの10回制限にも注意してください。
- 5
DKIMがActiveか確認
SiteGroundはDKIM鍵ペアを自動生成し、公開鍵をセレクター`default`（ホスト`default._domainkey`）で、`v=DKIM1; k=rsa; p=…`の形式の値として公開します。DKIMタブにはACTIVEまたはINACTIVEと表示されます。INACTIVEの場合、ACTIVATEをクリックすると、SiteGroundがレコードをゾーンに書き込みます。鍵の生成や貼り付けは一切不要です。鍵をローテーションするには、DeactivateしてからActivateします。この鍵が署名するのはSiteGround自身が送信するメールだけである点に注意してください。
- 6
自動作成されたDMARCレコードを見つけて編集
Webサイトの作成時に、SiteGroundは`v=DMARC1; p=none;`で始まる基本的なDMARCレコードを`_dmarc`に追加しています。DNS Zone Editorを開き、値が`v=DMARC1`で始まるTXTレコードを見つけて鉛筆アイコンをクリックし、Valueを編集して自分のレポート先アドレスを追加します（例：`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`）。その後Confirmをクリックします。配信に影響を与えずレポートを収集できるよう、ポリシーは`p=none`のままにしてください。タグを正しい形式にしたい場合は、DMARCレコード作成ツールで値を作成できます。
- 7
外部サービスのDKIMを各セレクターで追加
SiteGroundの`default`セレクターが対象とするのは、SiteGroundから送信するメールだけです。Google Workspace、ESP、Email Marketingはそれぞれ別のセレクター（`google._domainkey`、`s1._domainkey`、または各サービスがホストするCNAMEターゲット）を提示します。DNS Zone Editorで、指定されたとおりに追加のレコードとして公開してください。複数のDKIMセレクターが共存するのは正常で正しい状態です。それぞれ独自のホストにあるためです。
- 8
すべてのレコードが解決されることを確認
DNSの反映まで数分～2時間ほど待ち、ドメインとDKIMセレクター`default`を外部のチェックツールで確認します。SPFレコードがちょうど1つあること、`default._domainkey`でDKIM鍵が見つかること、`_dmarc`レコードが1つだけあることを確かめてください。SiteGroundが実際に公開している内容の基準となるのは、DNS Zone EditorのManage DNS Recordsの表です。
追加するレコード
正確な値はSiteGroundのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 +a +mx include:_spf.mailspamprotection.com ~allSiteGroundが自動作成するデフォルトのSPFレコードです。他の送信元のincludeはこの1つのレコードにまとめ、2つ目のSPFのTXTレコードは公開しないでください。値はSiteGroundから送信するメールについて正確なものです。+a、+mx、includeはそれぞれDNSルックアップを1回消費します（合計3回）。 |
| TXT | default._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC… (illustrative public key)SiteGroundがセレクター「default」で自動生成します。DKIMがActiveのときに作成されるので、貼り付けることはありません。表示している鍵は例で、実際の鍵は異なります。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSiteGroundは最小限のp=noneレコードを自動作成します。DNS Zone Editorで編集し、自分のruaレポート先アドレスを追加してください。値は例です。レポートに問題がなくなるまでp=noneのままにしてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。SiteGroundの設定がこの上限のうち何回を消費するかは、次のとおりです。
SiteGroundは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
SiteGroundのDKIMは完全に自動で、鍵を貼り付ける必要はありません。ドメインがSiteGroundのネームサーバーとメールサービスを利用している場合、SiteGroundはRSAの鍵ペアを生成し、秘密鍵をメールサーバーに保持して、公開鍵を固定のセレクター`default`で公開します。そのためレコードのホストは`default._domainkey`で、値は`v=DKIM1; k=rsa; p=<public key>`の形式になります。管理はすべてSite Tools > Email > Authentication > DKIMで行います。ステータスはACTIVEまたはINACTIVEと表示され、ACTIVATEをクリックするとレコードがゾーンに書き込まれます。鍵をローテーションするには、Deactivateしてからもう一度Activateします。重要な制限として、この鍵が署名するのはSiteGroundが送信するメールだけです。Google Workspace、Microsoft 365、またはESP経由で送るメールは各サービス独自のセレクターで署名されるため、そのサービスのDKIMレコードを別途公開する必要があります。SiteGroundの`default`セレクターではカバーされません。
DMARC
DMARCはポリシーの層で、SPFとDKIMを表示上のFromアドレスに結び付け、レポートを有効にします。SiteGroundはWebサイトのプロビジョニング時に、`v=DMARC1; p=none;`で始まる基本的なDMARCレコードを`_dmarc`に作成します。SPFやDKIMと異なり、Authenticationツールにはありません。DNS Zone Editor（Site Tools > Domain > DNS Zone Editor、またはClient Area > Services > Domains > Settings）で素のTXTレコードとして編集します。`v=DMARC1`で始まるTXTを見つけて鉛筆アイコンをクリックし、実際に読むメールボックスに集計レポートが届くよう、自分のレポート先アドレスを追加します：`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`。監視中は`p=none`のままにしてください。配信には何も影響せず、日次レポートが有効になるだけです。すべての正規の送信経路が、アライメントの一致したSPFまたはDKIMに成功していることをレポートで確認してから、`p=quarantine`、さらに`p=reject`へ引き上げてください。
正しく設定できたか確認する
反映まで数分～2時間ほど待ってから、送信ドメイン認証チェックを使い、SiteGroundの外部から3つすべてを確認します。ドメインとDKIMセレクター`default`を貼り付けてください。確認するのは、SPFレコードがちょうど1つ（2つではない）あること、`default._domainkey`でDKIM鍵が見つかること、`_dmarc`のTXTレコードが1つだけあることです。ゾーンが実際に公開している内容の基準となるのはSiteGround自身のDNS Zone Editor（Manage DNS Recordsの表）なので、チェック結果と食い違う場合はそちらと照合してください。レコードが見つからない場合は、次の順に再確認します。SiteGroundのネームサーバーが実際にドメインのDNSを提供しているか、DMARCレコードをAuthenticationツールで探さずDNS Zone Editorで編集したか、外部サービスのDKIMをそのサービス独自のセレクターで公開したか、です。
よくある注意点
- 適用範囲
すべてはSiteGroundがDNSを管理していることが前提です。ネームサーバーがCloudflare、レジストラ、または別のホストを指している場合、自動作成されたレコードもAuthenticationツールの切り替えも効果がなく、そのサービスのDNSエディターで、SPF、DKIM、DMARCのレコードを作成し直す必要があります。他のトラブルシューティングの前に、ネームサーバーを確認してください。
- DNS設定
SPFとDKIMの設定はSite Tools > Email > Authenticationにありますが、DMARCはDNS Zone Editorにしかありません。AuthenticationツールでDMARCの切り替えを探して見つからず、DMARCがないと思い込むことがありますが、v=DMARC1で始まるTXTレコードとしてすでに存在しています。
- 適用範囲
SiteGroundのデフォルトのDKIM（セレクター「default」）が署名するのは、SiteGroundが送信するメールだけです。Google Workspace、Microsoft 365、またはESPからのメールにはSiteGroundの署名が付かず、各サービス独自のセレクターでDKIMを公開する必要があります。そうしないと、SiteGroundでDKIMがACTIVEと表示されていてもDKIMに失敗します。
- 認証失敗の原因
2つ目のSPFレコードは絶対に公開しないでください。別の送信サービスを追加するときは、そのincludeをAuthenticationツールのincludeリストまたはDNS Zone Editorから、既存のv=spf1 …mailspamprotection.com…レコードにまとめます。SPFのTXTレコードが2つあると、ドメイン全体でSPFに失敗します。
- 適用範囲
MXレコードをGoogleやMicrosoftに移し、SiteGround経由の送信をやめている場合、デフォルトの+a +mx include:_spf.mailspamprotection.comは使っていないサーバーを許可しています。ポリシーを引き上げる前に、SiteGroundのincludeがまだ必要か見直してください。
- DNS設定
SiteGroundの標準のSPFレコードは、何も追加しないうちから10回のルックアップのうち3回（+a、+mx、include:_spf.mailspamprotection.comで各1回）を消費しています。Google Workspace（おおよそあと2回）とESPを加えると10回の上限に近づく可能性があるため、レコードは簡潔に保ち、SiteGroundのサーバーからメールを送らなくなったら+a/+mxを削ってください。
- 適用範囲
SiteGround Email Marketingは、独自のドメイン認証を持つ別の製品です（独自のレコードがあり、アカウントごとのspf.dnssmarthost.netのincludeも含まれます）。このサービスの認証を、Authenticationツールが管理するメールボックスのSPF/DKIMと混同しないでください。
- 適用範囲
~all（softfail）はSiteGroundのデフォルトです。すべての正規の送信元がレコードに含まれていることをチェックツールで確認するまで、-all（hard fail）に変更しないでください。先に変更すると、自社のメールがバウンスします。
SPFレコードを作成
以下ではSiteGroundがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証SiteGroundのSPFに関するよくある質問
関連記事
ホスティング・Webサイトの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。