Emails are failing because your new hosting provider’s DNS zone file lacks the specific MX and TXT records required by Google Workspace. You must update your DNS settings immediately to include the five specific Google MX records and necessary security signatures to restore email service following your website migration.
Emergency Stop-Gap: If you are currently unable to receive vital incoming emails, contact your current web host’s support team right away. Provide them with the “Google Workspace MX Records” list; they can manually inject these into your zone while you perform a manual audit of your DNS settings to ensure everything is correctly synchronized.
Why is my mail failing after moving websites?
The migration process often involves a major shift in how the internet identifies your domain, specifically through the update of your nameservers (NS records). By changing these records, you are handing over the “keys” to your domain’s information to a new provider. The problem arises because if this new host’s zone file doesn’t include the specific routing instructions required for Google Workspace, the global mail servers lose their map. They simply don’t know which server is responsible for holding your inbox, so they can’t complete the delivery.
Most migrations result in what we call a “blank slate” for DNS records. It is very common for your website (the A record) to point correctly to the new host—meaning your site looks and functions perfectly—while the underlying email infrastructure (MX and TXT records) gets left behind or overwritten by the new host’s default settings. Without these specific pointers, Google Workspace cannot route incoming mail into your account. When this happens, the sender’s server detects the broken path, rejects the delivery entirely, and “bounces” the message back to the original sender.
Related guide: Fix WooCommerce Emails Not Sending After Plugin Update: A
What are the common causes of bounce-backs?
I know how unsettling it is to see a flood of delivery failure notifications hit your inbox right after a migration; it feels like your primary line of communication has been cut. Usually, these issues aren’t caused by “broken” mail, but by specific configuration gaps in your DNS settings that occurred during the move. Here are the three most common culprits.
Are my MX records missing?
Think of an MX (Mail Exchange) record as a physical signpost for the internet; it tells every sending server exactly where to deliver mail for your domain. If you moved to a new host and they defaulted your settings, your emails aren’t reaching Google Workspace because the “signpost” is pointing to an old or non-existent location. To function properly, Google Workspace requires five specific MX records. If your current host has replaced these with a local default, any email sent to you will bounce because it never reached Google’s infrastructure.
Was my SPF record wiped?
The Sender Policy Framework (SPF) is a TXT record that acts as an authorization list. It tells the rest of the world which specific IP addresses are permitted to send emails on your behalf. During a migration, many hosting providers reset these records to their own defaults. If your SPF record was deleted or still points toward your old server’s IP address, other mail providers will view your outgoing messages as unauthorized and flag them as spam or block them entirely before they even reach the recipient.
Did my DKIM signature break?
DomainKeys Identified Mail (DKIM) provides a digital “seal” on your emails to prove that the message hasn’t been tampered with in transit. This requires a specific TXT record within your DNS settings. During a migration, if this unique key wasn’t manually carried over to the new DNS zone, you will start seeing “failed authentication” errors. Google Workspace relies heavily on these signatures to maintain high deliverability; without them, your emails are much more likely to be rejected by the receiving servers.
Related guide: How to Clean Crypto Spam Hack Google Search Console
How do I identify the current state of my records?
Before you start making any adjustments, we need to establish a baseline by seeing exactly what is currently live on the internet. It is much safer to verify your existing setup before pulling any levers. You can use web-based tools like MXToolbox for a visual overview, or if you prefer to work directly in your terminal (CLI) to get raw data, you can run the following commands.
To check your MX records via terminal:
host -t mx yourdomain.comTo check for the presence of an SPF record:
host -t txt yourdomain.com_._notless_spf1~all(Note: Replace yourdomain.com with your actual domain.)
If these commands return values that are not Google-specific, it means your migration did not successfully include your email configuration. In that case, we will need to manually update those records to ensure your mail continues to flow correctly.
Related guide: Fix GoDaddy Managed WordPress Migration Failure
How do I fix the MX records for Google Workspace?
It is incredibly frustrating when your emails stop arriving or go into a black hole, but this is a standard configuration issue that we can resolve. The problem usually lies in how your domain points to Google’s mail servers. Think of these records as a set of directions; if they are slightly off, the internet doesn’t know where to deliver your messages.
To fix this, you need to access your DNS management console. Depending on your setup, this will likely be through a provider like Cloudflare, GoDaddy, or your primary hosting company’s control panel. You must replace any existing MX records with these five specific entries. These are the current standards required by Google Workspace to ensure every email reaches your inbox reliably.
| Record Type | Host/Name | Priority | Value/Points To |
|---|---|---|---|
| MX | @ | 1 | SMTP.GOOGLE.COM |
| MX | @ | 5 | ALT1.ASPM.GOOGLE.COM |
| MX | @ | 5 | ALT2.ASPM.GOOGLE.COM |
| MX | @ | 10 | ALT3.ASPM.GOOGLE.COM |
| MX | @ | 10 | ALT4.ASPM.GOOGLE.COM |
Note: Some older configurations might list different addresses, but Google’s simplified “SMTP.GOOGLE.COM” is the current standard.
How do I re-establish my SPF and DKIM records?
Setting up your MX records is a major milestone, but it isn’t the final step for reliable delivery. To ensure your emails actually land in your customers’ inboxes rather than being flagged as spam or rejected entirely, you must establish a verified “handshake” between your domain and Google’s mail servers. This happens through SPF and DKIM records.
How do I add the correct SPF record?
Your DNS requires a TXT record that explicitly lists Google as an authorized sender for your domain. It is vital to note that you can only have one SPF record; if you use additional services like Mailchimp or HubSpot, their include statements must be merged into this single line.
v=spf1 include:_spf.google.com ~allHow do I find my DKIM keys?
Unlike the SPF record, you cannot guess the values for your DKIM records. These are unique identifiers generated specifically for your account within the Google environment. You will need to pull these from your admin dashboard.
- Log into the Google Admin Console.
- Navigate to Apps > Google Workspace > Gmail.
- Locate the Email authentication section.
- If a record does not already exist, click Generate New Record.
- Copy the provided TXT record (it will look similar to
google._domainkey.yourdomain.com) and paste it into your DNS provider’s settings.
What is DNS propagation and why does it take time?
Updating your records doesn’t mean the change hits every corner of the internet at once. When you hit save, that information has to travel through a massive web of interconnected servers. This “propagation” period is essentially the time it takes for every global cache server to receive, process, and adopt your new data. Because different Internet Service Providers (ISPs) around the world update their caches at different speeds, this window can vary wildly—sometimes resolving in just a few minutes, but occasionally taking up to 48 hours.
I know waiting on these updates while your site or email is down is incredibly stressful, but it is a standard part of how the internet’s infrastructure functions. If you make changes and your emails are still bouncing immediately, you don’t have to just sit and wait for the “worst-case” timer to run out. You can use a tool like dig to see if the records have successfully updated on major public networks:
dig @8.8.8.8 yourdomain.com MX(This command specifically bypasses local cache issues by querying Google’s public DNS, allowing you to confirm if the global infrastructure has recognized your update.)
What common mistakes make this problem worse?
Even if you follow the primary instructions perfectly, a few specific technical nuances can still cause your mail delivery to fail. These are the “gotchas” I see most often when troubleshooting broken records:
Having multiple SPF records
Your DNS settings must contain exactly one SPF record. If your setup includes one for your web host and another for Google Workspace, many receiving mail servers will see the conflict and discard both. They aren’t designed to process multiple instructions for a single domain. You need to merge them into a single string like this:
v=spf1 include:_spf.google.com include:thirdparty.com ~all
Using the wrong “Host” field
When you are entering MX records into your DNS control panel, the “Host” or “Name” field can be tricky. Many systems automatically append your domain name to whatever you type in that box. If you enter yourdomain.com as the host, the system might record it as yourdomain.com.yourdomain.com. This creates a broken path for mail. For the root domain, you should typically use the @ symbol or leave the field blank, depending on your provider’s specific requirements.
Failing to update the CNAME records
If you rely on third-party platforms like SendGrid or Mailchimp for marketing, those services rely on specific CNAME records to verify your identity. During a migration, these are often overlooked because they aren’t tied to your primary inbox. If these aren’t ported over accurately, your standard emails might arrive fine while your newsletters and automated marketing blasts continue to bounce.
When should I call a professional?
I know how incredibly stressful it is when your site goes dark or your communication lines go silent. It feels like everything is breaking at once, but these issues are almost always fixable with the right technical intervention. You should reach out to a specialist if you hit any of the following roadblocks:
- Persistent Email Failures: If you have updated your MX records but your emails continue to bounce after a full 24-hour window, there is likely a configuration conflict that requires an expert’s eyes to untangle.
- Lost Credentials: It is common to lose track of login details during a migration. If you cannot access your DNS zone editor because you’ve lost the necessary credentials, a professional can help navigate the recovery process with your registrar.
- Complex “Split DNS” Requirements: If your business requires a “Split DNS” setup—where your web traffic and your email services are hosted by different providers—the configuration becomes much more involved. A specialist ensures these two systems communicate perfectly without dropping packets.
- Registrar-Level Blocks: If your domain is stuck in a “ClientHold” status at the registrar level, it usually indicates an administrative or verification issue that needs professional navigation to resolve.
Beyond these specific scenarios, hiring a professional allows for a comprehensive DNS audit. This is vital during a migration because it ensures that secondary records—the smaller pieces of code responsible for your contact forms, analytics tracking, and other background services—weren’t dropped during the move.
Summary of Action Items
I know how frustrating it is when your emails aren’t hitting inboxes—it feels like a black hole for your business communications. We can get this sorted out by correctly configuring your DNS records. Follow these specific steps to ensure your domain is properly authenticated with Google Workspace.
- Access your primary DNS management panel. It is critical that you log into the site where your nameservers are managed (usually your domain registrar), rather than just your web hosting dashboard. Getting this right ensures the “directions” for your email actually reach the destination.
- Verify and input the five Google MX records. These records act as the roadmap for incoming mail; they tell the internet exactly where to deliver your messages so they land in your workspace instead of getting lost.
- Update your TXT record for SPF. You need to add or update the following:
v=spf1 include:_spf.google.com ~all. This tells other servers that Google has your permission to send mail on your behalf, which drastically reduces the chance of your emails being flagged as spam. - Generate and paste your unique DKIM key. You will need to pull this specific string from your Google Admin Console. Think of this as a digital signature; it verifies that your email hasn’t been tampered with in transit.
- Allow for propagation time. DNS changes aren’t always instant. You may need to wait up to 24 hours for these updates to spread across the internet before you can reliably test your outgoing mail with external providers.
Reference: For official configuration details, refer to the Google Workspace Admin Help.