When a WordPress website running Forminator started showing strange behaviour — from CSS not loading correctly to file uploads crawling at a snail’s pace — what followed was a deep dive into some of the most common yet misunderstood issues in WordPress email and file handling. Here’s the full story.

The First Sign: Forminator CSS Not Loading

The trouble began with a warning inside the Forminator dashboard:

“Forminator’s CSS style cannot be loaded because your website’s address is configured in WordPress to use HTTP instead of HTTPS.”

This is a classic mixed content issue. The website was being served over HTTPS — meaning all content should be loaded securely — but WordPress still had its Site URL and Home URL configured as HTTP in the database. The browser was blocking insecure resources, which caused Forminator’s styling to fail and forms to display incorrectly.

The fix required going directly into the database via phpMyAdmin and updating the siteurl and home values in the wp_options table from http:// to https://. Attempting to fix it through WordPress Settings triggered a Mod_Security firewall error on the hosting server, so the database route was the only option. Once corrected, Forminator’s CSS loaded cleanly and forms rendered as expected.

The Real Problem: Slow File Uploads Traced Back to Google

With the CSS issue resolved, attention turned to a more frustrating problem — file uploads through Forminator were painfully slow. A 6MB PDF was taking well over a minute and a half to submit, and a 13MB file was pushing four minutes. Yet uploading the same file directly through cPanel’s File Manager took under ten seconds. The server itself was not the bottleneck.

The investigation pointed to the email notification system. Forminator was configured to attach uploaded files directly to outgoing email notifications, and those emails were being sent via Gmail SMTP using a username and password.

Here’s where Google’s policy change became the hidden culprit.

Google had announced that it would no longer support third-party apps signing into Gmail using only a username and primary password. This older authentication method was being throttled and flagged. Every time a form was submitted, the SMTP connection to Gmail was slow to authenticate, and attaching a large file to an email being routed through Gmail’s servers added significant overhead. The result was a form that appeared to hang for minutes before showing a success message.

The warning was visible right inside the WordPress admin:

“To help keep your account secure, Google will no longer support using third-party apps to sign in to your Google Account using only your username and primary password.”

Switching to Gmail’s OAuth2 API would have been the ideal fix, but without access to the Gmail account credentials, that wasn’t possible. Instead, the mailer was switched from Gmail SMTP to PHP Mail — the built-in server mail function. The result was immediate and dramatic. What had been taking four minutes now completed in approximately fifteen seconds.

The Next Hurdle: Same-Domain Email Rejection with Outlook

Switching to PHP Mail introduced a new problem. The admin notification email was addressed to a recipient whose email was on the same domain as the website — but that inbox was actually hosted on Microsoft Outlook (Microsoft 365), not on the local server.

When PHP Mail attempted to deliver the email, the server saw that the recipient’s domain matched its own and tried to deliver it locally. Since the mailbox didn’t exist on the local server — it lived on Microsoft’s servers — the delivery failed with the error:

“No Such User Here”

The fix was to change the Email Routing setting in cPanel from Local Mail Exchanger to Remote Mail Exchanger. This instructed the server to stop trying to deliver emails for that domain locally and instead route them through the domain’s MX records — which correctly pointed to Microsoft’s mail servers.

Building Trust: SPF and DKIM Explained

With routing fixed, there was still the risk of emails landing in spam. PHP Mail sends directly from the server without the established reputation that services like Gmail carry, so receiving mail servers — especially Microsoft Outlook — needed a reason to trust the emails.

This is where SPF and DKIM come in.

SPF (Sender Policy Framework) is essentially an approved senders list for your domain. It’s a DNS record that tells receiving mail servers which IP addresses are authorised to send email on behalf of your domain. When an email arrives claiming to be from your domain, the receiving server checks whether it came from an approved IP address. If it did, the email is trusted. If it didn’t, it’s flagged as suspicious or rejected. Think of it like a guest list at a venue — if you’re not on the list, you don’t get in.

DKIM (DomainKeys Identified Mail) works differently. It adds an invisible cryptographic signature to every outgoing email. When the email arrives at its destination, the receiving server checks that signature against a public key stored in your DNS records. If the signature matches, the email is verified as genuine and untampered. If it doesn’t match, something is wrong. Think of it like a wax seal on a letter — it proves the message is genuinely from you and hasn’t been opened or altered along the way.

Both records were added as TXT entries in the domain’s DNS settings. The DKIM record went live immediately while the SPF record showed as pending, which is normal during DNS propagation. Together, they signal to receiving mail servers — including Microsoft Outlook and Hotmail — that emails from this domain are legitimate.

The Result: A Dramatic Improvement in Upload Speed

At the start of this journey, submitting a form with a 6MB PDF attachment was taking over ninety seconds. A 13MB file pushed that to nearly four minutes. Users filling out application forms were left staring at a loading screen, unsure whether their submission had worked.

After switching from Gmail SMTP to PHP Mail and correcting the underlying configuration issues, the same form submission completed in around fifteen seconds — a reduction of over 80% in wait time.

The root causes turned out to be layered: a Google authentication policy change throttling SMTP connections, large file attachments being routed through Gmail’s servers, and misconfigured email routing causing local delivery failures. None of these were obvious on the surface, but each one was contributing to the poor experience.

Key Takeaways

For anyone managing a WordPress site with file upload forms, here are the lessons from this troubleshooting journey:

  • Always match your WordPress URL settings to your SSL configuration. HTTP/HTTPS mismatches break more than just CSS.
  • Google’s SMTP restrictions are real and affect performance. If you’re using Gmail SMTP with a username and password, consider migrating to OAuth2 or an alternative mailer before Google forces the issue.
  • PHP Mail can be faster than Gmail SMTP for server-side form submissions, but it requires proper SPF and DKIM records to ensure deliverability.
  • Email routing matters when your domain email is hosted externally. If your MX records point to Microsoft 365 or Google Workspace, make sure your server knows to route emails remotely, not locally.
  • SPF and DKIM are not optional. Without them, legitimate emails from your server will be treated as spam, especially by Microsoft and Google mail servers.

A slow form is rarely just a slow form. More often, it’s a symptom of something deeper — and fixing it properly means following the trail all the way to the source.