HostingerのSPF・DKIM・DMARC設定。
Hostingerでの「送信ドメイン認証」の設定は1通りではなく、実際にメールを送信するのが誰かによって変わります。Hostinger Email（ほとんどのプランに付属するネイティブのメールボックス）には専用のSPFのincludeがあり、DKIMは珍しいことにCNAMEレコードで提供され、鍵はHostingerが管理します。Hostinger Reach（ニュースレター・マーケティング製品）は、まったく別のincludeとセレクターを使います。また、WebサイトがHostingerにあってもメールボックスがGoogle Workspace、Microsoft 365、またはESPにある場合、Hostingerのレコードはどれも該当せず、そのサービスのレコードを公開します。幸い、設定はすべて1つの画面（hPanelのDNS Zone editor）で行えて、HostingerがDNSを運用していれば、ほとんどを1クリックで追加できます。このガイドでは、ネイティブのHostinger Emailの手順をすべて説明し、Reachやサードパーティのメールで異なる点を示したうえで、Hostingerが自動では決して追加しない唯一のレコードであるDMARCレコードを正しく設定します。
Hostingerを認証すべき理由
SPF、DKIM、DMARCは、自社ドメインを名乗るメールが本当に自社のものであることを受信側が証明するための仕組みです。SPFは自社に代わって送信できるサーバーを列挙し、DKIMは各メールに暗号で署名し、DMARCはその両方を表示上のFromアドレスに結び付けて、失敗時の扱いを受信側に指示します。2024年2月以降、GoogleとYahooは、両社のユーザー宛てに大量送信するすべての送信者に3つすべてを義務付けており、未認証のドメインからのメールは速度を制限されるか破棄されます。送信量が少なくても、DMARCレコードのないドメインは簡単になりすまされ、自社の名前を騙ったフィッシングが1度あるだけで、送信者レピュテーションが何か月も損なわれることがあります。この3つのレコードの公開は受信トレイへの入場券のようなものです。正当なHostingerのメールが迷惑メールに振り分けられることが多いのは、これらを省略しているためです。
HostingerにおけるSPFの実情
Hostinger EmailのSPFは、ルートドメインに置く1つのTXTレコードで、`_spf.mail.hostinger.com`をincludeします。このincludeはそこで終わりではありません。Hostingerは送信メールをMailChannels経由で配送しているため、`relay.mail.hostinger.com`（Hostinger自身の送信IP）と`relay.mailchannels.net`へと連鎖します。その結果、この1つのincludeを追加するだけで、SPFのDNSルックアップの上限10回のうち3回を消費します。まだ十分に余裕はありますが、送信元を重ねていくと影響が出てきます。最も重要なルールは、SPFレコードは1つのドメインにつき1つだけということです。`v=spf1`で始まる2つ目のTXTレコードがあると、すべてのメールでSPFがPermErrorとなり失敗します。そのため、Hostinger Email、サードパーティのESP、Hostinger Reachのすべてで送信する場合も、SPFレコードを3つ公開するのではなく、すべてのincludeを1つの文字列にまとめます。例：`v=spf1 include:_spf.mail.hostinger.com include:_spf.reach.hostinger.com include:sendgrid.net ~all`。ここで注意が必要です。Hostinger Reachの設定画面には、既存のSPFをReachの値だけに置き換えるよう表示されることがあります。そのまま従うと`_spf.mail.hostinger.com`のincludeが消え、ネイティブのメールボックスのSPFが機能しなくなります。置き換えず、必ずまとめてください。監視している間は`~all`（soft fail）を維持し、正当な送信元がすべて記載されていると確信できてから`-all`に引き上げます。
設定手順
- 1
HostingerがDNSを実際に提供しているか確認
hPanelでレコードを編集して効果があるのは、ドメインがHostingerのネームサーバーで解決される場合だけです。ドメインを開いてNameserversセクションを確認してください。Hostingerのネームサーバーは通常ns1.dns-parking.comとns2.dns-parking.comです。Cloudflare、Route 53、レジストラなどが表示されている場合は、そのサービスが権威を持つので、SPF、DKIM、DMARCはそこに追加する必要があります。Hostingerに追加したレコードは、何の通知もなく無視されます。
- 2
認証するメール製品を決める
ネイティブのHostinger Email、Hostinger Reach、サードパーティのメールボックス（Google Workspace、Microsoft 365、ESP）では、それぞれ必要なレコードが異なります。メールボックスが別の場所にある場合は、Hostingerの値はすべて無視し、そのサービスの値を使ってください。WebサイトをHostingerでホストしていても、メールがHostingerのサーバーを使うとは限りません。このガイドのレコードはネイティブのHostinger Email用です。Reachのレコードは異なります（SPFとDKIMの説明を参照してください）。
- 3
まず1クリックの自動接続を試す
HostingerがDNSを運用している場合は、Emailsでドメインを開き、Connect automaticallyを使って確定します。HostingerがMX、SPF、DKIMの各レコードをDNSゾーンに書き込むので、コピー＆ペーストも入力ミスもありません。ネイティブのメール製品には、この方法を推奨します。DMARCは追加されないので、DMARCの手順は手動で行ってください。ドメインが外部のネームサーバーを使っている場合は、この手順を飛ばし、すべてのレコードを手動で追加します。
- 4
SPFレコードを追加（既存なら1つにまとめる）
自動接続を実行していない場合は、TXTレコードを追加します。TypeはTXT、Nameは@、値はv=spf1 include:_spf.mail.hostinger.com ~allです。重要な点として、v=spf1のTXTレコードがすでにある場合（HostingerのWebホスティング、以前のサービス、またはReachによるもの）は、2つ目を追加しないでください。既存のレコードを編集し、新しいincludeをそこにまとめます。SPFレコードは1つだけです。
- 5
3つのDKIM CNAMEレコードを追加
Hostinger EmailのDKIMは貼り付ける公開鍵ではなく、Hostingerがホストし自動ローテーションする鍵を指す3つのCNAMEレコードです。TypeをCNAMEにして、それぞれ追加します：hostingermail-a._domainkey → hostingermail-a.dkim.mail.hostinger.com、hostingermail-b._domainkey → hostingermail-b.dkim.mail.hostinger.com、hostingermail-c._domainkey → hostingermail-c.dkim.mail.hostinger.com。Nameには短いホストのラベルだけを入力し（Hostingerがドメインを付加します）、Points to／Targetフィールドにターゲットのホストを入力します。ターゲットを引用符で囲まず、TXTレコードに変換しないでください。
- 6
DMARCレコードを追加（Hostingerが追加しない唯一のレコード）
Hostingerでは、自動接続の後でもDMARCは常に手動です。TXTレコードを追加します。Nameは_dmarc、値はv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comです。p=noneから始めれば、レポートを集める間は何も強制しません。ruaは実際に読むメールボックスに向けてください。タグが正しくなるようDMARCレコード作成ツールで文字列を作成し、貼り付けます。
- 7
ReachやサードパーティのESPも使う場合はSPFを調整
Hostinger Reachはinclude:_spf.reach.hostinger.comと、独自のreach-a._domainkeyおよびreach-b._domainkeyのCNAME（ターゲットはdkim.reach.hostinger.com配下）を使います。ESPにも独自のincludeとDKIMがあります。各サービスのDKIMレコードは別々のエントリとして追加します（DKIMは自由に併用できます）。一方、SPFのincludeはすべてルートドメインの1つのSPFレコードにまとめてください。Reachの画面にはSPFをReachの値だけに置き換えるよう表示されることがありますが、無視してまとめます。置き換えると、ネイティブのHostinger Emailのincludeが消えてしまいます。2つ目のv=spf1の行は決して公開しないでください。
- 8
確認し、DMARCをポリシー適用へ進める
Hostingerは反映まで最大24～72時間を見込むよう案内していますが、通常はもっと早く反映されます。レコードが反映されたら、3つすべてが解決されることを確認します。その後、正当なメールの流れがすべてアライメントの一致した状態でSPFまたはDKIMに成功するまで、1～2週間、DMARCの集計レポートを確認します。そのうえで初めて、ポリシーをp=quarantine、最終的にp=rejectへと引き上げます。
追加するレコード
正確な値はHostingerのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| MX | @ | mx1.hostinger.comPriorityは5です。Hostinger Emailの標準の受信サーバーで、Hostingerがメールボックスをホストしている場合にのみ必要です。 |
| MX | @ | mx2.hostinger.comPriorityは10です。バックアップの受信サーバーで、mx1と併せて追加します。 |
| TXT | @ | v=spf1 include:_spf.mail.hostinger.com ~allネイティブのHostinger EmailのSPFレコードです。SPFレコードは1つだけ公開し、他の送信元のincludeは2つ目を追加せずこの行にまとめます。 |
| CNAME | hostingermail-a._domainkey | hostingermail-a.dkim.mail.hostinger.com3つあるDKIMセレクターの1つ目です。基盤となる鍵はHostingerが管理・ローテーションするので、公開するのはCNAMEだけです。 |
| CNAME | hostingermail-b._domainkey | hostingermail-b.dkim.mail.hostinger.com3つあるDKIMセレクターの2つ目です。3つのCNAMEをすべて追加してください。Hostingerがセレクター間で鍵をローテーションしても、署名は有効なままです。 |
| CNAME | hostingermail-c._domainkey | hostingermail-c.dkim.mail.hostinger.com3つあるDKIMセレクターの3つ目です。Hostinger Reachは別のセレクター（reach-a／reach-b）を使うので、混同しないでください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com例です。ruaのアドレスは実際に読むメールボックスに置き換えてください。Hostingerはこのレコードを自動では追加しません。常に手動で追加してください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Hostingerの設定がこの上限のうち何回を消費するかは、次のとおりです。
Hostingerは10回のルックアップのうち3回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Hostinger EmailのDKIMの扱いはほとんどのレジストラと異なり、よく間違えられる点です。鍵ペアを生成して貼り付け用の長い公開鍵のTXTを渡すのではなく、HostingerはDKIMを3つのCNAMEレコードとして公開します。hostingermail-a._domainkey、hostingermail-b._domainkey、hostingermail-c._domainkeyで、それぞれHostingerがホストするターゲット（…dkim.mail.hostinger.com）を指します。実際の鍵はHostinger側にあるので、自分でDNSを再度変更しなくても、Hostingerが鍵をローテーションできます。HostingerがDNSを運用している場合は、自動接続で3つすべてが追加されます。外部のDNSでは、自分でCNAME（TXTではなく）として追加します。Nameフィールドには短いセレクターのラベルを、Points to／Targetにはターゲットのホストを、引用符なしで入力します。メールの到達率のパネルには、独自の鍵をTXTレコードとして持ち込みたい上級者向けにCustom DKIMオプションもありますが、デフォルトかつ推奨の方法は、Hostingerが管理する3つのCNAMEです。Hostinger Reachからも送信する場合は、reach-a._domainkeyとreach-b._domainkeyのCNAME（…dkim.reach.hostinger.comを指します）も追加します。DKIMレコードは併用できるので、送信製品ごとに独自のセレクターを並べて置けます。
DMARC
DMARCは、Hostingerが決して作成しない唯一のレコードです。自動接続でも、メールのウィザードでも作成されないので、必ず_dmarcにTXTレコードとして手動で追加します。どのドメインもv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comから始めてください。p=noneポリシーは何も強制しません。どのサーバーがドメインを使って送信しているか、アライメントが一致した状態でSPFまたはDKIMに成功しているかを示す、XML形式の日次集計レポートを有効にするだけです。ruaは実際に読めるメールボックス（またはDMARCレポートサービス）に向けてください。正当なメールの流れ（Hostinger Email、Reach、ESP、CRM）がすべて問題なく認証されることをレポートで確認できるまでは、ポリシーをnoneのままにします。その後p=quarantineへ引き上げて再度確認し、最終的にp=rejectにします。監視せずに一気にrejectにするのは、自社の請求書やニュースレターを迷惑メールに追いやる最短の方法です。DMARCのアライメントはFromドメインと認証済みドメインの一致によって決まるので、このレコードがあってこそ、SPFとDKIMの作業は単にチェックに成功するだけでなく、なりすまし対策として機能します。
正しく設定できたか確認する
まずレコードが反映されるまで時間を置いてください。Hostingerはゾーンの変更をすばやく適用しますが、インターネット上のキャッシュにより、数分からHostingerが案内する24～72時間までの間、ルックアップが空で返ることがあります。反映後は、外部のSPF/DKIM/DMARCチェックツールで3つをまとめて確認します。ドメインとDKIMセレクター（ネイティブのHostinger Emailならhostingermail-a）を貼り付けると、各レコードが見つかるか、正しい形式かどうかがわかります。ターミナルからはdigで確認できます。SPFはdig TXT yourdomain.com、DKIMはdig CNAME hostingermail-a._domainkey.yourdomain.com、DMARCはdig TXT _dmarc.yourdomain.comです。見つからないレコードがあれば、次の順に確認してください。Hostingerのネームサーバーが実際にドメインのDNSを提供しているか、Nameフィールドに（完全なホスト名ではなく）短いホストのラベルを入力したか、v=spf1のレコードが1つだけか、DKIMレコードがTXTではなくCNAMEで、余分な引用符がないか。
よくある注意点
- 適用範囲
ネームサーバーが別の場所を指している：ドメインがCloudflare、Route 53、またはレジストラのDNSを使っている場合（ns1/ns2.dns-parking.comではない場合）、hPanelで追加したレコードは何の効果もありません。権威を持つサービスに追加してください。Hostingerのレコードが「機能しない」最も多い原因です。
- DNS設定
DKIMをTXTの鍵として扱う：ネイティブのHostinger EmailのDKIMは、Hostingerがホストする鍵を指す3つのCNAMEレコードで、貼り付ける公開鍵ではありません。TXTに変換せず、ターゲットを引用符で囲まず、1つだけでなく3つのセレクターをすべて追加してください。
- DNS設定
自動接続で完了したと思い込む：Connect automaticallyはMX、SPF、DKIMを追加しますが、DMARCは決して追加しません。そこで止めると、ドメインにDMARCポリシーがなく、なりすましが可能なままです。_dmarcのTXTレコードは必ず手動で追加してください。
- 認証失敗の原因
SPFレコードが2つある：HostingerのWebホスティング、以前のメールサービス、またはReachが、ルートドメインにv=spf1のTXTレコードをすでに残している場合があります。2つ目を追加すると、ドメイン全体でSPFがPermErrorとなり失敗します。編集してincludeを1つのレコードにまとめてください。
- 適用範囲
ReachにSPFを置き換えさせる：Reachの設定画面には、既存のSPFをReachの値だけに差し替えるよう表示されることがあります。そうすると_spf.mail.hostinger.comのincludeが消え、ネイティブのメールボックスのSPFが機能しなくなります。代わりに両方のincludeを1行にまとめてください。
- DNS設定
Hostinger EmailとHostinger Reachを混同する：両者はincludeが異なり（_spf.mailと_spf.reach）、DKIMセレクターも異なります（hostingermail-a/b/cとreach-a/b）。両方を使う場合は、SPFのincludeを1行にまとめ、DKIMのCNAMEは両方のセットを公開します。
- DNS設定
メールが実際にはGoogle WorkspaceやMicrosoft 365にあるのに、Hostingerのレコードを使う：サイトをHostingerでホストしていても、メールがHostingerを経由するわけではありません。これらではなく、利用中のメールプロバイダーのSPFとDKIMを公開してください。
- 適用範囲
Nameに完全なホスト名を入力する：Hostingerがドメインを付加するので、_dmarc、@、hostingermail-a._domainkeyのように入力します。_dmarc.yourdomain.comとは決して入力しないでください。入力すると、二重になった無効なホスト名に解決されます。
- 適用範囲
初日からDMARCのポリシーを適用する：集計レポートを読む前にp=rejectにすると、自社の正当なメールが届かなくなります。p=noneから始め、監視でアライメントを確認してから引き上げてください。
SPFレコードを作成
以下ではHostingerがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証HostingerのSPFに関するよくある質問
関連記事
ホスティング・Webサイトの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。