Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Email Stops Working After Moving a WordPress Website

A website migration can change the server that sends application mail without moving the mailboxes. WordPress may report success while the new host blocks outbound connections, uses an unauthorised IP or retains staging SMTP settings. Separate website-generated messages from mailbox delivery before changing DNS.

Define what stopped

Test a specific message path: password reset, contact notification or administrative alert. Record time, recipient, sender, plugin result and any message ID. Ask whether normal mailbox-to-mailbox email also fails.

If only WordPress notifications fail, do not replace MX records. MX controls where inbound mail arrives; it does not configure WordPress sending.

Map the intended mail architecture

Document who hosts the mailboxes and how the application should send: authenticated external SMTP, hosting mailbox SMTP, transactional provider or local server mail. Record host, port, encryption, username and permitted From domain without copying passwords into a ticket.

The migration plan should keep inbound DNS and application sending as separate workstreams.

Check the WordPress configuration

Inspect the active SMTP/mail plugin and any constants or environment variables. Cloned sites commonly retain a staging sender, disabled-delivery flag or old encrypted credentials tied to another server.

Send one instrumented test and read the exact error:

Connection timed out -> routing/firewall/port likely
Authentication failed -> credentials or provider policy likely
Sender rejected -> From identity/domain policy likely
Accepted with message ID -> investigate delivery after handoff

Do not expose full SMTP transcripts publicly; authentication material can appear in them.

Verify outbound connectivity

Some shared hosts block port 25 or all external SMTP except approved relays. Test the configured hostname and port from the new server, including DNS resolution and TLS negotiation. Typical authenticated ports are 587 with STARTTLS or 465 with implicit TLS, subject to provider documentation.

Do not disable certificate validation to bypass a hostname or trust error. Correct the server name, certificate chain or system time.

Reauthorise the new environment

Providers may restrict sending by IP, region, application password, OAuth redirect URL or account policy. Update allowlists deliberately and remove the old IP after the rollback period.

Ensure the visible From address is permitted by the authenticated account. Keep Reply-To for the visitor’s address; impersonating a visitor in From often harms authentication.

Audit DNS without damaging inbound mail

Check authoritative SPF, DKIM and DMARC for the actual sending service. There must be one consolidated SPF TXT record, not several competing records. Enable DKIM through the provider that signs the message.

Preserve MX and mailbox-provider verification records unless the mail service is intentionally moving.

Trace delivery beyond WordPress

An SMTP “accepted” response means the next server accepted responsibility; it does not guarantee inbox placement. Use the provider log and message ID to see delivered, deferred, bounced, suppressed or rejected status.

Check recipient quarantine and suppression lists. Review headers on a delivered sample for SPF, DKIM and DMARC results.

Test every operational recipient

Test the site owner’s domain and an external mailbox. Verify password resets, form alerts, user confirmations and security/backup notices. Remove test submissions from analytics or business queues where appropriate.

Confirm old cron queues do not suddenly release duplicate messages after migration.

Check that scheduled reports and backup notifications use the same verified route. A repair tested only with one plugin can leave other WordPress mail paths silently dependent on the retired host.

Prevent another silent failure

Store a non-secret mail architecture record with hosting documentation. Recurring monitoring should send a controlled application message, verify provider acceptance and alert on authentication or suppression errors. Also track domain/DKIM changes and credential expiry. Reliable email is demonstrated by traceable delivery, not a green WordPress notice.