A domain migration can change the visible From address, sending provider, DNS authority, server IP and reputation at the same time. Messages may still be accepted but filtered because the new identity is unauthenticated or unfamiliar.
Use the headers from a delivered spam-folder test to identify the failing signal instead of asking recipients to whitelist everything.
Establish what changed
Record the old and new From domains, SMTP provider, server IP, DNS provider and migration date. Determine whether WordPress sends through local hosting, an authenticated mailbox or a transactional service.
Use one synthetic form submission with a unique reference and a business recipient you control. Preserve the full headers privately; do not publish recipient addresses, internal routing or message content.
Compare with a known-good pre-migration header if one exists.
Read authentication results
Find SPF, DKIM and DMARC results in the received header. SPF evaluates the envelope sender’s authorised infrastructure. DKIM validates a cryptographic signature and selector. DMARC checks whether an authenticated domain aligns with the visible From domain.
A message can pass SPF yet fail DMARC because SPF authenticated a provider domain that does not align with From. Record the exact domains, not only the word pass or fail.
Do not infer authentication from the website’s padlock.
Correct the WordPress sender
Set From to a stable address on the domain verified with the mail provider. Put the visitor’s submitted address in Reply-To. Sending as a visitor after migration creates both authentication and impersonation problems.
Check every form notification, WooCommerce email, password reset and custom wp_mail() call for old-domain overrides. SMTP tests may use the new sender while live forms still use the old one.
Keep a monitored return path for bounces.
Publish records at the active DNS provider
Confirm which nameservers are authoritative. Records left in the old hosting panel no longer apply after DNS moved elsewhere.
Publish one SPF policy that includes the actual sender and the provider’s exact DKIM selector. Add or adjust DMARC only after understanding existing sources and alignment.
Avoid duplicate SPF records, copied private DKIM keys and a sudden restrictive DMARC policy before testing.
Check reputation separately
A new sending domain or IP has little history. Send only genuine transactional messages, keep complaint and bounce rates low, and avoid bursts created by repeated diagnostics or a released queue.
If local hosting shares an IP with unknown senders, an established transactional provider can offer clearer reputation and event logs. Changing provider does not excuse incorrect authentication or compromised forms.
Check provider suppression lists and hard bounces before resending.
Review message construction
Migration tools can leave old HTTP links, staging domains, broken images or mismatched branding in notifications. Update links to the canonical HTTPS domain and keep the message concise and useful.
Avoid URL shorteners, unnecessary attachments and excessive sales language in operational form notifications. Include a legitimate text alternative for HTML mail where the mailer supports it.
Content improvements cannot compensate for failed authentication, but they remove avoidable filtering signals.
Ask the recipient system for evidence
If the sending provider accepted the message, ask the authorised company mail administrator to search the gateway by message ID and timestamp. Review quarantine reason, transport rules and impersonation protection.
Do not rely only on a user’s spam folder or a single Gmail test. Different domains apply different policies.
Make only a narrow allow rule after sender authentication is correct.
Prove stable recovery
After correcting the failed signal, submit a new form test. Confirm provider acceptance, final mailbox placement, Reply-To and SPF/DKIM/DMARC results.
Monitor several genuine low-volume notifications across recipient domains and review bounces. Reconcile entries created during the migration window.
Request urgent deliverability repair when DNS ownership is unclear, DMARC alignment varies or a shared IP is impaired. Share redacted headers and message IDs—never passwords or real enquiry bodies.