Gmail API、Outlook API、Postmarkなどを見ながら、認証メール用途でSendGridを選んだ話です。SMTPと公式ライブラリの両方を使い、SPF / DKIM / DMARC も設定しました。
認証メールは、届かなかった瞬間に終わる
認証メールって、実装しているときは地味です。
でも本番ではかなり重いです。
届かなかったら、ユーザー登録がそこで止まります。
アプリ側のログでは「送信成功」。
でもユーザーの受信箱にはない。
迷惑メールにもない。
再送しても来ない。
この状態になると、もうボタンのデザインとかフォームの入力体験とかの話ではなくなります。
ユーザーがサービスに入れません。
自分も最初は、Gmail APIやOutlook APIを叩いてメールを送っていました。
送るだけならできます。
ただ、認証メールとして使うにはしんどい部分がありました。
- 独自ドメインで送りたい
- GmailやOutlookで迷惑メールに入りにくくしたい
- SPF / DKIM / DMARC をちゃんと設定したい
- SMTPでも公式ライブラリでも使いたい
- 個人のメールアカウントに認証メールを依存させたくない
いろいろ試したり見たりした結果、自分はSendGridに寄せました。
結論を書くと、認証メール用途ではかなり楽でした。
特に送信ドメイン認証まわりは、今まで触った中でSendGridが一番やりやすかったです。
SendGridを使えば必ず受信箱に届く、という話ではありません。メール到達率は本文、送信頻度、DNS設定、ドメイン評価、受信側の判定にも左右されます。この記事は、自分が認証メール用途で使ったときの体験談です。
3行で
- Gmail APIやOutlook APIでもメールは送れるが、認証メールの運用基盤としてはつらいところがあった
- SendGridはSMTPと公式ライブラリの両方で使えて、独自ドメイン送信に寄せやすかった
- SPF / DKIM / DMARC の設定が分かりやすく、GmailやOutlook宛の確認でも使いやすかった
Gmail APIやOutlook APIで感じた限界
最初からメール配信サービスを使っていたわけではありません。
Gmail APIやOutlook APIでも送信は試しました。
普段使っているアカウントからメールを送れるので、最初の検証としては分かりやすいです。
ただ、認証メールとして使い続けるなら話が変わります。
特に気になったのは、送信元です。
サービスの認証メールなのに、個人アカウントや特定のメールボックスに寄ってしまう。
これは運用として気持ち悪いです。
ユーザーから見ても、知らない個人名っぽい送信者より、サービスのドメインから届く方が自然です。
たとえば、こういう送信元にしたいわけです。
noreply@example.com
auth@example.com
support@example.com
でも、Gmail APIやOutlook APIを使うと、サービス用の送信基盤として設計するには考えることが増えます。
- 送信元アカウントを誰が管理するのか
- 送信制限に当たらないか
- アカウント停止や認証まわりで詰まらないか
- 失敗したときに追いやすいか
- SPF / DKIM / DMARC まで含めて整理できるか
検証ならよくても、ユーザー登録の入口に置くには少し怖い。
そこで、メール配信サービスを使う方向にしました。
「送信APIが成功した」と「ユーザーが認証を完了できた」は別物です。認証メールでは、受信箱に届いてリンクを踏めるところまで見ないと危ないです。
比較したときに見たポイント
SendGridだけを見て決めたわけではありません。
Postmarkも候補に入れていました。
また、認証メールやトランザクションメールの配信では、AWS SESやMailgunのようなサービスも比較対象になりやすいです。
自分が実際に重点的に見たのは、Gmail API、Outlook API、Postmark、SendGridでした。
| 選択肢 | よさそうだったところ | 認証メール用途で気になったところ |
|---|---|---|
| Gmail API | すぐ試せる。普段のGoogleアカウントから送れる | サービス用の送信元としては個人アカウント依存になりやすい |
| Outlook API | Microsoft系の環境では扱いやすい | 認証メール基盤として使うには、独自ドメインや運用設計を別で考える必要がある |
| Postmark | トランザクションメールに強い印象がある | 自分の用途では、SendGridの無料プランと設定のしやすさが勝った |
| SendGrid | SMTPと公式ライブラリの両方で使える。独自ドメインと送信ドメイン認証を設定しやすい | DNSやメール認証の最低限の理解は必要 |
これはサービスの優劣を決める比較ではありません。Postmarkが悪いという話でもありません。自分の用途、予算、試しやすさで見るとSendGridが合っていました。
Postmarkは認証メールと相性がよさそうでした。
ただ、自分は無料プランでいろいろ試したかったのと、SMTPと公式ライブラリの両方で触れるところに惹かれました。
あと、SendGridは「メールを送るAPI」というより、独自ドメイン、DNS、認証、送信方法までまとめて考えやすい感じがありました。
ここが大きかったです。
SendGridで一番助かったのはSPF / DKIM / DMARC
メールをちゃんと届けようとすると、SPF / DKIM / DMARC は避けられません。
自分も全部設定しました。
正直、ここが一番面倒です。
アプリのコードを書いているときとは別の脳を使います。
- SPFのTXTレコードをどう書くか
- 既存のSPFがある場合にどう足すか
- DKIMのCNAMEをどこに入れるか
- DMARCは最初にどのポリシーにするか
- DNSの反映待ちなのか、設定ミスなのか
- GmailやOutlook側で認証が通っているか
SendGridでは、管理画面で必要なDNSレコードが出てきて、それをDNS側に入れて検証する流れでした。
DNSの反映待ちはありますが、少なくとも「次に何をやればいいか」で迷いにくかったです。
これまでメール送信まわりをいろいろ触ってきましたが、送信ドメイン認証はSendGridが一番楽でした。
SPF / DKIM / DMARC は、DNSにレコードを入れたら終わりではありません。SendGrid側の検証結果と、実際に届いたメールの認証結果を見た方が安全です。
GmailとOutlookに送って確認した
認証メールは、実際にGmailとOutlook宛に送って確認しました。
見ていたのはこのあたりです。
- 受信箱に届くか
- 迷惑メールに入らないか
- 送信元の表示が不自然ではないか
- 件名が怪しく見えないか
- 認証リンクを踏んで登録を完了できるか
SendGrid経由のメールは、自分の用途では迷惑メールに振り分けられにくい印象でした。
もちろん、これはSendGridだけの力ではありません。
SPF / DKIM / DMARC を設定して、本文もそれなりに普通に書いて、変な送り方をしない。
そこまで含めての話です。
でも、認証メールは「たぶん届く」で済ませたくありません。
GmailとOutlookで確認して、自然に受け取れる状態にできたのは大きかったです。
SMTPと公式ライブラリの両方を使った
SendGridでは、SMTP経由と公式ライブラリの両方を使いました。
SMTPは既存のメール送信機能に差し込みやすいです。
フレームワークやアプリがSMTP送信に対応していれば、ホスト名、ポート、ユーザー名、パスワードを設定して使えます。
既存実装をあまり変えずにSendGridへ寄せたいときはSMTPが楽でした。
公式ライブラリは、アプリ側から送信処理を細かく書きたいときに使いやすいです。
送信先やテンプレート、本文をコードで扱いたい場合はこちらの方がしっくり来ました。
既存のメール送信に差し込みたい -> SMTP
コードで送信処理を管理したい -> 公式ライブラリ
この2つを選べるのは助かりました。
最初はSMTPで入れて、必要になったら公式ライブラリに寄せる、という進め方もしやすいです。
無料プランで試せたのもよかった
当時、自分は無料プランでかなり使っていました。
個人開発や小さめのサービスだと、最初から有料のメール配信基盤を入れるのは少し迷います。
でも認証メールは、本番に近い形で何度も試したいです。
- 登録したらメールが飛ぶか
- 再送信できるか
- Gmailでどう見えるか
- Outlookでどう見えるか
- 迷惑メールに入らないか
- 独自ドメインから送れているか
- SPF / DKIM / DMARC が通っているか
この確認を気軽に回せたのは助かりました。
メールは、実際に送ってみないと分からないことが多いです。
件名の見え方、送信者名、本文の怪しさ、迷惑メール判定。
管理画面と受信箱を見ながら調整できるのはありがたかったです。
認証メールでやっておいてよかったこと
SendGridを使ったかどうかに関係なく、認証メールでは次を見ておくと安心です。
送信成功だけを信じない
APIやSMTPのレスポンスが成功でも、ユーザーが受信できたとは限りません。
認証メールでは、送信処理よりも登録完了まで見た方がいいです。
GmailとOutlookでは実際に受ける
Gmailで自然に見えても、Outlookでは印象が違うことがあります。
迷惑メール判定も受信側によって変わります。
最低限、GmailとOutlookには実際に送った方がいいです。
独自ドメインと送信ドメイン認証は早めにやる
あとから送信元を変えると、確認をやり直すことになります。
認証メールを使うなら、早い段階で独自ドメイン、SPF、DKIM、DMARCを入れて確認した方が楽です。
本文を怪しくしない
配信サービスやDNSだけでなく、本文も見られます。
URLだけのメール、説明が少なすぎるメール、送信元が分かりにくいメールは不親切です。
認証メールでも、最低限これくらいは書いた方がいいと思います。
- どのサービスからのメールか
- なぜこのメールが届いたのか
- どのリンクを押せばいいのか
- 心当たりがない場合は無視していいこと
SendGridは「メール送信処理」ではなく「メール基盤」として楽だった
SendGridを使ってよかったのは、単にメールを送れたことではありません。
認証メールに必要なものを、サービス用のメール基盤としてまとめやすかったことです。
- SMTPで既存機能に差し込める
- 公式ライブラリでも送れる
- 独自ドメインで送りやすい
- SPF / DKIM / DMARC を設定しやすい
- GmailやOutlook宛で確認しやすい
- 無料プランで試しやすい
自分にはこのバランスが合っていました。
Gmail APIやOutlook APIは、検証用途なら便利です。
Postmarkも、トランザクションメール用途では強い選択肢だと思います。
ただ、認証メールをサービスの入口として考えたとき、自分はSendGridに任せるのが一番しっくり来ました。
まとめ
認証メールは、ただ送れればいいメールではありません。
届かないとユーザー登録が止まります。
迷惑メールに入ると気づかれません。
送信元が不自然だと、サービス自体も少し怪しく見えます。
自分はGmail APIやOutlook APIで送信を試し、Postmarkも見たうえで、最終的にSendGridを選びました。
使ってよかったのはこのあたりです。
- 独自ドメインからサービスらしく送れる
- SPF / DKIM / DMARC の設定が分かりやすい
- GmailやOutlook宛でも確認しやすい
- SMTPと公式ライブラリの両方で使える
- 無料プランで試しやすい
- 個人アカウント依存から離れられる
特に、送信ドメイン認証の設定が楽だったのは大きかったです。
認証メールはサービスの入口です。
ここで詰まると、ユーザーはログイン画面にたどり着く前に離れてしまいます。
だから、自分は早い段階でSendGridに任せてよかったと思っています。
これから認証メールを実装するなら、「送れるか」だけでなく、「独自ドメインで送れるか」「SPF / DKIM / DMARCを設定できるか」「GmailやOutlookで自然に届くか」まで見るのがおすすめです。