Question
We have had a Divi contact form on our GoDaddy hosted site that happily sent messages to our gmail account for years. About a month ago it stopped working. I changed the email address to send to a company domain Office 365 address and it works. But when the form is set to send to our email address on Gmail Workspace the message never shows up (not in inbox, not in spam, not anywhere). We could not find any mail logs in WordPress.
https://www.reddit.com/r/WordPress/comments/10jv867/Answer
Gmail enforces SPF and DKIM authentication as a hard gate for inbound mail. Microsoft 365 treats them differently: it combines SPF, DKIM, and DMARC with sender reputation and behavioral signals into a composite authentication result that downgrades messages but does not outright reject them at the SMTP level. A WordPress site sending through its host’s default mail relay, with no SPF record and no DKIM signing, will pass muster at Microsoft 365 (reaching Junk, or even the inbox) while being rejected entirely at Gmail. The asymmetry the questioner observed is the expected result of two different enforcement policies applied to the same unauthenticated message.
The fix is to stop sending through the host’s MTA and route through a transactional provider that publishes SPF and signs DKIM. That means an SMTP plugin plus an external provider, and the From address aligned to the domain those records authenticate.
Why Gmail and Microsoft 365 behave differently
Gmail’s sender guidelines require any sender to personal Gmail accounts to pass at least one of SPF or DKIM. This became the published floor for all senders on February 1, 2024 (a stricter version of a requirement introduced for new senders in November 2022). Google also extended requirements to bulk senders, defined as those sending 5,000 or more messages per day to Gmail: bulk senders must pass SPF AND DKIM, must publish a DMARC record, and must keep their spam rate below 0.3%. Google’s published requirements formally apply to email sent to personal Gmail accounts; for Google Workspace accounts, enforcement depends on the Workspace domain’s administrator-configured spam policies, though Google’s infrastructure evaluates SPF, DKIM, and DMARC on inbound Workspace mail regardless.
Microsoft 365’s inbound filtering works differently. Exchange Online Protection extends SPF, DKIM, and DMARC evaluation with additional signals (sender reputation, history, recipient history, and behavioral analysis) into a single composite authentication result (compauth). Microsoft documents this system explicitly: “a composite authentication failure doesn’t directly result in a message being blocked. Our system uses a holistic evaluation strategy that considers the overall suspicious nature of a message along with composite authentication results” (
Email authentication in Microsoft 365). A message that fails all three traditional checks and produces compauth=fail is typically routed to Junk rather than rejected at the SMTP level, unless other signals (a blocklisted IP, a content match to known phishing patterns) cross the threshold into an SMTP-level reject.
The practical result is predictable: the same unauthenticated message lands in Microsoft 365’s Junk folder while Gmail refuses it at the gate. Many senders interpret the Office 365 delivery as “mail is working” and the Gmail failure as “Gmail is broken.” The diagnosis is the reverse.
The chain that broke
A Divi contact form on a standard WordPress installation submits via the WordPress AJAX endpoint at admin-ajax.php. The Divi module handles the server-side in et_pb_contact_form_submit; on successful validation, it calls WordPress’s wp_mail() with the recipient from the form’s Email tab and a body assembled from the submitted fields.
wp_mail() constructs the From header in wp-includes/pluggable.php. Without an explicit override, the code strips any www. prefix from the site’s home URL host and constructs the address as wordpress@<domain>. A site at example.com or www.example.com both produce [email protected]. A site on a subdomain (shop.example.com) produces [email protected]. In any case, the From domain must be covered by the SPF record and DKIM signing on that domain for the message to authenticate correctly at the recipient end. Most shared-hosting sites have no SPF record at all for their domain, and no DKIM signing configured; that is the normal state for a site that has never explicitly set these up.
wp_mail() then hands the message to PHP’s configured mailer. On most shared hosts, that is the local sendmail binary, which passes the message to the host’s outbound MTA. GoDaddy’s shared hosting has historically relayed outbound through its own infrastructure. The relay sends from an IP address in GoDaddy’s pool, not from an IP the customer has registered as authorised for their domain.
At the recipient end, the authentication checks run in sequence:
SPF: does the sending IP appear in an SPF record published for the Return-Path domain? If the site has no SPF record, or if the record does not include GoDaddy’s relay infrastructure, the check fails (SPF=fail or SPF=none).
DKIM: is there a valid DKIM signature on the message, verifiable via a public key in the From domain’s DNS? If the host does not DKIM-sign outbound relay mail for the customer’s domain, the signature is absent (DKIM=none).
DMARC: with SPF failing and DKIM absent, DMARC alignment cannot be established. If the From domain publishes no DMARC record, Gmail applies its own internal anti-spam handling; if it publishes p=none, the message is monitored but not explicitly rejected by policy alone. Either way, combined with the failed SPF and absent DKIM, Gmail routes the message to spam or rejects it at the SMTP level.
Gmail’s post-2024 floor means this chain ends in rejection. The Divi-specific diagnostic chain covers the form-side checks; the problem described here is downstream of the form.
How to confirm what your site is actually sending
Two checks before touching the DNS.
Install a logging plugin. Check & Log Email and Log Emails both hook wp_mail() and record each outgoing call. Submit a test contact form. The log shows the From address WordPress used, whether the call returned successfully, and any error if it failed. The headers WordPress sent are visible in the log entry; they show the From as constructed by wp_mail(), before any SMTP relay touches it.
Run the message through mail-tester.com. Submit a contact form to a mail-tester.com address. The score report breaks down SPF, DKIM, and DMARC as a receiving server sees them, with separate pass/fail/none status for each check. This is the fastest way to see the authentication result from outside the sending domain’s DNS.
After the fix is applied, register the domain with Google Postmaster Tools. Postmaster Tools shows authentication pass rates, spam rate, and domain reputation as Google’s infrastructure measures them: the ground-truth view of how Gmail sees the sending domain once SPF and DKIM are in place. The email test suite and inbox placement testing guide cover the full verification sequence.
The fix
Three steps, in order.
1. Install an SMTP plugin and route through a transactional provider
Stop sending through the host’s MTA. A transactional provider publishes its own SPF records and DKIM keys, signs outbound mail on the customer’s behalf, and maintains the sending infrastructure at the authentication and reputation standards Gmail now requires.
The SMTP plugin side: WP Mail SMTP, FluentSMTP, and Post SMTP are the three plugins in regular use on WordPress sites. All three support the major transactional providers and handle the SMTP handshake correctly.
The provider side: Postmark is the cleanest starting point for most contact form senders. SMTP2GO has the most generous free tier. Mailgun and Resend are the other common options at this tier. Amazon SES is the cheapest at any volume above trivial, with the trade-off of more setup overhead.
The WordPress email setup guide covers the full configuration path from a blank SMTP plugin to a working authenticated sender.
2. Publish SPF and DKIM for that provider
Every transactional provider supplies a one-line SPF include: and a set of DKIM CNAME records specific to the customer’s sending domain. Add both to the DNS for the domain the From address will use. Verify SPF propagation with dig TXT example.com and DKIM with dig TXT <selector>._domainkey.example.com. The DNS setup guide for WordPress email covers the record formats and the steps inside major DNS providers.
Once SPF and DKIM are in place, publish a DMARC record at minimum:
v=DMARC1; p=none; rua=mailto:[email protected]p=none satisfies Google’s monitoring requirement for bulk senders and starts generating aggregate reports showing authentication pass rates. Tighten to p=quarantine and later p=reject only after the reports confirm alignment is stable across all sending paths. The DMARC aggregate report guide explains how to read what Postmaster Tools and the RUA reports show.
3. Align the From address
Set the SMTP plugin’s “From Email” to an address on the same organisational domain the SPF include and DKIM keys are published for. Enable “Force From Email” (the exact label differs by plugin) to prevent other plugins from overriding the From with a value that does not align.
The default From wp_mail() constructs is wordpress@<your-domain>. If the SPF and DKIM are published for example.com but the SMTP plugin’s From is left at the [email protected] default, the match is already correct; alignment is not the issue on a standard domain. Where alignment fails is when the SMTP plugin’s From is set to an address on a different domain than the one with the SPF and DKIM records, or when the SPF records simply do not cover the sending IPs. Setting From to [email protected] or [email protected] and confirming “Force From Email” is enabled covers both cases cleanly. The guide to changing WordPress email sender details shows the exact setting path inside each major SMTP plugin.
A note on GoDaddy shared hosting
GoDaddy’s shared-hosting accounts relay outbound PHP mail through GoDaddy’s MTA infrastructure, not the customer’s domain. GoDaddy’s relay IPs are not in the customer’s SPF record, and GoDaddy does not DKIM-sign relay mail for the customer’s domain. Attempting to fix this by chasing GoDaddy’s relay IPs into the customer’s SPF is fragile: GoDaddy changes relay infrastructure without notice, and including GoDaddy’s infrastructure domain in the SPF record authorises a large IP range the customer does not control.
The correct path is to bypass the relay entirely by installing an SMTP plugin and routing through an external transactional provider. The same solution applies to any cPanel-style shared host whose outbound relay the customer does not control. The relay stops being involved in authentication; the provider handles it instead.
If you only fix one thing
The single change that recovers Gmail delivery on a site whose contact form reaches Microsoft 365 but fails Gmail is to route mail through an authenticated transactional provider. Install WP Mail SMTP, FluentSMTP, or Post SMTP; sign up for Postmark or SMTP2GO; publish the provider’s SPF include and DKIM CNAMEs in DNS; set the SMTP plugin’s From address to an address on the authenticated domain. Gmail accepts what arrives next. The Microsoft 365 Junk problem resolves too. The general WordPress email troubleshooting guide is the reference for any sending failure that persists after the provider is connected.