To reduce the likeliness of email being flagged as SPAM, I believe these are the few things that should be done on email servers:
- Hostname resolves to a valid IP e.g. mail.example.com to 1.1.1.1
- Reverse DNS exists, e.g. 1.1.1.1 points mail.example.com
- Mail server issues "HELO" commands as mail.example.com
- Mail server has an MX record pointing to mail.example.com
- SPF record to include 1.1.1.1 as an authorized sending server
- DMARC and DKIM validates. DKIM signature encrypted by the mail server and public key is available for decryption.
How would you configure the DNS when the Postfix server relays to Office 365?
SMTP relay has been configured with option 3, refer to this article). I believe what I have listed below only apply when setting up SMTP relay and not SMTP auth (I believe the HELO exchange will be done between Office 365 and the recipients server when using SMTP auth and hence the reason this does not apply).
- Postfix server should resolves to a valid IP e.g. mail.example.com to 1.1.1.1
- Reverse DNS exists e.g. 1.1.1.1 points mail.example.com.
- What would happen if there were multiple domains and server sending from the same IP? Wouldn't this be a problem if the server uses there respective domain as hostnames? E.g. mail.abc-domain.com and mail.example.com are two separate servers using the same public IP address.
- Is the solution to use the same hostname for HELO exchange on all servers regardless of which domain the server is relaying for? Alternatively, we can have two public IP for each domain instead.
- Postfix server should issue "HELO" commands as mail.example.com.
- MX set as example.mail.protection.outlook.com for example.com as mails are being delivered to Office 365. Postfix server is only used as a relay server in this scenario.
- SPF record should include both 1.1.1.1 and spf.protection.outlook.com.
- It seems SMTP relay to Office 365 includes the Postfix server's hostname and IP in the HELO exchange meaning it is important to include the Postfix's public IP in the SPF record.
- Office 365 will send emails on behalf of example.com for authenticated users (e.g. the Outlook users) which is the reason spf.protection.outlook.com is required in the SPF record also.
- A PTR record already exists for example.com which is to the web server on 2.2.2.2. Web server shouldn't need the PTR record pointing to itself, so I would think it is safe to change the PTR to the Postfix server. What other use cases are there for the PTR record?
- DMARC and DKIM validates.
- I believe DKIM signature should be encrypted in Office 365 as both the Postfix server and ordinary user (Outlook users) submit emails to Office 365. Is this correct?
As mentioned early, I can see Postfix has included the hostname and IP in email header as shown below.
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
In the email header received, I can see the email header shows the HELO command starts at the Postfix server when relaying emails to Office 365
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
In contrast, when sending via Office 365 through Outlook, the HELO starts at 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;
Best Answer
Begin by confirming that your Postfix server's hostname correctly resolves to a valid IP address, like 'mail.example.com' to '1.1.1.1'. Additionally, make sure there's a reverse DNS record in place, linking '1.1.1.1' back to 'mail.example.com'. These basic DNS settings play a critical role in establishing trust and delivering emails without being flagged as spam.
In scenarios where multiple domains share a single server with a common public IP, consider adopting a consistent hostname, like 'mail.example.com,' for the HELO exchange. This simplifies configuration and management and requires only one SPF record. However, be cautious, as if one of your domains gets blacklisted, it could impact email deliverability across all your domains. Alternatively, you can choose to assign separate public IPs to each domain. While this provides enhanced isolation and resilience, it's a more complex setup to configure and manage.
It's crucial to include both the public IP of your Postfix server ('1.1.1.1') and Office 365's SPF record ('spf.protection.outlook.com') in your SPF DNS record. This step is vital because Office 365 may send emails on behalf of your domain, particularly for authenticated users like Outlook users. An example SPF record could look like this: 'v=spf1 a:1.1.1.1 include:spf.protection.outlook.com ~all.'
In cases where a PTR record exists for 'example.com,' pointing to your web server's IP ('2.2.2.2'), altering it to point to the Postfix server shouldn't negatively impact the web server. PTR records are instrumental in validating server authenticity and should accurately reflect the server's function. In this context, updating the PTR record for '1.1.1.1' to point to 'mail.example.com' aligns with its role as an email server.
Ensure that DKIM signatures are correctly encrypted in Office 365. This is pivotal because both the Postfix server and Outlook users submit emails to Office 365, and proper DKIM encryption is essential for email authentication and trustworthiness. It's worth noting that Office 365 automatically signs all outgoing emails with DKIM, so no additional configuration is required on your part.
By following these DNS and email configuration best practices, you can enhance the reliability of your email relay with Office 365. This, in turn, boosts email deliverability and reduces the likelihood of emails being flagged as spam. Encrypt email connections between your Postfix server and Office 365 to enhance security and privacy. Set up Postfix to authenticate with Office 365 using SMTP AUTH for a secure email relay.
Regularly inspect email headers to ensure that HELO commands align with your server's hostname, ensuring successful email delivery.