Skip to content
無料の100クレジットで検証を始める
Qualisend
SPF設定ガイド

Migaduの​SPF・DKIM・DMARC設定。

Migaduは、IMAP/POP/SMTPで自社ドメインのメールを送受信できる本格的なメールボックスサービスで、トランザクションメール向けのメール配信サービス(ESP)ではありません。そのため、ここでの「ドメイン認証」とは、Migaduの管理パネルでドメインを追加したときに表示されるDNSレコードを公開することを指します。これらは利用中のレジストラに設定する実際のDNSレコードで、所有権確認用のTXTレコード、Migaduでメールを受信するための2つのMXレコード(aspmx1/aspmx2.migadu.com)、本物の共有SPFのinclude(include:spf.migadu.com)、Migaduが署名鍵をローテーションできるようにCNAMEで委任する3つのDKIMセレクター(key1/key2/key3._domainkey)、そして自分で公開するDMARCポリシーで構成されます。Migaduを利用すると、エンベロープ送信者に自社ドメインが使われるため、SPFのアライメントが実際に一致します。正しく設定したMigaduのドメインはSPFとDKIMの両方でDMARCに成功し、転送にも耐える堅牢な構成になります。

SPFのinclude
Your DNSAdd the CNAME / TXT records
MigaduSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Migaduを認証すべき理由

Migaduのドメイン認証は、メールが受信トレイに届くかどうかを左右するだけでなく、Migaduがそのドメインでの送受信を行うかどうかの条件にもなります。2024年2月以降、GmailとYahooは、すべての大量送信者(1日あたり約5,000通以上)に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.com/Hotmail/Live宛ての大量メールに同じ要件の適用を始めました。Migaduは共有IPのインフラで送信します。そのため、利用者が築く送信レピュテーションは、メールが自社ドメインのものだと明確に示せるかどうかに左右されます。この点でMigaduは特に優れています。Migaduを利用すると、SMTPのMAIL FROM(エンベロープ/Return-Path)に自社ドメインが使われるので、SPFのアライメントが組織ドメインと一致し、単独でDMARCの成功に寄与します。これはMailchimpのようにReturn-Pathをサービス側で保有するESPにはできないことです。ただし、メーリングリストや.forwardルールでメッセージが転送された瞬間にSPFのアライメントは崩れるため、実際の運用でDMARCの成功を支えるのはCNAMEで委任したDKIMです。これを省くと、転送されたメッセージにはアライメントの一致した認証が何も残りません。また、所有権確認のTXTレコードとMXレコードが解決されるまでMigaduはドメインを有効化しないため、メールはまったく流れません。

MigaduにおけるSPFの実情

Migaduは本来の「include」タイプのサービスです。ルートドメインの1つのSPF TXTレコードに共有のメカニズムinclude:spf.migadu.comを1つ追加し、v=spf1 include:spf.migadu.com -allとします。これはMigadu自身のドメインで公開されているものとまったく同じです。CNAMEによる委任ではなく、Migaduの全顧客が使う本物の共有includeです。このincludeはDMARCでも実際に役立ちます。Migaduの送信では自社ドメインがエンベロープ送信者/Return-Pathになるからです。ドメインの所有者は自社で、そのドメイン宛てのバウンスをMigaduが処理します。そのためSPFのアライメントは、サービス所有のバウンス用ドメインではなく組織ドメインと一致します。Migaduは-all(hard fail)の修飾子を推奨しており、Migadu自身のドメインでも-allを公開しています。Migadu固有の本当の注意点はコストです。include:spf.migadu.comは、Googleの_spf.google.comやMicrosoftのspf.protection.outlook.comのようなルックアップ1回の軽いincludeではありません。include:smtp.migadu.com(サブミッションサーバー)、include:rel.migadu.com(送信リレー)、include:mx.migadu.com(メールエクスチェンジャー)の3つをネストしているため、RFC 7208に基づくと、10回のSPF DNSルックアップのうち1回ではなく4回を消費します。同じSPFレコードにGoogle Workspace、Microsoft 365、ニュースレターツールのいずれかを重ねると、すぐに10回の上限に達し、PermErrorになるおそれがあります。ドメインのSPF TXTレコードは必ず1つだけにし、すべての送信元のメカニズムをまとめてください。2つ目のv=spf1レコードは、それ自体がPermErrorになるため、絶対に公開しないでください。

設定手順

Migaduで
  1. 1

    管理パネルでドメインを追加

    admin.migadu.comにサインインしてDomainsを開き、yourdomain.comを追加します。Migaduがそのドメイン用の正確なDNSレコード(所有権確認のTXT、MX、SPF、3つのDKIM CNAME、提案されるDMARC)を生成し、ドメインのページに表示します。ここからコピーするので、このタブは開いたままにしておきます。

DNSホストで
  1. 2

    所有権確認用のTXTを追加

    DNSホストで、ルートドメイン(ホストは@または空欄)にTXTレコードを追加します。値はMigaduに表示されるもので、hosted-email-verify=xxxxxxxxxxxxの形式です。Migaduはメールを有効化する前に、これでドメインの管理権限を確認します。Migaduは再チェックを続けるので、ドメインの確認が済んだ後も削除せず、そのまま残してください。

  2. 3

    MXをMigaduに向ける

    ルートドメインに2つのMXレコードを追加します。aspmx1.migadu.comは優先度10、aspmx2.migadu.comは優先度20です。受信メールがMigaduだけにルーティングされるよう、以前のサービスのMXレコードは削除します。MXは認証ではなく受信のためのものですが、移行が中途半端なMXは、Migaduのメールが動作しない最も多い原因です。

  3. 4

    SPFレコードを公開(既存なら1つにまとめる)

    ルートドメインにv=spf1 include:spf.migadu.com -allのTXTレコードを追加します。v=spf1レコードがすでにある場合(Google Workspace、ニュースレターツールなど)は、include:spf.migadu.comをそのレコードにまとめ、2つ目のSPF TXTは絶対に追加しないでください。このincludeはDNSルックアップを4回消費するため、送信元を重ねる場合は10回の上限に注意してください。

  4. 5

    DKIM CNAMEを3つ追加

    CNAMEレコードを3つ作成します。ホストkey1._domainkeyはkey1.yourdomain.com._domainkey.migadu.comを指し、key2._domainkeyはkey2.yourdomain.com._domainkey.migadu.comを、key3._domainkeyはkey3.yourdomain.com._domainkey.migadu.comを指します。ターゲットに自社ドメインが含まれるのは正しい形で、誤字ではありません。タイプはCNAMEのままにし、TXTに切り替えたり鍵を貼り付けたりしないでください。

  5. 6

    DMARCレコードを公開

    MigaduはDMARCを作成しません。ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加します。p=noneは監視のみのため、SPFとDKIMの両方のアライメントが一致することを確認している間、配信には何も影響しません。_dmarcレコードは1つのドメインにつき必ず1つだけにしてください。

  6. 7

    (任意)クライアントの自動設定レコードを追加

    Thunderbird、Apple Mail、Outlookが設定を自動検出できるようにするには、autoconfig.migadu.comを指すCNAMEレコードautoconfigと、Migaduが一覧表示するSRVレコードを追加します。SRVレコードは_submissions._tcp(ポート465、smtp.migadu.com)、_imaps._tcp(993、imap.migadu.com)、_pop3s._tcp(995、pop.migadu.com)です。これらはメールクライアントの利便性のためのレコードで、認証用ではありません。クライアントを手動で設定する場合は省略できます。

Migaduで
  1. 8

    ドメインの有効化を待つ

    MigaduはDNSを定期的に再チェックします。ドメインは通常約30分以内にverified/activeに切り替わりますが、DNSが完全に反映されるまで最大24~48時間かかることがあります。パネルにドメインがactiveと表示され、所有権確認のTXTとMXが検出されるまで、送受信はできません。

確認
  1. 9

    テストメールを送信してヘッダーを確認

    そのドメインのメールボックスからGmailの自分宛てにメールを送り、開いて⋮ → Show originalを選びます。SPF: PASSに自社ドメインが表示され、DKIM: PASSにd=yourdomain.com(セレクターはkey1、key2、key3のいずれか)が表示され、DMARC: PASSと表示されていることを確認します。その後、ドメイン診断でドメインをチェックし、すべてのレコードが解決されることを確認します。

追加するレコード

正確な値はMigaduのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

タイプホスト値
TXT@hosted-email-verify=xxxxxxxxxxxxxxxxドメインの所有権確認です。例のため、正確な文字列はadmin.migadu.comからコピーしてください。Migaduが再チェックを続けるので、そのまま残します。
MX@aspmx1.migadu.com受信メール用、優先度10。受信に必須です。以前のサービスのMXは削除してください。
MX@aspmx2.migadu.com受信メール用、優先度20(バックアップのエクスチェンジャー)。
TXT@v=spf1 include:spf.migadu.com -allルートドメインのSPF:SPFレコードは必ず1つだけにし、他の送信元はこの行にまとめます。このincludeはDNSルックアップを4回消費します(smtp/rel/mxをネストしているため)。
CNAMEkey1._domainkeykey1.yourdomain.com._domainkey.migadu.comDKIMセレクター1:CNAMEで委任します。鍵はMigaduが保持してローテーションします。ターゲットに自社ドメインが含まれるのは仕様です。
CNAMEkey2._domainkeykey2.yourdomain.com._domainkey.migadu.comDKIMセレクター2:key1と対になり、Migaduがダウンタイムなしで鍵をローテーションできます。
CNAMEkey3._domainkeykey3.yourdomain.com._domainkey.migadu.comDKIMセレクター3:3つすべてを表示どおりに追加します。
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。Migaduが作成することはありません。1つのドメインにつき1つです。p=noneで始め、その後引き上げます。

ルートドメインのSPF(v=spf1)のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Migaduの設定がこの上限のうち何回を消費するかは、次のとおりです。

SPF 10-lookup budget4 used · 6 free

Migaduは10回のルックアップのうち4回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。

DKIM

MigaduのDKIMはCNAMEによる委任で処理されるため、鍵を生成したり貼り付けたりする必要はありません。Migaduはドメインごとにkey1、key2、key3の3つのセレクターを公開しています。DNSには、この3つに対応するCNAMEレコードを自分で追加します。key1._domainkey.yourdomain.comはkey1.yourdomain.com._domainkey.migadu.comを指し、key2とkey3も同じパターンです。ターゲットのホスト名keyN.yourdomain.com._domainkey.migadu.comに自社ドメインが含まれるのは奇妙に見えますが、これで正しい形です。この名前はMigaduのゾーン内にあり、実際の公開鍵(v=DKIM1; k=rsa; p=…)を含むTXTレコードに解決されます。コピーするTXTレコードではなくCNAMEなので、Migaduが秘密鍵を保持し、利用者がDNSを再度編集しなくても3つのセレクターの裏で公開鍵をローテーションできます。セレクターが3つあるのはこのためで、Migaduはダウンタイムなしで1つを廃止して別のセレクターに切り替えられます。Migaduは送信メールにd=yourdomain.comで署名するので、DKIMはFromドメインとアライメントが一致し、転送でSPFが崩れてもDMARCの成功を維持できます。3つのCNAMEはすべて表示どおりに追加してください。DNSがCloudflareの配下にある場合は、それぞれを「DNS only」(グレーのクラウド)に設定します。オレンジのクラウドでプロキシが有効なCNAMEはmigadu.comに解決されず、DKIMが失敗します。

DMARC

DMARCは、自分で公開する別のポリシーレコードです。Migaduは内容を提案しますが、ゾーンには作成しません。また、ドメインの有効化に必須でもありません(必須なのは所有権確認のTXTとMXだけです)。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみのため、配信には影響しません。受信側に集計レポート(rua)をメールで送るよう伝えるので、このレポートから、MigaduのメールがSPFとDKIMに自社ドメインとアライメントが一致した状態で成功していることを確認できます。Migaduは、ポリシーをスムーズかつ短期間で引き上げられるサービスの1つです。SPF(自社のエンベロープドメイン)とDKIM(自社ドメインのkeyNセレクター)の両方でアライメントが一致するため、メッセージが転送されても成功し続ける構成になります。1~2週間レポートを確認し、すべての正規の送信者が認証されていることを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者がいくつあっても、_dmarcレコードは組織ドメイン全体で必ず1つだけにしてください。サブドメインは、上書きしない限り親のポリシーを継承します。参考までに、Migadu自身のドメインはp=quarantineで運用しており、アライメントを確認した後のポリシー適用の目標として妥当です。

正しく設定できたか確認する

管理パネルのステータスのバッジだけで判断せず、実際のメールで確認してください。そのドメインのメールボックスから自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。SPF: PASSにyourdomain.comが表示され、DKIM: PASSにmigadu.comの署名ではなくd=yourdomain.comとkey1/key2/key3のセレクターが表示され、DMARC: PASSと表示されていれば成功です。ターミナルから生のレコードをスポットチェックするには、dig TXT yourdomain.com(SPF)、dig CNAME key1._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comを実行します。2つ目のコマンドでは、key1.yourdomain.com._domainkey.migadu.comに解決され、さらにDKIM1の鍵に解決されるはずです。Migaduの管理パネルでは、ドメインがverified/activeと表示され、MXとSPFが検出されているはずです。最後に、Qualisendのドメイン診断でドメインをチェックし、SPF、3つのDKIMセレクターすべて、MX、DMARCが正しく解決され、SPFが10回の上限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、Migaduが、アライメントが一致して成功している送信元として表示されることを確認します。

よくある注意点

  • 認証失敗の原因

    MigaduのSPFは重めです。include:spf.migadu.comはsmtp.migadu.com、rel.migadu.com、mx.migadu.comをネストしているため、GoogleやMicrosoftのような1回ではなく、DNSルックアップを4回消費します。同じレコードに他の送信元を重ねると、RFC 7208の10回の上限を超えてPermErrorになるおそれがあるので、ルックアップの回数を慎重に配分してください。

  • DNS設定

    所有権確認のTXT(hosted-email-verify=…)が解決され、パネルにドメインがactiveと表示されるまで、Migaduはそのドメインで送受信を行いません。設定後もこのTXTは削除しないでください。Migaduは再チェックを続けており、削除するとドメインが無効になることがあります。

  • 適用範囲

    MXレコードは2つとも必須で、どちらもMigaduのものでなければなりません。aspmx1.migadu.com(優先度10)とaspmx2.migadu.com(優先度20)です。以前のサービスのMXを残すと受信メールが分散し、これが「Migaduのメールが動作しない」の最も多い原因です。

  • DNS設定

    DKIM CNAMEのターゲットに自社ドメインが含まれるのは正常です。key1.yourdomain.com._domainkey.migadu.comは正しい形で、誤字やホストの重複ではありません。レコードタイプはCNAMEのままにし、TXTに変換したりDKIMの公開鍵を貼り付けたりしないでください。

  • DNS設定

    CloudflareのプロキシはCNAMEによるDKIMを壊します。key1/key2/key3._domainkeyは「DNS only」(グレーのクラウド)に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはmigadu.comに解決されず、DKIMの検証が失敗します。

  • DNS設定

    ホスト欄の重複:ドメインを自動で付加するレジストラでは、key1._domainkeyがkey1._domainkey.yourdomain.com.yourdomain.comになります。パネルがドメインを付加する場合は、ラベル(key1._domainkey)だけを入力してください。

  • 認証失敗の原因

    ルートドメインのSPF TXTレコードは必ず1つだけにしてください。Google Workspace、Microsoft 365、マーケティングツールのいずれかからも送信する場合は、include:spf.migadu.comをその1つのv=spf1の行にまとめます。SPFレコードが2つあると、それ自体がPermErrorになります。

  • 適用範囲

    移行中は~allを使い、正規の送信元をすべて記載してから-allに切り替えてください。Migaduは-all(hard fail)を推奨し、自身のドメインでも使っていますが、早すぎる-allでは、追加し忘れた送信元のメールがhard failになります。

SPFレコードを作成

以下ではMigaduがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。

1

送信元

メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。

選択済み
ガイド →
2

このドメイン自身のサーバー

ドメインが(上記のサービスを経由せず)直接メールを送信する場合は、ドメイン自体を許可します。

3

その他の送信元・IP

リストにないもの(別のサービスのSPFホストや特定のIPアドレス)を追加します。

接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。

4

その他すべての送信元へのポリシー

上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します(allメカニズム)。

生成されたSPFレコードDNSルックアップ1/10回
v=spf1 include:spf.migadu.com ~all
  • ルートドメインにTXTレコードとして公開します。ホストは@(ドメインそのもの)、値は上記の文字列全体です。
  • SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
  • DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。

送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。

リストを検証

MigaduのSPFに関するよくある質問

はい。CNAMEのみのESPとは異なり、Migaduは本来のincludeタイプのサービスです。Migaduから送信するときのエンベロープ送信者には自社ドメインが使われます。そのため、このincludeはMigaduの送信IPを許可すると同時に、DMARCでSPFのアライメントを一致させます。完全なレコードはv=spf1 include:spf.migadu.com -allです。SPFレコードがすでにある場合は、2つ目を追加せず、includeをそのレコードにまとめてください。

これがドメインごとにDKIMを委任するMigaduの仕組みです。key1._domainkey.yourdomain.comのレコードはkey1.yourdomain.com._domainkey.migadu.comへのCNAMEで、これはMigaduのゾーン内にある、実際の公開鍵が公開されている名前です。Migaduが秘密鍵を保持し、利用者がDNSを編集しなくてもローテーションできます。ターゲットは表示どおりで正しい形です。

複数のセレクターがあれば、Migaduはダウンタイムなしで署名鍵をローテーションできます。両方を有効に保ったまま、1つのセレクターを廃止して別のセレクターに切り替えられるためです。3つのCNAMEをすべて追加してください。どの鍵で実際に署名するかはMigaduが決めます。

4回です。include:spf.migadu.comはフラットなレコードではなく、include:smtp.migadu.com、include:rel.migadu.com、include:mx.migadu.comをネストしています。最上位のincludeで1回、ネストしたもので3回を消費します。これはGoogle WorkspaceやMicrosoft 365(各1回)より重いため、送信元を組み合わせる場合は10回の上限に注意してください。

はい。両方を設定してください。メーリングリストや.forwardルールでメッセージが転送された瞬間にSPFのアライメントは崩れ、その時点でDMARCの成功を支えるのはアライメントの一致したDKIMだけです。Migaduの3つのDKIM CNAMEはd=yourdomain.comとして署名するため、実際の運用でもDMARCに成功し続けられます。

いいえ。include:spf.migadu.comを優先してください。Migaduに関する古い記事の中にはv=spf1 mx -allを勧めるものがありますが、これはMX(aspmx1/aspmx2.migadu.com)が解決されるIPだけを許可します。これらはMigaduの送信インフラの一部と重なるものの、すべてではありません。Migaduはmxメカニズムではカバーされないsmtp.migadu.comとrel.migadu.comの範囲からも送信します。include:spf.migadu.comは3つの送信元(smtp、rel、mx)をすべて取り込み、Migadu自身のドメインで公開されているものとまったく同じなので、完全で将来も安心な選択肢です。

ほとんどの場合、原因はドメインの確認です。hosted-email-verifyのTXTがルートドメインで解決されること、両方のMXレコード(aspmx1とaspmx2.migadu.com)がMigaduを指し、以前のサービスのMXが削除されていること、管理パネルにドメインがactiveと表示されていることを確認してください。Migaduはこれらのチェックを通過して初めてドメインを有効化します。反映には最大24~48時間かかることがあります。

いいえ。_dmarcは、自社のDNSゾーンにv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まる形で自分で公開します。Migaduは管理パネルでDMARCレコードを提案しますが、書き込むことはありません。また、ドメインの有効化にも必須ではありません(必須なのは所有権確認のTXTとMXだけです)。_dmarc.yourdomain.comに1つのTXTレコードとして追加し、MigaduがSPFとDKIMにアライメントが一致した状態で成功していることを集計レポートで確認できるまでp=noneのままにしてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。

関連記事

ワークスペース・メールボックスの他のサービス

すべてのSPFガイド
MigaduのSPF、DKIM、DMARCを毎日監視レコードの設定は、最初の一歩にすぎません。ドメイン診断の監視は、SPFのルックアップ数、DKIMキー、DMARCポリシーを毎日再チェックし、どれかが壊れたときにメールでお知らせします。ドメイン診断の監視を見るSPFのDNSルックアップが多すぎる場合:数え方とpermerrorの直し方

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。

認証の次は、リストをクリーンに保つ

SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。

検証を始める