SMTP

SMTPは、受信システムが引き受けて配信するまでメールを次のホップに渡す役割を担います。これは受信トレイの同期プロトコルではなく、受信者がメールを読んだことを証明するものではありません。理解するには、接続上のコマンドと応答、およびサーバーキューでまだ配信が完了していないメールという、2つの状態を同時に追跡する必要があります。

メールの一連のパスと2つのアドレスレイヤー

クライアントは通常、MSA（メール送信エージェント）に対してメールを送信し、MTA（メール転送エージェント）がキューと中継を担当し、受信側でさらにメールボックス配信システムに渡されます。SMTP における client/server は現在の接続上の役割を指します：同じ MTA がメールを受信するときは server であり、次のホップに送信するときは client です。

SMTP エンベロープは MAIL FROM と1つ以上の RCPT TO によって定義されます。前者は返信用パスであり、後者はこのトランザクションの実際の受信者を決定します。メッセージの本文部分には RFC 5322 ヘッダーとコンテンツが含まれ、From、To、Cc はユーザーに見えるメッセージフィールドです。これらは異なる場合があります。例えば、返信用アドレスは専用の bounce サブドメインを使用し、BCC 受信者はエンベロープ内には存在しますが公開された受信者リストには表示されません。

Return-Path は通常、最終配信システムによってエンベロープの返信用パスに基づいて生成され、送信クライアントが適当にヘッダーを追加して返信用ルーティングを変更してはいけません。Message-ID はメッセージの識別子であり、SMTP のグローバルな冪等トランザクション番号ではありません。SMTP RFC 5321

MTA は受信ドメインの MX レコードに基づいて候補サーバーを選択し、数値が小さい preference を優先します。MX が存在しないことと、メールを受信しないことが明示的に宣言されていることは異なります。前者はルールに従ってアドレスレコードにフォールバックする可能性がありますが、MX 0 . の Null MX は受信しないことを明確に示します。Null MX RFC 7505

EHLO から本文の受領まで

以下は、TLS 完了と必要な認証が完了した後のトランザクションの例です。各行は実際には CRLF で終了します。S: と C: は読み取り用のマーキングであり、オンライン上のバイト列には含まれません。

複数受信者トランザクションでは部分的な成功があり得ます。クライアントは受信者とフェーズごとに結果を保持する必要があり、「送信失敗」という単一のブール値だけを保存してはいけません。4xx は一時的な失敗を、5xx はそのリクエストの永続的な失敗性質を示し、再試行戦略は具体的なフェーズと組み合わせる必要があります。例えば、認証情報が拒否された場合は、無限にメールを再送信するのではなく、まず設定を修正する必要があります。

DATA で本文内のドットがメッセージを prematurely に終了しないようにするには

DATA は、行全体がドットだけの行によって終了します。もしメッセージの行が本来ドットで始まる場合、送信時に追加でドットを1つ補い、受信時にこの透過的なエンコーディング文字を1つ削除します。以下のモデルでは、入力が正規化された CRLF を使用し、CRLF で終了していることを前提としています。これは任意のメールの MIME 生成器ではありません。

message = (b'From: sender@example.com\r\n'
           b'To: alice@example.net\r\n'
           b'Subject: dot example\r\n\r\n'
           b'.first\r\n.\r\n..third\r\n')
lines = message[:-2].split(b'\r\n')
wire = b'\r\n'.join(b'.' + line if line.startswith(b'.') else line
                    for line in lines) + b'\r\n.\r\n'
assert b'\r\n..first\r\n..\r\n...third\r\n.\r\n' in wire
received = []
for line in wire.split(b'\r\n'):
    if line == b'.':
        break
    received.append(line[1:] if line.startswith(b'.') else line)
assert b'\r\n'.join(received) + b'\r\n' == message
assert len(wire) - len(message) == 6  # 3つのドット補足バイト + 最後のドット行3バイト
print('DATA ドットスタンプ、終端、復元が成功')

CHUNKING がネゴシエートされた接続では、BDAT を使用して明示的なバイト数でコンテンツを送信でき、最後のブロックは LAST マークで終了します。これは DATA 内で本文の書き方を変えるものではなく、DATA のドット終端ルールで区切りません。CHUNKING RFC 3030

キュー、250、および重複メールの障害ウィンドウ

送信側が本文を送信したが最終応答を受信していない場合、2つの可能性があります。相手側がまだ受領していないか、相手側がキューに追加したが 250 が途中で失われたかです。送信側はタイムアウトだけではこれらを区別できません。メールの消失を避けるために再試行すると、重複メールが発生する可能性があります。同じ Message-ID を維持すると関連付けに役立ちますが、すべての受信システムがこれによって重複排除を保証するわけではありません。

受信側が最終的に 250 を返した後、配信できない場合、通常はプロトコルに従って非配信通知を生成する必要があります。返信用には空の逆パス MAIL FROM:<> を使用し、失敗通知が無限に相互に返送されるのを防ぎます。受信サービスは、任意のアドレスに対してまず成功を約束してから、偽装される可能性のある送信元に大量の返送メールを作成してはいけません。SMTP 受領責任と失敗処理

アプリケーションが認証コードや注文通知を送信する場合、ビジネス側は依然として通知イベントと配信試行を記録する必要があります。SMTP の成功応答は支払いトランザクションの一部ではなく、送信タイムアウト後に課金を再実行することはできません。メールの重複とビジネス副作用の重複は、それぞれ別々に処理する必要があります。

同じタイムアウトなのに、なぜすでに1通のメールがある可能性があるのか？

2つの障害とも、送信側が TIMEOUT に停止しますが、受信キューはそれぞれ0通と1通です。それぞれ1回再試行すると、1通と2通になります。この観測不可能なウィンドウは、「本文の送信完了」と「相手の受領確認」の間で不確実性を維持しなければならない理由を説明しています。

送信、サーバー中継、および TLS

465 は RFC 8314 によってメール送信の暗黙的 TLS サービスとして登録されており、「非標準 SMTPS」としてマークされ続けるべきではありません。送信と公開 MTA 中継の認証モデルは異なり、インターネット上のすべての送信 MTA が受信サーバーのアカウントを保持することを要求することはできません。RFC 8314、Submission RFC 6409

STARTTLS が準備完了を返した後、TLS ハンドシェイクが行われ、双方は以前に習得した SMTP 状態をクリアし、クライアントは再 EHLO を実行して現在の機能を取得します。平文フェーズで取得した AUTH 機能を信頼できるものとしてキャッシュしてはいけません。AUTH PLAIN の Base64 はエンコーディングにすぎず、パスワードの暗号化ではありません。認証の許可と使用する SASL メカニズムは、サーバーの機能とポリシーによって決定されます。STARTTLS RFC 3207

通常のオプティミスティック TLS では、ダウングレード攻撃に遭う可能性があります。MTA-STS は HTTPS を介して受信ドメインの TLS/MX ポリシーを公開およびキャッシュします。SMTP 用の DANE は、DNSSEC 認証された TLSA 情報に依存します。これらは中継リンクを制約するために使用され、メッセージ自体の署名に代わるものではなく、すべての中継サーバーがメールを読めなくするものでもありません。MTA-STS RFC 8461、SMTP DANE RFC 7672

SPF：送信元 IP がこのエンベロープドメインを使用する許可を得ているか

SPF は、今回の SMTP 接続の送信元 IP とエンベロープドメインに基づいて承認を評価します。空の返信用パスのシナリオでは、HELO 識別子のルールが使用されます。これはユーザーに見える From を直接検証するものではなく、本文が改ざんされていないことを証明するものでもありません。

例えば v=spf1 ip4:192.0.2.0/24 -all は、この教育用ドメインが指定された IPv4 範囲を承認し、それ以外は -all で fail となることを示します。結果には softfail、neutral、none、temperror、permerror も含まれ、DNS の一時的な障害と明確な不承認は混同してはいけません。SPF RFC 7208

include はテキストの貼り付けではありません。再帰評価における include、a、mx、ptr、exists、redirect などの DNS 照会系 term の総数には上限があり、10 を超えると permerror が返されます。これは最外層の include のみを数えるものではなく、パケットキャプチャ内のすべての DNS パケットを単純にカウントするものでもありません。複数の送信ベンダーを管理する際は、実際の展開パスとレコードの無効化を追跡し、include を追加し続けるべきではありません。

転送は接続の送信元を変更するため、元のエンベロープドメインの SPF は失敗する可能性があります。これは元のメールが必ずしも偽造されていることを意味するものではなく、なぜコンテンツ署名と整合性判断も必要なのかを説明しています。

DKIM：署名ドメインが選択した内容に署名する

DKIM-Signature の d= は署名ドメイン、s= はセレクターであり、検証器は s._domainkey.d に対して公開鍵を検索します。h= は署名対象のヘッダーを指定し、bh= は正規化された本文のダイジェスト、b= は署名値です。署名入力には、ルールに従って処理される DKIM-Signature ヘッダーも関与し、「header hash と body hash を適当に連結して RSA を行う」と単純化することはできません。From ヘッダーは署名に含まれなければなりません。DKIM RFC 6376

正規化ルールは、どの空白の調整が許容されるかを決定します。メールリストによるフッターの追加、Subject の変更、または本文の変換は、依然として署名を破壊する可能性があります。DKIM pass は、そのドメインの鍵を保持する側が検証されたコンテンツに署名したことを証明しますが、署名ドメインが目に見える From ドメインであることを証明するものではなく、メールコンテンツが善意であることを証明するものでもありません。

転送が外部エンベロープのみを変更し、署名されたコンテンツを保持する場合、DKIM は通過する可能性があります。複数の署名が共存でき、無関係なドメインの署名が通過したからといって、DMARC の通過を直接導き出すことはできません。

DMARC：認証結果が目に見える From ドメインとバインドされる

DMARC の通過条件は、少なくとも1つのパスが「認証 pass」と「Author Domain との整合」の両方を満たすことです。strict はドメイン名が同一であることを要求します。relaxed は組織ドメインの関係に基づいて判断され、文字列の接尾辞マッチングでは不十分であり、単純にドメインの最後の2つを取ってはいけません。DMARC RFC 9989

2026年9月現在、RFC 9989 は 2026年5月に RFC 7489/9091 を置き換えました。組織ドメインとポリシーの発見には DNS ツリーウォークが採用され、旧 pct タグが削除され、テスト用の t が導入され、集計レポートと失敗レポートは RFC 9990/9991 に分離されました。実際の受信実装は移行期間中である可能性があり、旧 PSL 判定と新しいツリートラバーサルがすべてのドメイン構造で同じ結果を得るとは限りません。新版の変更

以下は厳密な整合性のためのローカルな教育用モデルであり、DNS ポリシー発見は実装されていません。これを使用して、「pass」と「aligned」が同じ検証パスに属さなければならないことを明確にできます。

def dmarc_strict(author, spf_result, mail_from_domain, dkim_results):
    spf_ok = spf_result == 'pass' and mail_from_domain.lower() == author.lower()
    dkim_ok = any(result == 'pass' and domain.lower() == author.lower()
                  for result, domain in dkim_results)
    return spf_ok or dkim_ok

assert dmarc_strict('example.com', 'fail', 'example.com', [('pass', 'example.com')])
assert not dmarc_strict('example.com', 'pass', 'vendor.example', [('fail', 'example.com')])
assert not dmarc_strict('example.com', 'pass', 'bounce.example.com', [])
assert dmarc_strict('example.com', 'pass', 'example.com', [])
print('厳密な整合性及び SPF 失敗だが DKIM 通過のブランチが成功')

v=DMARC1; p=reject; rua=mailto:dmarc@example.com を公開することは、ドメイン所有者の処理方針とレポート要求を表現しますが、受信者は依然としてローカルポリシーと組み合わせて判断します。p=none は DMARC 失敗に基づいて隔離または拒否することを要求するものではなく、メールが受信トレイに入ることを保証するものでもありません。p=reject は、すべての受信者がすべての SPF fail メールを無条件に拒否することを意味するものではなく、整合した DKIM pass があれば DMARC pass になり得るためです。

ARC は、メールが中間システムを経由した際の認証結果チェーンを記録し、受信者が転送シナリオを評価するのに役立ちます。それは失敗した DKIM 署名を魔法のように修復するものではなく、受信者が任意の ARC 封印者を信頼することを要求するものでもありません。ARC RFC 8617

SPF 通過、DKIM 整合、なぜ組み合わせると依然として失敗する可能性があるのか？

初期設定では、成立条件を意図的に異なるパスに分離しており、全体として依然として失敗します。そのうちの1行を補充すれば通過できますが、もう1行は同時に通過する必要はありません。ここで得られるのは認証結果であり、受信者が最終的にメールをどのように処理するかは、依然として独自のポリシーに依存します。

$$DMARC=(SP{F}_{pass}\wedge SP{F}_{aligned})\vee (DKI{M}_{pass}\wedge DKI{M}_{aligned})$$

MIME、国際化、および最終診断

SMTP はメッセージを転送し、MIME は本文のタイプ、セグメンテーション、転送エンコーディングを記述します。Base64 添付ファイルは通常、データサイズを約3分の1増加させ、折り返しとメッセージヘッダーも考慮する必要があります。8BITMIME は、すべての国際化アドレスが合法であることを意味するものではなく、非 ASCII メールアドレスには SMTPUTF8 などの対応するサポートが必要です。MIME RFC 2045、SMTPUTF8 RFC 6531

トラブルシューティングでは、まず正確なフェーズ、応答コード、およびキュー ID を取得します。接続応答がない場合はネットワークを確認し、AUTH 失敗の場合は送信資格情報を確認し、RCPT 拒否の場合はアドレスとポリシーを確認し、最終的な DATA 後のキューイング成功の場合は後続のキューと受信側の処理を確認します。認証結果ヘッダーも、信頼できる受信境界によって生成された記録と送信者が自行挿入したテキストを区別する必要があり、spf=pass の行が見えただけで検証結論として扱ってはなりません。