By default WordPress sends messages using a server function. That worked ten years ago. These days receiving servers check whether the sender is allowed to send on behalf of that domain, and an unauthenticated message lands in spam or is rejected outright.
Try a password reset and the contact form. If neither works, this is about sending. If one works, this is about that one feature. This single test saves a lot of wasted effort.
The right fix is to configure WordPress to send through your own mailbox with authentication, the same way an email client sends. You need the address, the password, the server name and the port. The same details are in our guide on connecting a mailbox to an email client.
The sender must be an address on a domain you own, for example one reserved for forms. The visitor's own address belongs in the reply field, not in the sender field. This one change solves a large share of spam folder problems.
A domain has three records that state who may send on its behalf. If they are missing or outdated, messages go to spam even when sending technically succeeds. They are covered in our guide on SPF, DKIM and DMARC.
Always test to an outside address, not to a mailbox sitting on the same server as the site. A message can pass inside the house and be rejected outside. Check the spam folder too, because the message may have arrived in the wrong place.
Then this is about queuing. The usual cause is that messages are sent during a page load and the scheduled task does not run until somebody visits the site. On a busy site this never shows, on a quiet one it shows as hours of delay.
Do not solve this by using a free email service address as the sender. That is exactly the structure recipients reject, and it damages the reputation of your own domain. The basics of business email are covered in our guide on business email.
We switch sending to an authenticated mailbox, fix the sender address and check the domain records. We finish with a real test send, so we know messages arrive rather than merely leave.
