Documentation menu

ネイティブ送信

注: ネイティブ送信はFreeプランを含むすべてのプランで利用でき、アップグレードで解禁される機能ではなく月間送信量で計測されます。各プランの上限については料金を参照してください。

自分のSMTPリレー以外にも、MailInAppは自分が認証したドメインから直接送信できます — ESPも、発行・ローテーションが必要なSMTP認証情報も不要です。配信は自分の送信ドメインに対して当社のインフラ(Amazon SES)上で行われるため、受信者には共有のMailInAppアドレスではなく[email protected]からのメールとして表示されます。

ドメインを認証する

設定 → ドメインでは、次の手順が案内されます:

  1. ドメインを入力してドメインを認証を押します。既定では、MailInAppはmail.<yourdomain>用の送信アイデンティティと、バウンス処理用のサブドメイン(bounce.mail.<yourdomain>)を作成します — これは専用のサブドメインであり、ルートドメイン上で既に運用している他のメールと安全に共存します。ルートドメインから直接送信したい場合([email protected][email protected]ではなく)は、サブドメインではなくルートドメインを使用するをチェックしてください — これは、そのドメインが他のメールに一切使われていない場合に限って行ってください。受信メールが関わるとこれがより重要になる理由については、ドメインでのメール受信を参照してください。
  2. 表示されたDNSレコード — 複数のDKIM CNAMEレコード、バウンスサブドメイン用のMXTXTレコード、そして初期設定のDMARC TXTレコード — を、自分のDNSプロバイダーに追加します。これらは、そのドメインを自分が管理していることを証明し、そのドメインを通じて送信されたメールがDKIM/SPFチェックに通るようにします。
  3. 追加が終わったら今すぐ確認を押すか、そのまま待ちます — MailInAppは15〜30分ごとに自動的にポーリングします。
  4. ドメインとMAIL FROMサブドメインの両方が認証済みと表示されたら、アカウントの送信方法をネイティブ送信に切り替えるトグルが表示されます。

SMTPへの切り替えは常に可能で、即時に反映されます — ドメインの接続が切れることはないため、再認証なしで両者を切り替えられます。

DMARC

DMARCは、自分のドメインを名乗るもののSPF/DKIMに失敗したメールをどう扱うかを受信箱に指示します — 拒否する、迷惑メールに振り分ける、または(生成時の既定)単に監視するだけです。DKIMやMAIL FROMのステータスをポーリングするのとは異なり、これはMailInAppが自動的に認証できない唯一のレコードです — 対応するAPIが存在しないため、追加してもらうために表示されるだけで、認証済み/保留中のバッジは一切表示されません。

生成されるレコードは、意図的にp=none(監視のみ)として提供されます — これ単体では配信に影響しません。正当なメールが失敗していないことを確認したら、DNSプロバイダー側でポリシーをp=quarantine、最終的にはp=rejectへと段階的に厳格化してください。Cloudflareを含む多くのDNSプロバイダーは、レコードに自分のrua=mailto:アドレスを追加すればDMARC集計レポートを表示してくれます。

変わらないこと

手動送信、スケジュール送信、ライフサイクルメール(注文/チケット通知)、そしてトランザクション送信APIはすべて、アカウントに設定されている送信方法をそのまま経由します — 機能ごとに個別の設定はありません。サプレッション、送信履歴、インタラクショントラッキング、回答は、どちらの方法で配信されたかにかかわらず同じように動作します。

サンドボックスモード

アカウントがSESサンドボックス内にある間は、ネイティブ送信は自分が別途認証したアドレスにしか届きません — これは、当社があなたに代わって本番アクセスをリクエストする前に、自分自身の配信をテストするためのものです。設定カードには、サンドボックスモードが適用されている間は常にわかりやすい通知が表示されます。