アプリからメールを送る方法（受信トレイに届けるために）

アプリからメールを確実に送るには、自分のメールボックスではなくメール送信サービスを使い、自分のドメインのアドレスから送信し、サービスが指定するDNSレコードを追加して、SPF、DKIM、DMARCがすべて合格する状態にします。トランザクションメール（パスワードのリセット、領収書、確認メールなど）とマーケティングメールは分けて管理し、それぞれ受け取ることを想定している人にだけ送り、バウンスと配信停止を適切に処理してください。まずは認証を正しく設定することです。アプリのメールが迷惑メールに振り分けられる最大の原因はここにあります。

トランザクションメールとマーケティングメール

この2種類のメールは、コードの上では似ていますが、受信トレイのサービスや法律上の扱いは大きく異なります。

両者は分けて管理してください。マーケティングキャンペーンでスパムの苦情が出た場合、同じストリームのパスワードリセットメールまでその影響を受けるのは避けたいところです。よくある方法は、サブドメインを分けることです。たとえばアカウント関連のメールには mail.example.com、ニュースレターには news.example.com を使います。一部のサービスでは内部的に両者を分けています。たとえばPostmarkは、2026年9月時点で、トランザクションとブロードキャストの「メッセージストリーム」をそれぞれ別の送信基盤で運用していると説明しています。

送信サービスの選び方

アプリは自分のサーバーから直接メールを送るべきではありません。メール送信サービスが、インフラ、IPの評判、再送、バウンス処理を担当してくれます。代表的な選択肢には、Postmark、Resend、SendGrid、Amazon SES、Mailgunなどがあります。どれもHTTP APIとSMTPに対応しています。料金やプランは変わることがあるため、各サービスの公式サイトで比較してください。

比較するポイントは次のとおりです。

• 得意分野。 トランザクションメールに特化しているサービスもあれば、トランザクションとマーケティングの両方に対応しているサービスもあります。
• 開発者向けの使いやすさ。 わかりやすいAPI、使っている言語向けの公式ライブラリ、各メールが配信されたか、バウンスしたか、迷惑メールとして報告されたかを確認できる便利なログ。
• Webhook。 バウンス、苦情、配信完了の通知を受け取り、アプリが自動的に対応できるようにします。
• テンプレート。 サービス側に保存するか、自分のコード内で管理するか。コード内で管理すると、バージョン管理やテストがしやすくなります。
• リージョンとデータの扱い。 データをどの地域で処理するかについて要件がある場合は確認してください。
• 自分の送信量でのコスト。 無料枠を超えた場合の料金も含めて確認してください。

リストへのニュースレター配信には、アプリにキャンペーン機能を作り込むより、専用のニュースレターツールやメールマーケティングツールのほうが適していることが多いです。

送信ドメインを設定する

送信は自分のドメインから行ってください。たとえば hello@example.com のように、GmailやOutlookのアドレスは使わないことです。無料のメールアドレスから第三者サービス経由で送ると、認証チェックに失敗し、フィルタリングされる可能性が高くなります。

送信専用のサブドメインを用意することも検討してください。たとえばResendは、2026年9月時点で、送信の評判を分離するために updates.example.com のようなサブドメインから送ることを推奨しています。また、メール用のDNSレコードをメインサイトのものと分けておけます。

その後、サービスから提供されるDNSレコードを、ドメインのDNSを管理している場所に追加します。DNSを初めて扱う場合は、まずドメインとDNSの仕組みでレコードの基本を確認してください。

SPF

SPF（Sender Policy Framework）は、あなたのドメインに対してメールを送信してよいサーバーを列挙したTXTレコードです。受信側は、送信元のサーバーがそのリストに含まれているかを確認します。

• ドメインに設定するSPFレコードは 1つだけ にしてください。サービスを追加する場合は、2つ目のレコードを作るのではなく、既存のレコードにまとめてください。
• SPFの評価時のDNSルックアップは最大10回までです。include: の連鎖が長いと超過して失敗することがあります。
• 多くのサービスは、作成を求められる返信用（return-path）サブドメインにSPFを設定します。そのため、メインのSPFレコードには触れなくてよい場合もあります。

DKIM

DKIM（DomainKeys Identified Mail）は、各メールに暗号化された署名を付加する仕組みです。サービスは秘密鍵で署名し、対応する公開鍵をDNSレコード（サービスによってTXTまたはCNAME）として公開するよう求めます。受信側は署名を検証し、そのメールが許可された送信者から送られたこと、そして途中で改ざんされていないことを確認します。

サービスの「ドメインを検証」の手順の大部分はDKIMに関するものです。省略しないでください。

DMARC

DMARCは、SPFとDKIMを結びつける仕組みです。_dmarc.yourdomain.com に置くTXTレコードで、受信側に次のことを伝えます。

• アラインメント： 受信者に表示される差出人アドレスのドメインが、SPFまたはDKIMに合格したドメインと一致している必要があること。
• ポリシー： 不合格のメールをどう扱うか。p=none（報告のみ）、p=quarantine（不審なものとして扱い、多くの場合は迷惑メールに振り分ける）、または p=reject（拒否）。
• レポート： 集計レポートの送付先（rua=）。これにより、あなたのドメインを使って誰が送信しているかを把握できます。

おすすめの進め方は、まず p=none と報告用アドレスで始め、正規のメールが合格していることを確認してから、quarantine、最終的には reject に移行する方法です。厳格なポリシーにすると、第三者があなたのドメインをなりすますことも格段に難しくなります。

Gmailの要件

2026年9月時点で、Googleの送信者ガイドラインでは次のように定めています。

• すべての送信者は、個人のGmailアカウント宛てに送る場合、SPFまたはDKIMが必要です。また、送信サーバーに有効な順方向・逆方向のDNS設定、TLS、Postmaster Toolsで確認できるスパム率0.3%未満が求められます。
• 大量送信者（1日にGmail宛てへ5,000通を超える送信者）は、SPFと DKIM の両方、DMARCレコード（p=none ポリシーも可）、差出人ドメインのアラインメント、そしてマーケティングや購読中のメールでのワンクリック配信停止と、目に見える配信停止リンクが必要です。

サーバー側の設定はサービスが対応してくれます。DNSレコードと配信停止の処理はあなたの担当です。1日5,000通に届かなくても、大量送信者のルールを満たしておくのが安全を確保する最も簡単な方法です。

アプリにメール送信を組み込む

ドメインの検証が済んだら、次の手順で進めてください。

1. APIキーはサーバー側のシークレットとして保存する。 フロントエンドのコードには絶対に書かないでください。環境変数とシークレットとはを参照してください。
2. サーバーから送信する。 メールのきっかけとなる操作が成功した後に送信してください。
3. ユーザーをメールの完了まで待たせない。 最も単純なアプリ以外では、送信をキューに入れ、一時的な失敗時には再試行するようにしてください。そうすれば、サービスの応答が遅くても登録処理が遅くなりません。
4. 結果をログに残す。 サービス側のメッセージIDとステータスを記録してください。ただし、キーや個人データを含むメール本文の全文はログに残さないでください。
5. バウンスと苦情のWebhookを処理する。 ハードバウンスしたアドレスや、迷惑メールとして報告されたアドレスへの送信は停止してください。

基本をカバーするプロンプトの例です。

[PROVIDER] を使い、サーバーのシークレット [ENV_NAME] でトランザクションメールを送信してください。送信元は "Acme hello@mail.acme.com" です。登録後にウェルカムメールを、予約が保存された後に予約確認メールを送ってください。テンプレートはコード内で管理し、HTML と並べてプレーンテキスト版も用意してください。送信はキューに入れ、一時的な失敗は最大3回まで再試行してください。失敗はサービスのエラー内容とともにログに残しますが、APIキーは絶対にログに残さないでください。ハードバウンスや苦情があったアドレスを、配信不可としてマークするWebhookエンドポイントを追加し、今後そのアドレスへの送信はスキップしてください。

アカウント関連のメール（認証リンク、マジックリンク、パスワードリセット）はログインの一部です。アプリにログインを追加する方法では、これらのフローの組み立て方を解説しています。これらのリンクは1回限り有効で、有効期限を短く設定してください。

到達率を高める習慣

認証によってメールは「信頼される候補」になります。日頃の行動によって、受信トレイに届き続けられるかが決まります。

• 期待されているものだけを送る。 確認済みの登録者、マーケティングへの明確なオプトイン、購入したリストは使わない。
• 配信停止を簡単にする。 厳密にはトランザクションではないメールには必ず配信停止を用意し、すぐに反映してください。
• 新しいドメインは徐々に慣らす。 初日から数千通を送る新規ドメインは怪しく見えます。まずはトランザクションメールから始め、少しずつ送信量を増やしてください。
• リストを清潔に保つ。 ハードバウンスはすぐに削除し、長期間まったく開封されていない人を削除することも検討してください。
• 人が書いたような文面にする。 わかりやすい件名、認識しやすい差出人名、プレーンテキスト版、少ない画像、そして自分のドメインへのリンク。短縮URLは避けてください。
• 監視する。 Google Postmaster Toolsにドメインを登録し、DMARCレポートを定期的に確認してください。
• 実際に読まれる返信先を設定する。 返信は良いシグナルになるだけでなく、有用なフィードバックにもなります。

誰にもスパムを送らずにテストする

• 利用しているサービスにテストモードやサンドボックスがあれば、それを使ってください。なければ、自分が所有するアドレスに送信してください。
• 開発中は、実際のユーザーではなく キャッチオールのテスト用受信箱 に送ってください。実在しそうなアドレスが入ったシードデータベースは、見知らぬ人に誤ってメールを送る典型的な原因です。
• 各テンプレートは、Webブラウザ版のGmail、スマートフォンのメールアプリ、Outlookなど、いくつかのクライアントで、またダークモードでも確認してください。
• テストメールのヘッダーを確認すると、SPF、DKIM、DMARCが合格したかがわかります。

法律の基本

ルールは国によって異なります。大まかに言えば、多くの地域でマーケティングメールには同意が必要で、送信者を明示し、有効な配信停止手段を提供する必要があります。トランザクションメールは別の扱いになりますが、マーケティングを紛れ込ませる手段として使うべきではありません。ウェイティングリストページでアドレスを集める場合は、どのようなメールを送り、どのように保存するのかを、登録時に伝えてください。迷ったときは、ユーザーがいる地域のルールを確認してください。

メールのチェックリスト

• 送信サービスを選定し、APIキーをサーバー側のシークレットとして保存した
• 無料のメールボックスではなく、自分のドメインまたはサブドメインから送信している
• SPF、DKIM、DMARCのレコードを追加し、合格している
• トランザクションメールとマーケティングメールを分けている
• 送信はキューに入れ、再試行し、結果をログに残している
• バウンスと苦情のWebhookを処理している
• トランザクション以外のメールに配信停止があり、すぐに反映される
• テンプレートを複数のクライアントで確認し、テストメールが実際のユーザーに届かない

Mythexのアプリからメールを送る

Mythexで作るアプリには、標準のメール送信サービスは含まれていません。そのため、Resend、SendGrid、Postmarkなどのサービスを自分で用意する必要があります。APIキーはプロジェクトのシークレットとして保存してください。エージェントは、チャット内のシークレット入力カードでキーを求めることができます。必要なメールは、普通の言葉で依頼してください。ドキュメントには、アプリからメールを送るのスターターのプロンプトがあります。ProプランでMythexを通じてドメインを購入した場合は、ドメインのDNS設定でサービスのTXTレコードとCNAMEレコードを追加できます。詳しくはカスタムドメインをご覧ください。

よくある質問