The form says it was submitted successfully — so why isn’t there a single email in the inbox?

Start by taking the phrase “submitted successfully” apart. It’s just a message the front end shows you; it may come from JavaScript validation passing, or it may be a line of copy hard-coded in the theme. It has no necessary connection to whether an email was actually sent. What really determines whether you receive inquiries are the three layers behind it.

The first layer is the front end. A visitor clicks the button, and the browser packages the form data and sends it to the address specified by action. When something breaks here, it’s usually a validation script blocking the submission without a message, the button being covered by an overlay, or the post-submit redirect failing — the visitor thinks they didn’t submit, and you never receive anything either.

The second layer is the server side. PHP receives the data and decides how to send the email: some call mail() directly and use the host’s built-in sending, some connect an SMTP account to send on their behalf, and some write the inquiry to a database and send a notification. This layer has the most problems and is the hardest to see — because most themes won’t expose a sending failure to the visitor.

The third layer is delivery. The email leaves the server, goes through the recipient’s email provider’s judgment, and lands in the inbox or the spam folder depending on the SPF, DKIM, and DMARC identity authentication, along with the sending domain, content characteristics, and IP reputation. Many business owners only hear these abbreviations at this stage, yet they are exactly the most common break points.

If any one of these three layers breaks, the visitor sees the same “submitted successfully,” so you can only disprove them one layer at a time, in order. I also mentioned this order in the technical SEO checklist: first confirm the symptom can be reproduced, then locate the layer, and only then make changes.

Where should troubleshooting start? What’s my order?

My order is based on “how fast I can disprove something.” Things I can rule out in two minutes come first; things that require waiting for DNS to propagate or digging through logs come later.

First, run a real submission. Use an inbox you can log into as the recipient, walk through the entire flow on the page, and note the submission time. Don’t use an address on the same domain for the test — use an external mailbox like Gmail or Outlook, so you can see how cross-domain delivery actually behaves.

Next, look at where the form actually sends. Open the Network panel in your browser’s developer tools, click submit once, find that POST request, and check its destination, status code, and response. If the request never goes out, the problem is in the front end. If it goes out and returns 500, the problem is on the server side. If it returns 200 but the inbox stays quiet, only then do DNS authentication and delivery come into play.

Then check the DNS trifecta. SPF, DKIM, and DMARC can all be seen with a single dig command — no need to log into any back end. If any one of these three records is missing, your email looks “of unknown origin” to the recipient.

Then confirm the sending channel. Ask your host for sending logs, or just connect a proper SMTP service and replace mail(). This step removes the “host blocking” variable entirely.

Only at the end do you dig through the spam folder and bounces. If you reverse the order, you’ll spend ages searching the spam folder for an email that was never sent in the first place.

What do SPF, DKIM, and DMARC actually handle?

In one sentence: these three records issue an ID card for the email you send. When the recipient’s mail server receives it, it uses these three to verify “was this email really sent from your domain?” If it fails the check, the email lands in spam at best, or is rejected outright at worst — and usually no notice comes back to your form page.

They have different jobs. SPF authorizes which servers may send email using your domain; DKIM signs the email content with a key to prove it wasn’t altered along the way; and DMARC tells the recipient what you want done when neither SPF nor DKIM passes, while sending reports back to you. Miss any one of the three and the verification chain loses a link.

How do you look up and write an SPF record?

Looking up SPF means checking the TXT record at the root of the domain: dig TXT yourdomain.com +short. A normal record starts with v=spf1, followed by the authorized sending sources, and ends with ~all or -all.

The two most common mistakes I’ve seen: two SPF records existing under the same domain, and the record’s authorized sources missing the machine that actually sends the email. Two SPF records make it impossible for the recipient to decide, which is the same as having none; missing a source means you’ve personally put yourself on the unauthorized list.

There’s another easily overlooked limit: the number of DNS lookups in an SPF record is finite, so stuffing in too many include statements will exceed the limit and render the record useless. Keep the authorizations as lean as you can.

What happens if DKIM isn’t configured?

DKIM’s public key lives in a special subdomain of the form selector._domainkey.yourdomain.com, so the lookup must include the selector name. Use dig TXT selector._domainkey.yourdomain.com +short to see the public key.

The most common symptom of missing DKIM: SPF clearly passes, yet the email is still judged suspicious. That’s because SPF only verifies the envelope sender, while DKIM verifies the integrity of the headers and body. Only when both pass is it called aligned.

The most common slip when configuring DKIM is dropping a character while copying the public key, or losing a line break. The record exists, but the signature still won’t verify. After configuring it, always read back the result from a full test email — don’t just trust the green “enabled” dot in the back end.

Should DMARC start with p=none?

Yes. The DMARC record goes in _dmarc.yourdomain.com, and its policy has three levels: p=none only observes without blocking, p=quarantine sends suspicious email to spam, and p=reject rejects it outright.

I suggest starting with p=none and filling in an inbox that can receive reports in rua. Run it for a while, and the reports will tell you who is sending email using your domain — sometimes you’ll see sending sources you don’t recognize at all. Once you have a clear picture, tighten the policy gradually. Jumping straight to p=reject may well reject your own legitimate business email along with it.

Conversely, if you don’t even have p=none, you have neither protection nor any reports — you’re completely blind when something goes wrong.

How do you quickly spot a form action pointing to the wrong place?

This is the most easily overlooked and also the easiest to verify kind of problem. A form’s action attribute determines where the data is sent, and it can quietly change at many moments you’d never expect: switching themes, installing a form plugin, moving from a staging environment to production, or even an old version of the form still running after the page is cached.

There’s only one way to find it: click it for real and watch the request. Open the Network panel in developer tools, submit once, and find that POST. Confirm three things — whether the destination is the handler script you expect, whether the status code is 2xx, and whether the response body contains an error message.

A few typical symptoms to match against. If the POST goes to a path that doesn’t exist, the status code will be 404 and that inquiry is simply lost. If it goes to an old or staging domain, the request may be blocked by cross-origin policy and the console will show an error. If the form uses an empty action, the browser sends the data back to the current page URL — unless the page itself has handling logic, that amounts to nothing happening.

There’s a subtler one, too: the form refreshes the whole page on submit, which looks like success but is really just the default behavior not being prevented.

If your site is built on WordPress, abnormal form behavior caused by plugins and caching is especially common. I wrote about a similar troubleshooting approach in this piece on WordPress plugins, indexing, and content management — you can compare notes.

What does it look like when the host blocks SMTP?

Many shared hosts restrict PHP sending by default: either rate-limiting it, banning it outright, or closing the sending port. The symptom often isn’t a clear error, but rather “the page spins for a few seconds and then shows success” — while the email never went out.

There are several ways to judge. First, look at the sending or bounce logs in your host’s control panel; reputable hosts keep records. Second, temporarily switch the recipient to your own external inbox and test a few times to see whether the delivery rate is stable. Third, connect a standalone SMTP service directly and send on port 465 or 587, removing the “host’s built-in sending” variable.

Why do I recommend switching straight to SMTP instead of fiddling with the host? Because once host sending breaks, it’s very hard to get complete delivery feedback. A standalone SMTP service usually provides sending logs and bounce reasons, so you can pinpoint the problem directly. For inquiries — where “losing one email means losing one customer” — that observability is worth the price.

After switching, don’t forget to go back and verify SPF: the new SMTP provider also needs to be added to your SPF authorization list. Otherwise you’ve fixed the sending channel only for the authentication link to break again.

This idea of “make the channel observable first, then optimize content” is the same as B2B content and inquiries across long sales cycles: before the pipeline works, adding content just increases the denominator.

The email really was sent — so why does it land in the spam folder?

If you’ve confirmed the email went out and the SMTP log has a record, but the recipient’s inbox doesn’t have it, then you’re in spam-judgment territory. What you need to check is no longer “was it sent” but “does it look like legitimate email.”

First check sending-domain alignment. Many sites put info@yourdomain in the From address, but the actual sending server is a third party, and SPF authorizes the third party’s domain. This mismatch between the “displayed sender” and the “actual sender” is a high-frequency trigger for spam judgment. The easiest fix is to keep the sending domain, the SPF-authorized domain, and the DKIM signing domain consistent.

Next check content characteristics. An email that is just one big image, a body stuffed with short links, a subject line in all caps with exclamation marks, and a .zip attachment — these all raise the suspicion score. An inquiry notification email should really just be plain text plus one or two links; there’s no need to make it look like a marketing email.

You also need to check IP reputation. If you’re on shared hosting or shared SMTP, the sending behavior of others on the same IP can drag you down. In that case, switching to a dedicated sending channel is often more effective than tweaking content.

Don’t cut corners on the last step: add the sending address to the recipient’s allowlist, first confirm the “normal delivery” path works, and only then tackle the “judged as spam” problem. Investigating the two together will take you in circles for a long time.

To systematically see which emails arrived and which didn’t, manually refreshing your inbox isn’t enough. Connect the inquiry event to an analytics tool and look at it alongside traffic data, and you’ll spot “someone came but left no inquiry” faster. See GA4 organic traffic analysis for the specifics.

100% indexed in GSC but still no inquiries — what does that mean?

This is a judgment I’ve confirmed repeatedly in practice: when Google Search Console shows 100% of your site’s pages indexed, the problem is usually not SEO but the end of the pipeline — namely the form and email.

Why do I say that? Because 100% indexed means the upstream pipeline of crawling and indexing works, and pages can be found and clicked. You have traffic and the pages are fine, yet there are no inquiries — then the funnel can only be broken at the final step: the visitor wanted to contact you, but the form didn’t deliver the message to you.

The value of this conclusion is stopping the loss: when there are no inquiries, first run an end-to-end verification of the form-and-email pipeline before talking about driving traffic. Otherwise you’re pouring water into a bucket that leaks at the bottom.

How do you verify? Make a real submission using an external mailbox and confirm it arrives; then check GSC’s indexing and click data to confirm the upstream hasn’t collapsed; then use GSC’s SEO diagnostic method to rule out search-side problems. If both sides are clean, the problem is locked onto the form.

Traffic rising while inquiries don’t is another manifestation of the same kind of problem. I break this case down in more detail in diagnosing traffic up, inquiries flat — you can read on.

By the way, inquiries are worth counting carefully. There’s a public discussion on Reddit, with the original post titled “How I got 17 project inquiries from a random tweet,” and participants including /u/rufusdenne, /u/dcedrych, /u/HawkofDarkness, and others. The title of that public Reddit discussion is itself a reminder: inquiries are a number that can be counted explicitly, not a vague “feels like business has been okay lately.” If you can’t count it, you can’t tell how many inquiries the form is actually losing.

A troubleshooting checklist you can copy

Condense the steps above into a table, and work through it in order — don’t skip steps. Each step has a pass criterion; if you don’t meet it, stop and fix it there rather than guessing onward.

Each item in this table takes only about ten minutes, but the order can’t be shuffled. Checking DNS before digging through the spam folder is the most common wasted path.

After it’s fixed, which metrics should you watch?

Fixed doesn’t mean done — it has to stay monitorable. I watch three things: the number of form submissions, the number of emails actually received, and the gap between them. Normally these two numbers should be roughly equal; once they start diverging, authentication or the channel has gone wrong again.

If the form is self-built, you can push the submission event to GA4 and view it in the same chart as organic traffic. For how to place links and design events, see GA4 organic traffic and conversion analysis on this site. If you also want the form’s own semantics to be clearer, adding structured data to the page helps — see structured data and AI search for the approach.

Also, put “is the inquiry pipeline working” on your periodic check list. After changing a theme, swapping a plugin, migrating servers, or switching SMTP, run through the table above again. Forms always break quietly; they won’t tell you they’re broken.

Finally, if you do this as a service, don’t just run this check on your own site. A client’s inquiry form deserves the same verification before delivery — a form that can’t receive email turns all the SEO work in front of it into wasted effort. If you want to see how others write up this kind of troubleshooting record, start from the research articles list; if you’d rather just describe your situation, the form on the contact page is a working sample of the process above — if it also can’t receive email, I’d probably suspect SPF first.

Frequently Asked Questions

The form says success, but there’s nothing in the spam folder either — where did the email go?

Most likely it was never sent at all. The front-end message only means the request was submitted; when server-side sending fails, it usually doesn’t pass an error back to the visitor. First check the host’s or SMTP service’s sending log for a record of this email — no record means it’s stuck on the server side.

Do I need to configure all three: SPF, DKIM, and DMARC?

Yes. They have different jobs: SPF handles authorization, DKIM handles signing, and DMARC handles policy and reporting. Configure only one or two and the verification chain is incomplete; email may still be judged suspicious. The cost is very low — there’s no reason to skip it.

I switched SMTP services — why does email still land in the spam folder?

First check whether the new service’s sending servers have been added to the SPF authorization list, and whether the From domain and the signing domain match. Changing the channel without updating authentication along with it is the most common cause.

Can a WordPress form plugin avoid these problems?

The plugin only solves “how to send,” not “whether the sending identity is correct.” It can connect the form to SMTP, but SPF, DKIM, and DMARC still have to be configured by you in DNS. Installing the plugin only counts as halfway done.

How do I confirm the form isn’t quietly losing inquiries?

Connect the form submission event to an analytics tool and regularly run a real submission test with an external mailbox. Watch the two numbers — “submission count” and “actual received count” — and once they diverge, go through the checklist above from the top.

Liu Yu · Tianwen SEO Research

I work on SEO and GEO for independent foreign-trade sites, and I’m in the habit of writing down the tests I’ve run along with the failure criteria. See the About page for my research methods and integrity boundaries, and more records of the same kind in research articles.

Sources = hands-on testing: records of form-email loss troubleshooting in the tianwenseo content library (common root causes: SPF/DKIM/DMARC not configured, form action pointing to the wrong place, SMTP blocked, email landing in spam; on the GSC side: when the site is 100% indexed, the problem is often at the end of the pipeline — the form and email — rather than SEO); public material: the public Reddit discussion post “How I got 17 project inquiries from a random tweet” (participants /u/rufusdenne, /u/dcedrych, /u/HawkofDarkness, and others).

This page is a machine translation of the Simplified Chinese version and is pending human review.