How to fix Gmail blocking emails from my WooCommerce WordPress site?
Published 18 Jun 2025
Updated 3 Oct 2026
12 min read
Summarize with
Updated on 3 Oct 2026: We updated the Gmail recovery steps to separate rejected mail from accepted mail that is missing, and clarified how to verify DMARC alignment on a real WooCommerce order.
Fix Gmail blocking emails from a WooCommerce WordPress site by first confirming WooCommerce generated the notification, then routing WordPress mail through authenticated SMTP, publishing SPF and DKIM, and checking DMARC alignment. Configure a custom Return-Path or bounce domain if the sender supports it and SPF alignment is needed. Send a real order email to confirm the result. If the SMTP provider reports a Gmail deferral or rejection, use its full response to identify the cause.
A custom bounce domain is easy to miss. A site can move away from PHP mail and still fail DMARC if the visible From domain does not align with either the SPF-authenticated Return-Path domain or the DKIM signing domain. Aligned DKIM alone can satisfy DMARC, so check the actual headers before changing bounce routing. Start with the WooCommerce transactional email log, the provider delivery event, and the headers from a real order email.
- Confirm WooCommerce logged the expected transactional email after the order event.
- Get the full Gmail rejection or deferral text from the SMTP provider, not only its bounce label.
- Configure a custom bounce subdomain on the store's organizational domain if SPF alignment is needed and the sender supports it.
- Publish the SPF, DKIM, and DMARC records required for the sending route.
- Confirm WordPress, WooCommerce, and contact forms use the intended authenticated route.
- Check forms, unused plugins, and bot traffic that can damage the domain's reputation.
Confirm WooCommerce generated the email
Before changing DNS, confirm WooCommerce tried to generate the notification. Place a test order, then go to WooCommerce > Status > Logs and open the transactional-emails log. A successfully paid order normally moves to Processing or Completed and triggers the relevant enabled notification. An order left at Pending Payment usually does not trigger the customer order email.
- A Sent entry means WooCommerce handed the message to the mail system. Continue with provider and Gmail delivery evidence.
- A Failed entry means WooCommerce attempted the message but received an error to fix before Gmail testing.
- A Disabled entry means the notification is off under WooCommerce > Settings > Emails.
- A Skipped entry means a required condition, such as a recipient, was missing.
If the expected entry is missing, confirm logging includes INFO and NOTICE events, check that the notification is enabled, and inspect the order status, payment gateway, fatal errors, and plugin or theme conflicts. Sent and failed attempts for order emails also appear as private order notes. WordPress admin messages might not appear in this log, so use the SMTP provider delivery events for those paths.
Start with the real Gmail rejection
A WooCommerce store owner often sees only one line in the SMTP dashboard: accepted, deferred, or soft-bounced. That is not enough. Gmail's SMTP response tells you whether the problem is authentication, reputation, rate, policy, or a temporary deferral. For example, 5.7.26 can identify unauthenticated mail or a DMARC policy failure, 5.7.27 identifies an SPF failure, and 4.7.28 can signal temporary rate limiting. A 5.7.28 response is a permanent rejection related to unusual unsolicited mail from the sending IP. Read the full diagnostic text before changing DNS.
Ask the SMTP provider for the complete bounce or delivery event for one Gmail recipient. Keep the original Message-ID, the recipient address, the SMTP code, and the diagnostic text. If the provider rewrites the message after WordPress hands it off, inspect the final version Gmail received.
Bounce details to copy
Gmail SMTP code: Enhanced status code: Final recipient: Diagnostic text: Return-Path used: Message-ID: DKIM signing domain:
Do not diagnose from WordPress logs alone
A WordPress SMTP plugin can show that the message left the site successfully while Gmail still rejects it later. The log proves WordPress handed off the message. It does not prove Gmail accepted it.
If Gmail accepted the message but it is missing
A 2xx Gmail SMTP response means Gmail accepted the message for processing. It does not show whether the recipient sees it in the inbox. Match the provider delivery event to the test order, recipient, and Message-ID, then ask the recipient to check Spam, Promotions, All Mail, Trash, and any filters or forwarding rules.
If the message is found, use Gmail's Show original view to inspect SPF, DKIM, and DMARC results on that exact order email. If it is still missing, confirm the recipient address and ask the provider for the final Gmail acceptance event. Do not treat an inbox placement problem as an SMTP rejection.
Check DMARC alignment and the Return-Path
If the rejection or headers show SPF using the provider's domain, check the custom Return-Path. The Return-Path is the envelope sender used for bounces. Gmail does not display it to customers in the normal inbox view, but SPF checks it. DMARC passes when the visible From domain aligns with either the SPF-authenticated Return-Path domain or the DKIM signing domain.
A common bad pattern is this: WooCommerce sends as sales@example.com, the SMTP provider authenticates with its own bounce domain, and DKIM does not sign with example.com. DMARC fails because neither SPF nor DKIM aligns with the visible store domain. A custom bounce subdomain, such as bounces.example.com, can repair SPF alignment when the provider supports it. Aligned DKIM can also satisfy DMARC.
How From, Return-Path, SPF, DKIM, and DMARC work together.
Example custom bounce DNSdns
Type: CNAME Name: bounces.example.com Value: bounce.your-smtp-provider.example
Use the exact CNAME, TXT, or MX value your SMTP provider gives you. Do not invent the target value. After publishing it, send a new WooCommerce order email and inspect the delivered headers or the new bounce event. The old test message cannot prove the new Return-Path works.
The fast check
If Gmail starts accepting WooCommerce mail immediately after the custom bounce domain is verified, the evidence points to authentication identity or bounce routing rather than the WooCommerce template.
Why changing SMTP is not enough
Moving WordPress email away from the web server is the right direction, but it is not a complete fix on its own. Gmail evaluates the final message, the sender identity, the sending IP, the domain history, and whether the email looks like it came from a responsible sender.
Before: web server mail
- Shared hosting IPs often have unrelated sender history.
- SPF and DKIM are often missing or not connected to WordPress mail.
- Bounce handling is often local, broken, or ignored.
- Check whether another mail path sends directly from the web server.
After: authenticated SMTP
- Mail leaves through an email infrastructure built for sending.
- SPF, DKIM, and DMARC can pass with the store domain.
- A custom bounce domain can give SPF an aligned sender identity.
- Delivery events help you isolate the reason for a failure.
The key is making sure every transactional path uses the same authenticated route: order confirmations, password resets, admin notifications, contact forms, account emails, and abandoned cart messages.
Check DNS authentication
After checking the Return-Path, review the domain's SPF, DKIM, and DMARC records. A domain health check is useful here because it catches broken DNS records, missing authentication, and related mail configuration problems in one pass.
For message-level proof, send a real test email from WooCommerce itself, not from the SMTP plugin's generic test button. The WooCommerce path is the path customers use, so it is the one that matters.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Gmail requires all senders to authenticate with SPF or DKIM and recommends both. Senders that send about 5,000 or more messages per day to personal Gmail accounts must use SPF, DKIM, and DMARC. For WooCommerce mail, publish all three regardless of volume. SPF should authorize the sending IP for the envelope sender domain, DKIM should sign with the store domain or an aligned subdomain, and a new DMARC record can start at p=none while every legitimate source is verified. Move to an enforcement policy after those sources pass.
Illustrative authentication recordsdns
Type: TXT Name: example.com Value: v=spf1 include:_spf.provider.example -all Type: CNAME Name: selector1._domainkey.example.com Value: selector1.provider.example Type: TXT Name: _dmarc.example.com Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
|
|
|
|---|---|---|
SPF | Wrong sender | Authorize the sending route |
DKIM | No aligned signature | Verify the selector |
DMARC | Missing record | Publish and monitor |
Return-Path | Provider domain with no aligned DKIM | Use a custom domain if supported |
From | Free mailbox | Use the store domain |
Compact checklist for the records Gmail will evaluate.
Stop WordPress creating reputation problems
Once the mail route and DNS are correct, check the application layer. WooCommerce order emails are usually low volume and wanted by customers, but contact forms, review requests, password resets, and abandoned cart flows can create bad mail if forms are abused or plugins send unexpected notifications.
WooCommerce email settings in the WordPress admin dashboard.
The sender setup should be boring and consistent. Use a store-domain address like sales@example.com or orders@example.com. Put customer addresses in Reply-To, not in From. Never send WooCommerce mail using a Gmail, Yahoo, or Outlook address as the visible sender for your store.
WordPress checks to make
- Use one store-domain address for WooCommerce transactional email.
- Keep customer addresses in Reply-To instead of using them as the sender.
- Add spam controls to contact forms and checkout-adjacent forms.
- Audit email plugins so every path uses the intended SMTP route.
- Keep order emails clear, expected, and tied to a real customer action.
Check reputation and blocklist signals
If authentication is passing and Gmail still blocks the site, inspect reputation signals next. A web server IP, SMTP pool, domain, or URL can have a bad history. A blocklist (blacklist) hit does not automatically mean Gmail is using that exact list, but it is a useful clue when paired with the bounce wording.
Suped's blocklist monitoring keeps IP and domain checks beside authentication data. That helps identify whether the problem is a blacklist listing, a broken DNS record, or a specific WooCommerce message path.
Gmail SMTP result
Use the SMTP class to distinguish a delivery attempt from an inbox placement problem.
Accepted
2xx
Gmail accepted the message for processing; inbox placement is a separate check.
Deferred
4xx
Gmail returned a temporary failure that the sender should retry.
Rejected
5xx
Gmail returned a permanent failure that needs diagnosis.
Reputation recovery is slower than DNS correction. If the custom Return-Path and DKIM records are now correct, do not blast a backlog of customer emails. Send normal transactional volume, watch bounces, and keep forms locked down so Gmail sees consistent wanted mail.
Use Suped to keep the fix from breaking again
For a WooCommerce store, the practical goal is to fix the Gmail block and detect later changes to authentication or the sending route. Suped monitoring can flag authentication changes and show new sources sending as the store domain in DMARC reports.
Suped brings DMARC monitoring, SPF, DKIM, blocklist and blacklist signals, alerts, and repair steps into one workflow. Store teams can review authentication reports after an SMTP or DNS change, while agencies and MSPs can keep client stores separated in the multi-tenant dashboard.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
- Suped flags broken authentication and shows the next repair step.
- Suped can host and optimize SPF so senders stay under DNS lookup limits.
- Hosted DMARC helps stage policy changes deliberately.
- Alerts help catch authentication changes before customers complain.
- Hosted MTA-STS helps enforce TLS for inbound mail delivery with DNS setup.
Recovery checklist for a WooCommerce store
If the site has been blocked by Gmail for months, treat it as a recovery project, not a single plugin setting. This order keeps the work concrete and avoids confusing a DNS fix with a reputation delay. For a broader Gmail pattern, the related guide on Gmail deliverability issues covers additional mailbox placement checks.
- Confirm WooCommerce logged the expected email for the test order and order status.
- Pull the full Gmail bounce text for one blocked WooCommerce message.
- Confirm all WordPress mail uses the intended authenticated SMTP route.
- Check DKIM and SPF alignment; verify a custom Return-Path if the SPF path needs it.
- Authorize the SMTP sender in SPF and remove obsolete includes.
- Verify an aligned DKIM signature using the provider selector.
- Publish DMARC, review reports, then tighten policy after legitimate mail passes.
- Secure any abused forms and customer-facing submission paths.
- Place a real test order and inspect its Gmail delivery event or received headers.
Views from the trenches
Best practices
Pull the full Gmail bounce text before changing DNS so the fix matches the rejection.
Use a custom Return-Path subdomain so bounces route through the accepted SMTP provider.
Keep WordPress forms locked down so abused forms do not poison store mail reputation.
Common pitfalls
Assuming a new SMTP route fixes old domain reputation before Gmail has new mail evidence.
Publishing SPF for the provider but leaving DKIM unsigned with the store domain in headers.
Checking only the WordPress plugin log instead of the recipient bounce response message.
Expert tips
Send one real order email to a tester and inspect headers before customer traffic resumes.
Treat blocklist and blacklist hits as clues, then compare them with bounce wording.
Move DMARC policy slowly after authentication passes across real WooCommerce mail traffic.
Marketer view
Marketer from Email Geeks says a full bounce message is the first diagnostic item because soft-bounce labels hide Gmail's actual rejection reason.
2023-11-12 - Email Geeks
Marketer view
Marketer from Email Geeks says likely causes include a damaged sending IP, abused site forms, broken authentication, or poor reputation tied to message identifiers.
2023-11-12 - Email Geeks
Verify the fix with a real order
Confirm WooCommerce generated the notification, get the full Gmail bounce if it rejected or deferred the message, fix SPF or DKIM alignment, and verify a custom Return-Path when needed. Send a new WooCommerce order email to Gmail. If Gmail accepts it, check where it lands. If it still rejects, use the diagnostic text to determine whether the remaining issue is reputation, content, rate, or abuse.
Suped keeps DMARC reports, authentication changes, and related alerts visible after the immediate Gmail block is gone, especially when more plugins, forms, domains, or client stores get added later.
