Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Dns And Deliverability

Email Delivery Breaks After Moving DNS to Cloudflare

Restore website and company email after moving DNS to Cloudflare by auditing MX, SPF, DKIM, DMARC, mail hostnames and authoritative records.

Changing nameservers to Cloudflare makes its DNS zone authoritative. Mail records left only at the previous host stop being visible, and imported records may be incomplete or incorrectly proxied.

Separate inbound mailbox routing from outbound WordPress authentication before making corrections.

Freeze the evidence

Record the nameserver-change time, previous DNS provider, mail provider and first observed failure. Export or capture both old and current zones before editing.

Use a synthetic form message and note whether WordPress generated it, the sending provider accepted it and the recipient gateway saw it. Also test inbound company mail separately.

Do not change MX, SPF and SMTP settings simultaneously; the result will not identify the repaired layer.

Confirm Cloudflare is authoritative

Query the domain’s NS records and compare them with the nameservers assigned in the Cloudflare account. Check delegation at the registrar, including spelling and any DNSSEC status.

If DNSSEC was enabled at the old provider, a stale DS record can cause validation failures. Coordinate removal or replacement carefully through the registrar and Cloudflare instructions.

Do not assume the Cloudflare dashboard is live until public delegation confirms it.

Restore MX records exactly

Compare the current MX hosts, priorities and trailing domain names with the mailbox provider’s official configuration. MX targets must resolve and must not point to a Cloudflare-proxied web address.

Create the accompanying mail host A/CNAME records as DNS-only when the provider requires them. Cloudflare’s normal HTTP proxy does not proxy arbitrary SMTP delivery.

Keep old MX records only if the provider documents them as part of the active service.

Rebuild sender authentication

Copy the legitimate SPF policy into one TXT record at the correct hostname. Publish DKIM selectors or CNAMEs from the actual SMTP providers and the intended DMARC record at _dmarc.

Verify hostnames after Cloudflare’s interface appends the zone. Duplicate SPF records and selector names entered twice are common migration mistakes.

Never copy private DKIM keys or authorise a former provider that no longer sends.

Check mail-related proxy status

Mail hostnames used for IMAP, POP or SMTP should normally be DNS-only unless a supported mail service explicitly says otherwise. An orange-cloud proxy address can cause mail clients or WordPress SMTP to connect to the wrong network endpoint.

Website A/CNAME records may remain proxied; mail and web services do not need identical proxy settings.

Document each record’s owner and purpose before changing its status.

Review WordPress SMTP hostnames

WordPress should use the mail provider’s documented SMTP hostname. If it uses mail.yourdomain.example, confirm that name resolves directly to the correct mail server and has a matching TLS certificate.

Check port, TLS mode and outbound hosting restrictions. A DNS move can expose an old local hostname that previously resolved differently inside the hosting network.

Do not disable TLS verification to accommodate a mismatched hostname.

Allow propagation without guessing

Compare public resolver answers with the previous TTL. Some senders will temporarily see cached old records while others use Cloudflare.

Avoid repeated record deletion during that window. Use uniquely labelled tests and record which resolver or receiving system produced each result.

Lower TTL before a planned migration, not after a failure when old caches already exist.

Verify inbound and outbound independently

For inbound mail, send to an actual company mailbox and confirm the provider receives it. For website mail, submit the real form and trace notification generation, SMTP acceptance and final delivery.

Inspect SPF, DKIM and DMARC results from the delivered website message. Check that replies go to the synthetic visitor and that no local hosting mailbox captured the message.

Request urgent repair when the old zone is unavailable, DNSSEC validation fails or business mail routing is uncertain. Share public DNS and redacted status codes—never registrar, Cloudflare or mailbox passwords.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

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.

Assess my incident