You moved the website on Tuesday. Wednesday morning invoices stop reaching clients and Gmail drops your quotes into spam. The site loads fine. DNS looks "fine" in the panel. Nobody touched the mail server on purpose, but something in SPF, DKIM, or DMARC no longer matches reality.
Hosting changes and email changes are cousins, not twins. You can migrate WordPress without moving MX records and still break outbound mail if the site sends through PHP mail() from a new IP. You can keep Google Workspace and still break delivery if SPF only lists the old host.
What SPF, DKIM, and DMARC actually do
SPF tells receiving servers which hosts are allowed to send mail for your domain. It lives in a TXT record at the root or under a subdomain. If your newsletter tool, Google, and your web server all send as you@yourbusiness.ca, SPF must include all of them.
DKIM adds a cryptographic signature to messages so receivers can verify they were not tampered with in transit. Your mail provider gives you CNAME or TXT records to publish. No signature, or a broken key after a provider switch, hurts trust.
DMARC tells receivers what to do when SPF or DKIM fail (monitor, quarantine, reject) and where to send aggregate reports. Many SMBs run p=none at first, which is fine while you fix alignment.
None of this is WordPress-specific, but WordPress is how a lot of small businesses still send contact form mail and WooCommerce receipts from the same domain as their inbox.
What breaks when hosting changes
- Site sends mail from the new server IP but SPF still only authorizes the old host.
- Forms use SMTP with credentials tied to the previous provider's hostname.
- DKIM keys live at the old ESP; you copied DNS but not the signing setup in the app.
- Reverse DNS / PTR on a VPS does not match the From domain (common on fresh VMs).
- MX points to Google but PHP mail() tries to send locally anyway.
Read moving email when you change hosts and website migration without email downtime before cutover day so web and mail plans are written down.
A practical checklist after any hosting move
- List every system that sends as @yourdomain: Google/Microsoft, transactional SMTP (SendGrid, Mailgun), marketing tools, WordPress forms, WooCommerce, help desk.
- Export current DNS: SPF TXT, all DKIM CNAMEs, DMARC record, MX.
- Send test messages from each source to a Gmail account and a Microsoft account. View original / headers.
- Check SPF pass/fail in headers. Add includes or ip4 for the new sending path.
- Confirm DKIM passes for each sender. Rotate keys if you changed providers.
- Align From domain with the domain that signs DKIM and matches SPF (DMARC alignment trips people up here).
- Stop using raw PHP mail() on production if you care about deliverability. Use SMTP with a reputable relay or your workspace provider.
WordPress and WooCommerce specifics
Contact Form 7, Gravity Forms, WP Mail SMTP, and WooCommerce all need the same post-move love. Update SMTP host, port, and auth. Re-test order emails and password resets.
Plugins that "use default WordPress mail" will use whatever the server provides. On a new VPS that might be unconfigured Postfix sending from an IP with no reputation yet.
After migration, trigger: contact form submit, new user welcome, WooCommerce test order (gateway in test mode). If one works and another does not, you have multiple sending paths with different DNS requirements.
Canadian SMB nuance
Clients often ask whether mail "stays in Canada." MX location and where your SMTP relay processes mail are separate questions from where the website is hosted. Document both for privacy conversations. Fixing SPF/DKIM does not change data residency, but it does stop the embarrassing "why are our emails in spam" ticket.
Our shared IP vs dedicated IP for email post covers reputation when you send from hosting IPs instead of a dedicated mail provider.
Tools that save time
MXToolbox, Google Admin Toolbox, and provider dashboards show SPF/DKIM/DMARC at a glance. DMARC aggregate reports (rua) are noisy but useful once a month to spot stray senders you forgot about.
Do not publish multiple SPF TXT records at the root. Merge into one record with multiple includes.
Bottom line
After a hosting change, assume email authentication is wrong until test messages prove otherwise. Inventory every sender, fix SPF and DKIM for the new paths, route WordPress through proper SMTP, and only then tighten DMARC.
Migrating web or mail on Canadian infrastructure and want a second set of eyes on DNS? Talk with Swift Host. We would rather review records before launch than debug spam folders on Monday.
