Table of contents18
WordPress is not sending emails because a message is failing at one of a few clear points: the form is not saving, the message is in spam, the From address is untrusted, the site is using unauthenticated PHP mail, DNS authentication is missing, or sending was never attempted. Diagnose in that order, and you will find the break quickly, instead of changing settings at random and hoping the next test works.
That order matters because an email problem is rarely a single broken switch. A message travels through a chain, and each link in the chain can stop it quietly, without an error on screen. A visitor can submit a form, see a success message, and still never receive a reply, because the success message only means the form finished its own job. It does not prove that WordPress sent anything, that a mail server accepted it, or that an inbox provider delivered it. The guide below separates those stages, so you can test one link at a time and know exactly where the chain breaks.
What you will be able to do by the end of this guide
- Confirm whether a form submission was saved, and know whether you have a form problem or a delivery problem.
- Find a missing message in spam, junk, promotions, or a quarantine area, and stop it being filtered again.
- Set a trustworthy From address, with the visitor’s address in Reply-To only.
- Move WordPress mail from unauthenticated PHP mail to an authenticated SMTP service.
- Check SPF, DKIM and DMARC authentication with guidance from your mail provider or host.
- Read an email log and tell whether sending was attempted, accepted, or bounced.
How email travels from WordPress to an inbox
When someone submits a form, WordPress or the form plugin first handles the submission itself. If the form is set to save entries, it writes the entry to the database. Only after that does it ask WordPress to send a notification, using the wp_mail() function. By default, wp_mail() hands the message to PHP mail on the web server. The server then tries to deliver it to the recipient’s mail provider, which decides whether to accept it, filter it as spam, quarantine it, or reject it. Each stage leaves different evidence, and that evidence is what you should follow.
This is also why a test message can behave differently from a real form message. A test may use a different From address, a different recipient, or a different subject, and any one of those differences can change how a provider treats it. Keep the test as close as possible to the real message: same From address, same recipient, same kind of subject, and a form submission made in the same way a visitor would make it.
Where the email stops: a comparison
| Possible cause | Where the email stops | What to check |
|---|---|---|
| The form is not saving the submission | Before WordPress sends anything | Look for a saved entry in the form entries area; if there is none, treat it as a form problem. |
| The message is filtered as spam | At the recipient’s inbox provider, after delivery | Search spam, junk, promotions and quarantine, and check whether other recipients receive it. |
| The From address is untrusted | At the sending server or the inbox provider | Confirm the From address uses the site’s own domain, and that the visitor’s address is only in Reply-To. |
| WordPress uses PHP mail by default | At the sending server or the inbox provider | Route mail through an authenticated SMTP service instead of relying on PHP mail. |
| SPF, DKIM or DMARC authentication is missing or wrong | At the inbox provider’s authentication checks | Follow your mail provider or host DNS guidance, and check the records they ask you to publish. |
| Sending was never attempted, or it bounced | Inside WordPress or at the mail server | Use an email log to see whether sending was attempted, accepted, or bounced, and read the reason given. |
Step 1: Confirm the form submission was actually saved
Start here, because this one check changes the whole diagnosis. Open the entries area for the form you are testing, and submit the form exactly as a visitor would. Then look for the new entry. A saved entry means the form worked, and the problem is delivery: WordPress, the mail server, or the inbox provider stopped the message after the form had done its job. No entry means the problem is in the form itself, and changing mail settings will not fix it.
If there is no entry, check the form before you touch email settings. Look for a required field that fails quietly, a validation rule that rejects the test data, a confirmation or redirect that fires before saving, a payment or conditional step that stops the submission, or a conflict that prevents the form from completing. Test with simple, ordinary data first, then add back the complex fields one at a time. When an entry appears, you have a clear boundary: the form is working, and the rest of this guide is about delivery.
Keep a note of what you tested, including the time, the email address used, and whether an entry was saved. That note becomes useful later, when you compare it with the email log, because the two records should agree. If the form saved an entry at a certain time and the log shows no sending attempt at that time, the break is between the form and wp_mail(). If the log shows an attempt, the break is further down the chain.
Step 2: Check the spam and junk folders
Before changing any setting, search the recipient mailbox thoroughly. Check spam and junk, and also promotions, social, or other filtered tabs if the mailbox uses them. Search for the sender address, the subject, and a distinctive word from the message, because a filtered message is not always in the folder you expect. Also check any quarantine area provided by the mail service or by a security product, and check whether the message arrived for a different recipient, which would point to a problem with one mailbox rather than with sending itself.
If you find the message in spam, mark it as not spam, and add the sending address to the recipient’s contacts or safe senders list where that option exists. That helps for that mailbox, but it does not fix the underlying trust problem for other recipients, so keep working through the steps below. If the message is not in spam at all, do not assume it was never sent. It may have been rejected before delivery, or it may never have left WordPress, and the email log in Step 6 will tell you which.
Step 3: Set the From address to a fixed address at the site’s own domain
One of the most common causes of failed WordPress email is a From address that inbox providers cannot trust. Many forms, by default, put the visitor’s email address in the From field, so the message appears to come from the visitor. That looks convenient, because replying goes straight to the visitor, but it fails authentication checks: the sending server is not authorised to send mail for the visitor’s domain, so providers may filter or reject the message.
Fix this by using a fixed From address at the site’s own domain, such as an address on the same domain as the WordPress site, and putting the visitor’s address in Reply-To only. Replies will still go to the visitor when you press reply, because Reply-To controls where replies go, while the From address controls which domain is claiming responsibility for the message. Use the same fixed From address for test messages and real messages, so your tests reflect what visitors actually experience.
Also check that the From address actually exists as a mailbox or as an authorised sending address with your mail provider, and that the name shown with it is clear and recognisable. A From address that looks like a system address with no mailbox behind it can still work for sending, but an address that does not exist at all can cause bounces or rejections, depending on how the provider handles it. If in doubt, use a real address on the site’s domain that you can monitor.
Step 4: Route mail through an authenticated SMTP service
WordPress sends mail through the wp_mail() function, and by default wp_mail() uses PHP mail on the web server. PHP mail often sends without the kind of authentication that inbox providers now expect, and a message sent that way can look indistinguishable from a message sent by a compromised or careless server. That is why inbox providers often distrust it, filter it, or reject it, even when the content itself is perfectly legitimate.
The remedy is to route WordPress mail through an authenticated SMTP service. With SMTP, WordPress connects to a mail service using credentials for an account that is authorised to send for your domain, and the service sends the message on your behalf. That gives the receiving provider a clear, authenticated sender to check against your domain’s records, and it gives you a service whose sending behaviour you can inspect, rather than a web server quietly handing messages to PHP mail.
When you set this up, use the connection details supplied by your mail provider or host, and test with the same fixed From address you set in Step 3. If your host offers its own mail service, follow its guidance first, because the host may have specific requirements for sending from its servers. If you use a separate mail provider, follow that provider’s guidance instead, and make sure the domain you send from is verified with that provider before you judge the result. A test sent before verification can fail for a reason that has nothing to do with WordPress.
Step 5: Check SPF, DKIM and DMARC authentication
SPF, DKIM and DMARC are DNS-based checks that help an inbox provider decide whether a message really came from the domain it claims to come from. SPF lists which servers are allowed to send for a domain. DKIM adds a cryptographic signature that the provider can verify. DMARC tells providers what to do when a message fails those checks, and where to send reports about it. You do not need to memorise the full specifications to diagnose a problem, but you do need to know whether the records for your domain match the service that is actually sending your mail.
Check these records through the DNS guidance provided by your mail provider or host. The provider that sends your mail should tell you exactly which records to publish, and in what form, because the correct values depend on which service is sending. Publish the records at your DNS host, which may be your domain registrar, your hosting provider, or a separate DNS service, and allow time for the changes to spread before testing again. A test made minutes after a DNS change can still fail on the old records, so note the time of the change and test again after a reasonable interval.
If authentication fails, do not keep adding extra records in the hope that one of them will work. A domain should normally have one SPF record, and adding a second one can itself cause a failure. Instead, compare the published records with the provider’s guidance, check for typing errors, and check that the sending service named in the records is the service WordPress is actually using after Step 4. If you changed sending service recently, the old records may still describe the old service, and that mismatch is a common cause of messages that used to arrive and then stopped.
Step 6: Use an email log to see whether sending was attempted, accepted or bounced
An email log is the record that turns guessing into diagnosis. A logging facility records each attempt WordPress makes to send mail, including the time, the recipient, the subject, and the result. With that record, you can answer the question that matters most: was sending attempted at all, was it accepted by the mail service, or did it bounce with a reason?
Compare the log with the saved form entry from Step 1. If there is a saved entry but no log entry at the same time, the message never reached the sending stage, and the problem is between the form and wp_mail(). If the log shows an attempt that was accepted, the message left WordPress, and the problem is with the mail service or the inbox provider, so check spam and authentication again with that knowledge. If the log shows a bounce, read the bounce reason carefully, because it usually names the cause, such as an authentication failure, a rejected recipient, or a sending limit.
Keep the log enabled while you test, and test one change at a time. If you change the From address, the sending service, and the DNS records all at once, a successful test will not tell you which change fixed the problem, and a failed test will not tell you which change is still wrong. Change one thing, test, check the log, and write down the result before moving on. That discipline is slower in the moment, and much faster overall, because it prevents you from undoing a fix that was already working.
Step-by-step diagnosis checklist
- Submit the form as a visitor would, then check the form entries area for a saved entry.
- If there is no entry, fix the form first, and do not change mail settings yet.
- If there is an entry, search spam, junk, promotions and quarantine for the message.
- Check whether the message arrived for a different recipient, to separate a mailbox problem from a sending problem.
- Set the From address to a fixed address at the site’s own domain, with the visitor’s address in Reply-To only.
- Route WordPress mail through an authenticated SMTP service, using the details from your mail provider or host.
- Check SPF, DKIM and DMARC records against your mail provider or host DNS guidance.
- Allow time for DNS changes to spread, then test again with the same From address and recipient.
- Open the email log and compare it with the saved entry, noting whether sending was attempted, accepted or bounced.
- Change one thing at a time, test after each change, and record the result before moving on.
Frequently asked questions
Why does the form show a success message if no email was sent?
A success message usually means the form completed its own process, such as saving an entry or showing a confirmation. It does not prove that wp_mail() was called, that a mail server accepted the message, or that an inbox provider delivered it. That is why checking the saved entry and the email log matters more than the message on screen.
Why do test emails arrive but real form emails do not?
Test messages and form messages can differ in From address, recipient, subject, or sending path. A test that uses a different From address may pass authentication that the real form message fails. Make the test match the real message as closely as possible, and compare both against the email log.
Should the visitor’s email address ever go in the From field?
No. Use a fixed address at the site’s own domain in the From field, and put the visitor’s address in Reply-To. Replies will still go to the visitor, while the message will pass the authentication checks that depend on the sending domain.
Does WordPress need an SMTP service, or is PHP mail enough?
WordPress can send through PHP mail by default, but inbox providers often distrust mail sent that way, because it lacks the authentication they expect. Routing mail through an authenticated SMTP service gives providers a verifiable sender and gives you a log and a service to inspect when something goes wrong.
How long should I wait after changing DNS records?
DNS changes need time to spread, and the exact time depends on the records and on caching by providers. Wait a reasonable interval after publishing SPF, DKIM or DMARC changes, note the time of the change, and test again later, rather than judging the result from a test made immediately afterwards.
What should I do if the email log shows a bounce?
Read the bounce reason, because it usually names the cause. An authentication bounce points back to SPF, DKIM, DMARC, or the From address. A rejected recipient points to the address itself. A sending limit points to the mail service. Fix the cause named in the bounce, test once more, and check the log again.
Final thoughts
Email delivery problems feel mysterious because they fail quietly, but they follow a chain, and chains can be tested link by link. A saved entry tells you the form worked. A spam folder tells you the message was delivered but filtered. A fixed From address, an authenticated SMTP service, and correct SPF, DKIM and DMARC records give inbox providers a sender they can trust. An email log tells you whether sending was attempted, accepted or bounced. Work in that order, change one thing at a time, and keep a note of each result, and you will usually find the break without rebuilding the form or the site.
Related WordPress guides: shared versus managed WordPress hosting, plugin mistakes that slow WordPress, WordPress major versus minor updates, how to stop WordPress brute-force attacks, how to find and remove hidden WordPress malware, the WordPress file permissions security guide, is your WordPress theme slowing you down, the WordPress speed battleground, object caching with Redis and Memcached, how to switch WordPress themes safely, and how to choose a WordPress theme.
If you have worked through every step above and emails are still not arriving, share the exact point where your diagnosis stopped — saved entry or no entry, found in spam or not found at all, and what the email log showed — in the comments below, and we will help you read what that result means.
