☰

Office 365 への Postfix リレー - DNS 構成

tag-icon • tag-icon postfix smtp office365 e-mailrelay
Office 365 への Postfix リレー - DNS 構成

電子メールが SPAM としてフラグ付けされる可能性を減らすには、電子メール サーバーで次のいくつかのことを行う必要があると思います。

  • ホスト名は有効なIPに解決されます。例:メールに1.1.1.1
  • 逆DNSが存在する。例:1.1.1.1ポイントメール
  • メールサーバーは「HELO」コマンドを発行します。メール
  • メールサーバーにはMXレコードがあり、メール
  • 含めるSPFレコード1.1.1.1承認された送信サーバーとして
  • DMARC および DKIM が検証されます。メール サーバーによって暗号化された DKIM 署名と公開キーは復号化に使用できます。

Postfix サーバーが Office 365 にリレーする場合、DNS をどのように構成しますか?

SMTPリレーはオプション3で設定されています。こちらを参照してください。記事)。以下に挙げた内容は、SMTP リレーを設定する場合にのみ適用され、SMTP 認証には適用されないと考えています (SMTP 認証を使用する場合、HELO 交換は Office 365 と受信者のサーバー間で行われるため、これは適用されません)。

  • Postfixサーバーは有効なIPに解決する必要があります。例:メールに1.1.1.1
  • 逆DNSが存在する例1.1.1.1ポイントメール。
    • 複数のドメインがあり、同じIPからサーバーが送信している場合はどうなるでしょうか？サーバーがそれぞれのドメインをホスト名として使用している場合、これは問題になりませんか？例：mail.abc-domain.comそしてメール同じパブリック IP アドレスを使用する 2 つの別々のサーバーです。
    • 解決策としては、サーバーがどのドメインを中継しているかに関係なく、すべてのサーバーで HELO 交換に同じホスト名を使用することでしょうか? 代わりに、ドメインごとに 2 つのパブリック IP を持つこともできます。
  • Postfixサーバは次のように「HELO」コマンドを発行する。メール。
  • MXとして設定例: mail.protection.outlook.comのために例.comメールは Office 365 に配信されます。このシナリオでは、Postfix サーバーはリレー サーバーとしてのみ使用されます。
  • SPFレコードには両方を含める必要があります1.1.1.1そしてこのサイトについて。
    • Office 365 への SMTP リレーには、HELO 交換に Postfix サーバーのホスト名と IP が含まれるため、SPF レコードに Postfix のパブリック IP を含めることが重要です。
    • Office 365が代わりにメールを送信します例.com認証されたユーザー（Outlookユーザーなど）の場合、これが理由ですこのサイトについてSPF レコードにも必要です。
    • example.com には、2.2.2.2 の Web サーバーへの PTR レコードがすでに存在します。Web サーバーは、自身を指す PTR レコードを必要としないはずなので、PTR を Postfix サーバーに変更しても安全だと思います。PTR レコードには他にどのような使用例がありますか?
  • DMARC および DKIM が検証されます。
    • Postfix サーバーと一般ユーザー (Outlook ユーザー) の両方が Office 365 に電子メールを送信するため、DKIM 署名は Office 365 で暗号化される必要があると考えています。これは正しいです？

前述したように、以下に示すように、Postfix が電子メール ヘッダーにホスト名と IP を含めていることがわかります。

Hop Delay   From    By  With    Time (UTC)  Blacklist
1   *   userid  mail.example.com        9/8/2023 6:38:37 AM 
2   1 Second    mail.example.com 59.154.1.42    SY4AUS01FT019.mail.protection.outlook.com 10.114.156.121    Microsoft SMTP Server   9/8/2023 6:38:38 AM Not blacklisted
3   1 Second    SY4AUS01FT019.eop-AUS01.prod.protection.outlook.com 2603:10c6:10:1f4:cafe::15   SY5PR01CA0071.outlook.office365.com 2603:10c6:10:1f4::9 Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)    9/8/2023 6:38:39 AM Not blacklisted
4   0 seconds   SY5PR01CA0071.ausprd01.prod.outlook.com 2603:10c6:10:1f4::9 ME3PR01MB7048.ausprd01.prod.outlook.com 2603:10c6:220:16d::8    Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)    9/8/2023 6:38:39 AM

受信したメールのヘッダーを見ると、メールをOffice 365に中継するときにPostfixサーバーでHELOコマンドが開始されていることが分かります。

Received-SPF: Pass (protection.outlook.com: domain of example.com designates
 1.1.1.1 as permitted sender) receiver=protection.outlook.com;
 client-ip=1.1.1.1; helo=mail.example.com; pr=C
Received: from mail.example.com (1.1.1.1) by
 SY4AUS01FT019.mail.protection.outlook.com (10.114.156.121) with Microsoft
 SMTP Server id 15.20.6768.30 via Frontend Transport; Fri, 8 Sep 2023 06:38:38
 +0000

一方、Outlook経由でOffice 365経由で送信する場合、HELOはOffice 365から開始されます。

Received-SPF: Pass (protection.outlook.com: domain of example.com
 designates 40.107.108.68 as permitted sender)
 receiver=protection.outlook.com; client-ip=40.107.108.68;
 helo=AUS01-ME3-obe.outbound.protection.outlook.com; pr=C
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (40.107.108.68)
 by ME3AUS01FT015.mail.protection.outlook.com (10.114.155.141) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.6792.19 via Frontend Transport; Wed, 13 Sep 2023 04:01:55 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;

答え1

まず、Postfix サーバーのホスト名が有効な IP アドレスに正しく解決されることを確認します (例: 'mail.example.com' から '1.1.1.1')。さらに、'1.1.1.1' を 'mail.example.com' にリンクする逆 DNS レコードが設定されていることを確認します。これらの基本的な DNS 設定は、信頼を確立し、スパムとしてフラグ付けされることなく電子メールを配信する上で重要な役割を果たします。

複数のドメインが共通のパブリック IP を持つ単一のサーバーを共有するシナリオでは、HELO 交換に「mail.example.com」などの一貫したホスト名を採用することを検討してください。これにより、構成と管理が簡素化され、必要な SPF レコードが 1 つだけになります。ただし、ドメインの 1 つがブラックリストに登録されると、すべてのドメインにわたるメールの配信に影響する可能性があるため、注意が必要です。または、各ドメインに個別のパブリック IP を割り当てることもできます。これにより分離と回復力が強化されますが、構成と管理がより複雑になります。

SPF DNS レコードには、Postfix サーバーのパブリック IP ('1.1.1.1') と Office 365 の SPF レコード ('spf.protection.outlook.com') の両方を含めることが重要です。この手順は、Office 365 がドメインに代わってメールを送信する場合があるため、特に Outlook ユーザーなどの認証済みユーザーに対しては重要です。SPF レコードの例は次のようになります: 'v=spf1 a:1.1.1.1 include:spf.protection.outlook.com ~all.'

'example.com' の PTR レコードが存在し、Web サーバーの IP ('2.2.2.2') を指している場合、それを Postfix サーバーを指すように変更しても、Web サーバーに悪影響はありません。PTR レコードは、サーバーの信頼性を検証する上で役立ち、サーバーの機能を正確に反映する必要があります。このコンテキストでは、'1.1.1.1' の PTR レコードを更新して 'mail.example.com' を指すようにすることは、電子メール サーバーとしての役割と一致します。

Office 365 で DKIM 署名が正しく暗号化されていることを確認します。Postfix サーバーと Outlook ユーザーの両方が Office 365 に電子メールを送信し、適切な DKIM 暗号化が電子メールの認証と信頼性に不可欠であるため、これは極めて重要です。Office 365 はすべての送信電子メールに DKIM で自動的に署名するため、ユーザー側で追加の構成を行う必要はありません。

これらの DNS および電子メール構成のベスト プラクティスに従うことで、Office 365 での電子メール リレーの信頼性を高めることができます。これにより、電子メールの配信性が向上し、電子メールがスパムとしてフラグ付けされる可能性が低くなります。Postfix サーバーと Office 365 間の電子メール接続を暗号化して、セキュリティとプライバシーを強化します。安全な電子メール リレーのために、SMTP AUTH を使用して Office 365 で認証するように Postfix を設定します。

定期的に電子メール ヘッダーを検査して、HELO コマンドがサーバーのホスト名と一致していることを確認し、電子メールが正常に配信されるようにします。

答え2

リレーは電子メールの送信とはまったく異なります。あなたが説明した対策は電子メールの送信に関するものです。すべきこれらはすべて電子メールの中継とは無関係です。

Postfix サーバーと一般ユーザー (Outlook ユーザー) の両方が Office 365 に電子メールを送信するため、DKIM 署名は Office 365 で暗号化される必要があると思います。これは正しいですか?

いいえ、意味がありません。DKIM標識電子メール。受信者は署名を検証します。署名を読み取れない場合は検証できません。

関連情報