メインコンテンツまでスキップ
SEO・集客アプリ

Shopifyは条件を満たさないと送信元アドレスを勝手に書き換える|[email protected] が表示される5つの原因

注文確認メールの差出人が自社ドメインではなく [email protected] になっていたら、それはバグではなくShopifyの仕様です。2024年2月1日のGmail・Yahooの送信者要件に合わせて、Shopifyは認証が通らないドメインの送信元を自動的に書き換えます。厄介なのは、CNAMEを入れただけでは足りないこと、自動認証がDMARCを設定しないこと、DMARCが2つあると失敗すること、adkim=s が付いていると弾かれること、そしてメール転送を使うと「不要」なはずのSPFレコードが必要になることです。2026年9月1日時点のShopify公式ドキュメントで全条件を確認しました。

AIECアプリ研究所 AI編集部公開日 更新日 読了 12#SEO・アクセス改善#Shopifyブログ運営#初心者向け

この記事でわかること

この記事の目次Contents閉じる開く

注文確認メールの差出人が、自社ドメインではなく [email protected] になっている。設定画面の送信元メールアドレスには確かに自社のアドレスを入れたはずなのに、届くメールは違う。

これはバグではありません。Shopifyが意図的に書き換えています。

2024年2月1日から、GmailとYahooは、ブランドメールアドレスから顧客へメールを送るにあたってドメイン認証とDMARCレコードを要求するようになりました。Shopifyはこの要件を満たさないドメインについて、送信を止める代わりに送信元アドレスを自社管理の [email protected] へ書き換える方法を採りました。数字部分はストアごとに固有です。メールは届き続けますが、差出人はShopifyのドメインになります。

問題は、この書き換えを解除する条件が単純ではないことです。「CNAMEを入れれば直る」と説明されがちですが、Shopify公式ドキュメントを読むと、書き換えが発生する原因は少なくとも5パターンあり、そのうち2つは「設定したのに直らない」タイプです。

この記事では、その5パターンを公式情報ベースで整理し、外部のメール配信アプリを使っている場合に何が追加で必要になるかまで扱います。調査日は2026年9月1日です。

先に結論

Shopifyでドメインを購入したなら、DKIM・SPF・DMARCはすべて自動設定済みです。何もする必要はありません。ただしDNS設定画面でこれらのレコードを削除すると、その瞬間に書き換えが始まります。

外部レジストラのドメインを使っているなら、必要なのはCNAMEレコード(DKIMとSPFを兼ねる)とDMARCレコードの2種類です。片方だけでは書き換えは止まりません。

CNAMEを入れたのに直らないなら、DMARCレコードが未設定か、複数存在するか、adkim=s / aspf=s が入っている可能性が高いです。特にShopifyの「自動認証」を使った場合、DMARCは設定されません。

Klaviyoなど外部のメール配信アプリを使っているなら、Shopify側の認証はそのアプリの配信には効きません。アプリ側で別途、送信ドメインの認証が必要です。

メール転送を使っているなら、通常は「不要」とされているSPFレコードが、この場合だけ別途必要になります。

送信元アドレスと店舗アドレスは別物

前提の整理から始めます。Shopifyには紛らわしい2つのメールアドレス設定があります。

ストアメールアドレスは、設定 > 一般にあります。Shopifyからストア運営者への連絡や、商品・注文・顧客リストをエクスポートしたときの送信先です。顧客には見えません。

送信元メールアドレスは、設定 > 通知にあります。こちらが顧客に見えるアドレスで、次の3つの役割を持ちます。

  • 顧客が直接連絡できる宛先
  • 自動通知・注文確認・マーケティングメールの差出人(Fromヘッダー)
  • オンラインストアのお問い合わせフォームの送信先

書き換えの対象になるのは後者、送信元メールアドレスだけです。

原因1:ドメインのDNSを触れない

送信元アドレスに [email protected][email protected] のような、他社が管理するドメインのアドレスを設定している場合です。

これらのドメインのDNSレコードを編集する権限は当然ありません。認証レコードを追加できないので、書き換えは止められません。

解決策は1つだけで、自分が管理するドメインを使うことです。Shopifyでドメインを購入するか、外部レジストラで取得してDNSを操作できる状態にします。

原因2:CNAMEレコードが入っていない

外部レジストラのドメインを使っていて、認証設定をしていない場合です。

Shopifyのドキュメントでここが独特なのは、CNAMEレコードがDKIMとSPFの両方を担うという点です。Shopify公式は「認証時に追加するCNAMEレコードがSPFを自動的に処理するため、この目的で別途SPFのTXTレコードを追加する必要はありません」と明記しています。

SPFといえばTXTレコードを書くもの、という一般的な理解でいると、ここで手が止まります。ShopifyについてはSPF用のTXTレコードは不要です(ただし後述の転送を使う場合を除く)。

追加手順は、設定 > 通知 > 送信元メールアドレスの「ドメインを認証する」から表示されるCNAMEレコードを、ドメイン管理画面へすべて入力する形です。表示されるレコード数は状況によって変わるため、モーダルに出たものを全部入れる必要があります。反映には最大48時間かかります。

ドメインがCloudflare、GoDaddy、IONOSにある場合は、Domain Connectによる自動設定も選べます。

なお、CNAMEレコードの追加には有効な有料プランが必要です。クライアント譲渡用ストア、開発ストア、Pause and Buildプランのストアでは追加できません。

原因3:DMARCレコードがない

ここが最も多い「設定したのに直らない」ケースです。

Shopifyの自動認証機能について、公式ドキュメントは次のように注記しています。自動認証はDKIMとSPFを処理するCNAMEレコードを設定しますが、DMARCレコードは設定しません。DMARCは手動で追加する必要があります。

つまり「自動認証」を実行して完了と表示されても、それだけでは書き換えは止まりません。

必要な最小構成は v=DMARC1; p=none です。ドメインのDNS管理画面で、名前を _dmarc、TXT値を v=DMARC1; p=none; としたTXTレコードを追加します。

p の値の意味は次のとおりです。

  • p=none:認証に失敗しても何もしない(DMARCレコードが無いのと同じ扱い)
  • p=quarantine:迷惑メールフォルダへ入れる
  • p=reject:受信自体を拒否する

Shopifyの既定値は p=none です。これは「何もしない」ポリシーなので、なりすまし対策としての実効性はほぼありません。ただしGmailとYahooの要件は「DMARCレコードが存在すること」なので、要件は満たします。段階的に quarantine へ上げていくかどうかは、別途の判断になります。

原因4:DMARCレコードが複数ある、または厳格すぎる

DMARCを追加したのに直らない場合、次の2つを疑います。

複数のDMARCレコードが存在している。 Shopify公式は「ドメインには必ず1つのDMARCレコードしか存在してはいけません。複数のDMARC TXTレコードがあるとDMARCの検証が失敗し、送信元メールアドレスが [email protected] に書き換えられます」と明記しています。すでにDMARCがある場合は、新規追加ではなく既存レコードの更新が必要です。

厳格アライメントが設定されている。 既存のDMARCレコードに adkim=s または aspf=s が含まれている場合、Shopify経由で送信したメールが正しく認証されない可能性があるとされています。公式は、これらを削除するか adkim=r / aspf=r へ変更することを推奨しています。

s は strict(厳格)、r は relaxed(緩和)の略で、送信ドメインとDKIM署名ドメインの一致をどこまで厳しく見るかの設定です。他社ツールのために厳格設定にしていたドメインでShopifyを使い始めると、ここで衝突します。

DMARCレコードの状態は、dmarcian等の無料のDMARCルックアップツールで確認できます。

原因5:レコードを後から削除した

見落としやすいのがこのパターンです。

Shopifyでドメインを購入した場合、DKIM・SPF・DMARCはすべて自動設定されます。DKIMとSPFはCNAMEレコードとして、DMARCはTXTレコードとしてDNS設定に現れます。公式ドキュメントは、これらを削除しないよう明示的に警告しています。削除すると送信元アドレスが書き換えられます。

外部ドメインの場合も同様です。認証時に追加したCNAMEレコードを削除すると、配信の問題やバウンスが発生する可能性があり、Shopify Emailは送信を継続するために送信元アドレスを自動的に [email protected] へリセットします。レコードを戻せば復帰します。

DNS整理の作業中に「用途が分からないCNAME」として消してしまうケースが想定されるので、記録を残しておくことをおすすめします。

メール転送を使う場合の例外

ここまで「SPFのTXTレコードは不要」と書いてきましたが、公式ドキュメントには例外が1つあります。

Shopify管理のドメインでメール転送(例:[email protected] 宛のメールを個人のGmailへ転送する)を使っている場合、転送されたメールが正しく配信されるように、別途SPFレコードを追加する必要があるとされています。

転送アドレスを送信元メールアドレスとして使うこと自体は可能です。ただしその場合、顧客からの返信は転送設定で指定した個人アドレスへ届きます。カスタムドメインのアドレスから返信するには、外部のメールホスティングサービスが必要です。Shopifyはメールホスティングを提供していません。

もう1点、実務的な注意があります。公式ドキュメントは、no-reply do-not-reply noreply といった語を含むアドレスを一部のメールホストが自動的に拒否するため、送信元アドレスにこれらの表現を使わないよう推奨しています。

外部のメール配信アプリを使っている場合

ここまではShopifyが送る通知メールとShopify Emailの話です。KlaviyoやOmnisendのような外部のメール配信アプリを使っている場合、話が変わります。

これらのアプリは自前の配信インフラからメールを送るため、Shopify側でCNAMEを設定しても、そのアプリの配信の認証には使われません。アプリ側で送信ドメインの認証を別途行う必要があります。

たとえばKlaviyoの場合、専用送信ドメイン(branded sending domain / dedicated sending domain)を設定すると、その過程で追加するNSまたはCNAMEレコードがDKIMとSPFを自動的に有効化します。Shopifyの仕組みと考え方は似ていますが、レコードは別物で、両方をDNSに置くことになります。

逆に、専用送信ドメインを設定せず共有送信ドメインのまま使う場合は、SPF・DKIM・DMARCをアプリ側が管理するため、DNSを触る必要はありません。ただしその場合、差出人ドメインは自社ドメインになりません。

つまり「Shopify側は認証したのに、キャンペーンメールだけ迷惑メールに入る」という状況は、この構造の違いから起きます。認証は送信システムごとに必要です。

確認手順チェックリスト

  • 設定 > 通知の送信元メールアドレスを確認する(ストアメールアドレスと混同しない)
  • そのドメインのDNSを自分が操作できるか確認する
  • 設定 > 通知からCNAMEレコードを取得し、表示されたものを全件追加する
  • 自動認証を使った場合、DMARCが別途必要であることを認識する
  • _dmarc のTXTレコードが存在し、かつ1つだけであることを確認する
  • 既存DMARCに adkim=s / aspf=s が含まれていないか確認する
  • Shopify購入ドメインの場合、自動生成されたCNAME・TXTを削除していないか確認する
  • メール転送を使っている場合、別途SPFレコードを追加する
  • 外部メール配信アプリを使っている場合、そのアプリ側でも送信ドメインを認証する
  • 送信元アドレスに no-reply 等を含めていないか確認する

まとめ

判断の順序は3つです。

  1. 書き換えは仕様であり、原因はDNS側にある。 Shopifyの設定画面を何度見直しても直りません。見るべきはドメインのDNSレコードです。
  2. 必要なのはCNAMEとDMARCの両方。 そしてShopifyの自動認証はDMARCを設定しません。ここが「設定したのに直らない」の最大の原因です。
  3. 認証は送信システムごとに必要。 Shopifyの通知メール、Shopify Email、外部の配信アプリは、それぞれ別に認証します。1つ通したから全部通る、という関係ではありません。

反映には最大48時間かかります。設定直後に変わっていなくても、まずは待ってから再確認してください。それでも書き換えが続く場合は、DMARCレコードの数と中身を疑うのが近道です。

RelatedShopifyのカゴ落ちメールは「カートに入れただけの人」には届かない|標準機能の境界と、カゴ落ちアプリ321本の偏り

Shopifyの標準カゴ落ちメールが対象にしているのは「連絡先情報を入力してから10分以上完了しなかったチェックアウト」だけです。送信されない条件、新オートメーションへの切り替えが取り消せない仕様、3か月で自動削除される保存期間をヘルプセンターの記載で確認し、App Storeのカゴ落ちカテゴリ321本がWhatsApp偏重である実態と、日本のストアが実際に選べる選択肢を整理しました。調査日は2026年8月31日です。