自己ホスト型アプリからメールを送信する方法

自己ホスト型アプリケーションでメール送信に必要なもの

自己ホスト型アプリケーションからメールを送信するために、メールサーバーは必要ありません。必要なのはリレーです。ホスト上で一度だけ設定した認証済みの SMTP アカウントに、同じホスト上のすべてのアプリケーションが送信メールを渡します。メールボックスを運用することが難しい作業であり、これは別の問題です。

メールを受信するには、インターネット全体から port 25 への接続を受け入れ、スパムをフィルタリングし、メールボックスを保存してバックアップし、サーバーが存在する限り IP レピュテーションを維持する必要があります。この作業は確実に難しくなっています。メールを送信する場合は、パスワードリセット、サインアップ確認、「バックアップに失敗しました」というアラート、フォーラム返信の通知などを扱います。これらは短い低頻度のメールで、1 通ずつ送信されます。リレーで処理でき、設定も半日程度で完了します。

実際に解決しようとしているのが、2 つのうちどちらなのかを決めてください。自分でメールボックスを運用する価値がまだあるかは、明確な答えのある現実的な問題です。ほとんどの人にとって、答えは「いいえ」です。答えが「はい」なら、VPS 上で完全な Mailcow メールサーバーを運用することが正攻法です。もう一方のメール送信は、ほぼすべての人に必要でありながら、ほとんど誰も事前に計画していません。

まず、2 つの用語を確認します。SMTP (simple mail transfer protocol) は、この仕組みのすべての部分で使用するプロトコルです。リレ​​ーは smarthost とも呼ばれ、認証済みのメールを受け取り、自身のアドレスとレピュテーションを使って宛先へ配送するサーバーです。

VPS がポート 25 でメールを送信できない理由

ほぼすべての VPS プロバイダーは、デフォルトで送信 TCP ポート 25 をブロックします。ポート 25 はメールサーバー同士が通信するために使用するポートです。そのため、送信ポート 25 が開いた侵害済みの VPS は、すべての受信メールサーバーへスパムを直接送信できます。プロバイダーは接続を拒否する代わりに、これらのパケットを破棄します。そのため、エラーが返るのではなく、接続がハングしてタイムアウトする症状になります。

サーバーからテストします。

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

最初のコマンドが 5 秒間そのまま待機し、2 番目のコマンドがすぐに応答する場合、ブロックされていることが確認できます。アカウント審査後にブロックを解除するプロバイダーもあります。解除しないプロバイダーが大半です。

ブロックされていることが、リレーを使用する主な理由ではありません。ポート 25 が開いていても、新しく割り当てられた VPS のアドレスから直接送信したメールは、スパムフォルダーに入るか、完全に拒否されます。そのアドレスには送信実績がなく、受信側からホスティング用アドレスの範囲と見なされるネットワークに属しているためです。Google の送信者向けガイダンスでは、送信 IP に正引き DNS と逆引き DNS が正しく設定されていることを求めています。また、多くの VPS アドレスには、変更できない汎用的な PTR（pointer）レコードが設定されています。リレーを使用すると、すでに送信実績のあるアドレスを利用できます。

送信用ポートを使用すれば解決できます。ポート 587 は STARTTLS に対応しています。セッションは平文で開始し、その後暗号化へ切り替わります。ポート 465 は暗黙的 TLS（transport layer security）に対応しています。こちらは最初のバイトからセッションが暗号化されます。どちらも認証済みクライアント向けのポートです。どちらも VPS ネットワークでは開放されており、使用するリレーは少なくとも一方に対応しています。

リレーと送信用サブドメインを選ぶ

トランザクションメールのプロバイダーは多数ありますが、基本的な役割は同じです。次の4点で評価します。

• SMTP AUTH に対応した submission ポート（587 または 465）
• プロバイダー独自のドメインだけでなく、自分のドメインと自分の selector で DKIM 署名できること
• ダッシュボードまたは webhook で確認できる、バウンスと苦情のデータ
• 送信量に合った料金プラン。2026年8月時点でも、月数千通を無料で含むプロバイダーが複数あります。ただし、条件は頻繁に変わるため、ブログ記事ではなく最新の料金ページを確認してください

アプリケーションのメールはサブドメインから送信します。example.com の代わりに、notify.example.com のようなものを使用します。受信側はドメインごとにレピュテーションを評価するため、アプリケーションからの送信状態が悪化しても、請求書やチームのメールに使用するドメインへの影響を避けられます。ただし、限界もあります。一部の受信側では、サブドメインのシグナルを組織ドメインに集約します。そのため、サブドメインは影響を抑えますが、完全に切り離すものではありません。

セルフホストアプリごとにリレーを1回だけ設定する

各アプリの設定画面を開き、SMTP ホスト、ユーザー名、パスワードを貼り付ける方法は簡単に見えます。Nextcloud、フォーラム、Grafana、Vaultwarden、稼働監視ツールには、すべてその入力欄があります。この方法では、認証情報が6か所、6種類の形式で保存されます。そのうちのいくつかは、設定ではなくデータとしてバックアップするデータベース内に保存されます。パスワードをローテーションすると、5か所を更新することになります。6か所目は送信を停止します。しかも、多くの場合は静かに停止します。アプリの大半はSMTPエラーをサーバー側のログに記録するだけで、ユーザーには成功ページを表示するためです。

代わりにホスト上で1回だけ設定し、アプリからローカルに送信させます。この用途に適したツールは2つあります。どちらを選ぶかは、キューが必要かどうかで決まります。

msmtp はデーモンを持たない sendmail 互換クライアントです。接続して送信し、終了します。キューを持たないため、リレーに到達できない場合はメッセージが失われ、呼び出し元のアプリには0以外の終了ステータスが返ります。

Postfix を satellite として設定すると、実際のキューを持つ完全なメール転送エージェントになります。メッセージを即座に受け付け、障害時には数日間再試行し、リレーの認証情報を root のみが読めるファイルに保存します。リレー障害中にアラートを失うことが問題になる場合や、複数のアプリを異なるシステムユーザーで実行する場合に使用してください。

msmtp、小規模な選択肢

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta は /usr/sbin/sendmail シンボリックリンクをインストールします。そのため、sendmail を呼び出すプログラムは、msmtp の存在を意識せずに msmtp へ到達できます。

/etc/msmtprc を作成します。

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on は常に From ヘッダーを設定し、既存の From ヘッダーを上書きします。そのため、アプリが生成した値は from のアドレスに置き換えられます。これを設定しない場合、cron ジョブは root@your-hostname として送信します。しかし、そのアドレスは検証済みではないため、リレーは拒否します。syslog on はログを syslog 経由で送信するため、journalctl -t msmtp で確認できます。共有の logfile パスを使う方法もありますが、メールを送信するすべてのユーザーに書き込み権限が必要です。複数ユーザーのホストでは問題になりやすい設定です。

権限は自分で設定します。msmtp はユーザー単位の設定ファイル（~/.msmtprc）では権限を強制し、contains secrets and therefore must have no more than user read/write permissions の状態では実行を拒否します。一方、/etc/msmtprc には権限を強制しません。読み取り可能であれば、そのファイルを読み込むだけです。

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v はSMTPの通信全体を表示します。そのため、リレーからの各応答を確認できます。送信が成功すると、最後にメッセージを受け付ける 250 応答が表示されます。authentication failed という行は、ユーザー名またはパスワードが間違っているか、リレーがアカウントパスワードの代わりにAPIキーを要求していることを示します。

ここで注意が必要です。多くの人が Postfix に移行する理由もここにあります。モードを600、所有者を root にすると、root だけが送信できます。www-data として実行されるアプリはファイルを読み取れません。msmtp はそのファイルをスキップし、アプリはデフォルトアカウントが見つからないというエラーで失敗します。解決策はグループを作ることです。

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

これは明確に理解しておく必要があります。mail グループのメンバーは全員、リレーのパスワードを読み取り、そのホストからドメインのアドレスとしてメールを送信できます。自分だけで管理する VPS であれば許容できます。自分が作成していない複数のアプリを異なるユーザーで実行する環境では適切ではありません。その場合は Postfix の方が適しています。アプリが認証情報を目にすることがないためです。

Postfix を satellite として使用する

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules は必須です。これがないと、/usr/lib/sasl2 に PLAIN および LOGIN メカニズムのライブラリがインストールされていないため、Postfix は warning: SASL authentication failure: No worthy mechs found をログに記録します。

残りの設定は postconf -e で行います。これは /etc/postfix/main.cf を直接編集します。

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

リレーホスト名を角括弧で囲むと、Postfix はその名前の MX レコードを検索せず、名前に直接接続します。リレーホスト名によっては、別の場所を指す MX レコードを公開していることがあります。角括弧がないと、メールがそのレコードに従って誤ったサーバーへ送信されます。

smtp_tls_security_level = encrypt はTLSを必須にするため、メッセージが平文で送信されることはありません。ただし、証明書は検証しません。Postfix のドキュメントにも明記されているとおり、このレベルでは、サーバー証明書が信頼されていない場合や名前が一致しない場合でも配送が続行されます。証明書を検証する場合は verify または secure を使用し、smtp_tls_CAfile を有効なままにしてください。

認証情報は root のみが読める1つのファイルに保存します。

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap は、Postfix が実際に読み取るインデックス付きコピーを作成します。後でテキストファイルを編集して postmap を忘れると、Postfix は古いデータベースを使い続けます。ログにはそのことを示す情報が記録されません。Postfix 3.9 以降では、デフォルトのマップタイプが lmdb です。これを使用する場合は、パラメーターと postmap 引数の両方に lmdb: と記述してください。両方の行でタイプを指定すると、設定の不一致を防げます。

アプリは引き続き、メールを root@hostname として指定します。送信者を書き換えます。

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

regexp: テーブルは直接読み取られるため、postmap は必要ありません。これで、すべてのメッセージが同じエンベロープ送信者と同じ From ヘッダーで送信されます。これはリレーが要求する形式です。ただし、返信はすべて1か所に届きます。人が返信を受け取る必要がある場合は、各アプリ内で Reply-To ヘッダーを設定してください。

テストを送信し、ログを確認します。

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

配送されたメッセージには、status=sent に続いて、角括弧内にリレー自身の応答が記録されます。それ以外の内容には理由が示されます。Connection timed out とともに status=deferred が表示される場合、まだ何かがポート25を指しています。Host or domain name not found. Name service error for name=smtp.relay.example type=A は、リレーホスト名が間違っているか、そのホストでDNSが機能していないことを示します。mailq は滞留しているメッセージを一覧表示し、sudo postqueue -f はすぐに再試行します。

Docker コンテナからホストのリレーに接続する

コンテナからホストの sendmail を呼び出すことはできません。イメージ内にバイナリがなく、キューも共有されていないためです。代わりに、コンテナへネットワーク上の接続先を指定します。Postfix は Docker ブリッジのアドレスで待ち受けられます。

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

最初のコマンドで自分のブリッジアドレスを確認し、その値を使用してください。この値をそのままコピーしないでください。Compose プロジェクトは別のサブネット上に専用ネットワークを作成し、docker network inspect <name> がそのアドレスを表示するためです。ここでは reload ではなく restart を使用してください。Postfix のドキュメントでは、inet_interfaces を変更した後は停止してから起動する必要があると説明されています。reload では変更が反映されません。各アプリには SMTP ホストとして 172.17.0.1、ポート 25、認証なし、TLS なしを設定します。この通信はホストの外部へ出ないためです。サービスが Compose ネットワーク上にある場合は、VPS で Docker Compose を実行する方法で、そのサブネットがどこから来るかを確認できます。

ここは特に注意が必要な手順です。Postfix が公開アドレスで待ち受け、mynetworks の範囲が広いと、オープンリレーになります。第三者があなたのリレーアカウント経由でメールを送信し、プロバイダーによってアカウントが停止され、ドメインの評価も数か月にわたって損なわれる可能性があります。変更するたびに、両方の側を確認してください。

ss -tlnp | grep ':25'

出力にはループバックアドレスとブリッジアドレスだけが表示される必要があります。別のマシンからは、nc -vz your.server.ip 25 が失敗しなければなりません。

送信ドメインの SPF、DKIM、DMARC

最初の実送信前に、3 つすべてのレコードを公開します。いずれも無料で、DNS に設定し、受信側が最初に確認する情報です。

SPF（sender policy framework）は、エンベロープ送信者にドメインを指定できる送信元を一覧にします。送信サブドメインに公開します。

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

include: の値は、リレー自身の設定ページからコピーします。解決できない include を設定すると、pass ではなく永続的なエラーになるためです。SPF の評価は、DNS クエリを発生させるメカニズムが 10 個に達すると停止し、permerror を返します。受信側はこれを失敗として扱うため、include は少数に抑えます。名前ごとに v=spf1 レコードを正確に 1 つだけ公開します。2 つ設定すると、それも permerror になります。

DKIM（domainkeys identified mail）は、リレーが保持する秘密鍵で各メッセージに署名し、受信側は DNS から一致する公開鍵を取得します。リレーから、公開するセレクタと TXT レコードまたは CNAME が提供されます。

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM は転送後も有効なため、SPF より重要です。メーリングリストや .forward ルールによってメッセージが転送されると、転送元の IP アドレスから送信された形で到着します。そのため SPF は失敗しますが、署名の検証は成功します。

DMARC（domain-based message authentication, reporting and conformance）は、どちらの検査も整合しない場合に受信側が取る処理を指定し、結果のレポート送信も依頼します。組織ドメインに公開します。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

p=none から始め、2 週間レポートを確認します。p=none は配信結果を変更せず、レポート送信を有効にするだけです。これにより、自分のドメインを送信元として使っていたことを忘れていたシステムを見つけられます。その後 p=quarantine に変更し、次に p=reject へ移行します。初日から p=reject を公開すると、請求システムがそのドメインを送信元として使っていたことを、請求書を受け取れなかった顧客から知らされることになります。

DNS パネルの表示ではなく、インターネットから見える状態を確認します。

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

出力が空の場合、レコードがまだ伝播していないか、名前が間違っています。5 分前に修正したレコードでも、以前の TTL（time to live）の期間はキャッシュ上で誤った状態が続くことがあります。結論を出す前に TTL を確認します。

From と Return-Path の整合性を保つ

すべてのメッセージには 2 つの送信者アドレスがあり、それぞれ異なる方法で検証されます。エンベロープ送信者は SMTP の MAIL FROM コマンドで指定され、配信済みメッセージでは Return-Path として表示されます。ヘッダーの From は、読者に表示されるアドレスです。

SPF は、エンベロープ送信者のドメインを接続元 IP アドレスと照合します。DKIM は、署名に使用したドメインを d= として示します。DMARC がパスするのは、その 2 つのドメインの少なくとも一方が、ヘッダーの From にあるドメインと整合している場合だけです。緩い整合性（adkim=r、aspf=r。デフォルト設定です）ではサブドメインも認められるため、notify.example.com のエンベロープ送信者は example.com のヘッダー From と整合します。厳格な整合性では整合しません。

実際のルールは簡単です。ヘッダーの From とエンベロープ送信者を同じドメインにすれば、この問題は発生しません。msmtp では set_from_header on が、Postfix では sender_canonical_maps がこれを実現します。

配信済みメッセージで判定結果を確認します。Gmail では「Show original」を選択すると、受信側が記録したヘッダーが表示されます。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

ここでは 3 つの検証がすべてパスしています。それ以外の場合は、失敗した検証と通常はその理由が示されます。これは、この問題をデバッグする際に得られる最も迅速な情報です。

大量送信が始まる前に、バウンスと苦情を確認する

バウンスとは、受信側がメッセージを拒否することです。ハードバウンスは恒久的な失敗で、Gmail では 550 5.1.1 The email account that you tried to reach does not exist と表現されます。ソフトバウンスは一時的な失敗です。メールボックスが満杯の場合やグレイリスティングの場合は 4xx コードが返され、リレーが自動的に再試行します。

リレーはハードバウンス率を測定します。存在しないアドレスへの送信を続けるアカウントは停止します。そのパターンが購入したリストに見えるためです。苦情はさらに重要です。苦情とは、受信者が迷惑メールボタンを押すことです。Google の送信者向けガイダンス（2026年8月確認）では、Postmaster Tools で報告される迷惑メール率を 0.30% 未満に保つよう求めています。また、0.10% 未満を推奨しています。

大量送信が始まる前に、次の4つを用意します。

• バウンスを把握できるよう、webhook またはリレーの suppression list を週1回確認する仕組み
• 実際に誰かが読むメールボックスの From アドレスと、返信先を指定する Reply-To
• アドレスを何かに追加する前の確認。所有者が入力していないアドレスには送信しない
• メール送信を発生させるフォームへのレート制限

最後の2つは、self-hosted アプリで最初に問題になりやすい部分です。保護されていない登録フォームでは、誰でも他人のアドレスを入力できます。サーバーが確認メールを送信すると、入力された本人が迷惑メールとして報告する可能性があります。登録フォームでサブスクリプション爆撃を防ぐ方法は、不正利用対策であると同時に、メール到達性の対策でもあります。

大量メールをこの経路で送信しないでください。ニュースレターには、トランザクションメールにはないリスト管理と配信停止用ヘッダーが必要です。そのため、独自のサブドメインとレピュテーションを持つ self-hosted Listmonk インスタンスを使って配信します。self-hosted forum からの通知メールは、その中間に位置します。形式はトランザクションメールに近く、量は大量メールに近い構成です。通常は、設定が正常に機能しているかを最初に確認できる種類のメールです。

参考として、Gmail の大量送信者向けルールは、Gmail アドレス宛てに 1日 5,000 件を超えて送信する場合に適用されます。マーケティングメールには SPF、DKIM、DMARC とワンクリック配信停止が必要です。ほとんどの self-hosted アプリは、この基準に達しません。ただし、認証関連の要件は現在、すべての送信者に求められています。

信頼する前にテストする

swaksは、この用途に使うツールです。SMTP で通信し、やり取り全体を表示するため、どの手順で失敗したかを確認できます。

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

このテストでは、relay に対して認証情報を直接検証します。アプリケーションが実際に使用する経路をテストするには、代わりにホスト側の relay を指定します。

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

次に、実際のメールを使い、サーバーから送信結果をエンドツーエンドで確認します。設定ファイルだけでは、これらを検証できません。自分で実行してください。

• mail-tester.com などのスコアリングサービスに送信する。このサービスは SPF、DKIM、DMARC、メッセージ内容を確認し、スコアの理由を示します
• ユーザーが実際に利用している 2 つのプロバイダーそれぞれのメールボックスに送信し、生メッセージ内の Authentication-Results を確認する
• アライメント結果が明確でない場合は、learndmarc.com で 1 通のメッセージを確認する
• コマンドラインからだけでなく、アプリケーション自体から送信を実行する。From ヘッダーを設定するのはアプリケーションだからです

最後に、率直な注意点を 1 つ示します。3 つのレコードがすべて正しく設定された新しいドメインでも、ときどき迷惑メールに分類されます。履歴がなく、受信側は先週登場したばかりのドメインを慎重に扱うためです。最初は少量から始め、受信者が想定しているメールを送信してください。そこから評価が積み上がります。この点を設定だけで回避することはできません。

FAQ

VPS の送信ポート 25 はなぜブロックされているのですか？

ほぼすべてのプロバイダーは、デフォルトで送信 TCP ポート 25 をブロックしています。このポートを開いたサーバーが侵害されると、受信側のメールサーバーへスパムを直接送信できるためです。パケットは拒否されずに破棄されるため、接続がハングアップしてタイムアウトする症状になります。エラーメッセージは表示されません。nc -vz -w 5 gmail-smtp-in.l.google.com 25 と nc -vz -w 5 smtp.relay.example 587 を続けて実行すると確認できます。前者はそのまま応答を待ち続け、後者はすぐに応答します。ブロック解除を依頼するのが解決策ではありません。送信ポート 587 または 465 のリレー経由で送信してください。これらのポートは開いたままで、認証済みクライアント向けに設計されています。

アプリの通知を少し送るだけでも SPF、DKIM、DMARC は必要ですか？

はい。送信量は関係ありません。受信側は、パスワードリセット通知 1 通にも、5 万通のキャンペーンメールにも同じ検証を適用します。SPF と DKIM がなければメールは認証されません。また、Google の現在の送信者ガイドラインでは、すべての送信者に少なくともいずれか 1 つが必要です。DMARC がなければレポートを受け取れないため、問題に気付く最初のきっかけが、ユーザーからの「リセットリンクが届かない」という連絡になる可能性があります。3 つとも DNS レコードであり、費用はかかりません。公開に必要な時間も約 10 分です。

リレークライアントには msmtp と Postfix のどちらを使うべきですか？

サーバーを 1 人で管理し、リレー障害時にメッセージが失われても許容できる場合は msmtp を使います。単一の設定ファイルだけで動作し、デーモンもありません。また、キューを持たないため、リレーに接続できなければメッセージは失われます。数日間再試行するキューが必要な場合や、複数のアプリが異なる system user で動作する場合は、Postfix を satellite として使います。Postfix はリレーのパスワードを root のみが読み取れるファイルに保存するため、アプリがそのファイルを読む必要はありません。一方、msmtp では送信するすべてのユーザーが設定を読める必要があります。

アプリのメールが root から送信されたとして拒否されるのはなぜですか？

Cron ジョブや多くのアプリは、ローカルユーザーとホスト名から送信者を組み立てるため、root@srv1.localdomain のような値になります。これはリレーで検証済みのアドレスではありません。そのためリレーは、送信者アドレスを示す 553 または 554 の応答を返してメッセージを拒否します。各アプリではなくホスト側で修正します。/etc/msmtprc に from アドレスとともに set_from_header on を設定するか、Postfix で sender_canonical_classes = envelope_sender, header_sender とともに sender_canonical_maps を設定してください。返信を特定の担当者に届ける必要がある場合は、各アプリ内で Reply-To を設定します。

アプリメール専用のサブドメインを本当に用意すると、メインドメインを保護できますか？

部分的には保護できます。それでも実施する価値はあります。受信側はドメインごとに評価を追跡するため、notify.example.com に対する苦情の影響は主に notify.example.com にとどまり、メインドメインの配信は継続しやすくなります。ただし限界もあります。一部の受信側はサブドメインの評価を組織ドメインへ集約します。また、組織ドメインに公開した DMARC ポリシーは、sp= を個別に設定しない限りサブドメインにも適用されます。サブドメインは被害を限定する手段であり、保証ではないと考えてください。