Upcoming Primary MX Migration - 8/29/2025

Summary

We will be upgrading the operating system of our primary MX on 8/29/2025, starting at 10pm Eastern Time, with a planned outage time of no more than 3 hours. There will be a downtime for sending emails, as well as the ability to read incoming emails via IMAP. However, no incoming email will be lost, as it will be received by our backup MXs while the server is offline.

As part of this upgrade, we will be making changes to our DNS hostnames to realign our mail infrastructure under the Petalpost name, as well as to better setup our mail infrastructure for future changes.

Our Plan

Our current plan is as follows:

• We will have the new A/AAAA record for irys.petalpost.kazehana.io already in place. For any domains which are not under our control, MX records can be changed as of right now to use irys.petalpost.kazehana.io as the primary MX. We additionally have records for imap.petalpost.kazehana.io and smtp.petalpost.kazehana.io in place, but these cannot be used yet.
• TTLs will be dropped at least 24 hours in advance to 5 minutes.
• At start of maintenance, verify Postfix queues are empty and stop inbound mail flow on the primary MX. Mail will queue on the backup MXs.
• Export all mailbox & database files.
• Reinstall OS on primary MX. During the reinstall process, PTR records will be changed from irys.notfurprofit.org to irys.petalpost.kazehana.io. MX records on domains that we manage DNS for will be changed at this time also.
• After reinstall is complete, perform initial setup tasks, then begin running Ansible playbooks to configure the machine. To ensure services are not accessible until functionality is verified, we will firewall all mail ports.
• After Ansible playbooks have run, stop all services again so that mailboxes can be reimported. Once reimport is completed, start services and verify functionality.
• After functionality is verified, re-open all firewall ports, and flush queues on backup MXs so that queued mail is delivered immediately. Migration is completed at this stage.

Once 24 hours have passed, the TTL on the PTR record for IRyS' IP will reflect the new irys.petalpost.kazehana.io domain. At that point, we will be removing the irys.notfurprofit.org A/AAAA records. As our goal is to migrate away from legacy hostnames, we prefer to remove these swiftly. This also allows us to better identify any straggling clients and fix them sooner rather than later.

Changes Required for Petalpost Users

There are two primary changes for users of Petalpost:

• For domains that are not under our DNS control, you will need to change your primary MX record, so that the hostname is irys.petalpost.kazehana.io. This can be done now to avoid disruption later. If your domain is under our DNS control, we will make these changes on your behalf.
• Clients will need to set their IMAP settings to use imap.petalpost.kazehana.io for the IMAP server, and smtp.petalpost.kazehana.io for the SMTP submission server. This change must be done at the conclusion of the maintenance. It cannot be done before, as our current certificates do not contain the new hostnames. Clients will stop working after the maintenance if they are not changed over to the new hostnames, as the old hostname will not be on the new certificates.

Disruptions to Service

As noted in the summary, there will be a disruption to inbound and outbound mail during the reinstall process. Inbound mail will not be lost, as it will queue on our backup MXs, but it will not be accessible until the migration is completed.

Additionally, there is a very small possibility of some outbound mail being deferred or rejected for up to 24 hours after the migration. This is due to the TTL of IRyS' PTR record, which is set to 24 hours by the provider. We are not able to change this TTL. As a result, it is possible for mail systems that are very strict to defer outbound mail, as the EHLO/HELO of the mail server will be irys.petalpost.kazehana.io, but the PTR could still be cached as irys.notfurprofit.org.

There are two factors which we believe will mitigate this for most, if not all outbound mail:

• The first is that most mail providers do not require alignment between the EHLO/HELO of a mail server, and its PTR record. This is true for the major mail providers such as Google, Microsoft, Yahoo, etc. What many mail providers do require is that the PTR result for a mail server's IP address has an A/AAAA record which points back to that IP address (also known as Forward-confirmed reverse DNS or FCrDNS). This will be maintained throughout the migration, as we will not remove the irys.notfurprofit.org A/AAAA record until after the PTR TTL has expired. Therefore, any mail server which has the old PTR record cached will still see valid FCrDNS, same as hosts which correctly have the new PTR record.
• In the case of mail hosts which do have a strict EHLO/HELO <-> PTR check, it is highly likely that these would be destinations that we do not frequently send mail to. As such, it is unlikely that those hosts would have checked the PTR record of IRyS' IP address in the last 24 hours, resulting in the old name being cached. It therefore tracks that those hosts would be more likely to receive the new PTR record. To help with the possibility of any such hosts querying a public resolver which might cache the result, we will be flushing caches on the popular public DNS resolvers which offer such a mechanism.

Conclusion

As always, if you have questions or concerns, please do not hesitate to contact us ahead of the maintenance period. We will be happy to clarify as needed.

Otherwise, we appreciate your patience as we conduct these migrations. We will do our best to provide up to date information during the maintenance period on our public status page. Please keep an eye on this page during the maintenance period, as it will be our sole source of information during that time. If we need to extend the maintenance for any reason, that will be noted on the status page. If we are unable to commit to the prescheduled maintenance time, we will provide ample notification, and the maintenance will be rescheduled for a later date.