Eメールとは？送受信の仕組みとBccが見えない理由を実物で解説

この記事で実際に動かしたもの：127.0.0.1 だけで動く自作のメール配送の仕組み（送信サーバー1台・受信サーバー3台・POP3 サーバー1台・DNS サーバー1台）です。curl と Python の smtplib でメールを送り、STARTTLS・認証・MX の検索・中継・メールボックスへの保存・POP3 での受信までを動かし、届いたヘッダー、Bcc の扱い、添付ファイルの大きさ、SPF と DKIM の判定、エラーと戻ってきたメールの原文を記録しました。外部のメールサーバーには接続も送信もしていません。

Eメールは毎日使う道具ですが、「送信ボタンを押した後に何が起きているか」は画面からは見えません。この記事では、その見えない部分を手元のサーバーで再現し、実際の会話（コマンドと応答）と届いたメールの中身で説明します。最初に全体像を示します。

flowchart TB
    A[送る人のメールソフト] -->|SMTP 587 認証あり| B[送信サーバー]
    B -->|DNS で MX を調べる| D[(DNS)]
    B -->|SMTP 25| C[受け取る側のサーバー]
    C --> M[(メールボックス)]
    M -->|POP3 か IMAP| R[受け取る人のメールソフト]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB の共用マシン）で、作業用フォルダーの Python 3.13.18 の仮想環境に aiosmtpd 1.4.6（SMTP サーバー）・dnslib 0.9.26（DNS サーバー）・dnspython 2.9.1・dkimpy 1.1.8・pyspf 2.0.14 を入れ、送信サーバー（127.0.0.1:5587、STARTTLS と認証が必須）と、example.net・example.org・example.com の受信サーバー（127.0.0.1 の 2525〜2527 番）、POP3 サーバー（127.0.0.1:1110、標準ライブラリで自作）、実験用のゾーンを返す DNS サーバー（127.0.0.1:5300）を動かしました。本物の配送では受信サーバーの 25 番ポートに届けますが、実験では 127.0.0.1 の別のポートに置き換えています。ドメインは説明用に予約された example.com・example.net・example.org だけを使いました。クライアントは curl 8.5.0（OpenSSL 3.0.13）と Python の smtplib、DNS の確認は Ubuntu の .deb を作業用フォルダーに展開した dig・nslookup 9.18.39、通信の確認は同じく展開した tcpdump 4.99.4（ループバックのみ）です。Gmail と Outlook の画面の手順、Gmail の送信者ガイドラインは Google と Microsoft の公式ヘルプ、ヘッダーの決まりは RFC で確かめました。図は mermaid-cli で描画を確かめています（確認日 2026年10月29日）。

Eメールとは（ふだんの意味とITの意味）

この節では、「Eメール」という言葉が指すものと、似た言葉（メール・電子メール・メッセージ・チャット）との違いが分かります。

Eメールは electronic mail（電子の郵便）の略で、インターネットにつながった機器どうしで、宛先のメールアドレスあてに文章やファイルを送る仕組みです。 日本語では「電子メール」、ふだんは単に「メール」と呼ぶことがほとんどです。ただ、「メール」という言葉は場面によって指すものが少しずつ違います。

Eメールのいちばんの特徴は、相手が同じサービスを使っていなくても届くことです。Gmail から会社のアドレスへ、会社のアドレスから携帯電話の会社のアドレスへ、と運営元が違っても届くのは、どのサーバーも SMTP という共通の約束ごとで話すからです。チャットのアプリは、同じアプリを使う人どうしでしかやり取りできないのがふつうです。

Eメールの送受信の仕組み（4つの登場人物）

この節では、送信ボタンを押してから相手が読むまでに、どの機械が何をしているのかが分かります。

Eメールの送受信には、メールソフト・送信サーバー・DNS・受信サーバーの4つが関わります。 手元の実験でも、この4つをそれぞれ別のプログラムとして動かしました。

手元の実験では、alice@example.com から bob@example.net・carol@example.net・dave@example.org の3人に1通送り、送信サーバーと受信サーバーのログを並べました。時刻はミリ秒までです。

11:17:05.870 [MSA] queued BCC7784528 from=<alice@example.com> rcpt=['bob@example.net', 'carol@example.net', 'dave@example.org'] size=317
11:17:05.873 [MSA] BCC7784528 example.net: MX 10 mx.example.net -> A 127.0.0.1
11:17:05.878 [MX example.net] 6E8D8F5634 from=<alice@example.com> to=['bob@example.net', 'carol@example.net'] spf=pass dkim=pass dmarc=pass saved
11:17:05.879 [MSA] BCC7784528 to=['bob@example.net', 'carol@example.net'] relay=mx.example.net[127.0.0.1] status=sent (8.9 ms)
11:17:05.881 [MSA] BCC7784528 example.org: MX 10 mx.example.org -> A 127.0.0.1
11:17:05.886 [MX example.org] 384215CED3 from=<alice@example.com> to=['dave@example.org'] spf=pass dkim=pass dmarc=pass saved
11:17:05.886 [MSA] BCC7784528 to=['dave@example.org'] relay=mx.example.org[127.0.0.1] status=sent (7.4 ms)

大事なのは、「送信完了」と表示された時点では、まだ相手に届いていないことです。送信サーバーが受け付けただけで、その後の配送で失敗すると、数秒から数日後に「届きませんでした」というメールが戻ってきます。この例は後の節で実物を示します。

メールアドレスの読み方とMXレコード

この節では、メールアドレスの @ の左右が何を表し、送信サーバーがどうやって宛先のサーバーを見つけるのかが分かります。

メールアドレスは「ユーザー名@ドメイン名」の形で、@ の右側（ドメイン）で届け先のサーバーを決め、左側（ユーザー名）で、そのサーバーの中の誰の箱かを決めます。

MX（Mail eXchanger）レコードは、DNS に登録する「このドメインあてのメールはこのサーバーへ」という情報です。実験用の DNS サーバーに dig で問い合わせると、次のように返りました。

$ dig @127.0.0.1 -p 5300 example.net MX +noall +answer +stats
example.net.		300	IN	MX	10 mx.example.net.
;; Query time: 4 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1) (UDP)

$ dig @127.0.0.1 -p 5300 mx.example.net A +short
127.0.0.1

$ dig @127.0.0.1 -p 5300 example.invalid MX | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35876

10 mx.example.net. の 10 は優先度で、数字が小さいサーバーから順に試します。MX を複数登録しておくと、1台が止まっていても別のサーバーで受け取れます。存在しないドメイン（example.invalid）は NXDOMAIN（そのような名前は無い）が返り、送信サーバーはこの時点で配送をあきらめます。アドレスの @ の右側を1文字打ち間違えると届かないのは、このためです。

DNS のレコードの種類全体は関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で、入力されたアドレスの形をプログラムで確かめる方法は関連記事「メールアドレスの正規表現｜実用パターンとチェックの注意点」で扱っています。

SMTPとは（Eメールを送る会話を実際に見る）

この節では、メールソフトと送信サーバーが SMTP でどんな言葉をやり取りしているのかを、実際の通信の記録で確かめられます。

SMTP（Simple Mail Transfer Protocol）は、メールを送る・中継するための約束ごとです。 決まりは RFC 5321 に書かれていて、クライアントが英単語のコマンドを送り、サーバーが3桁の数字と短い文で答える、という往復で進みます。curl の -v を付けて送ると、この会話がそのまま見えます（> が送ったコマンド、< がサーバーの答え）。

curl --noproxy '*' -v --ssl-reqd --cacert tls.crt \
  --resolve mail.example.com:5587:127.0.0.1 smtp://mail.example.com:5587 \
  --mail-from alice@example.com \
  --mail-rcpt bob@example.net --mail-rcpt carol@example.net --mail-rcpt dave@example.org \
  -u alice@example.com:alicepass -T m1.eml

< 220 mail.example.com Python SMTP 1.4.6
> EHLO m1.eml
< 250-mail.example.com
< 250-SIZE 33554432
< 250-8BITMIME
< 250-STARTTLS
< 250 HELP
> STARTTLS
< 220 Ready to start TLS
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
*  subject: CN=mail.example.com
*  SSL certificate verify ok.
> EHLO m1.eml
< 250-mail.example.com
< 250-SIZE 33554432
< 250-8BITMIME
< 250-AUTH LOGIN PLAIN
< 250 HELP
> AUTH PLAIN
< 334
> AGFsaWNlQGV4YW1wbGUuY29tAGFsaWNlcGFzcw==
< 235 2.7.0 Authentication successful
> MAIL FROM:<alice@example.com> SIZE=317
< 250 OK
> RCPT TO:<bob@example.net>
< 250 OK
> RCPT TO:<carol@example.net>
< 250 OK
> RCPT TO:<dave@example.org>
< 250 OK
> DATA
< 354 End data with <CR><LF>.<CR><LF>
< 250 2.0.0 Ok: queued as 8ECFED520D

sequenceDiagram
    participant C as メールソフト
    participant S as 送信サーバー
    C->>S: EHLO
    S-->>C: 250 STARTTLS
    C->>S: STARTTLS
    Note over C,S: ここから暗号化
    C->>S: AUTH PLAIN
    S-->>C: 235 認証成功
    C->>S: MAIL FROM / RCPT TO
    C->>S: DATA（ヘッダーと本文）
    S-->>C: 250 queued

応答の3桁の数字は、最初の1桁で意味が分かれます。2 で始まれば成功、3 は「続きを送って」、4 は一時的な失敗（あとで再送する）、5 は恒久的な失敗（送り直しても同じ）です。2.7.0 や 5.1.1 のような点で区切られた数字は、失敗の理由をさらに細かく示す拡張ステータスコードです。

ここで1つ注意があります。AUTH PLAIN の後に送った AGFsaWNl… は暗号ではありません。Base64 という、データを英数字に置き換えるだけの書き方です。

$ echo AGFsaWNlQGV4YW1wbGUuY29tAGFsaWNlcGFzcw== | base64 -d | od -c
0000000  \0   a   l   i   c   e   @   e   x   a   m   p   l   e   .   c
0000020   o   m  \0   a   l   i   c   e   p   a   s   s

だれでも元に戻せるので、パスワードを守っているのは、その前の STARTTLS による暗号化です。実験の送信サーバーは、暗号化する前の送信を断る設定にしてあります。STARTTLS を使わずに送ると、次のように止められました。

> MAIL FROM:<alice@example.com> SIZE=317
< 530 Must issue a STARTTLS command first
* MAIL failed: 530

プログラムからメールを送るコードは関連記事「Python smtplibでメール送信｜添付・HTML・Gmail対応コード」で扱っています。この記事は、その裏で動いている仕組みの説明に絞ります。

POP3とIMAPとは（Eメールを受け取る仕組み）

この節では、受信サーバーにしまわれたメールを、メールソフトがどうやって取りに来るのかと、POP3 と IMAP の違いが分かります。

SMTP は「送る・運ぶ」だけで、受け取る人がメールを読むときは POP3 か IMAP を使います。 POP3 は「メールを端末に取り込む」考え方、IMAP は「メールはサーバーに置いたまま、どの端末からでも同じ状態で見る」考え方です。手元では POP3 のサーバーを自作し、curl で bob の箱を開きました。

$ curl --noproxy '*' -v pop3://127.0.0.1:1110/ -u bob:bobpass
< +OK POP3 server ready (t223 lab)
> CAPA
< +OK
< USER
< UIDL
< TOP
< .
> USER bob
< +OK
> PASS bobpass
< +OK 1 messages
> LIST
< +OK 1 messages
1 1500

POP3 の答えは +OK（成功）か -ERR（失敗）の2種類で、SMTP より単純です。LIST で「1番のメールが 1,500 バイト」と分かり、RETR 1 で中身を取り出します。送ったときは 317 バイトだったメールが、届いたときは 1,500 バイトに増えていました。増えた分は、途中のサーバーが付け足したヘッダーです（次の次の節で中身を読みます）。

スマートフォンとパソコンの両方で同じメールを読む今の使い方では、IMAP を選ぶのが一般的です。ブラウザで読む Gmail や Outlook.com のような Webメールは、メールソフトの代わりにブラウザの画面で、サーバーに置いたメールを直接見る形です。

ポート番号と暗号化（STARTTLSとSSL/TLS）

この節では、メールの設定画面に出てくるポート番号（25・587・465・110・995・143・993）と、「SSL/TLS」「STARTTLS」の意味が分かります。

メールの通信は、用途ごとに使うポート番号が決まっています。メールソフトの設定で迷いやすいのは、送信の 587 と 465、受信の 995 と 993 です。

メールソフトの設定画面で「SSL/TLS」と書かれていれば接続した瞬間から暗号化する方式（465・993・995）、「STARTTLS」と書かれていれば平文で接続してから暗号化に切り替える方式（587・143）を指すことが多いです。どちらも、正しく設定すれば中身は暗号化されます。家庭の回線から外のサーバーの 25 番へ直接送ることは、多くのプロバイダーが迷惑メール対策として制限しているため、メールソフトの送信には 587 か 465 を使います。

Gmail の公式ヘルプ（POP を使用して他のメール クライアントで Gmail のメールを読む）では、送信サーバーを smtp.gmail.com、TLS/STARTTLS のポートを 587、受信の POP サーバーを pop.gmail.com のポート 995 と案内しています。ほかのサービスの値は、それぞれの公式ヘルプで確かめるのが確実です。

暗号化は「区間ごと」

手元で tcpdump を使い、ループバックを流れたデータを記録しました。メールソフトから送信サーバー（5587番、STARTTLS あり）の区間と、送信サーバーから受信サーバー（2525番、実験では暗号化なし）の区間を比べています。

--- 5587番（メールソフト → 送信サーバー）で読めた文字
EHLO m1.eml
STARTTLS
220 Ready to sta
（この後の AUTH・MAIL FROM・本文は暗号化されて読めない）

--- 2525番（送信サーバー → 受信サーバー）で読めた文字
ehlo mail.example.com
mail from:<alice@example.com>
rcpt to:<bob@example.net>
rcpt to:<carol@example.net>
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: =?UTF-8?B?5L2c5qWt44Gu44GU6YCj57Wh?=
（本文の「ボブさん」も UTF-8 のまま記録に残っていた）

メールソフトと送信サーバーの間を暗号化しても、その先のサーバーどうしの区間が暗号化されなければ、その区間では中身が読める状態で流れます。今の大手のメールサービスはサーバーどうしでも STARTTLS を使うのが一般的ですが、相手が対応していなければ暗号化なしで届けることもある仕組みです。送ってから読まれるまでずっと中身を守りたい場合は、S/MIME や PGP のようにメールそのものを暗号化する方法か、パスワード付きのファイル共有サービスなど、別の手段を選びます。

ポート番号全体は関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

Eメールのヘッダーの読み方（届いた実物）

この節では、届いたメールの「ヘッダー」に何が書かれているのかと、Received を下から上へ読む理由が分かります。

Eメールは「ヘッダー（宛先・件名・経路などの情報）」と「本文」でできていて、その間は空行1つで区切られます。 形式の決まりは RFC 5322 にあります。dave が POP3 で受け取ったメールを、そのまま載せます（DKIM の署名の長い値は途中で省きました）。

Return-Path: <alice@example.com>
Delivered-To: dave@example.org
Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=alice@example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Received: from mail.example.com (localhost [127.0.0.1])
	by mx.example.org (aiosmtpd) with ESMTP id 384215CED3
	for <dave@example.org>; Sat, 31 Oct 2026 11:17:05 +0900
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com;
 i=@example.com; q=dns/txt; s=s1; t=1793413025; h=from : to : subject :
 date : message-id; bh=BUryClX4axqwqAg4js5wByxoqsKuaP0EM5P9qtHK1M0=;
 b=ZzF7gw6srOHW3dEwETtWxdWjiy1iRFSZvIbRzmWXHq2DxVstxAwA0ZY7RySCYJpXtTsX0
 （省略）
Received: from m1.eml (localhost [127.0.0.1])
	by mail.example.com (aiosmtpd) with ESMTPSA id BCC7784528
	; Sat, 31 Oct 2026 11:17:05 +0900
Message-ID: <BCC7784528@mail.example.com>
Date: Sat, 31 Oct 2026 11:17:05 +0900
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Cc: Carol <carol@example.net>
Subject: =?UTF-8?B?5L2c5qWt44Gu44GU6YCj57Wh?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

ボブさん、キャロルさん
明日の打ち合わせは10時からです。

送ったときのヘッダーは From から Content-Transfer-Encoding までの8行だけでした。それより上は、すべて途中のサーバーが付け足したものです。サーバーは自分の記録をいちばん上に足していくので、Received は下から上へ読むと、通った順番になります。

1. 1いちばん下の Received：送信サーバーが受け付けたwith ESMTPSA の「SA」は、暗号化（S）と認証（A）ありで受け付けたという意味
2. 2DKIM-Signature：送信サーバーが電子署名を付けたd=example.com のドメインが署名したという印
3. 3上の Received：受信サーバー mx.example.org が受け取ったfrom mail.example.com から、for <dave@example.org> あてに
4. 4Authentication-Results：受信サーバーが送信元を確かめた結果spf・dkim・dmarc がすべて pass
5. 5Delivered-To・Return-Path：箱にしまうときに付けた実際に届けた宛先と、エラーの戻り先

件名の =?UTF-8?B?5L2c5qWt44Gu44GU6YCj57Wh?= は、「UTF-8 の文字を Base64（B）で書いた」という意味の書き方（RFC 2047）です。Python で戻すと「作業のご連絡」になりました。ヘッダーは英数字で書くという昔からの決まりがあるため、日本語の件名はこの形に変換して運ばれ、メールソフトが表示するときに元へ戻します。

Received に並ぶ時刻を比べると、どのサーバーで時間がかかったかも分かります。「メールが遅れて届いた」ときは、隣り合う Received の時刻の差がいちばん大きいところが、待たされた場所です。

To・Cc・BccとBccが受信者に見えない理由

この節では、To・Cc・Bcc の使い分けと、Bcc の宛先が他の受信者に見えない仕組みを、実際に送ったメールで確かめられます。

メールの宛先には「封筒に書く宛先（エンベロープ）」と「便せんに書く宛先（ヘッダーの To・Cc）」の2種類があります。サーバーが実際に配る先を決めるのは封筒のほう、つまり SMTP の RCPT TO です。 Bcc の人は封筒にだけ書かれ、便せんには書かれないので、他の受信者から見えません。

Python の smtplib の send_message() で、To に bob、Bcc に dave を入れて送り、実際に送られた SMTP のコマンドを記録しました。

send: 'mail from:<alice@example.com> size=213\r\n'
send: 'rcpt to:<bob@example.net>\r\n'
send: 'rcpt to:<dave@example.org>\r\n'
send: 'data\r\n'
send: b'From: Alice <alice@example.com>\r\nTo: Bob <bob@example.net>\r\nSubject: =?utf-8?b?QmNj44Gu56K66KqN?=\r\n...'

RCPT TO（封筒）には bob と dave の2人が並んでいますが、DATA で送ったヘッダーには Bcc の行がありません。send_message() が Bcc の行を取り除いてから送ったためです。届いたメールのヘッダーを比べました。

== bob が受け取ったヘッダー
Return-Path: <alice@example.com>
Delivered-To: bob@example.net
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: =?utf-8?b?QmNj44Gu56K66KqN?=

== dave（Bcc）が受け取ったヘッダー
Return-Path: <alice@example.com>
Delivered-To: dave@example.org
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: =?utf-8?b?QmNj44Gu56K66KqN?=

bob のメールには dave の名前がどこにもありません。dave のメールは To が bob のままで、dave 自身のアドレスは受信サーバーが付けた Delivered-To にだけ出ています。Bcc で受け取ったメールの To や Cc に自分の名前が無いのはこのためで、故障ではありません。 RFC 5322 の 3.6.3 節も、Bcc の行を取り除いて送る使い方を最初に挙げています。

Bcc の行を残したまま送ると見えてしまう

反対に、プログラムでメールを組み立て、Bcc の行を残したまま本文ごと送ると、全員に Bcc の宛先が見えてしまいます。同じメールを sendmail() にそのまま渡して試すと、bob のメールに次の行が残りました。

== 誤った送り方：bob が受け取ったヘッダー
Delivered-To: bob@example.net
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: =?utf-8?b?QmNj44Gu56K66KqN?=
Bcc: dave@example.org

添付ファイルと文字化けの仕組み（MIME・Base64）

この節では、添付ファイルがメールの中でどう運ばれ、なぜ元のファイルより大きくなるのかが分かります。

メールはもともと文字だけを運ぶ仕組みなので、画像や PDF のようなファイルは、MIME という決まりで本文と区切り、Base64 で英数字に置き換えてから運びます。 Base64 は3バイトを4文字にするため、それだけで約 1.33 倍になり、さらに 76 文字ごとの改行が加わります。手元で、ランダムなデータを添付して送り、送信サーバーが受け取ったメール全体の大きさを測りました。

小さいファイルほど倍率が大きいのは、ヘッダーや MIME の区切りの分が目立つからです。大きなファイルでは約 1.37 倍に落ち着きました。メールサービスの「添付は○MBまで」という上限は、元のファイルではなく変換後のメール全体の大きさで数えられることが多いため、上限ぎりぎりのファイルは届かないことがあります。 実験でも、140,000 バイトのファイルは届き、300,000 バイトのファイルは受信サーバーの上限（200,000 バイト）を超えて拒否されました。

文字化けは、送る側と受け取る側で文字コードの解釈が食い違うと起きます。今のメールは本文を UTF-8 で書き、ヘッダーの Content-Type: text/plain; charset=UTF-8 で「この本文は UTF-8」と伝えるのが一般的です。古くからの日本語のメールでは ISO-2022-JP（JIS）が使われてきたため、以前のシステムとやり取りするときは、この charset の値を確かめると原因が見つかります。

SPF・DKIM・DMARCとは（送信元を確かめる仕組み）

この節では、届いたメールが本当にそのドメインから送られたのかを、受け取る側がどう確かめているのかを、考え方と判定の実物で理解できます。

SMTP には、差出人のアドレスが本物かを確かめる仕組みがもともとありません。そこで、ドメインの持ち主が DNS に「正しい送り方」を公開し、受け取る側がそれと照らし合わせる仕組みが加えられました。それが SPF・DKIM・DMARC です。

実験用の DNS には、example.com の3つのレコードを次のように登録しました。

$ dig @127.0.0.1 -p 5300 example.com TXT +short
"v=spf1 ip4:127.0.0.1 -all"
$ dig @127.0.0.1 -p 5300 _dmarc.example.com TXT +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
$ dig @127.0.0.1 -p 5300 s1._domainkey.example.com TXT +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAniJ6sf480SoLpY0FuADUdynPlxW..."

受信サーバーが届いたメールで判定した結果が、先ほどのヘッダーの Authentication-Results の行です。さらに、届いたメールの一部を書き換えたとき、DKIM の判定がどう変わるかを dkimpy で確かめました。SPF は、送ってきたサーバーの IP アドレスを変えたときの判定を pyspf で見ています。

届いたまま           : True
本文の10時を11時に   : False
Subjectを書き換え    : False
Receivedを1行追加    : True
SPF 送信元IP 127.0.0.1  : ('pass', 'sender SPF authorized')
SPF 送信元IP 192.0.2.10 : ('fail', 'SPF fail - not authorized')
SPF example.net(レコードなし): ('none', '')

本文の「10時」を「11時」に変えただけで、DKIM の署名は合わなくなりました。署名の対象にした Subject を変えても同じです。一方で、途中のサーバーが Received を足すのは配送の決まりどおりの動きなので、署名の対象に入っておらず、判定は変わりません。SPF は、一覧にない IP アドレスからの送信を fail と判定し、レコードを公開していないドメインは none（判定できない）になりました。

Gmail の公式ヘルプ「メール送信者のガイドライン」では、2024年2月1日以降、Gmail アカウントに送るすべての送信者に SPF か DKIM の設定と TLS 接続の使用を、1日あたり 5,000 件を超えて送る送信者には SPF と DKIM の両方と DMARC の設定を求めています。会社のドメインからお知らせメールを送る場合は、この3つが設定されているかを最初に確かめると、届かない原因を減らせます。

自分のドメインの MX や TXT（SPF・DMARC）を調べる方法は、関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

Eメールが届かないとき（エラーと戻ってくるメール）

この節では、メールが届かないときに表示されるエラーや、戻ってきたメール（バウンスメール）の読み方が分かります。

配送に失敗すると、送信サーバーは差出人（Return-Path の宛先）に「Undelivered Mail Returned to Sender」のような件名のメールを送り返します。中に書かれた3桁の数字と英文が、原因の手がかりです。 手元で、存在しないユーザーあてに送ったときに戻ってきたメールです。

Return-Path: <>
Delivered-To: alice@example.com
From: MAILER-DAEMON@mail.example.com (Mail Delivery System)
To: alice@example.com
Subject: Undelivered Mail Returned to Sender

メール 1B033045C3 を次の宛先に届けられませんでした。

<zed@example.net>: 550 5.1.1 <zed@example.net>: Recipient address rejected: User unknown in local recipient table

戻ってきたメールの Return-Path が <>（空）になっているのは、エラーのメールがさらに届かなかったときに、エラーのやり取りが繰り返されないようにするためです。手元で起こしたエラーの原文をまとめます。

[送信サーバーのログ]
status=bounced (550 5.1.1 <zed@example.net>: Recipient address rejected: User unknown in local recipient table)
status=bounced (552 Error: message size exceeds fixed maximum message size)
status=bounced (Host or domain name not found. Name service error for name=nonexistent.invalid type=MX)

[メールソフト側で出たエラー]
SMTPAuthenticationError: 535 5.7.8 Authentication credentials invalid
< 530 Must issue a STARTTLS command first
< 554 5.7.1 <dave@example.org>: Relay access denied
curl: (7) Failed to connect to 127.0.0.1 port 2599 after 0 ms: Couldn't connect to server
curl: (60) SSL: certificate subject name 'mail.example.com' does not match target host name '127.0.0.1'
< -ERR [AUTH] Authentication failed.
curl: (67) Access denied. -

とくに 554 の Relay access denied は、受信サーバーが「自分の担当ではないドメインあてのメールは、認証の無い相手からは中継しない」と断った結果です。だれのメールでも中継してしまうサーバー（オープンリレー）は迷惑メールの踏み台にされるため、今のメールサーバーはこのように断る設定が基本です。

• 1宛先のアドレスを1文字ずつ見直す@ の右側の誤りは Host not found、左側の誤りは 550 User unknown になる
• 2戻ってきたメールの3桁の数字を見る4 で始まれば一時的（自動で再送されることが多い）、5 で始まれば送り直しても同じ
• 3添付の合計を約 1.37 倍で見積もる上限ぎりぎりなら、ファイル共有のリンクに切り替える
• 4相手の迷惑メールフォルダーを確かめてもらうエラーが戻らないのに届かないときは、受け取った側で振り分けられていることが多い

自分で確かめる（ヘッダーとMXを見る手順）

この節では、手元のメールソフトやターミナルで、ここまでの内容を自分のメールで確かめる手順が分かります。

ヘッダーは、ほとんどのメールサービスで「元のメッセージ」「ソース」「メッセージの詳細」として表示できます。 Google と Microsoft の公式ヘルプに書かれている手順は次のとおりです。

もう1つは、ターミナル（Windows のコマンドプロンプト・PowerShell、Mac・Linux のターミナル）で、ドメインの MX を調べる方法です。nslookup はどの OS にも入っています。手元では実験用の DNS サーバーに問い合わせるため、サーバーとポートを指定しました。

$ nslookup -port=5300 -type=mx example.net 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#5300

example.net	mail exchanger = 10 mx.example.net.

自分の会社のドメインで調べるときは、nslookup -type=mx の後にドメイン名だけを付けて実行します（ふだん使っている DNS サーバーに問い合わせます）。mail exchanger = の行が出れば、そのドメインあてのメールの届け先が登録されています。何も出なければ、そのドメインではメールを受け取れない設定です。同じように -type=txt を付けると、SPF（v=spf1 で始まる行）が公開されているかも確かめられます。

Webメール・メールソフト・チャットの使い分け判断表

この節では、Eメールの読み方（Webメール・メールソフト）と受信の方式、チャットとの使い分けを、場面ごとに選べます。

迷ったら「複数の端末で読むか」「社外とやり取りするか」「記録を残すか」の3つで決めます。 次の表は、手元で確かめた仕組みと公式の情報をもとにした目安です。

よくある質問

Q. Eメールとメールは違うものですか？ A. 同じものを指すことがほとんどです。「Eメール」「電子メール」は、紙の郵便や SMS と区別したいときに使われる呼び名で、ふだんは単に「メール」と呼ばれます。

Q. 送信済みになったのに相手に届いていないのはなぜですか？ A. 「送信済み」は、送信サーバーが受け付けたという意味で、相手に届いたという意味ではありません。その後の配送で失敗するとエラーのメールが戻ってきます。エラーが戻らないときは、相手の迷惑メールフォルダーに振り分けられていることが多いです。

Q. Bcc で送ったことは相手に分かりますか？ A. To・Cc の受信者には分かりません。Bcc の行は送る前に取り除かれるためです。Bcc で受け取った人は、To や Cc に自分の名前が無いことから、Bcc で受け取ったと分かります。

Q. POP3 と IMAP はどちらを選べばよいですか？ A. スマートフォンとパソコンなど複数の端末で読むなら IMAP が向いています。1台の端末に取り込んで保存したいときは POP3 です。迷ったら IMAP を選ぶのが一般的です。

Q. 送信サーバーのポートは 587 と 465 のどちらですか？ A. どちらも、メールソフトから送るためのポートです。587 は接続してから STARTTLS で暗号化し、465 は接続した瞬間から暗号化します。使っているサービスの公式ヘルプが案内する組み合わせ（ポートと暗号化の方式）を、そのまま設定します。

Q. メールは暗号化されていますか？ A. 今の多くのサービスでは、メールソフトとサーバーの間やサーバーどうしの通信が TLS で暗号化されています。ただし区間ごとの暗号化なので、サーバーの中では読める状態です。中身を最後まで守るには S/MIME や PGP などを使います。

Q. ヘッダーの Received はどう読みますか？ A. 下から上へ読みます。サーバーは自分の記録をいちばん上に足していくため、いちばん下が最初に通ったサーバー、いちばん上が最後に受け取ったサーバーです。

Q. SPF・DKIM・DMARC は個人のメールでも設定が要りますか？ A. Gmail や Outlook.com などのアドレスを使う場合は、サービス側が設定しています。自分や会社でドメインを持ってメールを送る場合に、そのドメインの DNS に設定します。

Q. 添付ファイルが送れないのはなぜですか？ A. 添付ファイルは Base64 に変換されて約 1.37 倍の大きさになり、送る側か受け取る側の上限を超えると拒否されます。手元の実験でも、300,000 バイトのファイルが 411,110 バイトのメールになり、上限 200,000 バイトのサーバーで 552 のエラーになりました。

Q. 件名の =?UTF-8?B?…?= という文字は何ですか？ A. 日本語の件名を英数字だけで運ぶための書き方です。メールソフトは表示するときに元の日本語へ戻します。ヘッダーを直接見たときにだけ、この形で見えます。

まとめ

• Eメールは、メールアドレスあてに文章やファイルを届ける仕組み。送るときは SMTP、受け取るときは POP3 か IMAP を使い、運営元が違っても届く。
• 送信サーバーは @ の右側のドメインで DNS の MX を調べ、受信サーバーへ渡す。「送信完了」は受け付けられただけで、届いたことではない。
• 宛先には封筒（RCPT TO）と便せん（To・Cc）の2種類がある。Bcc は封筒にだけ書き、ヘッダーから取り除くので他の受信者に見えない。
• ヘッダーの Received は下から上へ読む。Authentication-Results で SPF・DKIM・DMARC の判定が分かり、本文を1文字変えただけで DKIM は fail になった。
• 届かないときは戻ってきたメールの3桁の数字を見る。550 は宛先、552 は大きさ（添付は約 1.37 倍）、535 は認証、554 は中継の拒否。

次に読むとよい記事です。プログラムからメールを送る方法は関連記事「Python smtplibでメール送信｜添付・HTML・Gmail対応コード」で、MX や TXT の調べ方は関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• RFC 5321「Simple Mail Transfer Protocol」：https://www.rfc-editor.org/rfc/rfc5321
• RFC 5322「Internet Message Format」（3.6.3 Destination Address Fields）：https://www.rfc-editor.org/rfc/rfc5322
• RFC 6409「Message Submission for Mail」：https://www.rfc-editor.org/rfc/rfc6409
• RFC 8314「Cleartext Considered Obsolete: Use of TLS for Email Submission and Access」：https://www.rfc-editor.org/rfc/rfc8314
• RFC 1939「Post Office Protocol - Version 3」：https://www.rfc-editor.org/rfc/rfc1939
• RFC 9051「Internet Message Access Protocol (IMAP) - Version 4rev2」：https://www.rfc-editor.org/rfc/rfc9051
• RFC 7208（SPF）・RFC 6376（DKIM）・RFC 7489（DMARC）：https://www.rfc-editor.org/rfc/rfc7208 ／ https://www.rfc-editor.org/rfc/rfc6376 ／ https://www.rfc-editor.org/rfc/rfc7489
• Gmail ヘルプ「メール送信者のガイドライン」：https://support.google.com/a/answer/81126?hl=ja
• Gmail ヘルプ「詳細ヘッダーからメールの経路を確認する」：https://support.google.com/mail/answer/29436?hl=ja
• Gmail ヘルプ「POP を使用して他のメール クライアントで Gmail のメールを読む」：https://support.google.com/mail/answer/7104828?hl=ja
• Microsoft サポート「Outlook でインターネット メッセージ ヘッダーを表示する」：https://support.microsoft.com/ja-JP/Outlook/view-internet-message-headers-in-outlook
• 総務省「国民のためのサイバーセキュリティサイト　電子メールの仕組み」：https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/basic/service/04/
• aiosmtpd（PyPI）：https://pypi.org/project/aiosmtpd/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。