お知らせ・ブログ一覧へ戻る

Shopifyの自動メールが届かないときはドメイン認証を疑う|差出人を独自ドメインにする正しい順番


Shopifyの自動メールが届かないときはドメイン認証を疑う|差出人を独自ドメインにする正しい順番

Shopifyの自動メールが届かないときはドメイン認証を疑う|差出人を独自ドメインにする正しい順番

ECサイトを立ち上げたあと、こういう相談が来ます。

  • 注文確認メールがお客様に届いていないらしい
  • 差出人を info@自社ドメイン に変えたら、管理画面からメールが送信できなくなった
  • 問い合わせフォームのテスト送信が、自分宛なのに受け取れない

先に結論を書きます。

Shopifyの差出人アドレスを独自ドメインに変える作業は、「アドレスの入力」ではなく「メールドメインの認証」までがワンセットです。 認証を先に済ませてからアドレスを切り替える。この順番を守るだけで、上の3つはほぼ起きません。

理由は単純で、受信側のメールサーバーが「そのドメインから本当に送られたメールか」を確認できないと、送信がエラーになるか、送れても迷惑メールに振り分けられるからです。アドレス欄を書き換えただけでは、この確認材料(DNSの認証レコード)はどこにも増えていません。

この記事では、正しい順番を4ステップに分けて書きます。あわせて、認証が済んでいない状態で何が起きるのか、稼働中の会社メールに影響を出さずに作業する条件までまとめます。Shopifyを例にしていますが、考え方はどのカートシステム・どのフォームでも同じです。

正しい順番は4ステップ

差出人アドレスの変更は、次の順で進めるのが正解です。

手順 やること ここを飛ばすと
①受け皿を作る 新しい差出人アドレス(例:info@自社ドメイン)を実際に作り、受信できる状態にする 認証用のメールが受け取れず先に進めない
②認証レコードを追加 プラットフォームが指定するCNAMEをDNSに追加する 送信エラー、または迷惑メール行き
③反映を確認して認証 DNSに載ったのを確かめてから管理画面で認証を実行 「反映されていません」で何度もやり直すことになる
④実送信テスト 注文・問い合わせの両方で実際に1通ずつ送って着弾を見る 本番のお客様で初めて発覚する

多くの事故は②と③を飛ばして、①のあとすぐアドレスだけ切り替えることで起きます。順番を入れ替えるだけで防げる種類の失敗です。

①新しいアドレスを先に作り、受信できるようにしておく

意外と抜けるのがここです。プラットフォームは差出人アドレスを登録すると、そのアドレス宛に確認メールを送ります。受信できる状態になっていないと、確認リンクが踏めず先へ進めません。

メールアカウントを新規作成したら、そのアドレスで実際にメールを受け取れるかを自分の携帯から1通送って確かめておきます。転送を設定する場合は、転送先まで届くかも同時に見てください。受信箱には残るのに転送先には届かない、という状態が起こり得るためです。問い合わせメールを担当者のチャットへ自動で流す運用にしておくと見落としが減ります。組み方は問い合わせメールをLINEに自動転送する仕組みにまとめています。

②プラットフォーム指定のCNAMEをDNSに追加する

Shopifyなら「設定 → 通知 → メールドメインの認証」に、追加すべきレコードが表示されます。実際に指定されるのはCNAMEが6件です。

種類 件数 役割
DKIM用レコード 4件 送信されたメールに付く電子署名を、受信側が検証するための公開鍵の置き場所
送信ホスト用レコード 2件 実際にメールを送り出すサーバーを、自社ドメイン名で名乗れるようにする

DKIMは「このメールは確かにこのドメインが送りました」という電子署名の仕組みです。受信側はDNSの公開鍵で署名を検証し、なりすましでないと確認できたメールを受信箱に入れます。

DNS側での追加は、契約しているサーバーやDNSサービスの管理画面から行います。設定値は次の通りです。

  • レコード種別:CNAME
  • TTL:3600で問題ありません
  • 既存のA・MX・SPF・すでにあるDKIMレコードは触らない

ここが重要な判断材料です。この作業で追加するのはCNAMEだけで、既存のSPFやMXは1文字も変更しません。 つまり、社内で稼働中のメール(既存の会社メール、外部の請求書配信サービスなど)に影響を与えずに実施できます。「今使っているメールが止まると困るから触りたくない」という理由で先送りされがちですが、追加するレコードの種類さえ守れば、その心配はいりません。

なお、サーバー側のメール送信用のSPF・DKIMと、ECプラットフォームの送信用の認証は別物です。 たとえば主要なレンタルサーバーでは、ドメインを追加した時点でA・MX・SPF・DKIMが自動生成され、DKIMも有効になっていることがあります。それでも、ECプラットフォームが自社のサーバーから送るメールには、プラットフォーム指定のCNAMEが別途必要です。「DKIMは自動で入っているから大丈夫」と読み違えると、原因究明が遠回りになります。

③反映を確認してから、管理画面の認証を実行する

DNSにレコードを追加したら、すぐ管理画面のボタンを押さずに、実際にDNSへ載ったかを先に確認します。

確認は、そのドメインの権威ネームサーバー(そのドメインの正式な答えを持っているサーバー)に直接聞くのが確実です。手元のパソコンやスマホが見ているDNSは古い情報を持っていることがあり、「まだ反映されていない」ように見えてしまうためです。

コマンドが使える環境なら、次の形で1件ずつ確認できます。

dig @<権威ネームサーバー名> +short CNAME <追加したホスト名>

追加した値がそのまま返ってくれば、DNS側の作業は完了です。6件すべてが返ることを確認してから、管理画面の「DNSレコードを更新しました」に相当するボタンを押します。

コマンドが使えない場合は、ブラウザで使える無料のDNS確認ツールで同じホスト名を引いても構いません。大事なのは押す前に確かめるという順番です。

ここで知っておくと安心なのが、認証完了までの実際の時間です。管理画面には「最大48時間」と表示されることが多いのですが、これは悲観的な最大値です。DNSに正しく載っていれば、ステータスは「設定が必要」→「反映中」と進み、実際には数分から数時間で「認証済み」になります。当日中に切り替えを終えられる作業だと考えて予定を立てて構いません。

ひとつ運用面の注意として、レンタルサーバーの管理パネルはログイン後のセッション切れが早いものがあります。クライアントにログインしてもらって作業する場合は、追加する6件の値を手元に用意してから画面を開き、一気に入力してください。説明から始めると入力途中でセッションが切れます。

④注文と問い合わせの両方で実送信テストをする

認証済みになったら、必ず実際に送って着弾を確認します。確認するのは次の2経路です。

  • 注文まわりのメール:管理画面から顧客宛にメールを送る操作(注文確認の再送など)でエラーが出ないか
  • 問い合わせフォーム:自分宛にテスト送信して、想定した宛先に届くか

このとき、受信箱だけでなく迷惑メールフォルダと隔離フォルダも見てください。「届かない」と報告されるケースのかなりの割合が、実は「別のフォルダに入っている」だけです。

認証していないと、具体的に何が起きるか

未認証の状態は、症状が2種類に分かれます。どちらなのかを見分けると、原因の切り分けが早くなります。

症状 状態 意味
管理画面から送信しようとするとエラーになる 送信自体が止まっている 未認証のドメインを差出人として送ることが拒否されている
エラーは出ないのに、相手に届かない 送信はされている 認証済みでないため、プラットフォームの共有ドメインから代替送信されている

やっかいなのは後者です。プラットフォーム側は「送信済み」と記録しており、送信元は自社ドメインではない共有アドレスになっています。メールは出ているが到達率が低いという、いちばん判断に迷う状態です。ログに失敗の記録がないので、送信側の問題ではないと結論づけてしまいがちです。

贈答品を扱うECサイトで「フォームのテスト送信が受け取れない」という相談を受けたときも、DNSを実測すると認証レコードが6件とも未設定でした。この場合の対処は次の順です。

  1. 迷惑メール・隔離フォルダを確認する
  2. 認証レコードをDNSに追加して認証を完了させる(既存のSPF・MXは触らないので安全に実施できます)
  3. それでも届かないなら、受信側のメールサーバーで送信元ドメインを許可リストに登録する

なお、問い合わせが届いているかを日常的に点検する手順は問い合わせが届いているか確かめる手順にまとめています。

あわせて確認しておきたい3つの仕様

差出人の認証とは別に、EC標準のメール機能には知っておくべき仕様があります。認証が終わってから「思った動きと違う」となりやすい部分です。

通知先は1か所しか指定できないことがある。 問い合わせフォームの内容は「差出人メールアドレス」に設定したアドレス1つにだけ届く、という仕様のプラットフォームがあります。受注のスタッフ通知(複数指定できることが多い)とは別の設定項目なので、混同しないでください。複数人で受けたい場合は、専用アドレスを1つ登録し、メール側で転送・エイリアスを組んで配るのが正解です。この形なら、担当者が増減してもECの設定を触らずに済みます。

送信者本人に控えが届かない場合がある。 お客様が問い合わせフォームを送っても、お客様の手元には何も残らない仕様です。送信完了ページに「お客様側に控えのメールは届きません」と明記するか、自動返信を別途実装します。

返信先の設計を間違えると全部迷惑メールになる。 自社サイトのフォームを実装するときの定番の事故がここです。正しい設計は次の通りです。

  • From(差出人)=自社ドメインのアドレス(例:info@自社ドメイン)。SPF・DKIMが効くので署名付きで送信でき、迷惑メール判定を避けられます
  • Reply-To(返信先)=訪問者のアドレス。受信側で「返信」を押せばお客様に返ります

Fromに訪問者のアドレスを入れると、自社サーバーが他人のドメインを名乗る形になり、認証に失敗して通知メールも自動返信もまとめて迷惑メール行きになります。フォームプラグインの初期設定のまま公開すると起こりやすいので、公開前に必ずここを見てください。

届かないときの切り分け順

原因を上から順に潰していく手順です。上ほど発生頻度が高く、確認コストが低い順に並べています。

順番 確認すること 判断
1 受信側の迷惑メール・隔離フォルダ ここにあれば認証の問題。②へ
2 管理画面の認証ステータス 「設定が必要」なら未認証が原因で確定
3 認証レコードがDNSに載っているか 権威ネームサーバーに直接聞いて確認する
4 送信操作でエラーが出るか エラーあり=送信段階、なし=到達段階の問題
5 転送を挟んでいないか 元アドレスに残っていて転送先に無いなら、原因はメールサーバー側の転送設定
6 受信側の組織ポリシー 企業のメール環境では外部ドメインを一律ブロックしていることがある

5番目は見落とされやすいポイントです。受信自体は成功しているのに転送処理の側で消えることがあり、この場合はEC側をいくら調べても原因は出てきません。

まとめ

  • 差出人アドレスの変更は、アドレス入力ではなくドメイン認証までがワンセット。認証を先に済ませてから切り替える
  • 追加するのはCNAME 6件(DKIM用4件+送信ホスト用2件)。既存のSPF・MXは触らないので、稼働中の会社メールに影響なく実施できる
  • 管理画面のボタンを押す前に、権威ネームサーバーでレコードが載ったことを確認する。手元のDNSは古い情報を返すことがある
  • 「最大48時間」は悲観値。正しく載っていれば数分から数時間で認証済みになる
  • 未認証でも送信自体は行われることがある。メールは出ているが到達率が低いという状態がいちばん判断に迷うので、認証ステータスは必ず目視する
  • フォームはFrom=自社ドメイン/Reply-To=訪問者。ここを逆にすると、通知も自動返信もまとめて迷惑メールになる

注文確認メールが届かない状態は、お客様から見れば「注文できたのか分からない」という体験になります。公開前のチェックリストに、この4ステップを入れておいてください。

よくある質問

Q. 差出人アドレスを変えずに、初期設定のままでも問題ありませんか

すぐに困ることはありません。ただし、初期状態はプラットフォームの共有ドメインからの送信になるため、自社ドメインで送る場合に比べて到達率の面で不利です。また、お客様から見て差出人が自社名でないメールは、迷惑メールと誤解されやすくなります。独自ドメインで運用しているなら、認証まで済ませて自社ドメイン送信にしておくのが望ましい状態です。

Q. DNSの設定を触るのが不安です。既存のメールが止まりませんか

今回追加するのはCNAMEレコードだけで、メールの配送先を決めるMXレコードと、送信元を宣言するSPFレコードには一切手を加えません。既存のメール送受信の動作は変わりません。不安があれば作業前にDNSレコード一覧をスクリーンショットで残しておくと比較できます。

Q. 認証済みになったのに、まだ一部の相手に届きません

受信側の組織ポリシーによるブロックが考えられます。企業のメール環境では、外部ドメインからのメールや画像付きのメールを一律で制限していることがあります。この場合は送信側で解決できないため、相手先に送信元ドメインを許可リストへ登録してもらう依頼が必要です。あわせて、DMARC(SPFとDKIMの結果をどう扱うかを宣言する設定)を追加しておくと、受信側の判定がより安定します。

Q. 認証は誰がやる作業ですか

DNSの管理権限を持っている人が実施する作業です。まず確認すべきは「DNSを誰が管理しているか」で、ここが不明なまま依頼すると待ち時間だけが発生します。ドメインの契約先の管理画面にログインできるかどうかで判断できます。

関連記事

2026.08.29

WordPressのテーマを変えずにデザインを今風にする方法|停止すれば全て戻せる「上書きしない改修」の実例

2026.08.29

自動処理の監視は「最後に成功した時刻」を見る|安全に止まる仕組みは通知とワンセット

2026.08.29

ホームページリニューアルの効果はいつ出るか|28日で判断した実測データと見るべき数字


お知らせ・ブログ一覧へ戻る