BeehiivのSPF・DKIM・DMARC設定。
Beehiivは、共通のSPF行を貼り付ける方式ではなく、CNAMEによる委任でニュースレターの送信ドメインを認証します。Settings → Domainsでカスタムのメール（送信）ドメインを設定すると、3つのCNAMEレコードが提示されます。1つはBeehiivが管理する送信用サブドメインでSPFを有効にするもの、残りの2つはローテーションするDKIM鍵をBeehiivに委任するものです。これに加えて、ガイド付きのウィザードでDMARCのTXTレコードも作成できます。確認が完了すると、ニュースレターはyou@yourdomain.comから送信され、DKIMは自社ドメインで署名されてアライメントが一致し、DMARCに成功します。積み上げた送信者レピュテーションも、beehiivの共有ドメインのプールではなく自社ブランドに蓄積されます。ルートドメインのSPFレコードに追加するinclude:...beehiivはなく、追加しても効果はありません。
Beehiivを認証すべき理由
Beehiivの送信ドメインを認証するかどうかで、メールが受信トレイに届くか迷惑メールフォルダーに振り分けられるかが決まります。ニュースレターは定義上、大量送信者にあたるため、ほとんどの送信者以上に重要です。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail/Liveに同じルールを拡大しました。成長中のニュースレターなら、1日5,000通はすぐに超えます。カスタムの送信ドメインを設定するまで、Beehiivは同社の共有ドメインから送信します。この状態ではFromアドレスのアライメントが自社ドメインと一致せず、自社ブランドとしてDMARCに成功することもなく、レピュテーションも同じ共有インフラを使う他のパブリッシャーすべてと共有されます。Beehiivはこれを重く見て、2024年2月から、すべてのカスタムドメインアカウントに有効なDMARCレコードを義務付けました。CNAMEとDMARCを設定すると、DKIMのアライメントが自社ドメインと一致し、DMARCに成功し、共有ドメインへの依存がなくなります。さらにBeehiivのSmart Warmingにより、正真正銘自社のものである送信者レピュテーションを築けます。
BeehiivにおけるSPFの実情
BeehiivはCNAMEでドメインを認証するサービスのため、ルートドメインに追加するinclude:...beehiivはありません。共有のSPFのincludeがあると考えている人は、ここでつまずきがちです。代わりに、Beehiivが提示する3つのCNAMEの1つが自社ドメイン上に専用の送信用サブドメインを作り、Beehiivが管理するホストに向けます。このホストのSPFレコードは、すでに送信IPを許可しています。この送信用サブドメインのSPFはCNAMEを通じて委任されるため自動的に満たされ、ルートドメインのSPFレコードに触れる必要はありません。DMARCの成功を確実に支えるのはDKIMです。2つのDKIMセレクターのCNAMEにより、Beehiivはメールにd=yourdomain.comで署名でき、組織ドメインとアライメントが一致します。Beehiivのフローが、CNAMEとDMARCレコードは求めてもルートドメインのSPFレコードの編集を求めないのはそのためです。実務上は、Beehiivの設定によって、ルートドメインのSPFレコードに対するRFC 7208のDNSルックアップの10回制限のうち1回も消費しないことになります。すでにGoogle Workspace、Microsoft 365、トランザクションメールのリレーなどをルートドメインのSPFレコードに積み重ねている場合には、大きな利点です。ルートドメインのSPFレコードは、実際にルートドメインをエンベロープ送信者として使う送信者のために残し、Beehiivについては、CNAMEで委任したDKIMに任せてください。架空のinclude:beehiiv.comやinclude:sendgrid.netをルートドメインに貼り付けないでください。アライメントには何の効果もなく、ルックアップを無駄に消費します。
2つの設定方法
カスタム送信ドメイン：CNAME（推奨）
- ニュースレターはyou@yourdomain.comから送信され、DKIMは自社ドメインで署名されてアライメントが一致します
- beehiivの共有送信ドメインのプールではなく、送信者レピュテーションを自社で保有できます
- ルートドメインのSPFレコードのルックアップを消費せず、BeehiivがCNAMEを通じてDKIM鍵を自動でローテーションします
- 自社ブランドとアライメントが一致した状態でDMARCに成功し、自社ドメインでGmail/Yahooの大量送信者向けルールを満たすために必要です
デフォルトのbeehiiv共有送信ドメイン
- すべてのプランで、DNSを変更せずにすぐ使えます
- メールはbeehiivが所有するドメインから送信されるため、レピュテーションは他のパブリッシャーと共有されます
- 表示上のFromアドレスのアライメントは自社ドメインと一致せず、自社ドメインのレピュテーションも築けません
- 始めるには十分ですが、規模を拡大する前にカスタムドメインへ移行しないと、到達率が頭打ちになります
設定手順
- 1
アップグレードは不要（カスタムドメインは全プランで利用可能）
カスタムドメインは、ニュースレターを認証するメール（送信）カスタムドメインも含め、無料のLaunchプランを含むbeehiivの全プランに含まれています。先に購入するものはありません。これはbeehiivの2025年の料金改定で変わった点で、以前は有料機能だったため、古い手順にはアップグレードを促すものがあります。どのアカウントも、デフォルトではbeehiivの共有サブドメインから送信します。自社ドメインを認証するには、以下のメールドメインの設定を実行します。
- 2
Settings → Domainsを開く
パブリケーションのダッシュボード左下にあるSettingsをクリックし、Domainsページを開きます。このページでWeb（ウェブサイト）ドメインとメール（送信）ドメインの両方を管理します。この2つは別々の設定です。
- 3
メールドメインの設定を開始
Set Up Custom Domainをクリックし、「Set up email custom domain」を選びます（両方が必要な場合は「Set up web and email custom domain」）。ニュースレターの送信に使うドメインまたは送信用サブドメインを入力します。メールを認証するのはこのドメインで、パブリケーションのサイトをホストするWebドメインとは別のものです。
- 4
Entri（自動）または手動を選択
Beehiivには「Verify with Entri」があります。対応するDNSホスト（Cloudflare、GoDaddy、Namecheapほか40以上）にログインし、代わりにレコードを書き込む機能です。手間をかけずに設定するならEntriを、自分でレコードをコピーしてレジストラに貼り付けるなら手動を選びます。どちらでも作成されるDNSレコードは同じです。
- 5
3つのCNAMEレコードをコピー
手動の画面には、3つのCNAMEレコード（SPF用が1つ、DKIM用が2つ）が、それぞれNameとValueとともに表示されます。Name/Valueの組をそれぞれ正確にコピーしてください。セレクターと向け先はアカウントごとに生成されます。
- 6
3つのCNAMEを追加
DNSホストで、各レコードをタイプCNAMEとして作成します。BeehiivのNameをName/Host欄に、ValueをValue/Target欄に貼り付け、3つすべてを追加します。タイプをAやTXTに変更したり、値を変更したりしないでください。
- 7
Cloudflareのプロキシをオフにし、ホストの二重化を修正
DNSがCloudflareにある場合は、各CNAMEを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なレコードはBeehiivのホストに解決されず、確認に失敗します。レジストラがドメインを自動で付加する場合は、二重化を避けるために、name.yourdomain.comのような完全な名前ではなくレコードのラベルのみを入力します。
- 8
DMARCレコードを作成して公開
2024年2月以降、すべてのBeehiivカスタムドメインでDMARCが必須です。Beehiivの組み込みDMARCウィザードでレコードを生成し、ホスト_dmarcにTXTレコードとして追加します（例：v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com）。p=none（監視のみ）から始めてください。_dmarcレコードがすでにある場合は、2つ目を作成しないでください。
- 9
Verify Setupをクリック
Beehiivに戻り、Verify Setupをクリックします。レコードが解決されると、ドメインの上部に「Email」のチェックマークが表示されます。DNSの反映は通常数分ですが、最大72時間かかることがあります。進まない場合はVerifyを繰り返しクリックせず、数時間待ってから再チェックしてください。
- 10
Fromアドレスを設定し、テストを送信
Settings → Emails → Sending Detailsを開き、Fromアドレスを認証済みドメインのもの（例：hello@yourdomain.com）に設定します。Gmailアカウントにテストを送り、⋮ → Show originalを開いて、DKIM: PASSでd=yourdomain.com、さらにDMARC: PASSと表示されていることを確認します。DKIMが「Found」と表示されるのは、実際にメールが流れ、受信側が署名を観測した後だけです。
追加するレコード
正確な値はBeehiivのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | em | sending.beehiiv.com送信用サブドメイン：このCNAMEがSPFをBeehiivのメールホストに委任するため、ルートドメインのSPFレコードは変更されません。例です。正確なNameとValueは、BeehiivのSettings → Domainsのメール設定からコピーしてください。 |
| CNAME | bh1._domainkey | bh1.dkim.beehiiv.comDKIM鍵1（Beehiivが管理、自動ローテーション）。例です。実際のセレクターと向け先はアカウントごとに生成されるので、Beehiivに表示された値をそのまま使ってください。 |
| CNAME | bh2._domainkey | bh2.dkim.beehiiv.comDKIM鍵2：2つ目のセレクターにより、DNSを再編集しなくてもBeehiivが鍵をローテーションできます。例です。値はアカウントごとに異なります。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com2024年2月以降、すべてのBeehiivカスタムドメインで必須です。BeehiivのDMARCウィザードで作成し、_dmarcレコードはドメインごとに1つだけにして、p=noneから始めてください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Beehiivの設定がこの上限のうち何回を消費するかは、次のとおりです。
Beehiivの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。
DKIM
BeehiivでDMARCの成功を実際に支えるのはDKIMで、3つのCNAMEレコードのうち2つがこれを担います。2つのDKIMセレクターのレコード（アカウントごとに表示されます）が、公開鍵をBeehiivに委任します。貼り付け式のTXTレコードではなくCNAMEなので、対応する秘密鍵はBeehiivが保持し、2つのセレクターを使って、DNSを再編集しなくても公開鍵を自動でローテーションします。確認が完了すると、Beehiivはニュースレターにd=yourdomain.comで署名します。そのためDKIMは組織ドメインとアライメントが一致し、SPFが失敗するメール転送時でもDMARCの要件を満たします。Beehiiv固有の注意点は2つあります。1つ目に、DNSがCloudflareの配下にある場合は、両方のセレクターのCNAMEを「DNS only」（グレーのクラウド）に設定してください。プロキシが有効なCNAMEはBeehiivのホストに解決されず、DKIMの確認がいつまでも完了しません。2つ目に、追加したばかりのDKIMレコードは、実際にメールを送信するまでpendingや「not found」と表示されることがあります。受信側（と確認ツール）は実際の署名を観測してDKIMを確認するので、レコードが解決された後に数通送信してから、「Found」のステータスを確認してください。DKIMのTXTレコードを自分で作成する必要はなく、コピーする公開鍵もありません。Beehiivに表示されたとおりに、2つのセレクターのCNAMEを追加するだけです。
DMARC
BeehiivではDMARCは任意ではありません。2024年2月から、すべてのカスタムドメインアカウントに有効なDMARCレコードが必須となっており、レコードがなければ送信ドメインは完全に認証済みとして扱われません。Beehiivには組み込みのDMARCウィザードがあるので、作業は簡単です。ドメインとポリシーを指定すると、_dmarc.yourdomain.comに公開する正確なTXTレコードが出力されます。v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるものです。p=noneは監視のみのため、配信には一切影響しません。その一方で受信側に集計レポート（rua）の送付を求めるので、ポリシーを引き上げる前に、Beehiivから送信したメールのDKIMが成功し、自社ドメインとアライメントが一致していることを確認できます。1～2週間レポートを確認し、正規の送信元すべて（Beehiivと、そのドメインで使う他のツール）が認証されていることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信元がいくつあっても、_dmarcレコードは組織ドメイン全体で1つだけにしてください。Beehiiv専用に2つ目のDMARCレコードを公開してはいけません。なお、ウィザードのデフォルトはp=noneで、レコード必須の要件はこれで満たせますが、ドメインをなりすましから実際に守るのはp=rejectです。
正しく設定できたか確認する
「Email」のチェックマークだけで判断せず、実際のメールで認証を確認してください。認証済みドメインのアドレスからテストのニュースレター（またはプレビュー）を送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASSでd=yourdomain.com（beehiivのドメインではなく）、SPF: PASS、DMARC: PASSと表示されていれば成功です。DKIMが「Found」/確認済みと表示されるのは実際にメールが流れた後だけなので、ステータスがpendingに見える場合は、まず数通送信してください。レコード自体は、2つのセレクターのホストに対するdig CNAMEとdig TXT _dmarc.yourdomain.comで確認できます。続いて、Qualisendのドメイン診断でドメインをチェックし、3つのCNAMEとDMARCレコードが正しく解決され、ルートドメインのSPFレコードがDNSルックアップの10回制限に収まっていることを確かめます。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Beehiivが、アライメントが一致し、認証に成功している送信元として表示されるはずです。ヘッダーのDMARCにbeehiivの送信ドメインが表示されたままでも、設定ミスではなく、単にウォームアップの途中である可能性があります（後述のSmart Warmingを参照）。
よくある注意点
- 適用範囲
カスタムドメインは、無料のLaunchプランを含むbeehiivの全プランで無料なので、購入するアップグレードはありません（これはbeehiivの2025年の料金改定で変わりました）。ただし、どのアカウントもデフォルトではbeehiivの共有ドメインから送信するため、メールドメインの設定を実際に実行するまで、自社ブランドとしては何も認証されません。
- 認証失敗の原因
Webドメインとメールドメインは別々の設定です。パブリケーションのWebドメインを認証しても送信は認証されません。「Set up email custom domain」を明示的に実行しないと、ニュースレターはbeehiivの共有ドメインのまま送信されます。
- DNS設定
2024年2月以降、DMARCは必須です。有効な_dmarcのTXTレコードがなければ、Beehiivはカスタムドメインを完全に認証済みとして扱いません。問題なく送信するには、まず組み込みのDMARCウィザードを使い、その結果を公開してください。
- DNS設定
Cloudflareのプロキシが原因で失敗します。BeehiivのCNAMEをすべて「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはBeehiivのホストに解決されず、SPFの委任とDKIMの確認の両方が失敗します。
- DNS設定
ホスト欄の二重化：多くのレジストラはドメインを自動で付加するため、完全なレコード名を入力するとname.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、Beehiivに表示されたラベルのみを入力してください。
- 適用範囲
Smart Warmingにより、カスタムドメインからの送信は徐々に増えていきます。数週間（少なくとも週1回送信するパブリケーションで通常6～8週間）は、一部の購読者にだけ自社ドメインからメールが届き、残りには引き続きbeehiivから届きます。ウォームアップ中に一部のヘッダーにbeehiivのドメインが表示されるのは想定どおりで、設定の不具合ではありません。
- 適用範囲
DKIMが「Found」と表示されるのは、実際にメールを送信し、受信側が署名を観測した後だけです。正しく追加したレコードでも、最初の送信までpendingに見えることがあります。失敗と決めつけないでください。
- 認証失敗の原因
Beehiiv用のincludeを作り出して、ルートドメインのSPFレコードに追加しないでください。CNAMEの設定はルートドメインのSPFレコードのルックアップを消費しません。偽のinclude:beehiivやinclude:sendgridはDMARCのアライメントに何の効果もなく、10回のSPFルックアップのうち1回を無駄にします。
SPFレコードを作成
Beehiivでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証BeehiivのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。