メールサーバーのセキュリティ対策は、「なりすましを防ぐ（SPF・DKIM・DMARC）」「踏み台にされない（不正中継の防止と認証の強化）」「盗み見を防ぐ（TLS）」「穴をふさぐ（更新）」「異変に気づく（見張り）」の5つを、この順に固めていきます。自分でメールサーバーを動かしている人も、レンタルサーバーやメールサービスを契約している人も、まずDNSの設定を確かめるところから始められます。
結論：この順番で対策する
- 今の設定をDNSで確かめる（MX・SPF・DKIM・DMARC・逆引き）
- SPFとDKIMを整え、DMARCを p=none から始めて、レポートを見ながら quarantine、reject へ強める
- 不正中継（オープンリレー）になっていないか確かめる
- メールの送信には必ず認証を求め、暗号化していない通信でパスワードを送らせない
- メールソフトとサーバーの間はTLSで暗号化し、サーバー同士もTLSを使う
- メールサーバーのソフトとOSを更新し続ける
- DMARCレポートとログを見て、なりすましや乗っ取りに早く気づく
メールが届く仕組み（SMTP・POP3・IMAP、ポート番号、MXレコード）はメールサーバーの仕組みを図解｜SMTP・POP3・IMAPの違いとポート番号、MXレコードまでわかりやすく解説にあります。
自分でできる範囲を先に分ける
| 使い方 | 自分でやること | サービス側がやること（契約先の案内を確かめる） |
|---|---|---|
| レンタルサーバー・メールサービスを契約している | DNSのSPF・DKIM・DMARCの設定（管理画面でできることが多い）、アカウントのパスワード、メールソフトの暗号化の設定、DMARCレポートを見ること | サーバーのソフトの更新、不正中継の防止、TLSの証明書 |
| Postfixなどで自分で動かしている | 上の全部に加えて、不正中継の防止、認証、TLS、更新、ログの見張り | なし（全部自分） |
迷惑メール対策推進協議会のDMARC導入ガイドラインも、自分でメールサーバーを運用していない場合は、使っているメールサービスの機能を確かめて設定するよう求めています。
1. 今の設定をDNSで確かめる
まず、自分のドメインに何が設定されているかを見ます。example.com は自分のドメインに置き換えます。
メールを受け取るサーバー（MX）：
dig +short MX example.comSPF（v=spf1 で始まる行）：
dig +short TXT example.comDMARC：
dig +short TXT _dmarc.example.comDKIM（selector は、使っているメールサービスやサーバーで決めたセレクター名に置き換えます）：
dig +short TXT selector._domainkey.example.com送信に使うサーバーのIPアドレスの逆引き（PTR）。192.0.2.10 は自分の送信サーバーのIPアドレスに置き換えます：
dig +short -x 192.0.2.10GoogleとYahooは、メールを送るすべての送信者に、送信元のIPアドレスに正引き・逆引きのDNSレコードがあることを求めています。逆引きが出てこない、または送信サーバーの名前と合わない場合は、サーバーやIPアドレスの提供元に設定を頼みます。
2. なりすましを防ぐ：SPF・DKIM・DMARC
SPF・DKIM・DMARCのしくみとレコードの書き方はメールのドメイン認証とは？仕組みと重要性を徹底解説にあります。
SPF：自分のドメインから送るサーバーを全部書く
- 自分のサーバーだけでなく、メルマガの配信サービスや問い合わせフォームの送信など、自分のドメインでメールを送るサービスを全部入れます
- SPFの仕様（RFC 7208）では、
includeなどのDNSを引く項目は、include先で引く分も合わせて10個までです。超えると、SPFの結果がエラー（permerror）になり、正しいメールも認証に通りません。引いた名前が見つからない、または答えが0件だった問い合わせ（void lookup）は、2回までにするよう勧められています includeでほかのサービスのSPFを読み込んでいる場合は、相手の都合で中身が変わることがあります。迷惑メール対策推進協議会のガイドラインは、読み込み先のドメインの状態も定期的に確かめるよう勧めています
DKIM：送るメールすべてに署名する
- 送るメールに電子署名を付け、公開鍵をDNSに置きます。レンタルサーバーやメールサービスでは、管理画面で有効にできることが多いです
- Yahooは、DKIMの鍵の長さを1024ビット以上にするよう求めています
DMARC：p=none から始めて、reject を目指す
DMARCは、SPFかDKIMの結果がFromのドメインと合っているかを確かめ、合わないメールをどう扱ってほしいかを受け取る側に伝えます。迷惑メール対策推進協議会のガイドラインとフィッシング対策協議会のガイドラインは、どちらも段階を踏んで強めるやり方を示しています。
- レポートの宛先（
rua）を付けて、p=noneで始める。この段階では、受け取る側の扱いは変わりません - 届いた集約レポートを見て、自分の送ったメールがSPFかDKIMで合格しているかを確かめる。合格していない送り元（配信サービスなど）があれば、SPFやDKIMを直す
- 正しいメールが合格していることを確かめたら、
p=quarantine（迷惑メールに入れてもらう）、最後にp=reject（受け取らない）にする
フィッシング対策協議会のガイドラインは、p=none のままではなりすましメールがそのまま届き続けるとして、最終的に p=reject にすることを勧めています。総務省も2025年9月、電気通信事業者に向けて、DMARCの導入と「隔離」「拒否」のポリシーの設定などを要請しています。
レコードの例（レポートの宛先は自分で受け取れるアドレスにします）：
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"2026年5月に、DMARCの新しい仕様（RFC 9989・9990・9991）が出て、これまでのRFC 7489に置き換わりました。新しい仕様では、一部のメールだけにポリシーを当てる pct タグがなくなりました。代わりに、ポリシーを試している最中だと伝える t タグができ、t=y にすると、受け取る側には指定より1段ゆるい扱い（reject なら quarantine、quarantine なら none）が求められます。段階を踏むときは、pct ではなく、p の値を none、quarantine、reject と変えていきます。
メールを送らないドメインも守る
メールを送らないドメインやサブドメインも、なりすましに使われることがあります。迷惑メール対策推進協議会のガイドラインには、メールに使わないドメイン名への設定の項目があります。同じガイドラインは、送らないドメインには、SPFで「どのサーバーからも送らない」と示し、DMARCを p=reject にし、メールを受け取らないことを示すNull MX（RFC 7505）も設定する方法を挙げています。総務省も、2026年9月1日から、自分のドメイン（soumu.go.jp）のサブドメインになりすましたメールを拒否する対策を入れています。
example.net. IN MX 0 .
example.net. IN TXT "v=spf1 -all"
_dmarc.example.net. IN TXT "v=DMARC1; p=reject"3. 不正中継（オープンリレー）を防ぐ
認証なしで、どこからでもほかのドメインあてにメールを中継できる状態は、迷惑メールの踏み台に使われます。Postfixでは、中継の許可は smtpd_relay_restrictions で決めます。Postfix 2.10以降の初期値は、次のとおりです。
permit_mynetworks：信頼するネットワーク（mynetworks）からの中継は許すpermit_sasl_authenticated：認証した人からの中継は許すdefer_unauth_destination：それ以外からは、自分あて以外を受け付けない
自分の設定を確かめるには、サーバーで次を実行します。
postconf smtpd_relay_restrictions mynetworks mynetworks_style見るところは2つです。smtpd_relay_restrictions に reject_unauth_destination か defer_unauth_destination が入っているか。mynetworks が、サーバー自身や本当に信頼できる社内のネットワークだけになっているか。Postfix 3.0以降では、mynetworks_style の初期値が host（自分のサーバーだけを信頼する）になっています。古い設定を引き継いでいる場合は、広い範囲を信頼していないかを見直します。
4. 送信の認証を強める
総務省の2025年9月の要請には「踏み台送信対策」も入っています。不正中継をふさいでも、アカウントのパスワードを盗まれると、そのアカウントから迷惑メールを送られてしまいます。
- メールソフトからの送信は、587番（STARTTLS）か465番（最初からTLS）で受け、SMTP認証を必ず求めます
- 暗号化していない通信では、パスワードを受け付けないようにします。Postfixでは
smtpd_tls_auth_only = yesにすると、TLSを使っていない接続では認証を出さず、受け付けもしません - Dovecot 2.4では
auth_allow_cleartextの初期値がnoで、TLSを使っていない接続では、パスワードによるログインはできません（同じサーバーの中からの接続など、安全とみなす接続は除きます。2.3まではdisable_plaintext_auth） - パスワードを当てようとする試行を減らします。Postfixの
smtpd_client_auth_rate_limitで、1つの接続元が一定の時間に送れるAUTHの回数をかぎれます（初期値は0で、制限なし）。Dovecotは、認証に失敗したときに返事を遅らせます（auth_failure_delay、初期値2秒） - アカウントごとに長いパスワードを使い、ほかのサービスと使い回しません。使っていないアカウントは消します
Postfixで、TLSと認証まわりの今の設定を見るには：
postconf smtpd_tls_security_level smtpd_tls_auth_only smtpd_sasl_auth_enable smtpd_client_auth_rate_limitDovecotの設定のうち、初期値から変えているものを見るには：
doveconf -n5. 通信をTLSで暗号化する
メールソフトとサーバーの間
RFC 8314は、メールソフトとサーバーの間の通信を暗号化し、暗号化しないサーバーはできるだけ早くやめるよう求めています。送信は587番（STARTTLS）か465番、受信はIMAPの993番かPOP3の995番を使います。メールソフトの設定で「暗号化なし」になっていないかも確かめます。
自分のサーバーの証明書と、TLSでつながるかは、次で確かめられます（mail.example.com は自分のサーバー名に置き換えます）。
openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com
openssl s_client -connect mail.example.com:993 -servername mail.example.com出力の Verify return code: 0 (ok) で証明書が正しく確かめられたこと、証明書の名前と期限が合っていることを見ます。
サーバー同士の間
Googleは、メールの送信にTLSを使うことを送信者に求めています。Postfixで受ける側は smtpd_tls_security_level = may にするとSTARTTLSを出します。Postfixの文書は、MXとして公開しているサーバーでTLSを必須（encrypt）にしてはいけないとしています。送る側は smtp_tls_security_level = may で、相手が対応していればTLSを使います（Postfix 3.11からは初期値が may）。
さらに、受け取る側としてTLSを必ず使ってほしいと示す仕組みに、MTA-STS（RFC 8461）があります。TLSでの配送に失敗したときに報告を受け取る仕組みに、TLS-RPT（RFC 8460）があります。どちらも、自分のドメインに設定があるかをDNSで確かめられます。
dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com6. ソフトとOSを更新し続ける
Postfixは、最新の系統（stable release）と、いくつかの古い系統（legacy release）に、修正を入れたリリースを続けて出しています。自分のサーバーで動いているバージョンを確かめ、OSのパッケージの更新などで、修正の入ったバージョンにしておきます。
postconf mail_version
dovecot --versionOSが配っているパッケージを使っている場合は、OSのパッケージの更新で、Postfix・Dovecot・OpenSSLも新しくなります。OSそのもののサポートが終わると更新が届かなくなるので、OSのサポート期限も見ておきます。メールサーバーへの通信を、使うポートだけに絞るのはファイアウォールの重要性と仕組みを徹底解説を見てください。
7. 見張る：DMARCレポートとログ
- DMARCの集約レポートで、自分のドメインを名乗って送っている、知らない送り元がないかを見ます
- 送信の数が急に増えていないか、キューに配送待ちのメールがたまっていないかを見ます。アカウントを乗っ取られて迷惑メールを送られていると、ここに出ます
- Gmailあての状態は、GoogleのPostmaster Toolsで見ます。Googleからは、迷惑メール率を0.3%未満に保つよう求められています。Yahooには、迷惑メールとして報告されたことを知らせる仕組み（Complaint Feedback Loop）があり、DKIMで署名したメールが対象です
Postfixでキューにたまっているメールを見るには：
postqueue -pよくある質問
レンタルサーバーのメールでも対策は必要ですか
必要です。サーバーのソフトの更新や不正中継の防止はサービス側がしますが、自分のドメインのSPF・DKIM・DMARCの設定と、アカウントのパスワードは自分で決めます。契約先の管理画面と案内で、設定できる項目を確かめます。
DMARCをいきなり p=reject にしてもいいですか
自分のメールが全部SPFかDKIMで合格していると確かめられないうちは、p=none から始めます。配信サービスや社内のシステムから送っているメールが合格していないと、reject にしたとたんに届かなくなります。転送やメーリングリストでは認証に失敗することがあり、総務省も、転送のしかたによっては自分たちのメールを受け取れなくなることがあると案内しています。
Gmailの送信者ガイドラインは、何通から関係しますか
すべての送信者に、SPFかDKIM、正引き・逆引きのDNS、TLSでの送信、迷惑メール率0.3%未満が求められています。1日に5,000通以上を送る場合は、SPFとDKIMの両方、DMARC（p=noneでもよい）、Fromのドメインの一致、マーケティングなどのメールでのワンクリックでの登録解除も必要です。くわしくはGoogleの「メール送信者のガイドライン」を見てください。
参考リンク
- 送信ドメイン認証技術 DMARC 導入ガイドライン（迷惑メール対策推進協議会）
- フィッシング対策ガイドライン（フィッシング対策協議会）
- フィッシングメール対策の強化に関する要請（総務省）
- 総務省を装ったなりすましメールへの対策強化について（総務省）
- メール送信者のガイドライン（Google）
- Sender Best Practices（Yahoo Sender Hub）・Complaint Feedback Loop（Yahoo Sender Hub）
- RFC 9989：DMARC・RFC 9990：DMARCの集約レポート・RFC 9991：DMARCの失敗レポート・RFC 7208：SPF・RFC 8314・RFC 8461：MTA-STS・RFC 8460：TLS-RPT・RFC 7505：Null MX
- Postfix SMTP relay and access control・Postfix TLS Support・postconf(5)・Postfix Announcements
- Dovecot Settings
コメント