Postfix設定 逆引きガイド集｜基本から応用まで実践解説

最終更新日：2026.05.27

Postfixと聞いて、具体的にどのような仕組みを想像されるでしょうか？

「名前は知っているが、詳しくは分からない」「単にメールを送るためのツール」といった漠然としたイメージをお持ちの方も多いかもしれません。

本記事では、Postfixをセキュアかつ安定して動作させるための必須設定から、現場の難題を解決する高度なリレー制御の方法まで、実務に即した「main.cf」での設定例を逆引き形式で紹介します。

Postfixの基本構造と設定のルール

Postfixは、Linuxサーバー環境でデファクトスタンダードとなっているメール転送エージェント（MTA）です。高い安全性と、大規模な配送基盤にも対応可能な堅牢性を兼ね備えています。

他のMTA（SendmailやExim等）に対する最大の優位性は、そのモジュール構造にあります。各処理を独立したプロセスに分離することで、万が一の障害時も影響範囲を最小限に抑え、優れた保守性と拡張性を実現しています。

導入前に知っておくべきこと

導入にあたってまず理解すべきは、Postfixの役割が「メールを配送すること」に特化していることです。そのため、メールを受信して手元の端末で読むには、別途DovecotなどのPOP/IMAPサーバーを組み合わせる必要があります。

なお、PostfixはWindowsネイティブ版が存在しません。検証目的などでWindows環境を使用する場合には、WSL2（Windows Subsystem for Linux）などを活用する構成が一般的です。

Postfixを支える2つの設定ファイル

Postfixの動作は、主に 「/etc/postfix/」ディレクトリに格納されている「main.cf」と「master.cf」という2つの設定ファイルによって決定されます。それぞれの違いは以下の通りです。

• main.cf：Postfixでどうメールを送るか
  • 役割：「どこから、どこへ、どう送るか」という外部的なルールを定義します。
  • 内容：ドメイン名、中継ルール、セキュリティ関連、メールサイズの制限などを設定します。日常的な運用では、ほとんどはこのファイルを扱います。
• master.cf：Postfixをどう動かすか
  • 役割：「どのように、どんな条件で動かすか」という内部的な動作を定義します。
  • 内容：Postfix内部の各モジュールの起動方法や引数、並列数などを制御します。SMTPサーバーの起動、SASL認証の有効化など。初期構築時や高度なカスタマイズ時以外は、あまり触れることはありません。

【基本設定】自サーバーのホスト名とドメインを設定したい

まず、Postfixを導入した直後に最低限設定すべき、基本的な設定項目をご紹介します。

特にドメイン関連の設定は、メールの送信元アドレスやヘッダ情報が明確になるため、受信側サーバーでの信頼性が向上します。その結果、メールの到達率にも大きく貢献する重要な設定となりますので、しっかり押さえておきましょう。

自サーバーのホスト名（FQDN）を定義したい｜myhostname

設定例：

myhostname = mail.example.com

メールヘッダの「Received」などに使われ、他のメールサーバーに自身を識別させるために必要な設定です。技術的にはFQDN形式（完全修飾ドメイン名）でなくても動作自体はしますが、受信側への信頼性という意味でも、ここはFQDN形式にしておくことが推奨されています。

使用するメインドメインを指定したい｜mydomain

設定例：

mydomain = example.com

Postfixで中心として扱うドメイン名を指定します。通常は「example.com」のような、みなさんがお持ちの自身のドメインを指すパラメータです。

ドメイン名を省略した際の補完ルールを決めたい｜myorigin

設定例：

myorigin = $mydomain

サーバー内やプログラムからドメイン名を省略してメールを配信した場合に、自動的に補完されるドメイン名を決める設定です。ここで指定した値が、送信元の「From:」ヘッダなどに影響してきます。特別な理由がなければ、上記のように mydomain の値をそのまま参照させる設定（$mydomain）にしておくのがおすすめです。

通信プロトコルをIPv4のみに制限したい｜inet_protocols

設定例：

inet_protocols = ipv4

例では「xxx.xxx.xxx.xxx」のようなIPv4形式のみを有効にしています。

デフォルトのままだとIPv6も動こうとしますが、環境によってはあえてIPv6を無効化することで、IPv4のみを使用している環境での動作安定性が向上する場合があります。「なぜかメールの配送が遅いな」と思ったら、ここを見直してみると解決するかもしれません。

【共通ルール】外部ファイル参照とテーブルタイプの基本

次の章からは、メールの行き先をコントロールする「配送・リレー制御」をはじめ、アドレスの書き換えやセキュリティ対策など、少し複雑で実務的な設定に入っていきます。

これから先の章では、共通して外部に別のテキストファイルを用意して、Postfixにそれを読み込ませて動かすという設定がたくさん登場します。そこで、具体的な設定に入る前に、Postfixで外部ファイルを扱うときの超重要ルールである「テーブルタイプ」と「postmapコマンド」の前提知識について、ここで先にお話ししておきます。これを理解しておくと、この先のすべての章の設定がスムーズに頭に入ってくるようになりますよ！

Postfixの設定では、ここから先「alias_maps = hash:/etc/aliases」のように外部ファイルを参照するケースが頻繁に出てきます。 その際、検索を高速化するためにテキスト形式のマップファイルを「postmap」コマンドでバイナリデータベース形式(.db)に変換する必要があります。

外部ファイルを更新した際には「postmap」コマンドを実行し、バイナリデータベースも一緒に更新しないと設定内容が反映されませんので注意してください。

両方の設定を更新したら「postfix reload」や「systemctl reload postfix」のコマンドで設定を反映させる必要があります。小難しいことは置いといて、別ファイルを参照する設定の場合は「postmap」が必要で、変更した設定を反映させるには「reload」が必要になると覚えておきましょう。

例）

postmap /etc/postfix/sender_relay

本記事では明確に「hash:」等のテーブルタイプを指定していますが、「hash:」を指定しなくても内部的には「hash:」として解釈されます。使用可能なテーブルタイプは下記の通りです。

【配送・リレー制御】メールの行き先や中継ルートをコントロールしたい

ここでは、メールの配送経路や中継（リレー）に関する設定を紹介します。受け取ったメールを適切な宛先へ届けるために、要件に応じた配送経路をコントロールする方法を見ていきましょう。

外部へのメール中継先（リレーホスト）を指定したい｜relayhost

設定例：

relayhost = [smtp.example.com]:25

受け取ったメールをどこに中継（リレー）して送信するかを指定します。

ここで一つ細かいポイントなのですが、設定値のサーバー名に [ ] をつけるかどうかで動きが変わります。[ ] がある場合は「MX解決をスキップしてAレコードに直接接続」し、ない場合は「MXレコードの引き先」に送るという違いがあります。有無によって動作が異なるため注意して下さい。

自サーバーが最終目的地となるドメインを指定したい｜mydestination

設定例：

mydestination = $myhostname, localhost.$mydomain, localhost

このPostfixが「最終受信者（自分宛てのメール）」として扱うドメイン名のリストを指定します。簡単に言うと、ここで指定したドメイン宛のメールは外部へ中継されずに、ローカルのメールボックスに格納されます。この指定を間違えると、自分宛てのメールなのに外部へ転送しようとしてループしてしまう、といったトラブルの原因になるので注意が必要です。

宛先ドメインごとに配送ルートを強制分岐させたい｜transport_maps

設定例：

transport_maps = hash:/etc/postfix/transport

ファイルの中身（/etc/postfix/transport）：

example.com smtp:[relay.example.com]

ドメインやメールアドレスごとに、配送先（配送手段やリレー先）を個別に指定できる設定です。例では「/etc/postfix/transport」というファイルを用意して、「example.com宛のメールは、relay.example.comにSMTPで転送する」という設定を入れています。特定の宛先ドメインに対して、デフォルトの配送経路（MX参照や relayhost の設定）を上書きしたい場合にすごく便利です。

ちなみに、転送先（リレーホスト）を指定せずに「example.com smtp」とだけ書いた場合は、「example.com」の通常のMXレコードを参照して転送する動きに戻すことができます。

送信元ドメインに応じてリレー先のSMTPサーバーを切り替えたい｜sender_dependent_relayhost_maps

設定例：

sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay

ファイルの中身（/etc/postfix/sender_relay）：

@example.com    [smtp.relay1.local]:587
@sample.org     [smtp.relay2.local]:25

「送信元アドレス（envelope from）によって転送先を変える」機能です。Postfixが外部にメールを配送するとき、Fromのドメインごとに別のリレー先を指定することができます。特定の送信者や部署からのメールだけ別のSMTPサーバーを経由させたい、といった現場の要件でよく使われます。

もし通常の relayhost も一緒に設定されていた場合は、この sender_dependent_relayhost_maps の設定が優先されます。ここに記載されていない送信元ドメインのメールは、通常の配送（または relayhost の設定通り）となります。

メールサイズの上限を設定したい｜message_size_limit

設定例：

message_size_limit = 26214400

メールサイズの上限をバイト（byte）単位で指定し、この制限値を超えた場合は送受信を拒否する設定です。大きすぎるメールをそのまま許可してしまうと、ネットワークやサーバーのストレージを圧迫して、システム全体に大きな負荷がかかってしまうので注意してくださいね。

設定例では「26214400」と指定して25MBまでのメールを許容していますが、もし何も設定をしない場合のデフォルト値は「10MB（10240000バイト）」が上限になっています。運用の要件や、社内で扱うファイルの大きさに合わせて調整してみてください。

【アドレス変換・転送】送信元や宛先のアドレスを書き換えたい

Postfixの基本設定を終え、運用を始めると「特定の条件下で挙動を変えたい」と考えることは少なくありません。ここでは、送信元や宛先のアドレス変換、別アドレスへの転送など、運用の現場でよく求められるカスタマイズ例を紹介します。

送信元アドレスを代表アドレスなどに書き換えたい｜sender_canonical_maps

設定例：

sender_canonical_maps = hash:/etc/postfix/sender_canonical

ファイルの中身（/etc/postfix/sender_canonical）：

root@localhost  admin@example.com
@old.example.com  @new.example.com

(※rootユーザから送信されるメールを admin@example.com として送信 )

(※@old.example.com を @new.example.com として送信 ) 

送信元アドレスのエンベロープFromとヘッダーFromを、任意の形式に書き換えることができる設定です。

Linuxのユーザ名やローカルドメインのままメールを送信してしまうと、受信側で迷惑メールと判定されたり、ブランドの印象が損なわれる恐れがありますよね。メール送信側が正しいアドレスを名乗れない場合の「最終防衛ライン」として、Postfix側でアドレスを整形して組織の代表アドレスなどに統一したいときに役立ちます。ユーザ単位やドメイン単位、正規表現での一括変換など、用途に応じて細かいコントロールが可能です。

ただ、注意点として、書き換え後のドメインでSPFレコードやDKIM署名が正しく設定されているかなど、送信ドメイン認証（特にDMARC）への影響を考慮して慎重に設定しましょう。

宛先アドレスを内部的に別のアドレスへ変換したい｜recipient_canonical_maps

設定例：

recipient_canonical_maps = hash:/etc/postfix/recipient_canonical

ファイルの中身（/etc/postfix/recipient_canonical）：

support_aaa@example.com  support@example.com
support_bbb@example.com  support@example.com

(※「support_aaa@example.com」や「support_bbb@example.com」宛のメールを「support@example.com」宛に変換 ) 

受信メールを処理する際に、宛先アドレス（エンベロープTo）を内部的に別のアドレスへ変換するための設定です。複数のエイリアスアドレスを一つのユーザに統合したい場合に有効で、配送処理の前に適用されるため、最終的な配送先の正規化・簡略化に役立ちます。

Postfix内部の配送処理に影響するものなので、エンベロープToは書き換えられますが、メールヘッダの表示自体は基本的に変わらないのが特徴です。ちなみに、以下のように「regexp:」を使えば、ワイルドカード的なパターンマッチも可能になります。

/^support_[^@]+@example\.com$/ support@example.com

もし、変換するだけでなく配送先そのものを完全に変更・転送したい場合は、次に紹介する virtual_alias_maps の利用が適しています。

ローカルユーザ宛のメールを別のアドレスへ転送したい｜virtual_alias_maps

設定例：

virtual_alias_maps = hash:/etc/postfix/virtual

ファイルの中身（/etc/postfix/virtual）：

support@example.com      user@example.net
sales@example.com        user@example.net

(※「support@example.com」、「sales@example.com」宛のメールを「user@example.net」に集約 ) 

宛先アドレスを別のアドレスに転送・変換するための設定です。仮想ドメインのメール転送や、複数の別名アドレスを1つの実アドレスに集約する場合などに使用されることが多いのではないでしょうか。この設定は、さきほどの recipient_canonical_maps と違って「配送先を完全に書き換える」ため、実際にどのメールボックスに届けるかを制御できます。変換前のアドレス宛には届かなくなってしまうので、正しくマッピングができていないとメールを紛失してしまう恐れがある点には注意してくださいね。

特定ユーザにBCCで監査・保存したい｜sender_bcc_maps / recipient_bcc_maps

設定例：

sender_bcc_maps = hash:/etc/postfix/sender_bcc
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

ファイルの中身（/etc/postfix/sender_bcc）：

test@example.com    archive@example.net

ファイルの中身（/etc/postfix/recipient_bcc）：

bob@example.com      audit@example.net

送信、または受信メールを指定した別アドレスに、BCCとして自動送信する設定です。メールの監査やバックアップ用途で利用されるケースが多いのではないでしょうか。「sender_bcc_maps」の例で言うと、「test@example.com」が送ったメールは、本人が意識していなくても、必ず「archive@example.net」にも自動でBCC配送されるようになります。

【セキュリティ強化】安全にメールを送受信するための対策を行いたい

メールサーバーを安定して運用するためには、外部からの攻撃や不正利用を防ぐ堅牢なセキュリティが不可欠です。ここでは、オープンリレー（踏み台化）の防止をはじめ、通信内容を保護するTLS暗号化、SMTP認証など、セキュリティに関する主要な設定項目と実装方法について解説します。

信頼するネットワークを指定して不正中継（オープンリレー）を防ぎたい｜mynetworks

設定例：

mynetworks = 127.0.0.0/8, 192.168.0.0/24

サーバーから「中継（リレー）送信」を許可する送信元IPの許可リストです。ここで許可されたIP範囲からの送信要求のみ、外部への配送が許可されます。正しく設定すれば不正利用を防止できますが、もしここに「0.0.0.0/0」を指定してしまうと、全ネットワークからの中継を許可することになってしまいます。このような状態を「オープンリレー」と言いますが、オープンリレーになってしまうとメールを送信するための踏み台として世界中から不正利用されてしまいますので、特に注意が必要です。

宛先不明メールをSMTP通信時に拒否してバックスキャターを防ぎたい｜alias_maps / local_recipient_maps

設定例：

alias_maps = hash:/etc/aliases
local_recipient_maps = unix:passwd.byname $alias_maps

ファイルの中身（/etc/aliases）：

postmaster: root
support: user1@example.com

alias_maps はメールの転送先や別名（エイリアス）を定義し 、local_recipient_maps はローカルユーザが存在するかどうかをチェックする設定です。設定例にある unix:passwd.byname は /etc/passwd にあるユーザを確認し 、$alias_maps はエイリアスファイルに定義されている名前かどうかを確認しています。

これらを明示的に指定して合わせることで、Postfixは「ユーザまたはエイリアスとして定義されたもの」だけをローカル配送可能とみなします。もし、どちらにも存在しない宛先へのメールが届いた場合は、受信時（RCPT TO）の段階でエラーとして拒否してくれます。

もしこの設定を正しく行わないと、存在しない宛先宛てのスパムメールを一旦受け取ってしまい、その後で「宛先がありませんでした」というエラーメールを送信元（大抵は偽装された他人のアドレス）に返すことになります。これは「バックスキャター（バウンス悪用スパム）」と呼ばれ、自分のサーバーがスパムの片棒を担ぐ原因になってしまうため、これを防止する意味でも極めて重要な設定です。ちなみに unix: はUNIXシステムデータベースを参照するテーブルタイプなので、postmap コマンドによるバイナリ化は不要です。

接続元と宛先の制限ルールを定義してオープンリレーを厳格に阻止したい｜smtpd_relay_restrictions

設定例：

smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination
smtpd_recipient_restrictions = reject_unknown_recipient_domain

不正な第三者によるメールの中継（リレー）を防止するための、Postfixのセキュリティの要となる制限設定です。設定しない場合、簡単にスパム中継として悪用される危険性があります。

例のように、permit_mynetworks（信頼するIPからの送信を許可）、permit_sasl_authenticated（認証に成功したユーザからの送信を許可）を並べ、最後に reject_unauth_destination（それ以外の外部宛てメールは拒否） を記述するのが王道の構成です。Postfixはこれらを上から順番に評価していくため、記述する順番を間違えないように注意してください。

送受信時の通信内容をTLSで暗号化して保護したい｜smtpd_tls_security_level / smtp_tls_security_level

設定例：

# 受信側（サーバーとして動作するとき）

smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem
smtpd_tls_key_file = /etc/ssl/private/postfix.key
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level = may

# 送信側（クライアントとして外に送るとき）

smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

パッと見ると似たような設定が並んでいてややこしいですが、smtpd_* は受信時のTLS接続設定（Postfixが受信サーバーとして動く際の設定）となり 、送信側（他のサーバーにメールを転送・配送するとき）の設定パラメータは smtp_* となります。

秘密鍵や証明書の設定（cert/key）は、受信サーバーとして自分の身元を証明するために提示するものなので、基本的には smtpd_* 側にしか書きません。ただし、相手のサーバーからクライアント証明書を求められた場合などのために、送信側の smtp_* にもクライアント証明書を設定できるようになっています（smtp_tls_cert_file / smtp_tls_key_file）。

また、security_level の設定値を変えることで、どの程度厳格にTLS（暗号化）を使用するかの方針を決めることができます。設定値の意味は以下の通りです。

SMTP認証を導入して正規ユーザのみ送信を許可したい｜Cyrus SASL

連携設定手順と設定例：

1.パッケージのインストール（RHEL8系の場合）

dnf install cyrus-sasl cyrus-sasl-plain cyrus-sasl-lib

2.main.cf の設定

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

3.master.cf の設定

submission inet n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

4.外部認証設定ファイル（/etc/sysconfig/saslauthd / /etc/sasl2/smtpd.conf）

# /etc/sysconfig/saslauthd
MECH=pam
# /etc/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login

5.設定反映とデーモンの起動

systemctl restart postfix
systemctl start saslauthd
systemctl enable --now saslauthd

通常のSMTPは、標準の仕様だと「誰でも接続できてしまう」仕組みになっているため、そのまま公開するとスパムメールの踏み台に悪用される危険が非常に高いです。この対策として導入するのが、ユーザ名とパスワードでログインさせる「SMTP認証（SMTP AUTH）」です。認証に成功した正規のユーザだけがメールを送信できるようになります。

Postfix単体では認証の仕組みを持たないため、「Cyrus SASL」や「Dovecot」といった外部の認証サービスと連携させて動かすのが基本構成です。本記事ではCyrus SASLを使う例を紹介しています。

このSMTP認証を安全に運用するために、一般的には25番ポートではなく「submissionポート（587番）」を使い、暗号化（STARTTLS）と認証をセットで利用します。25番ポートでも認証自体は有効化できますが、25番は本来「サーバー同士がメールを配送し合うためのポート」ですので、ユーザからの送信用には master.cf で 587番ポートを分けてあげるのが推奨されています。

ヘッダや本文の内容で簡易的にメールを拒否したい｜header_checks / body_checks

設定例：

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

ファイルの中身（/etc/postfix/header_checks）：

/^Subject:.*spammail!/    REJECT 不審な件名を検出しました
/^From:.*example\.com/ DISCARD ローカルポリシーで破棄

ファイルの中身（/etc/postfix/body_checks）：

/スパムメールです！/    REJECT 不審な本文を検出しました

メールのヘッダや本文に対して正規表現による検査を行って、特定のパターンにマッチしたメールを拒否・破棄・隔離できる簡易的なフィルタリング機能です。

例えば、設定例のように「REJECT」と書いておくと、特定のキーワードが含まれるメールを検知した際に「554 5.7.1 不審な本文を検出しました」といったSMTPエラーコードを返して受信を拒否できます。これにより、相手のログに拒否理由を残しつつ、送信者へ届かなかったことをエラー通知することができます。正規表現にマッチした際に使用できるアクションには、以下のような種類があります。

【高度な制御】防御・宛先検証・代替配送を設定したい

Postfixは一律的なメール配送だけでなく、送信者や宛先の条件に応じた柔軟な制御や、高度な防御機能が備わっています。ここでは、外部のスパムボットを効率的に遮断する仕組みや、サーバー障害に備えた代替ルートの用意など、実務の運用シーンで一歩踏み込んで役立つ設定を解説します。

postscreenを使って接続前の段階でスパムボットを効率的に遮断したい｜ボット対策

設定手順と設定例：

1.master.cf の設定（変更前）

smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen

↓↓↓（変更後）

#sm
tp      inet  n       -       n       -       -       smtpd
smtp      inet  n       -       n       -       1       postscreen

2.main.cf の設定

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 1h
postscreen_dnsbl_cache_cleanup_interval = 12h
postscreen_cache_retention_time = 7d

# ホワイトリスト・ブラックリストを使う場合

postscreen_access_list = cidr:/etc/postfix/postscreen_access.cidr

3.ホワイトリストファイルの中身（/etc/postfix/postscreen_access.cidr）

123.45.67.89/24 permit
98.76.56.43          permit
111.222.33.44      reject

Postfixには「postscreen」という接続前スクリーニングの機能が備わっています。

これは、SMTP接続（メールのやり取り）が本格的に始まる前に、接続元のIPアドレスの信頼性をチェックすることで、スパムメールを大量に送信しているホストサーバーやボットからの接続を入り口で遮断できる仕組みです。もちろん、postscreenのチェックを無事にパスした正常なメールは、通常通りに配信されますので安心してください。

• 通常のアクセス順：クライアント → smtpd
• postscreenを有効にした場合：クライアント → postscreen → smtpd

有効にするには main.cf だけでなく、master.cf の変更も必要になります。設定例のように書き換えることで、本来の smtpd デーモンが受ける前に、postscreen が先頭に立ってSMTP接続を受けるようになります。main.cf で指定しているそれぞれのパラメータの意味は以下の通りです。

ちなみに、action に設定できる値は以下の3種類があります。

本番環境でいきなり遮断するのは怖いと思いますので、まずは ignore で導入してみて、ログで遮断されるIPやドメインを確認したあとで enforce に変更する、というステップを踏む運用がおすすめです。ただ、運用していると「DNSBL（ブラックリスト）に載ってしまっている相手だけど、どうしてもメールを受信したい」といったケースも出てくるかと思います。そうした場合には、ホワイトリスト機能（postscreen_access_list）を使いましょう。postscreen_access.cidr ファイルで permit に設定したIPアドレスは接続が許可され、reject にしたIPは強制ブロックできます。

ここで一つ大きな注意点なのですが、postscreenはSMTP接続の「最初の最初のTCP接続」のレベル（IPベース）で動作するため、ドメイン情報を利用できません。この時点ではまだSMTPセッションが始まっておらず、メールの送信元ドメインが何であるかをPostfixが知らないからです。そのため、「特定のドメインだけを許可したい」と思ってもドメイン名での指定はできません。許可したい送信元のIPアドレスをすべて調べて登録する必要がある点だけ、忘れないように覚えておきましょう。

相手サーバーに宛先が実在するか確認してから配送処理に入りたい｜address_verify_map

設定例：

address_verify_map = btree:/var/lib/postfix/verify

これから送ろうとしている宛先のメールアドレスが相手側に本当に実在するかどうかを事前に確認し、その結果をデータベース（/var/lib/postfix/verify）にキャッシュしてくれる設定です。これを入れることで、届くはずのない無効なアドレスへメールを送り続け、エラーで戻ってきたメールのせいでメールキューが大量に溜まってしまう、といった事態を防ぐことができます。

ただし、良いことばかりではなく、いくつかトレードオフがあります。まず、受信相手のセキュリティポリシーによってはアドレスの実在性を外から確認できない（教えてくれない）場合がありますので、あくまで「補助的な仕組み」として利用するのが現実的です。

また、メールを送るたびに宛先検証のための通信が裏で発生するため、多少のシステムオーバーヘッドが発生します。さらに、相手サーバーに何度も検証をかける動きが「怪しいスキャン行為」とみなされて、こちらのレピュテーション（サーバーとしての信頼度）が下がり、かえってメールの到達率に悪影響を与えてしまうリスクもある点には注意してください。

ちなみに、指定している /var/lib/postfix/verify はPostfixが検証結果をキャッシュするために自動で扱うデータベースファイルですので、みなさんが手動で生成・更新する必要はありません。必要に応じてPostfixが自動的に作成・更新してくれますし、もしファイルを削除してしまっても、勝手に再生成されるので大丈夫です。

リレー失敗時に備えて代替の配送経路を用意したい｜fallback_relay

設定例：

relayhost = [primary.smtp.example.net]
fallback_relay = [backup.smtp.example.net]

メインとして指定した通常のリレー先（relayhost）に何らかの障害が発生し、メールが配送できなかった場合に、予備として設定した別のSMTPサーバー（fallback_relay）に経路を切り替えて配送を継続してくれる設定です。障害時の自動バックアップ経路として機能してくれるため、メールシステムの可用性をグッと高めるのに役立ちます。

ただし、ここで運用上、非常に重要な注意点があります。もし予備として指定した fallback_relay 側のサーバーで「配送できなかったら primary.smtp.example.net（メイン側）に転送する」といった設定が残っていた場合、メインと予備の間でメールが何度も行き来する「無限ループ」が発生してしまいます。こうなると、送れないメールがぐるぐる回り続けてキューが恐ろしい勢いで膨れ上がってしまうため、両方のサーバーの設定の組み合わせには細心の注意を払ってくださいね。

ちなみに、このパラメータはメインの relayhost を設定していない状態でも使えます。通常のDNS（MXレコード）を参照した直接配送がうまくいかなかったドメインに対してのみ、この fallback_relay で指定したサーバーへリレーする、という動きをしてくれるため、システムの「最後の逃げ道」として機能させることも可能です。

【保守・管理】現在の設定やメールキューを操作したい

Postfixを運用していくうえで、一番お世話になり、かつ強力で便利なのがコマンドによる操作です。ここでは日常のトラブルシューティングやメンテナンス時によく使う管理コマンドを、目的別に逆引き形式で紹介します。

現在の有効な設定値やデフォルト値を安全に確認・変更したい｜postconfコマンド

Postfixの設定を確認するとき、ついつい vi コマンド等で直接 main.cf を開きたくなりますが、本番環境ではこの postconf コマンドを使うのが絶対に安全でおすすめです。

というのも、ファイルを直接開いてしまうと「間違えてキーボードに触れて変な文字を入れちゃった」といった誤編集の事故が起きかねないからです。postconf を使えば、現在有効になっている値を安全に画面上で確認できます。

また、設定を変更するときも postconf -e “項目 = 設定値” を使えば、指定したパラメータを main.cf に自動で追記や上書きをしてくれます。万が一、タイポなどの構文ミスがあった場合でもコマンドがエラーを返してくれるため、手動でファイルを書き換えるよりも遥かに安全に設定変更が行えますよ。

滞留しているメールキューの確認や再配送、削除などの操作を行いたい｜postqueue / postsuperコマンド

よく使うコマンド一覧：

Postfixでは、送受信の途中で相手に届かなかったり保留になったりしたメールを「キュー」という形でサーバー内に保持して管理しています。メールが相手に届かないときの調査では、まず postqueue -p を叩いてキューの一覧を見ることから始まります。

「ネットワークの障害が復旧したから、溜まっているメールを一気に再送したい！」というときは、postqueue -f を実行すれば強制的に再配送を試みてくれます。

逆に、宛先間違いなどで滞留してしまった不要なメールを消したい場合は postsuper -d を使います。ちなみに、postsuper -d ALL というすべてのキューを吹き飛ばす強力なコマンドもありますが、これを本番環境でうっかり実行するとユーザの正常なメールまで全部消えて大惨事になるので、あくまで開発中のテスト用など、限定的なシーンだけで使うように細心の注意を払ってくださいね。

Postfixの起動・停止や設定ファイルの再読み込みを制御したい｜systemctlコマンド

CentOS 7 / RHEL 7系以降の環境（systemd）

CentOS 6系などの古い環境（SysV init）

最近のLinux環境であれば基本的には systemd の管理下で動いているので、上の systemctl コマンドで制御します。

ここで覚えておいてほしい運用のコツは、main.cf などの設定を書き換えたあと、安易に restart（再起動）をしないことです。再起動すると、一瞬ですがSMTPの受付プロセスが完全に止まってしまうため、タイミング悪く接続してきた他のサーバーとの通信が瞬断されるリスクがあります。新しく設定値を反映させたいだけであれば、プロセスを落とさずに設定の裏読み込みをしてくれる systemctl reload postfix を使うのが、稼働中のサービスへの影響がなくて安全ですよ。

設定変更後の構文エラーやファイルのアクセス権限を診断したい｜postfix checkコマンド

実行コマンド：

postfix check

このコマンドが検査してくれる主な項目：

Postfixには、設定ファイルの整合性やアクセス権の問題を事前に検証するための便利な診断コマンドが標準で用意されています。設定を変更したあとや、「なんだか新設定がうまく反映されない」「挙動が不安定だな」と感じたときは、サービスを再読込する前にまずこの postfix check を叩く癖をつけておくと、潜在的な記述ミスを早期に見つけることができますよ。

ただし注意点として、このコマンドはあくまで「構文やファイルの権限レベルの検査専用」となっています。コマンドを実行して何もエラーが出なかった（無言で終わった）からといって、実際のSMTPの応答やメールの送受信テストまで保証してくれるわけではないので、最終的なテストはしっかりとメールを流して確認するようにしてくださいね。

まとめ

Postfixは柔軟で強力なMTAであり、シンプルな構成から複雑な配送ルールやセキュリティ設定まで、幅広い要件に対応できるよう設計されています。この記事で紹介した各種設定を適切に活用することで、安定したメール環境を構築し、スパムや不正利用を防止しつつ、効率的なメール配送が実現可能です。

ただし、現在のメール運用において到達率を高く保つには、Postfix単体の設定だけでは不十分です。 特に主要なプロバイダーのガイドラインに対応するため、送信ドメイン認証の実装が必須となっています。

安定したシステムを構築するためには、Postfixの基本設定を正しく行うことに加え、これら外部連携やDNS設定、そして継続的なログ監視とトラブルシューティングの体制を整えることが不可欠です。

本記事で紹介した設定はあくまでPostfixの強力な機能の一部に過ぎません。公式のmanページや最新のセキュリティガイドラインを併せて参照し、ご自身の要件に最適な、信頼性の高いメールサーバ環境を構築してください。