Your website · Updated October 4, 2026
Why did my email go to spam after we changed providers?
Updated October 4, 2026
Your email goes to spam because receiving servers check your domain's DNS records, and after you changed providers they still describe the old setup. Usually SPF names the old provider, DKIM was never turned on at the new one, or another sender, like your website form, fails DMARC. Read one message's header first.
If mail went to spam right after a move, the move broke authentication
If your messages started landing in spam the week you moved email, moved your website or added a tool that sends as your domain, fix the DNS records before you touch anything else. Receiving servers decide whether a message really came from you by checking three records published in your domain's DNS: SPF, DKIM and DMARC.
SPF lists the servers allowed to send for your domain. DKIM puts a signature on each message that a public key in your DNS can verify. DMARC tells receivers what to do when a message fails, and it only counts a pass when the domain that passed matches the one in the From line.
A move changes who sends your mail, but your DNS keeps vouching for whoever sent it before. Google's guidelines say messages that are not authenticated "might be marked as spam or rejected with a 5.7.26 error." Google requires every sender to personal Gmail accounts to set up SPF or DKIM, and Yahoo sets the same minimum.
The rules got stricter. Gmail and Yahoo began enforcing their sender rules in February 2024, and Google says that from November 2025 Gmail is "ramping up its enforcement", including "temporary and permanent rejections".
The three records
SPF, DKIM, DMARC
All three live in your domain's DNS, not in your inbox. Moving email does not move them for you.
For example
A roofing company moves its email from the web host to Google Workspace and adds Google's SPF record next to the host's old one. Two SPF records count as an error, so SPF fails on every message. DKIM was never turned on in Workspace either. Nothing passes, and quotes sent to customers' Gmail addresses land in spam.
Read one message's header before you change any record
Send a message from the new account to a personal Gmail address you own, then open the header and read the three results. Google notes you cannot check DKIM by sending yourself a test, so use an outside address.
- Open the message in Gmail on a computer. Next to Reply, click More, then Show original. The full header opens in a new window.
- Find the line that starts with Authentication-Results. It carries spf=, dkim= and dmarc=, each followed by pass or a failure.
- Note the domains on that line: smtp.mailfrom= shows the domain SPF checked, the DKIM part names the domain that signed (Microsoft shows it as header.d=), and header.from= is the domain your customer sees.
- To get the same results laid out for you, click Copy to clipboard and paste the header into the Messageheader tool in the Google Admin Toolbox.
A quicker check. In Gmail, click the down arrow under the sender's name. Google says a message is authenticated when it shows Mailed by and Signed by with the sending domain, and a question mark next to the sender's name means it is not.
Repeat the test for every system that sends as your domain: the website form, your invoicing tool, your CRM. Each one is a separate sender with its own result.
What each result means and which fix it points to
Google's SPF troubleshooting page maps the results. spf=neutral, softfail or fail usually means the server that sent the message is not in your SPF record. spf=permerror means the record itself is broken: two SPF records, or more than 10 lookups. No dkim= entry at all means the message was not signed. dmarc=fail with SPF or DKIM passing means the passing domain is not yours.
Microsoft's DMARC guide shows that last case in one line: spf=pass with smtp.mailfrom=bounces.adatum.com, dkim=pass with header.d=adatum.com, and dmarc=fail because header.from=contoso.com. Both checks passed for the sending service's domain and neither for the customer's. The fix is to make the service sign with your domain or send bounces through it.
The fixes, in the order to check them
If mail to you bounces or reaches the old inbox, fix the MX records first
If incoming mail is missing, open your DNS settings and make sure the only MX records are the new provider's. MX records tell other servers where to deliver mail for your domain, and they are separate from the records that decide spam.
Google's setup page for Workspace gives a single MX value, smtp.google.com, and is direct about the leftovers: "Remove any other MX records. Your email might not work correctly if you keep old or incorrect MX records." It allows up to 72 hours for a new MX record to be recognized.
Check where your DNS lives. If a website move also moved your domain's nameservers to the new host, your email records live there now. Make sure the MX, SPF, DKIM and DMARC records came across; a record left behind no longer exists. Cloudflare, for one, warns that its automatic import can miss records such as a custom-named DKIM key, and says to "review your DNS records and manually add any missing ones before changing your nameservers."
If SPF fails or shows permerror, merge everything into one SPF record
Keep exactly one TXT record that starts with v=spf1, and list every service that sends as your domain inside it. Delete the old provider's entry once nothing sends through it.
The SPF standard, RFC 7208, says a domain "MUST NOT have multiple records", and a check that finds more than one returns permerror. Microsoft puts it plainly: multiple SPF records "cause SPF to return permerror". A second record added during a move is an easy way to end up there.
Google's line is include:_spf.google.com and Microsoft 365's is include:spf.protection.outlook.com. Add each other sender's include to the same record, exactly as its own help page lists it.
Watch the 10 lookup limit. Each include, a, mx, ptr and exists costs a DNS lookup, and the RFC caps the total at 10 for the whole check, including the lookups inside each provider's own record. Go over and SPF returns permerror. Google's troubleshooting page warns the error can even look like you have no SPF record at all.
For example
A plumbing company's DNS has v=spf1 include:mail.oldhost.example ~all from the old host and v=spf1 include:_spf.google.com ~all from the move. Staff now send through Google, but the website form still sends through the old host's mail service. The fix is one record: v=spf1 include:_spf.google.com include:mail.oldhost.example ~all. When the form moves too, the old host's include comes out.
Why fewer than 10 includes can still break the limit
Google's setup page says an SPF record "can have up to 10 include: tags". Its own troubleshooting page and the RFC are stricter: nested lookups count. Microsoft gives the arithmetic: an include that points to a record with three more includes "adds four total lookups", so "having fewer than 10 include: statements doesn't guarantee fewer than 10 DNS lookups."
Count them with the Check MX tool in the Google Admin Toolbox or any SPF checker that shows the lookup total. ip4 and ip6 entries cost nothing. If you are over, remove services that no longer send, or move a newsletter or CRM to a subdomain such as news.yourdomain.com, which Microsoft notes gets "its own 10 lookup budget."
Should the record end in ~all or -all?
The two big providers disagree. Google recommends ~all and warns that a hyphen "can be overly restrictive and cause delivery issues for legitimate email." Microsoft recommends -all for Microsoft 365 domains because it also recommends DKIM and DMARC. Either one is valid. While you are still finding every sender, ~all is the safer of the two: a sender you missed is marked suspicious rather than likely rejected.
If the header shows no DKIM for your domain, turn DKIM on at the new provider
Generate the DKIM key in the new provider's admin, publish it in DNS, then switch signing on. Neither Google Workspace nor Microsoft 365 signs mail with your own domain until you do.
Microsoft says it in one line: "Currently, no DKIM signing occurs for outbound mail from custom domains." Google's setup has a step people skip: after the key is in DNS you still have to click Start authentication.
- Google Workspace. In the Admin console go to Apps, Google Workspace, Gmail, then Authenticate email. Click Generate New Record, choose 2048 if your DNS host supports it, publish the TXT record it shows (named google._domainkey), then come back and click Start authentication. The status should read Authenticating email with DKIM. Google says the key is only available 24 to 72 hours after Gmail is turned on, and DKIM can take up to 48 hours to start working.
- Microsoft 365. In the Defender portal go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings, then the DKIM tab. Select your domain, publish the two CNAME records it lists (selector1._domainkey and selector2._domainkey), then turn on Sign messages for this domain with DKIM signatures. The status should read Signing DKIM signatures for this domain.
Long keys get cut off. Google warns that most DKIM TXT records can hold 255 characters, so a 2048-bit key can be truncated. If DKIM still fails after 48 hours, compare the published key with the one in the Admin console.
If DMARC fails while SPF and DKIM pass, make one of them pass for your own domain
Get the sending service to sign with your domain or to use your domain for bounces, then start or keep DMARC at p=none until every sender passes.
Google spells out the rule: to pass DMARC, a message must pass SPF with alignment or DKIM with alignment. Aligned means the domain that passed is the one in the From line, or belongs to the same main domain under the default relaxed setting. A tool that passes SPF for its own domain still fails DMARC for yours.
Start with monitoring. Both Google and Microsoft say to begin with p=none and tighten to quarantine or reject only once reports show everything passing. Under p=quarantine, Google says failing mail is sent "to the recipient's spam folder". If you inherited a quarantine or reject policy and mail is now failing, that policy is doing exactly what it says.
Publish it as a TXT record at _dmarc.yourdomain.com, for example v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com, with reports going to a separate mailbox rather than your own. Google says to let SPF and DKIM run for 48 hours first.
Every other system that sends as you
If your website form sends from your own address, send it through an authenticated route
If form messages go to spam or vanish, change how the form sends: log it in to your mail provider over SMTP, or use a form or mail service you can add to SPF and DKIM. Do not leave it sending as you from the web server.
Many site forms are set to send each enquiry "from" the owner's own address to the owner's own inbox. The message then leaves from the web host's server, which is not in your SPF record and does not sign with your domain's DKIM key. To Gmail it looks like someone else using your address, and with a DMARC policy in place it fails. Google's guide to contact forms says the form "isn't the cause of the issue, but how the message is sent", and that a form "is an email sender for your domain."
Google lists three ways a form passes: SPF, SMTP relay or DKIM. Ask your form provider which one it uses, then add its include to your one SPF record, publish its DKIM key, or enter your mailbox's SMTP login in the form. For WordPress Contact Form 7, Google points to the WP Mail SMTP plug-in.
Keep the visitor's address out of the From line too. A form that sends "from" the customer's Gmail address is impersonating Gmail, which Google says will get a DMARC quarantine policy. Put the customer's address in Reply-To instead. WPForms' setup guide suggests the same, so you can "simply reply to the notification email to get in touch with them."
For example
A landscaping company moves to Microsoft 365 and replaces its SPF record with v=spf1 include:spf.protection.outlook.com -all. Staff email is fine. The quote form on the website still sends from info@ through the web host, which the new record no longer lists, and with -all receivers may now reject it. The owner notices a week later, when the form's leads stop arriving. The fix is to send the form through the info@ mailbox over SMTP, or through a form service whose include and DKIM key are added to the domain.
If a CRM, invoicing or newsletter tool sends as your domain, give it your DKIM
List every tool that sends mail with your domain in the From line, then authenticate each one in its own settings.
Find them all.
Google's SPF guide lists web servers, your host's mail servers, "Contact us" forms and "any third-party provider or service that sends email for your domain." Think invoices, booking confirmations and newsletters.
Prefer DKIM with your domain.
Many tools offer domain authentication: DNS records you publish so the tool signs with your domain. That makes DKIM pass for your domain, which satisfies DMARC without adding SPF lookups.
Use a subdomain for bulk tools.
Microsoft recommends sending from a subdomain, such as news.yourdomain.com, for services you do not control, so a newsletter's complaints do not weigh on the mail your staff send.
If you send a newsletter to thousands, meet the bulk sender rules too
If you ever send close to 5,000 messages a day to personal Gmail addresses, set up all three records, make DMARC pass, and add one-click unsubscribe. Google counts your main domain and its subdomains together, and a sender who reaches it once is "permanently considered" a bulk sender.
Gmail also wants a visible unsubscribe link and a spam rate below 0.3%. Yahoo asks bulk senders for SPF, DKIM, a passing DMARC policy of at least p=none, and unsubscribes honored within 2 days. Outlook.com's postmaster site says it has enforced SPF, DKIM and DMARC since May 5, 2025 for domains sending over 5,000 emails a day, sending failing mail to junk, and that it will "shortly" start rejecting it.
If every check passes and mail still goes to spam, look at complaints
Wait 48 hours after your last DNS change, test again, and if all three results pass, look at what you send and who you send it to. Google is explicit that authentication "by itself isn't enough to guarantee your messages can be delivered," and that with DMARC at none, spam placement "might be something other than your DMARC record."
Google says to keep your user-reported spam rate below 0.1% and never reach 0.3%. Postmaster Tools shows it, but Google notes data can be missing "if the total number of messages for a given day is too low." This part is a judgment, not Google's: a small business sending everyday mail will often see an empty dashboard, so the header is the test that works.
Judge the fix by quotes answered, invoices paid and form leads arriving. Send a test from each system to a Gmail and an Outlook address once a quarter: the next tool someone adds is the next sender your records do not know.