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

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

Gmail、メール転送、SMTP、MXレコード、SPF、DKIM、DMARC、ドメインレピュテーション、ルートドメインとサブドメインの使い分けを実用的に解説します。

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

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

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

ドメインからメールを送信するときは、GmailやOutlookなど受信側のメールサービスに、そのメールが正規に許可され、認証されていることを示す必要があります。そのために使われるのがSMTP設定、SPF、DKIM、DMARCです。

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

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

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

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

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

ただし、独自ドメイン宛てのメールを受信できるだけでは、Gmailからそのアドレスを使って送信することはできません。送信するには、そのドメインからの送信を許可されたSMTPサーバーをGmailで利用する必要があります。

通常は、Gmailの「他のメールアドレスを追加」機能から独自ドメインのアドレスを追加し、SMTPサーバーの情報を入力します。以降、そのアドレスから送信または返信するときは、Gmailが設定したSMTP接続を使用します。

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

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

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

MailLogic SMTPを使ってGmailから送信する場合、Gmailは送信サーバーとしてMailLogicへ接続します。MailLogicは独自ドメインの送信元情報を使って、そのメールを宛先へ中継します。

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

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

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

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

まとめると、MailLogicはメールを自動的にルーティングし、プログラムによって迷惑メールや不正利用を検査し、サービスを安定して運用するために必要なメタデータだけを保持するよう設計されています。

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の検索、迷惑メール、フィルタ、最終的な振り分け先を確認します。

独自ドメインからの送信には、Webアプリ、SMTP、APIのどれを使えばよいですか？

独自ドメインからメールを送る方法は、主に3つあります。

適した方法は、何をしたいかによって異なります。

Webアプリを使う場合は、別のサービスへログインし、別の受信トレイまたは作成画面を開いてメールを送ります。この方法でも送信できますが、確認する画面と管理する作業が増えます。

SMTPは異なります。SMTPを使うと、普段使っているメールアプリから、認証済みのメールサーバーを経由して送信できます。たとえばGmail内で[email protected]から送信するには、通常、Gmailの「他のメールアドレスを追加」機能を使い、サーバー、ポート、ユーザー名、パスワードといったSMTP接続情報を入力します。

これなら、普段使うメールアプリはGmailのままです。MailLogicが裏側の送信経路を担当します。

APIは、一般の利用者が手動でメールを書くためではなく、プログラムやソフトウェアから送信するためのものです。アプリやスクリプトがエンドポイントを呼び出して、メールを自動送信します。確認メール、通知、領収書、アラート、社内ツールなどに適しています。

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

  • 人がメールを書いたり返信したりする場合は、GmailとSMTPを使います。
  • ソフトウェアが自動的にメールを送る場合は、APIを使います。
  • 別の場所でメールを作成・管理したい場合に限り、専用のWebアプリを使います。

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

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

たとえば、顧客、取引先、業務委託先、クライアントへ人が書いたメールを送る場合は、ルートドメインが自然です。相手との関係が大切で、メールを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へ届きやすくなるようにします。