Summary

  • Hetzner says mail-port blocking is enforced per account. Moving a cloud server to another account’s project applies the new owner’s rules.
  • A month as a customer and payment of the first invoice establish eligibility to request unblocking of ports 25 and 465; approval remains case-by-case.
  • Port 587 through an external mail-delivery service is a documented alternative, not proof of equivalent architecture, service approval or inbox delivery.

The resource can move before the dependency does

Imagine an agency handing a mail-dependent application to its client. The server appears in the client’s project; the inventory now records the correct owner. It would be tempting to call the handover finished. That would overlook an explicit qualification in Hetzner’s Cloud server FAQ: mail-port restrictions are enforced per account, and a transferred server follows the rules of its new owner.

This is a hypothetical decision problem, not a report of a customer outage. If the destination account already has the relevant ports unblocked, the distinction may produce no interruption. If it does not, the old owner’s permission is not evidence that the new owner can use the same path. Hetzner expressly tells operators using ports 25 and 465 to check the new owner’s unblocked status before transferring.

The important boundary is consequently neither the server’s age nor whether its software once sent mail. It is the account to which the resource becomes subject. Treating successful ownership transfer as complete application acceptance would confuse a provider’s resource operation with the readiness of a dependency governed elsewhere.

A project invitation is not the whole transfer

Hetzner’s general Cloud FAQ describes transfer to another account through a project owned by that target account. The receiver creates the project and invites the current owner; the current owner moves the resource. The product-migration guide sets out the Cloud server exchange separately from its other product procedures.

This matters because access and ownership are not interchangeable. Collaboration in a project does not, by itself, mean that a different account owns it. The general FAQ distinguishes project roles and assigns the bill to the project owner. It also says that only the source project’s owner can move resources out. A team should therefore know whether its proposed handover changes the governing owner, not merely which people can see the server.

The analysis should remain within Cloud. Robot dedicated-server, domain and other migration procedures are not evidence that this account-bound Cloud mail policy can be bypassed or carried over. A familiar transfer procedure from another product is not a substitute for the rules attached to the resource actually being moved.

Eligibility is not an inherited approval

Hetzner explains the default blocking of ports 25 and 465 as a response to spam and fraud. Its English FAQ says that customers who have been with it for a month and paid their first invoice may request unblocking for a valid use case. The request is decided case by case. The German FAQ likewise describes individual review rather than automatic release.

Three different events must not collapse into one: satisfying the documented conditions, submitting a request, and receiving permission. An invoice is not an unlock receipt. A server that previously operated under another customer’s rules is not evidence of approval for its destination account. Nothing in the reviewed policy establishes that a machine’s history carries those conditions forward.

The general FAQ also describes limit requests as manually reviewed during business hours. It gives no guaranteed completion time for this port decision. A migration plan built around an assumed automatic or immediate approval would therefore contain a scheduling premise that the sources do not supply.

There is an economic reason for the extra discretion. Cheap and readily provisioned compute can be useful to legitimate applications and to abusive senders. A recipient or another network bears consequences that a server purchase alone does not price. Account-level controls let the provider assess the party receiving authority, not simply the existence of a payable machine. That is an interpretation of the policy’s incentive structure, not a measurement of abuse prevented.

The alternative changes who does the work

Hetzner documents port 587 through an external mail-delivery service as an alternative that does not require this limit request. It is not blocked under the stated policy. That can change a legitimate deployment’s dependency, but “587 is available” does not mean a direct mail setup can be reproduced by changing a number.

RFC 6409 separates message submission from relay and reserves 587 for submission. An external service introduces its own authorisation and operational relationship. The application must be accepted under that service’s conditions; network-port availability is not proof of that acceptance, or of a message reaching a recipient’s inbox.

For the handover decision, the useful distinction is between retaining a direct path subject to the destination account’s policy and arranging a supported external submission dependency. They may allocate effort and control differently. The reviewed sources do not provide a price comparison, service quota or deliverability result that would justify declaring one universally cheaper or safer.

Nor is this a recommendation to evade controls through a proxy or a disguised route. The documented alternative is a different service arrangement. Its value is in making the dependency explicit, not in pretending the provider’s account approval no longer matters to the original architecture.

Paying for a machine is not paying for readiness

The Cloud billing FAQ says a created server remains billable while it exists, including when switched off. Thus power state is not a general pause button for a waiting deployment’s resource charge. This is a bounded billing fact, not advice to delete a customer’s server or a calculation of migration losses.

It reinforces the distinction between acquiring capacity and commissioning the application. A resource can be present and chargeable while a required permission remains unresolved. The responsible investment case would acknowledge that possibility without inventing a waiting period, cost amount or rejection rate.

The conclusion is narrow but consequential. Moving a Hetzner Cloud server changes resource ownership; it does not establish that the old owner’s mail authority moved with it. Handover should be judged against the destination account and the application’s chosen mail dependency. A server inventory proves where the resource is. It cannot, alone, prove that the service is ready.

Sources