H HACKLIFE

メール・セキュリティ

Postfixの設定方法：SPAM対策と安全なメールサーバー運用

公開日 2026.10.05　／　公式情報確認日 2026.10.05　／　読了目安 14分

Postfixをインストールしてメールを送受信できるようにするだけでは、安全なメールサーバーとはいえません。最優先は不正中継を防ぐこと。その次にTLSと認証、迷惑メールを入口で減らす設定、送信ドメインを守るSPF・DKIM・DMARCを整えます。

前提
Rocky Linux／AlmaLinux系のVPSで、example.jpを運用する例です。実際には自分のFQDN、ドメイン、証明書パスへ置き換えてください。既存メールサーバーでは、設定ファイルとメールデータをバックアップしてから変更します。
外部メールサーバーTCP 25
→
Postfix受信・検査・配送
←
利用者TCP 587 + TLS + AUTH
重要：インターネットからメールを受け取る25番ポートと、利用者がメールを送る587番ポートは役割が違います。25番で全接続に認証を要求せず、587番ではTLSと認証を必須にします。

DNSとホスト名を先に整える

Postfixの前に、ホスト名とDNSが一致していることを確認します。メール配送では正引きだけでなく逆引きも見られます。

Postfixの基本設定を作る

/etc/postfix/main.cfの中心部分です。mynetworksへ自宅回線や広いプライベートネットワークを安易に追加しないことが重要です。

# 自分の環境へ置き換える
myhostname = mail.example.jp
mydomain = example.jp
myorigin = $mydomain

inet_interfaces = all
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# 信頼するのはサーバー自身だけ
mynetworks = 127.0.0.0/8, [::1]/128

# 第三者への不正中継を禁止
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

disable_vrfy_command = yes
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
message_size_limit = 26214400

Postfix 2.10以降では、中継可否をsmtpd_relay_restrictions、迷惑メール判定をsmtpd_recipient_restrictionsへ分けると事故を避けやすくなります。reject_unauth_destinationを外してはいけません。

TLSを有効にする

公開MXの25番は、相手がTLSに対応していれば暗号化する「機会的TLS」にします。すべての相手へ暗号化を強制すると、対応していないサーバーからメールを受け取れません。

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.jp/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.jp/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may

# AUTHは暗号化後だけ表示する
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

証明書の秘密鍵はrootだけが読める権限を保ち、更新後にPostfixを再読み込みします。証明書ファイルをメール送受信用ユーザーへコピーする運用は避けます。

587番でSMTP AUTHを提供する

メールソフトからの送信はsubmission（587番）へ分離します。認証基盤としてDovecot SASLを使う例では、PostfixからDovecotのUNIXソケットへ接続します。

# /etc/postfix/main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

/etc/postfix/master.cfではsubmissionサービスにだけ厳しい上書きを設定します。

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_auth_only=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

外部へ認証なしで送れる状態になっていないか、別回線から必ずテストします。認証失敗を繰り返すIPは、Fail2banなどで一定時間遮断する方法もあります。

受信時の軽量なSPAM対策を入れる

最初から厳しい拒否ルールを大量に追加すると、正常なメールまで失う可能性があります。明らかな異常を拒否し、ログを確認しながら段階的に追加します。

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unlisted_recipient,
    reject_unauth_destination

smtpd_sender_restrictions =
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

smtpd_data_restrictions = reject_unauth_pipelining

reject_unknown_client_hostnameのような強い拒否は、設定不良の正規サーバーも落とす可能性があります。導入するならログで影響を確認してからにします。

postscreenでボットをSMTP処理の前に減らす

postscreenは25番への接続をSMTPデーモンへ渡す前に検査し、早すぎるコマンド送信など、正常なメールサーバーらしくない動きを見つけます。最初は記録だけの既定動作で観察し、問題がないことを確認してからenforceへ進めます。

# /etc/postfix/main.cf
postscreen_access_list = permit_mynetworks
postscreen_greet_action = enforce
postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce

# DNSBLは利用条件と誤判定を確認してから追加
# postscreen_dnsbl_sites = zen.spamhaus.org*2
# postscreen_dnsbl_threshold = 2
# postscreen_dnsbl_action = enforce

master.cfでは25番の入口をpostscreenへ切り替え、通過した接続を専用smtpdへ渡します。

smtp      inet  n       -       n       -       1       postscreen
smtpd     pass  -       -       n       -       -       smtpd
dnsblog   unix  -       -       n       -       0       dnsblog
tlsproxy  unix  -       -       n       -       0       tlsproxy

587番のsubmissionへpostscreenを適用してはいけません。DNSBLには利用条件や問い合わせ上限があるため、名前だけコピーせず公式条件を確認します。

本文検査は専用フィルターへ任せる

Postfixの接続制御だけでは、本文内容や添付ファイルまで十分に判定できません。RspamdやSpamAssassinをmilter／コンテンツフィルターとして組み合わせ、スコアに応じて件名付与、隔離、拒否を行います。

いきなり削除せず、最初はヘッダーへ判定結果を付けて迷惑メールフォルダーへ振り分けます。誤判定を確認してから閾値を調整するほうが安全です。ウイルス検査が必要ならClamAVなどを別途組み合わせます。

SPF・DKIM・DMARCで送信ドメインを守る

受信SPAMを減らす設定とは別に、自分のドメインを騙った送信を判定しやすくし、正規メールが迷惑メール扱いされにくい状態を作ります。

仕組み役割DNS例
SPF送信を許可するサーバーを宣言example.jp TXT "v=spf1 ip4:203.0.113.10 -all"
DKIM送信メールへ電子署名し、公開鍵をDNSで公開mail2026._domainkey.example.jp TXT "v=DKIM1; k=rsa; p=公開鍵"
DMARCFromドメインとSPF／DKIMの整合を確認し、失敗時の扱いを宣言_dmarc.example.jp TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.jp"

SPFは実際に使うすべての送信元を含めます。DKIMはOpenDKIMやRspamdなどで署名し、秘密鍵をサーバー内で保護します。DMARCは最初にp=noneでレポートを集め、正規メールがSPFまたはDKIMで整合することを確認してからquarantine、最終的にrejectを検討します。

反映前後に検証する

# 差分として有効な設定を確認
postconf -n

# 構文とファイル権限を検査
postfix check

# 問題がなければ再読み込み
systemctl reload postfix

# 状態とログを確認
systemctl status postfix
journalctl -u postfix --since today

設定後も続けること

メールサーバーは公開して終わりではありません。OSとPostfixの更新、証明書更新、キューとログの監視、バックアップからの復元確認を続けます。特に認証情報が漏れると、正規ユーザーとして大量送信されるため、強いパスワードとレート制限が必要です。

参考：Postfix SMTP relay and access control、Postfix TLS Support、Postfix SASL Howto、Postscreen Howto、SPF RFC 7208、DKIM RFC 6376、DMARC RFC 9989

最初に守る3点

設定項目が多くても、優先順位は明確です。第三者への中継を拒否する。利用者の送信は587番＋TLS＋認証へ分ける。SPF・DKIM・DMARCを実際の送信経路に合わせる。この3点を先に完成させ、その後にpostscreenや本文フィルターを調整します。

トップへ戻る