0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@BrainDirection(Ko Nakamura)

共用サーバーのままメールをDKIM/DMARC対応にする手順（Cloudflare DNS + Amazon SESリレー）

0
Last updated at Posted at 2026-06-09

はじめに

「共用（レンタル）サーバーでDKIM署名が付けられない」「Gmailに送ると迷惑メール扱いされる」——2024年以降のGmail/Yahoo!の送信者ガイドラインで、SPF・DKIM・DMARCはほぼ必須になりました。しかし共用サーバーはDKIM署名機能を持たないものが多く、対応に困っているケースをよく見ます。

この記事では、メールボックスを移さず（受信は無変更）、送信経路だけを変えることで、共用サーバーのままメールをDKIM/DMARC対応にする手順を、実務で再現できる粒度でまとめます。

変えるのは次の2点だけです。

  • DNSの管理場所（→ Cloudflareへ）
  • 送信SMTPサーバー（→ Amazon SESリレーへ）

差出人（From）は自社ドメインのまま、受信（POP3/IMAP）もそのままです。

全体像

[メールクライアント]
   送信(SMTP 587/STARTTLS) ──> [Amazon SES] ──DKIM署名──> 宛先
   受信(POP3/IMAP) ────────> [従来の共用サーバー]  ← 変更しない

[DNS] Cloudflare（無料）に移管
   SPF(TXT) / DKIM(CNAME×3) / DMARC(TXT) / MAIL FROM(MX,SPF) を公開

前提と費用

  • 独自ドメインの管理権限（レジストラのネームサーバーを変更できること）
  • Cloudflareアカウント（DNSは無料）
  • AWSアカウント（Amazon SES。送信量に応じた少額課金。小規模なら月数十円〜のレンジ）

所要時間

設定自体は1〜2時間ですが、次の「待ち」が入ります。

  • DNS切替（NS変更）の反映：数時間〜最大72時間
  • SES本番アクセス審査：通常24時間以内

STEP 1. DNSをCloudflareへ移管する

レコードを自由に追加できる土台を作ります。Web・メールの実体は移動せず、DNSの管理場所だけ移します。

  1. Cloudflareで Add a domain → Connect a domain を選択（Transfer＝ドメイン移管は選ばない）。Freeプランを選ぶ。
  2. 自動スキャンされた既存レコードを確認し、すべて DNS only（グレーの雲） にする。いきなりProxy（オレンジ雲）にするとメール系で事故るため。
  3. 表示されたCloudflareのネームサーバー2つを、レジストラの管理画面で設定する。DNSSECが有効なら先に無効化しておく。
  4. NSが切り替わったか確認する。
# Windows (PowerShell)
Resolve-DnsName example.jp -Type NS -Server 8.8.8.8

# macOS / Linux
dig NS example.jp @8.8.8.8 +short

返ってきたNSがCloudflareのものになっていれば切替完了です。

✅ チェック：権威DNSがCloudflareに切り替わり、既存のWeb・メールが従来どおり動いている。

STEP 2. DMARCレコード（まず監視モード）を追加する

DNS → Records → Add record で、次のTXTを1件作成します（Proxy statusは DNS only）。

Type   : TXT
Name   : _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc@example.jp; adkim=r; aspf=r; pct=100
  • p=none：まずは「監視（レポートを集めるだけ・拒否しない）」から始めます。いきなりrejectにすると正規メールまで止めかねません。
  • rua：集計レポート（XML）の送り先。受け取れるアドレスにしておく。
  • adkim=r / aspf=r：アライメントは緩和（relaxed）。サブドメイン送信でも整合が取りやすい。

✅ チェック：_dmarc のTXTが公開され、DNSで引ける。

dig TXT _dmarc.example.jp +short

STEP 3. Amazon SESでEasy DKIMを有効化する

  1. AWSコンソール → SES → リージョンを選択（例：東京 ap-northeast-1）。以降の設定はリージョン単位なので、送信に使うリージョンを最初に固定する。
  2. Verified identities → Create identity → Domain でドメインを登録し、Easy DKIM を有効化（RSA 2048bit / CNAME方式）。
  3. 表示される CNAME 3本 をCloudflareに DNS only で追加する。数分〜で検証が完了し、Verified になる。

CNAMEは次のような形（トークンはダミー）です。CNAMEのターゲットを勝手に書き換えないこと。

Name : xxxxxxxx._domainkey.example.jp
Type : CNAME
Value: xxxxxxxx.dkim.amazonses.com
（同様に3本）

✅ チェック：DKIM configurationが「Successful」、CNAME 3本が「Verified」。

STEP 4. カスタムMAIL FROMでSPFを整える

そのままでもDKIMは効きますが、SPFを**自ドメインで整合（aligned）**させるために、カスタムMAIL FROMを設定します。

  1. SESのドメイン設定で Custom MAIL FROM を設定（例：bounce.example.jp）。
  2. 指定された MX と SPF(TXT) をCloudflareに追加する。
# MAIL FROM サブドメイン用
Name : bounce.example.jp
Type : MX     Value: feedback-smtp.ap-northeast-1.amazonses.com  (priority 10)

Name : bounce.example.jp
Type : TXT    Value: v=spf1 include:amazonses.com ~all

ここまでで、Cloudflare DNS上に DMARC(TXT) / DKIM(CNAME×3) / MAIL FROM(MX・SPF) が並びます。すべて DNS only で公開します。

✅ チェック：SPF(TXT)・DKIM(CNAME×3)・DMARC(TXT)・MAIL FROM(MX) が全て公開されている。

STEP 5. SES本番アクセス申請とSMTP認証情報の発行

  1. 本番アクセスを申請する。初期状態はサンドボックスで、検証済みの宛先にしか送れない。用途（送信内容・想定量・バウンス対応方針など）を記載して申請。審査は通常24時間以内。
  2. SMTP settings → Create SMTP credentials で SMTPユーザー名／パスワードを発行する。

⚠️ SMTPパスワードは再表示できないので、発行時に必ず控える。IAMユーザーのアクセスキーとは別物（SES SMTP専用の認証情報）である点に注意。

✅ チェック：本番アクセスが承認され、SMTP認証情報を取得・安全に保管した。

STEP 6. クライアントの送信SMTPだけ切り替える

メールクライアント（Outlook等）の 送信(SMTP)サーバーだけ をSESに変更します。

送信サーバー : email-smtp.ap-northeast-1.amazonses.com
ポート       : 587
暗号化       : STARTTLS
ユーザー名   : (SESで発行したSMTPユーザー名)
パスワード   : (SESで発行したSMTPパスワード)
  • 受信(POP3/IMAP)は変更しない（従来の共用サーバーのまま）。
  • 差出人(From)も自社ドメインのまま。SESは検証済みドメインからの送信を許可します。

✅ チェック：送信だけSES経由になり、受信は従来どおり。通常どおりメール送受信できる。

STEP 7. 動作確認（pass×3）とDMARCの段階強化

  1. Gmail等の外部宛にテスト送信する。
  2. 受信側で 「メッセージのソースを表示」 を開き、Authentication-Results を確認する。
Authentication-Results: mx.google.com;
   spf=pass   ... smtp.mailfrom=bounce.example.jp
   dkim=pass  ... header.d=example.jp
   dmarc=pass ... header.from=example.jp

SPF・DKIM・DMARCの3つともpassで、いずれも自社ドメインで整合していれば成功です。

DMARCの段階強化

p=none のまま2〜4週間、rua で届く集計レポートを確認します。正規の送信がすべてpassしていることを確認できたら、段階的に引き上げます。

p=none  →  p=quarantine  →  p=reject

慎重に進めるなら pct= で適用割合を絞りながら上げる手もあります（例：p=quarantine; pct=25）。いきなりrejectにしないのが事故防止のコツです。

✅ チェック：外部受信でSPF/DKIM/DMARCが3つともpass。一定期間の監視後にポリシーを強化。

つまずきどころ

社内宛（同一ドメイン）が弾かれる

受信ゲートウェイが、外部リレー経由で届いた自社ドメイン宛のメールを厳格に検査する場合があります。特に件名・本文が空のテストメールは拒否されがちですが、多くは正常な挙動です。中身のある通常メールが届くかで判断してください。

特定の宛先にだけ送れない

SESは過去にバウンス／苦情のあった宛先を 抑制リスト（Suppression list） に載せることがあります。コンソールで確認・解除できます。

認証エラー（535など）

  • SMTPユーザー名／パスワードがSESで発行したものか（IAMのキーと取り違えていないか）。
  • ポート587 + STARTTLSになっているか。
  • 送信元リージョンとSMTPエンドポイントのリージョンが一致しているか。

DNSが反映されない

NS切替直後は最大72時間かかることがあります。Cloudflareの権威サーバーへ直接問い合わせると、反映待ちに惑わされず確認できます。

dig TXT _dmarc.example.jp @<CloudflareのNS> +short

完了チェックリスト

  • DNSをCloudflareへ移管した（NS切替完了）
  • DMARC（p=none 監視）を追加した
  • SESのEasy DKIM（CNAME×3）が「Verified」
  • カスタムMAIL FROMでSPFを整え、DNSに公開した
  • SES本番申請が承認され、SMTP認証情報を取得した
  • 送信SMTPをSESへ切替（受信は無変更）
  • 外部受信でSPF/DKIM/DMARCが3つともpassを確認した

まとめ

共用サーバーでDKIMが付けられなくても、「受信は触らず、送信(SMTP)とDNSの管理場所だけ変える」というアプローチで、メールボックスを移さずにSPF/DKIM/DMARC対応が実現できます。ポイントは、DMARCを必ずp=noneの監視から始め、レポートで正規送信のpassを確認してから段階的に強化することです。

株式会社ブレインディレクションは、ITソリューション・生成AI・クラウド・セキュリティの導入支援を行っています（ISMS取得）。https://www.brain-d.jp

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?