ホーム メールガイド
メールガイド

独自ドメインメールをやさしく解説

メール転送、ダッシュボード送信、Batch Send、SMTP、API、Replies、配信結果、宛先保護、DNS認証、ドメインレピュテーションを実用的に解説します。

受信と送信：独自ドメインメールを理解するための大切な違い

メールはひとつのサービスとして使うことが多いものの、独自ドメインメールには「受信」と「送信」という別々の役割があります。

メールを受信するときは、ドメインのMXレコードが受信メールの配送先をインターネット上のメールサーバーへ伝えます。MXレコードがMailLogicを指定していれば、MailLogicがドメイン宛てのメールを受信し、現在お使いの受信トレイへ転送できます。

ドメインからメールを送信するときは、GmailやOutlookなど受信側のメールサービスに、そのメールが正規に許可され、認証されていることを示す必要があります。MailLogicでは、ダッシュボード、Batch Send、API、または認証済みSMTPから送信でき、SPF、DKIM、DMARCが送信元の認証を支えます。

MailLogicでは、この2つの役割を分けています。受信側はメール転送、送信側は各送信機能が担当します。まずは無料の転送だけで始め、必要になったときに送信を追加できます。

この違いを理解すると、独自ドメインメールの仕組みがずっとわかりやすくなります。メールには古いプロトコルや独特な用語が今も多く残っていますが、最初に押さえたい考え方はこの「受信と送信の違い」です。

メール転送は無制限ですか？アドレス数の上限とはどう違いますか？

MailLogicでは、どのプランにも転送メッセージ数の固定された月間上限はありません。メール転送はフェアユースの対象です。

これは、プランごとの登録アドレス数の上限とは別です。登録アドレスとは、[email protected]のように個別に作成・管理するアドレスです。FreeとSMTPプランは5個、Starterは15個、Founderは50個まで登録できます。

キャッチオール受信はさらに別の仕組みです。キャッチオールを有効にすると、あらかじめ個別登録していないアドレス宛てのメールも、指定した転送先で受信できます。

要点は次のとおりです。

  • 転送量には固定された月間上限がなく、フェアユースが適用されます。
  • 登録アドレス数の上限はプランによって異なります。
  • キャッチオールでは、すべてのアドレスを個別登録せずに、それ以外の宛先も受信できます。

独自ドメインメールをGmailで使う仕組みは？

独自ドメインのアドレスへメールが送られると、ドメインのMXレコードがそのメールの配送先を決めます。MXレコードがMailLogicを指定していれば、MailLogicがメールを受信し、現在お使いのGmailへ転送します。

そのため、独自ドメインのアドレスを使っても、メールを読む場所はこれまでどおりGmailのままです。別のメールボックスを確認する必要はありません。

ただし、独自ドメイン宛てのメールを受信できることと、Gmailからそのアドレスで送信できることは同じではありません。受信と送信では別の経路を使います。

Googleの2026年中の移行期間では、Gmailの第三者メールアドレス向け「他のメールアドレスから送信」機能からMailLogic SMTPへ接続できます。ただし、Googleはこの機能を2027年1月に終了すると発表しており、それ以前に新規設定が制限される場合もあります。詳しくはGoogleのお知らせをご確認ください。

この変更は、MailLogicからGmailへの受信メール転送には影響しません。送信には、MailLogicダッシュボードのSend EmailまたはBatch Send、利用プランに含まれるAPI、あるいはMailLogicのSMTP認証情報を設定した対応メールクライアントやアプリケーションをご利用ください。

サブドメインでMailLogicを利用する

サブドメインとは、メインのドメイン名の前に、ドットで区切って名前を追加したものです。たとえば、www.example.com、mail.example.com、billing.example.com などがあります。

MailLogicでは、サブドメインもルートドメインと同じように利用できます。さらに、サブドメインには、ルートドメインとは別に独自の送信・受信設定を持たせることができます。

たとえば、example.com では引き続きGoogle WorkspaceやMicrosoft 365を利用しながら、mail.example.com はMailLogicで管理し、SMTP、API、Batch Send、またはメール転送に利用できます。

MailLogicは、追加されたドメインがサブドメインであることを認識し、ルートドメインとの関係も把握したうえで、DNS設定の案内を適切に調整します。

MailLogicはメールをどのように処理しますか？

MailLogicは、自動化されたSMTPルーティング層として動作します。

独自ドメインへメールが送られると、ドメインのMXレコードに従ってMailLogicへ届きます。MailLogicはメールを受信し、自動ルーティングと迷惑メールチェックを行ったうえで、設定されたGmailなどの転送先へ配送します。

送信メールは、Send Email、Batch Send、送信API、または認証済みSMTPクライアントからMailLogicへ渡されます。MailLogicは独自ドメインの送信元情報を使って、そのメールを宛先へ中継します。

このルーティング処理は自動化されています。通常のルーティング、フィルタリング、配送の過程で、人がメールを確認することはありません。

迷惑メールや不正利用を防ぐため、MailLogicはRspamdなどの自動フィルタリングツールを使用します。これらのシステムは、送信元の評価、認証結果、迷惑メールのパターン、配送リスクなどのプログラム上のシグナルを使ってメールを判定します。お客様のメールを人が確認することなく、到達性を守り、不正利用を防ぐことが目的です。

MailLogicは、配送上の問題の調査、不正利用の防止、システムの信頼性維持に必要な運用ログを保持します。ログには、送信元・宛先アドレス、ルーティング方向、SMTPステータスコード、配送先からの応答、日時、迷惑メール判定結果などの通信メタデータが含まれる場合があります。

MailLogicは、メール本文や添付ファイルをアプリケーションログへ意図的に保存しません。ただし、メールサーバーがメールを処理、キューイング、転送、再試行、またはバウンス処理している間、メッセージ内容が一時的に存在する場合があります。通常の配送が完了するか、キューの保持期限が切れると、一時的なメッセージのコピーはメールシステムから削除されます。

MailLogic Repliesは明示的な例外です。Repliesに対応する会話では、元の件名と、受信・送信した返信の件名および本文を、ダッシュボードに表示される所定の保持期間中保存します。最初に送信したメールの本文や添付ファイルの内容はRepliesへコピーされません。受信した添付ファイルの内容も保存せず、会話には添付ファイルがあったことだけを記録します。保持期間が終了すると保存された会話内容は削除されますが、ルーティング、配信、重複防止、監査に必要な限定的なメタデータが残る場合があります。

まとめると、通常のルーティングは自動化され、アプリケーションログにはメール本文ではなく運用上のメタデータを保存します。会話内容を保存するのは、利用者がMailLogic Repliesに対応する機能を選択または使用した場合に限られ、保存期間も明示された保持期間内に限られます。

MXレコードの役割を簡単に説明すると？

MXレコードは、ドメイン宛てのメールをどこへ配送するかをインターネット上のメールサーバーへ伝えます。

ドメイン宛てにメールが送信されると、送信側のメールサーバーはドメインのDNSレコードを確認して配送先を特定します。このとき、受信メールのために使われるDNSレコードがMXレコードです。

「MX」はmail exchanger（メール交換サーバー）の略ですが、次のように考えるとわかりやすくなります。

MXレコードは、ドメイン宛てメールの配送先住所です。

MXレコードには「優先度」と呼ばれる数字が付くことがあります。数字が小さいほど優先度が高いため、優先度10のMXレコードは、優先度20のレコードより先に試されます。

ひとつのサーバーが利用できない場合に備え、複数のMXレコードで予備の配送経路を用意するサービスもあります。多くの利用者にとって大切なのは、数字そのものより、MXレコードが正しい配送先を指定していることです。

そのため、MXレコードの変更は慎重に行う必要があります。MXレコードはドメイン宛ての受信メールを制御します。正常に動作しているレコードを誤った内容へ置き換えると、新しいメールが期待した場所へ届かなくなる可能性があります。

SPF、DKIM、DMARCはそれぞれ何を証明しますか？

SPF、DKIM、DMARCは、それぞれ役割の異なるメール認証の仕組みです。

SPFは、メールを送ったサーバーがそのドメインからの送信を許可されているか確認します。簡単に言えば、「このメールは、このドメインが許可したサーバーから送られたか」を確認します。

DKIMは、メールにドメインの暗号学的な署名が付いているか、そして署名の対象となった部分が配送途中で変更されていないかを確認します。簡単に言えば、「このメールには有効なドメイン署名があり、その署名後に内容が変わっていないか」を確認します。

DMARCは、SPFとDKIMの結果を、受信者に表示されるFromアドレスのドメインと結び付けます。あるドメインから送られたように見えるメールが、正しく整合した認証に合格しない場合、どのように処理してほしいかをドメイン所有者が受信側へ伝えられます。

簡単に言えば、DMARCは「自分のドメインから送られたように見えるメールが正しく証明できない場合は、このように処理してください」と伝える仕組みです。

ドメインのDMARCポリシーに応じて、受信側のサーバーはメールを監視対象にしたり、迷惑メールへ振り分けたり、受信を拒否したりします。

送信サービスを増やしすぎるとSPFが壊れるのはなぜですか？

ひとつのドメインに設定するSPFレコードは、サービスごとにひとつではなく、すべてをまとめたひとつのレコードです。

各メールサービスから「このSPFレコードを追加してください」と案内されることがあるため、ここは混乱しやすい点です。

たとえば、あるサービスから次のレコードを追加するよう案内されたとします。

v=spf1 include:_spf.google.com ~all

別のサービスからは、次のように案内されるかもしれません。

v=spf1 include:mailservice.example ~all

さらに別のサービスから、次のように案内されたとします。

v=spf1 include:another-service.example ~all

しかし、同じドメインに3つのSPFレコードを別々に追加してはいけません。SPFが失敗する原因になります。

代わりに、各サービスをひとつのTXTレコードへまとめます。

v=spf1 include:_spf.google.com include:mailservice.example include:another-service.example ~all

これにより、3つのサービスすべてがそのドメインからのメール送信を許可されていることを受信側へ伝えられます。

もうひとつ注意したいのが、SPFにはDNSルックアップ回数の上限があることです。それぞれの「include」が、内部で追加のDNSルックアップを発生させる場合があります。多くのサービスを追加しすぎると、レコードの見た目が正しくても上限を超えてSPFが失敗することがあります。

基本はシンプルです。SPFレコードはひとつにまとめ、各サービスを慎重に組み合わせ、実際に使う以上の送信サービスを追加しないようにします。

ドメインのDMARCポリシーはどのように設定しますか？

DMARCは、アライメントの取れたSPFまたはDKIMのどちらか一方に合格すれば成功します。両方への合格は必要ありません。

どちらもアライメントに合格しない場合、受信側のシステムはドメインのDMARCポリシーを確認します。

  • p=none：DMARCの結果を理由とする特別な強制処理は行わず、主に監視します。
  • p=quarantine：疑わしいメールとして扱い、通常は迷惑メールへ振り分けます。
  • p=reject：メールの受信を拒否します。

これらはDNSで公開される受信側への要請であり、すべての受信サービスが機械的に従わなければならない命令ではありません。

特に、p=noneはメールを破棄するという意味ではありません。DMARCの結果を理由に隔離または拒否しない、という意味です。

「アライメントの取れたSPFに合格」とはどういう意味ですか？

SPFへの合格とSPFアライメントは、別々の確認項目です。

  1. SPFは、送信元IPアドレスがエンベロープ送信元のドメインからの送信を許可されているときに合格します。このドメインは通常、Return-PathまたはMAIL FROMに表示されます。
  2. SPFアライメントは、そのエンベロープ送信元のドメインが、受信者に表示されるFrom:アドレスのドメインと一致するときに成立します。DMARCで標準の緩和アライメントを使用する場合は、同じ組織ドメインのサブドメインもアライメントが取れていると見なされます。

DMARCでSPFが有効と見なされるには、この両方を満たす必要があります。

たとえば、次のようなメールを考えます。

SPFに合格し、ドメインのアライメントも取れているため、SPFによってDMARCの要件を満たせます。

一方、次の場合は異なります。

SPF認証そのものには合格していますが、mailvendor.comとexample.comのアライメントは取れていません。そのため、このSPFの結果ではDMARCの要件を満たせません。

DMARCレポートが届くのはなぜですか？

ドメインの_dmarc TXTレコードのrua項目にメールアドレスが設定されていると、GoogleやMicrosoftなどの受信サービスからDMARCレポートが送られます。このレポートには、そのドメインから送られたとされるメールについて、SPFとDKIMの結果が集計されています。

DNSが正しくても、新しいドメインのメールが迷惑メールになるのはなぜですか？

新しいドメインには通常、メール送信の実績がほとんど、またはまったくありません。Gmail、Outlook、Yahooなどのメールサービスは、まだそのドメインから十分な通常利用の履歴を確認できていません。受信側から見ると、認証は正しくても、まだ馴染みのないドメインです。

そのため、新しいドメインはSPF、DKIM、DMARCのすべてに合格していても、慎重に扱われることがあります。

ドメインの送信状況が突然大きく変わった場合も同様です。迷惑メールやフィッシングが常に発生しているため、メールシステムは慎重に判定します。認証への合格は出発点であり、送信元としての評価は時間をかけて築かれます。

正しいDNS設定は、ドメインが適切に構成されていることを示します。しかし、そのドメインに信頼できる送信実績があることまで即座に証明するものではありません。

Gmailでメールを受信できないときは、何を確認すればよいですか？

「Gmailでメールを受信できなかった」という場合、通常は2つの異なる問題が考えられます。

メールがGmailまで届かなかったか、Gmailには届いたものの受信トレイ以外の場所へ入ったかのどちらかです。

この違いを確認することが大切です。

MailLogicとGmailを使用している場合、通常の受信経路は次のようになります。

送信者 → ドメインのMXレコード → MailLogic → Gmailの受信トレイ

最初に確認したいのは、メールがこの経路のどこで止まったかです。

まずGmail内を確認します。送信者、件名、または本文に含まれる固有の語句で検索してください。迷惑メール、すべてのメール、ゴミ箱、カテゴリタブ、フィルタ、ブロック中のアドレスも確認します。メールは届いていても、受信トレイに表示されていないことがあります。

次に、送信者へバウンスメールが届いていないか確認します。バウンスメールを調べると、配送に失敗したのか、拒否されたのか、遅延しているのかがわかります。画面に表示される短いエラー概要より、技術的な詳細のほうが役立つこともあります。

続いて、独自ドメインの設定を確認します。送信者が正しいメールアドレスを使用したか確かめてください。

ドメインのMXレコードがMailLogicを指定していることも確認します。MXレコードは、ドメイン宛ての受信メールの配送先を制御します。別の場所を指定していると、MailLogicまでメールが届かない可能性があります。

最後に、MailLogicの転送設定を確認します。独自ドメインのメールアドレスがMailLogicに登録され、正しいGmailアドレスが転送先として設定されている必要があります。

有料プランでは、MailLogicのログ画面から問題の範囲を絞り込めます。MailLogicがメールを受信して転送した場合は、ログで確認できます。メールがログに表示されない場合は、送信者、宛先アドレス、またはドメインのMXレコードなど、MailLogicへ届く前の段階に問題がある可能性があります。

次のように考えるとわかりやすくなります。

  • MailLogicがメールを受信していない場合は、送信者、宛先アドレス、MXレコードを確認します。
  • MailLogicがメールを転送済みの場合は、Gmailの検索、迷惑メール、フィルタ、最終的な振り分け先を確認します。

ダッシュボードのSend Email、Batch Send、SMTP、APIはどう使い分けますか？

MailLogicには4つの送信方法があります。いずれも同じ認証済みドメインを使いますが、それぞれ異なる用途に向いています。

ダッシュボードのSend Emailは、MailLogicで直接メールを作成する機能です。複数の宛先に同じ内容を送る場合にも利用できます。To、Cc、Bccを合わせて最大100件の宛先を指定でき、プレーンテキストまたはHTMLを選び、プレビューを確認して、合計25MBまでのファイルを添付できます。

Batch Sendは、宛先ごとに内容を変えた個別のトランザクションメールを送るための機能です。CSVをアップロードまたは貼り付け、その列名をテンプレート変数として使い、表示結果をプレビューしてから、SMTPは最大100件、Starterは最大500件、Founderは最大2,000件のメールを個別にキューへ追加できます。Batch Sendは添付ファイルに対応していません。

認証済みSMTPは、対応するメールクライアントやアプリケーションから送る場合に使います。MailLogicに表示されるサーバー、ポート、ユーザー名、パスワードを設定して接続します。送信元として登録した各アドレスには、それぞれ専用のSMTP認証情報があります。

APIは、ソフトウェアから送信するための機能です。Send APIは通常のトランザクションメールをプログラムから送信します。Batch Send APIは、パーソナライズされた一括送信を非同期で受け付け、進捗と配信結果を確認するためのエンドポイントを提供します。

次のように選ぶとシンプルです。

  • その場でメールを作成して送る場合は、Send Emailを使います。
  • 氏名、月、参照番号、金額など、宛先ごとに値を変える場合は、Batch Sendを使います。
  • 別のメールクライアントやアプリケーションでメールを作成する場合は、SMTPを使います。
  • ソフトウェアから送信を開始する場合は、APIを使います。

Send Email、Batch Send、認証済みSMTPは、すべての有料プランで利用できます。Send APIとBatch Send APIはStarterとFounderで利用できます。

パーソナライズBatch Sendはどのように機能しますか？

Batch Sendでは、ひとつのメールテンプレートとCSV形式の宛先リストを組み合わせます。多数の宛先をToやBccへまとめるのではなく、CSVの各行から1通ずつ個別のメールを作成します。

たとえば、宛先リストは次のようになります。

email,name,month,amount
[email protected],Alice,8月,4200円
[email protected],Bob,8月,5800円

テンプレートでは、二重の波かっこを使って各列を参照できます。

件名：{{month}}のご利用明細

{{name}}様、現在のご利用額は{{amount}}です。

送信前に、MailLogicはCSVを検証し、すべての変数に対応する列と値があることを確認します。また、送信抑止中の宛先を特定し、置換されたメールをプレビューできます。1回のBatch Sendには、SMTPは最大100行、Starterは最大500行、Founderは最大2,000行の宛先を含められます。

送信可能な1行につきSMTPクレジットを1通分使用します。送信抑止中の宛先はスキップされ、クレジットを使用しません。MailLogicは処理開始前に送信可能な全件分のクレジットを確保するため、クレジット不足によって一部だけが送信されることはありません。クレジットの手動購入を待っているバッチは、24時間の保持期間内であれば処理を再開できます。

送信処理が始まると、最近のバッチ画面では進捗と配信結果を分けて表示します。100 / 100のような進捗は、すべての行で送信処理段階が完了したことを意味します。すべての宛先サーバーがメールを受け付けたという意味ではありません。実際の結果は、宛先サーバー受付済み、再試行中、保留、バウンス、失敗、送信抑止の件数で確認してください。

MailLogic Repliesとは何ですか？どの送信に対応していますか？

MailLogic Repliesは、MailLogicから送信した対応メールの会話を確認するためのダッシュボード画面です。別のメールボックスを作成せずに、宛先からの返信を読み、そのまま会話を続けられます。

ダッシュボードとAPIのBatch Sendでは、送信可能な宛先ごとに追跡対象の会話が作成されます。ダッシュボードのSend Emailでは、To宛先が1件のみでCcとBccがない場合に、Reply-ToとしてMailLogic Repliesを選択できます。宛先からの返信はReplies画面に表示され、最初に使った独自ドメインアドレスから返信できます。

通常のSend APIによる送信や、認証済みSMTPから直接送信されたメールでは、MailLogic Repliesの会話は作成されません。Reply-Toに転送アドレスを選んだ場合は、返信がその転送経路を通って現在お使いの受信トレイへ届きます。

Repliesは一般的なメールボックスではありません。上記の対応する会話だけを扱います。保存された返信の件名と本文は、ダッシュボードに表示される所定の保持期間中に限り閲覧でき、その期間後に削除されます。添付ファイルの内容は保存しませんが、添付ファイルがあったことは会話に表示されます。

MailLogicのSMTP配信結果は何を意味しますか？

メール送信には複数の段階があります。まずMailLogicがメールを受け付けて送信処理へ渡します。その後、宛先のメールサーバーから、宛先を受け付けた、一時的に保留した、または拒否したという結果が返されます。

  • 送信受付済み（Submitted）：MailLogicがメールを受け付け、送信処理へ渡しました。
  • 宛先サーバー受付済み（Accepted by destination）または送信済み（Sent）：宛先のメールサーバーがメールを受け付けました。
  • 再試行中（Deferred）：宛先が一時的にメールを受け付けなかったため、メールサーバーが再試行しています。
  • 保留（Pending）：宛先から確定的な結果がまだ得られていません。
  • バウンス（Bounced）：宛先から恒久的な拒否が返されました。
  • 失敗（Failed）：送信または配信に失敗したか、再試行期間が終了しました。
  • 結果不明（Unknown）：送信処理が成功したかどうかをMailLogicで確認できませんでした。
  • 送信抑止（Suppressed）：過去に条件を満たす配信失敗があったため、送信処理へ渡す前にMailLogicがその宛先をスキップしました。

「宛先サーバー受付済み」は、SMTP送信者が通常確認できる最も確かな結果ですが、受信トレイに表示されたことを証明するものではありません。受信サービスは受付後に、迷惑メールへ振り分けたり、フィルタを適用したり、別の方法で分類したりする場合があります。MailLogicは、「宛先サーバー受付済み」が受信トレイへの到達や受信者による開封を証明するとは表示しません。

有料プランのログ画面では、転送とSMTPの履歴を検索可能なフィルタ、詳細な応答、日時とともに確認でき、CSVでダウンロードできます。Batch Sendでは、宛先ごとの配信結果もバッチ単位で集計します。

宛先の送信抑止は今後の送信をどのように保護しますか？

受信できないアドレスへ繰り返し送信すると、送信容量を無駄にし、配信レピュテーションを損なうおそれがあります。そのためMailLogicは、MailLogicが管理する送信で条件を満たす配信失敗があった宛先を、ワークスペース共通の送信抑止リストで管理します。

存在しないアドレスなど、明確で恒久的な宛先エラーでは、直ちに送信抑止となる場合があります。それ以外の曖昧な失敗や、最終的なソフトエラーでは、異なる2通のメールでの失敗が必要です。一時的な再試行は送信抑止の判定には数えません。また、ポリシーや内容による拒否、認証、接続、ローカル送信処理の問題だけを理由に、宛先を送信抑止することはありません。

その後の配信に成功すると、恒久的ではない失敗履歴はクリアされます。明確なハードバウンスによる送信抑止は、利用者が明示的に解除するまで継続します。

宛先が送信抑止中になると、次のように動作します。

  • Batch Sendではその宛先をスキップし、クレジットを使用しません。
  • Send APIでは送信可能な宛先から除外します。ほかに送信可能な宛先が含まれていれば、その宛先への送信は続行できます。
  • ダッシュボードのSend Emailでは警告を表示し、保護を上書きして送信するには明示的な確認が必要です。
  • MailLogic Repliesでは、送信抑止中の宛先への返信をブロックします。

ログ画面の下にある送信抑止中の宛先テーブルでは、アドレス、理由、直近の失敗を確認できます。アドレスが有効で、再び受信できる状態であることを確認した場合にのみ「解除」を使用してください。

自動送信抑止の対象は、現在、ダッシュボードのSend Email、Send API、Batch Send、MailLogic Repliesです。外部クライアントから認証済みSMTPで直接送信したメールはログに表示されますが、この直接SMTP送信から自動的な宛先の送信抑止状態が作成されることは、現在ありません。

メールにはルートドメインとサブドメインのどちらを使うべきですか？

通常、主なビジネス上の送信元にはルートドメインが適しています。

たとえば、顧客、取引先、業務委託先、クライアントへ人が書いたメールを送る場合は、ルートドメインが自然です。相手との関係が大切で、メールを1通ずつ作成または確認して送るような用途です。

アプリが自動生成するメールやトランザクションメールには、通常サブドメインが適しています。

たとえば、領収書、請求書、支払いのお知らせ、パスワードリセット、ログイン通知、製品からの通知、システム更新などをサブドメインから送信できます。

理由は、送信用途を分けられるからです。自動メールは、通常の人同士のメールとは送信量、形式、バウンスの傾向、利用者の反応が異なる場合があります。サブドメインを使うことで、その送信活動を主なドメインから分けて管理しやすくなります。

サブドメインを使えば評価へのリスクがなくなるわけではありませんが、用途の境界が明確になります。ルートドメインは人同士のビジネス上のやり取りに集中させ、アプリやシステムからのメールは専用のサブドメインで運用できます。

MailLogicでは、サブドメインをひとつの独立したメールドメインとして扱います。

つまり、example.comとnotify.example.comは別々に設定します。

次のサブドメインを追加した場合：

notify.example.com

アプリから送るメールアドレスは、次のようになります。

[email protected]

次のアドレスではありません。

[email protected]

サブドメインには、受信と送信のためのDNSレコードを個別に設定する必要があります。使い方に応じて、MXレコード、SPF、DKIM、DMARCなどを設定します。

メール転送で使われるSRSとは何ですか？

SRSはSender Rewriting Scheme（送信者書き換え方式）の略です。

メール転送を正しく機能させるために使われる技術のひとつです。

メールを転送すると、元の送信者から最終的な受信トレイへ直接配送されるのではなく、途中で転送サービスを経由します。

これがSPF上の問題を引き起こします。

SPFは、メールを送信したサーバーがエンベロープ送信元のドメインからの送信を許可されているか確認します。GmailがMailLogicから転送メールを受け取ったとき、エンベロープ送信元が元の送信者のドメインのままだと、SPFが失敗する可能性があります。通常、MailLogicは元の送信者のSPFレコードで許可されていないためです。

SRSは、転送時にエンベロープ送信元を書き換えることで、この問題を解決します。

受信者に表示されるFromアドレスは変わらないため、元の送信者を確認できます。一方、技術上のReturn-Pathは書き換えられ、転送サービスを経由したメールとして正しく認証できるようになります。

簡単に言えば、次のような仕組みです。

  • メール転送によって配送経路が変わります。
  • SRSが技術上の送信者情報を更新し、転送後もSPFの仕組みが正しく働くようにします。

正しく設定されたメール転送がGmailなどの受信サービスでも安定して機能するのは、このためです。転送自体が問題なのではありません。多くの場合、問題は転送サービスがSPF、SRS、DKIM、配送動作を適切に処理していないときに起こります。

MailLogicでは、SRSを転送経路の一部として使用しています。メールが転送されたという理由だけでSPFが失敗することを防ぎ、転送メールがGmailへ届きやすくなるようにします。