MailerLiteのSPF・DKIM・DMARC設定。
MailerLiteでは、Account settings → Domainsからドメインを認証します。SPFの1行を貼り付ける方式ではなく、CNAME/DKIMによる設定です。実質的な役割を果たすのは、litesrv._domainkey.mlsend.comを指す1つのDKIM CNAME、litesrv._domainkey.yourdomain.comです。これにより、自社ドメインの名義でMailerLiteがメールに暗号署名できるようになります。これを、送信アドレスの所有を証明する1回限りのドメイン確認用TXTレコードが支えます。MailerLiteは自身のmlsend.comをバウンス用ドメインとして使って送信し、Return-Pathの変更を認めていないので、DMARCの成功を担うのはSPFではなくDKIMのアライメントです。Automatic Domain Authenticationでは、MailerLiteがDNSホストにサインインしてレコードを代わりに書き込むこともできます。それができない場合（ソーシャルログインでホストにログインしている場合など）や手動で行いたい場合は、Domainsページから3つのレコードをコピーし、Check DNS recordsをクリックして確認します。
MailerLiteを認証すべき理由
MailerLiteのドメイン認証は、キャンペーンが受信トレイに届くかどうかを左右します。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、DKIMとDMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail全体で、要件を満たさない大量メールを迷惑メール扱いにし、続いて拒否するようになりました。認証が済むまで、MailerLiteは自身のmlsend.comのインフラで署名とバウンス処理を行います。Gmailには「via mlsend.com」の表記が表示され、Fromアドレスは暗号学的に自社のものではなく、DMARCにも成功できません。レピュテーションも、その共有ドメインにいる他の未認証のMailerLite送信者全員と共有されます。同じルールのもと、MailerLiteは現在、無料メールのFromアドレス（you@gmail.com、you@yahoo.com）からの送信も一律にブロックしているので、自社で所有し、認証したドメインから送信する必要があります。ドメイン認証を完了すると、MailerLiteの署名が自社ドメインの名義になり（DKIMのアライメントが一致）、「via」タグが消え、DMARCに成功し、共有プールではなく自社の名前で送信レピュテーションを築けます。
MailerLiteにおけるSPFの実情
MailerLiteはCNAME/DKIMで認証するサービスで、ルートドメインのSPFにincludeを追加して認証するサービスではありません。そして、多くのガイドが誤っている重要なポイントがあります。MailerLiteは公開すべきSPFのTXTレコード（ルートドメインの1つのSPFレコードにまとめるv=spf1 include:_spf.mlsend.com ~all）を提示しますが、このレコードで、DMARCにおけるSPFのアライメントが自社ドメインと一致するわけではありません。MailerLiteではカスタムのReturn-Pathが認められず、すべてのメールのエンベロープ送信者（バウンスアドレス）はmlsend.comのままです。SPFは常にこのエンベロープのドメインに対して評価されるので、MailerLite自身のmlsend.comのSPFレコードに対して認証され、MailerLite側では成功しますが、表示されるFromアドレスのyourdomain.comとは一致しません。つまり、DMARCの成功はlitesrv._domainkeyのCNAMEによるDKIMのアライメントにすべてかかっており、SPFは事実上、付随しているだけです。Domainsページをすべて緑にしたい場合はMailerLiteのSPFの値を公開してください（MailerLiteはこの値もチェックします）。ただし、要となるレコードはDKIMのCNAMEです。DKIMが確認されていなければ、SPFがどうであれDMARCは失敗します。もう1つの注意点は、MailerLiteのプラットフォームが2つあることです。現行の「new MailerLite」はinclude:_spf.mlsend.comとlitesrv._domainkeyのセレクターを使います。従来の「MailerLite Classic」はinclude:_spf.mailerlite.comとmailerlite._domainkeyのセレクターを使っていました。値は常に、ブログではなく自分のアカウントのDomainsページから正確にコピーし、ルートドメインのv=spf1のTXTレコードは1つだけにしてください。
2つの設定方法
Automatic Domain Authentication（推奨）
- MailerLiteがドメインをスキャンしてDNSホストを検出し、（自分でそのホストにサインインすると）DKIMのCNAME、SPF、確認用の各レコードを代わりに書き込みます
- 入力ミスが最も少なく、ホスト欄のドメイン重複やレコードタイプの誤りが起きません
- 通常は数分から数時間で確認が完了します
- DNS/ホスティングプロバイダーにGmailなどのソーシャルログインでログインしている場合は機能しません。MailerLiteが代わりにサインインできないので、Manualを使ってください
DNSレコードの手動設定
- Domainsページの3つのレコードを、レジストラまたはDNSホストに自分で直接コピーします
- DNSホストでソーシャルログイン（Gmailなど）を使っている場合や、MailerLiteがホストを自動検出できない場合に必要です
- 各レコードの設定先（ルートドメインか送信用サブドメインか）を正確に管理できます
- Cloudflareでは、DKIMのCNAMEレコードを手動で「DNS only」（グレーのクラウド）に設定する必要があります
設定手順
- 1
Domainsページを開く
ログインしてAccount settings（左下のプロフィールメニュー）→ Domainsを開きます。Add domainをクリックします。または、送信者メールアドレスを設定している場合は、MailerLiteからそのアドレスのドメインを認証するよう案内されます。
- 2
送信アドレスを入力
キャンペーンの送信に使うメールアドレス（例：news@yourdomain.com）を入力します。MailerLiteがそこから認証するドメインを割り出し、ドメインのエントリーを作成します。
- 3
AutomaticかManualの認証を選択
MailerLiteにはAutomatic Domain Authentication（DNSホストを検出し、自分でそのホストにサインインすると、レコードを代わりに書き込みます）とManualがあります。Automaticが最も簡単です。GmailなどのソーシャルログインでDNSホストにログインしている場合（MailerLiteが代わりにサインインできません）、ホストが検出されない場合、自分でレコードを追加したい場合はManualを選んでください。
- 4
3つのレコードをコピー
Domainsページに、DKIM（CNAME）、SPF（TXT）、Domain verification（TXT）の各レコードが正確なNameとValueのフィールドとともに表示されます。これらはMailerLite内で編集できないので、完全に一致する形でDNSに追加する必要があります。このタブは開いたままにしてください。
- 5
DKIMのCNAMEレコードを追加
CNAMEレコードを作成します。Nameはlitesrv._domainkey、Valueはlitesrv._domainkey.mlsend.comです（向け先はすべてのMailerLiteアカウントで同じです）。これが要となるレコードで、DKIM署名をMailerLiteに委任し、自社ドメインの名義でMailerLiteが署名できるようにします。TXTレコードとして追加しないでください。
- 6
SPFのTXTレコードをまとめる
ルートドメインの1つのSPFのTXTレコードを追加または更新し、include:_spf.mlsend.comを含めます（例：v=spf1 include:_spf.mlsend.com ~all）。他の送信者用のSPFレコードがすでにある場合は、includeをその1行にまとめ、2つ目のv=spf1レコードは絶対に公開しないでください。
- 7
ドメイン確認用のTXTレコードを追加
確認用のTXTレコードを、MailerLiteに記載されたとおりに公開します（ルートドメインに設定するアカウント固有の値です）。これにより送信アドレスの所有が証明され、そのアドレスから送信できるようになります。
- 8
DMARCレコードを自分で追加
MailerLiteはDMARCレコードを代わりに作成しません。_dmarcにv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comのTXTレコードを追加し、ポリシーを適用する前にレポートを収集できるようにします。
- 9
Check DNS recordsをクリック
MailerLiteのDomainsページに戻り、Check DNS recordsをクリックします。DNSの反映は多くの場合数分ですが、最大24～48時間かかることがあります。レコードが解決されると、MailerLiteがドメインをAuthenticatedと表示します。
- 10
テストを送信し、DKIMのアライメントを確認
自分宛てにキャンペーンかテストを送り、Gmailで開いてShow originalを使います。d=yourdomain.comのDKIM: PASSと、DMARC: PASSが表示されていれば成功です。SPFにはmlsend.comと表示され、アライメントは一致しません。MailerLiteではこれが想定どおりです。
追加するレコード
正確な値はMailerLiteのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| CNAME | litesrv._domainkey | litesrv._domainkey.mlsend.comDKIMは要となるレコードです。MailerLiteがd=yourdomain.comとして署名できるようになり、DMARCに成功します。向け先はすべてのアカウントで同じです。TXTではなくCNAMEとして追加してください。 |
| TXT | @ | mailerlite-verification=abc123def456… (account-specific)ドメイン所有権の確認用で、ルートドメインに公開します。例です。正確なNameとValueはDomainsページからコピーしてください。 |
| TXT | @ | v=spf1 include:_spf.mlsend.com ~allMailerLiteが提供するSPFのincludeです。ルートドメインの1つのSPFレコードにまとめてください。ただし、DMARCのアライメントは一致しません（Return-Pathはmlsend.comです）。新プラットフォームの値の例です。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシーです。MailerLiteは追加しません。ドメインごとに1つだけです。例です。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。MailerLiteの設定がこの上限のうち何回を消費するかは、次のとおりです。
MailerLiteは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
DKIMこそが、MailerLiteのメールを実際にDMARCに成功させるレコードです。公開するのは1つのCNAMEレコードで、Nameはlitesrv._domainkey.yourdomain.com、Valueはlitesrv._domainkey.mlsend.comです。これは委任であり、鍵を貼り付けるものではありません。MailerLiteを指すCNAMEなので、秘密鍵はMailerLiteが保持してすべてのメールにd=yourdomain.com; s=litesrvで署名し、受信側はCNAMEをたどってmlsend.comから対応する公開鍵を取得します。このd=がFromドメインと同じであることで、DKIMのアライメントが一致します。MailerLiteのエンベロープ送信者はmlsend.comのままでSPFのアライメントは一致しないので、このDKIMのアライメントが、DMARCの成功の唯一の根拠です。向け先はすべてのMailerLiteアカウントで同じです（アカウントごとの鍵ではなく委任先のホストです）。自分専用でなくても驚く必要はありません。TXTレコードではなくCNAMEレコードとして追加し、レジストラがドメインを重複させないようlitesrv._domainkeyのラベルだけを入力してください。Cloudflareでは「DNS only」（グレーのクラウド）に設定しないと解決されません。このレコードが緑以外の状態なら、SPFがどうであれDMARCは失敗します。
DMARC
DMARCは、ルートドメインに設定する別のポリシーレコードです。MailerLiteは代わりに作成しないので、自分で追加してください。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみのため、MailerLiteのメールの認証を確かめている間も配信には影響しません。MailerLite固有の注意点があります。MailerLiteではSPFのアライメントが一致することはない（Return-Pathはmlsend.com上です）ので、DMARCの成功はすべてDKIMにかかっています。そのため、p=quarantineやp=rejectへ引き上げる前に、集計レポート（rua）で、MailerLiteがアライメントの一致したDKIMで成功している送信元として表示されることを確認してください。そうしないと、ポリシー適用によって自社のキャンペーンが隔離または拒否され始めます。送信者がいくつあっても、_dmarcレコードはドメイン全体で1つだけにし、MailerLite用に2つ目を公開しないでください。
正しく設定できたか確認する
Domainsページの「Authenticated」のバッジだけで判断せず、実際のメールで確認してください。自分宛てにキャンペーンかテストを送り、Gmailで開いて⋮ → Show originalを選びます。署名ドメインがyourdomain.com（litesrvセレクター経由）のDKIM: PASS、さらにDMARC: PASSと表示されていれば成功です。SPFはmlsend.comと表示され、自社ドメインとはアライメントが一致しません。DMARCの成功を担うのはDKIMなので、これはMailerLiteでは正常で想定どおりです。「via mlsend.com」の表記も消えているはずです。詳しいレポートが必要なら、check-auth@verifier.port25.comにテストを送ると全項目の内訳を確認できます。あるいは、Qualisendのドメイン診断と送信ドメイン認証チェックで、CNAMEレコードが解決され、DKIMのアライメントが一致していることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。MailerLiteは、DKIMでアライメントが一致して成功している送信元（SPFのアライメントは不一致ですが、問題ありません）として表示されるはずです。
よくある注意点
- 適用範囲
ClassicとnewのMailerLiteでは値が異なる：mailerlite._domainkeyやinclude:_spf.mailerlite.comを追加するよう案内するガイドは、従来のMailerLite Classicのものです。new MailerLiteはlitesrv._domainkeyとinclude:_spf.mlsend.comを使います。レコードは常に自分のアカウントのDomainsページから正確にコピーしてください。
- DNS設定
MailerLiteではSPFのアライメントが一致することはない：カスタムのReturn-Pathがないため、エンベロープ送信者はmlsend.comのままで、SPFは自社ドメインではなくMailerLiteに対して認証されます。DMARCをSPFに頼らないでください。DKIMのCNAMEが確認されていなければ、SPFがどうであれDMARCは失敗します。
- DNS設定
CloudflareのプロキシでDKIMのCNAMEが機能しなくなる：litesrv._domainkeyを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシが有効なCNAMEはmlsend.comに解決されず、MailerLiteのCheck DNS recordsが失敗し続けます。
- DNS設定
ホスト欄のドメイン重複：多くのレジストラはドメインを自動で付加するため、litesrv._domainkey.yourdomain.comと入力するとlitesrv._domainkey.yourdomain.com.yourdomain.comになります。管理画面がドメインを付加する場合は、litesrv._domainkeyのラベルだけを入力してください。
- DNS設定
DKIMはTXTではなくCNAMEで追加：よくある失敗は、litesrv._domainkeyの値をTXTレコードに貼り付けることです。litesrv._domainkey.mlsend.comを指すCNAMEレコードにする必要があります。
- 認証失敗の原因
ルートドメインのSPFレコードは1つだけにする：すでにGoogle、Microsoft 365、その他のツールから送信している場合は、include:_spf.mlsend.comをその1つのv=spf1の行にまとめてください。SPFのTXTレコードが別々に2つあると、それ自体がPermErrorになります。
- 適用範囲
MailerLiteはDMARCレコードを作成しない：_dmarcレコードがないと、GmailとYahooの大量送信者向けガイドラインを満たせません。自分で追加し、p=noneから始めてください。
- 適用範囲
無料メールのFromアドレスは拒否される：MailerLiteでyou@gmail.comやyou@yahoo.comを認証することはできません。自社で所有し、認証済みのドメインから送信してください。
- 適用範囲
自動認証はDNSホストへのソーシャルログインを利用できない：レジストラやDNSプロバイダーにGoogle/Gmailなどのソーシャルログインでサインインしている場合、MailerLiteの自動フローは代わりにログインできません。Manualに切り替えて、レコードを自分で追加してください。
SPFレコードを作成
MailerLiteでは、ルートドメインに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:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証MailerLiteのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。