Why TYPO3 mail delivery fails after a server move

TYPO3 mail delivery fails after moving to a new server when one of the handoffs changes: PHP can no longer reach the local mail agent, that agent cannot authenticate to the SMTP relay, or the new IP and hostname fail a receiver’s checks. The TYPO3 form may still report success because a transport can acknowledge that it queued a message without confirming delivery. That makes the fault resemble an application bug even when the TYPO3 installation is otherwise healthy.

Treat the incident as a delivery chain rather than a single setting. Check sender DNS, the server’s mail client, the local transfer agent, TYPO3 transport configuration and the provider response in that order. Keep the old host available for comparison, but do not copy its secret values blindly: password storage, outbound firewall rules and TLS policies can differ between Australian hosting providers even when the domain and application are identical.

Recognise where the delivery chain breaks

Start by classifying the symptom. A TYPO3 error or an SMTP connection refusal points to configuration, authentication or connectivity. A message accepted with no later bounce points towards DNS, reputation or content filtering. Delivery delayed until a queue drains suggests a stalled mail service, an unsent queue or a worker that was not restarted after deployment.

Before changing production settings, send one controlled message to an address on another provider and record the exact time, sender, envelope-from address and TYPO3 log entry. Repeat the same test on the previous host if possible. A general server troubleshooting reference can help separate host-level failures from DNS and application-level ones without exposing SMTP passwords.

Rebuild sender DNS and reputation

Sender DNS is the most common hidden dependency. SPF must authorise the new server or relay, DKIM must use a selector whose public key is published, and DMARC must align with the visible From domain. If a third-party relay sends the mail, its sending domain belongs in SPF and the DKIM signature should be generated by that provider. Review DNS immediately after every hostname or mail-routing change.

A fresh VPS in Sydney, Melbourne or Brisbane may have no reverse DNS, a generic hostname or an IP with no sending history. Set a stable fully qualified hostname, ensure PTR matches it, make that name the SMTP HELO identity, and use TLS consistently. Warm the new address gradually with legitimate mail rather than a bulk campaign. If the business uses a .com.au domain, allow for DNS propagation and keep the authoritative nameservers and mail records in the same administrative account.

For Australian commercial messages, technical success is not enough. The Spam Act 2003 requires consent, clear sender identification and a working unsubscribe path for most marketing email, while transactional invoices can be treated differently. Keep the TYPO3 template compliant because compliant wording reduces filtering complaints, and make sure links, tracking and reply-to addresses behave consistently across the new host.

Configure the outbound mail path

On a typical Linux host, PHP hands mail to Postfix, Exim or sendmail, which then relays it. Confirm the PHP sendmail path, that the mail service is running, and that the local socket or binary is reachable under the web-server user. A container image may contain PHP without the MTA package, and a server migration often leaves the queue directory owned by the previous account.

Using an authenticated SMTP relay is usually clearer. Confirm the host, port, encryption mode, username and password in the provider’s current documentation; 587 with STARTTLS and 465 with implicit TLS are common but not interchangeable. Check outbound firewall rules, the trusted certificate store and whether the account requires an app password. These details vary across Australian SMTP services and cPanel-based hosts, so copy the provider’s current values rather than values from an old server.

If TYPO3 uses a custom transport or extension, keep the SMTP exchange in one small, testable wrapper and log a sanitised connection result without recording credentials. For developers maintaining JVM services as well, the site’s Scala implicit classes guide shows the same design principle: extend behaviour through a focused wrapper instead of scattering transport calls through unrelated code.

Verify TYPO3 transport and queues

TYPO3 may read transport details from environment variables, installation configuration or the backend mail settings, depending on its version. Check the active installation configuration and deployment environment, then confirm that the server can resolve the configured host. If the new host stores secrets differently, an encrypted value carried over from the old server may no longer decrypt, producing an authentication or configuration error.

Run a test through TYPO3, then inspect the resulting envelope rather than trusting a green success message. PHP’s mail function can report that the local agent accepted a message while the agent later rejects it. Test an external mailbox and the domain’s own mail system, and check that queued jobs have a worker running. A TYPO3 cache or deployment script may clear application state without starting the mail or queue process.

Read the TYPO3 log, MTA log and provider response as one timeline. Record connection timeouts, authentication results, queue IDs and final status codes. Keep timestamps in UTC while comparing them: daylight-saving changes can make a Brisbane server log and a Sydney administrator’s laptop appear to disagree by an hour. Mail payloads can also contain personal information covered by the Privacy Act 1988 and Australian Privacy Principles, so restrict access and avoid copying full messages into public issue trackers.

Use a focused verification checklist

Start at the outside edge and work inward; each answer removes a layer of uncertainty.

DNS and identity

• Confirm SPF includes the actual sending service.
• Verify the active DKIM selector and public key.
• Check DMARC alignment and recent aggregate reports.
• Match PTR, hostname and the SMTP greeting name.

If those records pass, the next pass covers the application and host:

Application and delivery

• Test SMTP connectivity from the web-server user.
• Review TYPO3 and MTA logs against one timestamp.
• Check queue workers, service permissions and disk space.
• Compare envelope, header and final bounce details.

Stop at the first layer that produces a concrete error. That evidence is more valuable than changing DNS, PHP settings and TYPO3 configuration simultaneously.

Put a repeatable migration routine in place

Before cut-over, document the old mail path: DNS owner, sender hostname, relay provider, ports, certificate issuer, transport configuration and the queue procedure. Lower DNS TTL far enough in advance, then export only the required mail settings and secrets through the approved deployment process. Verify both a normal message and one sent during a password reset, because password-reset mail exercises a different TYPO3 workflow.

After cut-over, watch queues, bounces and provider logs for at least one normal business cycle. Australian trades, clinics and professional services often depend on emailed invoices, booking reminders or job notifications, so a delayed message can affect customers as well as internal reporting. Run the post-deploy checks through the same automation as the rest of the release; the Coding Journal’s Capistrano cache warm-up hook demonstrates how a small deployment hook can make routine post-release work repeatable.

Make server migration include mail delivery in its definition of done. Update the runbook now, assign an owner to DNS and queue checks, and schedule a real customer-message test after every host change. Treat a successful handover as evidence of a working chain: signed outbound mail, accepted SMTP sessions, cleared queues and no unexpected bounces.