A contact form is the most common thing a website does that involves the server actually doing something, and it fails in two directions that look identical to the visitor: the message is never sent, or it is sent and never arrives.
Almost everything below follows from that distinction.
Store submissions as well as emailing them
The single most valuable setting, and it is off by default in some plugins.
A form that only emails has no record. When mail delivery fails, and it does. The enquiry is simply gone, and nobody knows it existed.
Storing submissions in the database means a delivery problem costs you a delay instead of a customer. It also gives you something to check when someone says "I sent a message last week".
The trade is that you are now holding personal data, with retention to decide. What a Website Needs for Privacy and Cookie Compliance explains that side.
Send from your own domain, not the visitor's address
The configuration mistake behind most form mail landing in spam.
Putting the visitor's address in the From field means your server sends mail claiming to be from a domain it is not authorised to send for. That fails authentication, and it fails at the receiving end where you cannot see it.
Set From to an address on your own domain, and put the visitor's address in Reply-To. Replying still works exactly as expected, and the message authenticates properly. For that, see Understanding SPF, DKIM and DMARC Records.
Use SMTP instead of the server's default
Mail handed to the server's local mail program arrives with weaker credentials than mail authenticated to a real mailbox, and increasingly gets filtered.
An SMTP plugin authenticating to a mailbox you created is the fix, and it is the difference between form mail arriving and form mail existing. How to Fix WordPress Email Not Sending explains the settings, including the username that must be the full address.
Send the notification to an address you check, and not one on the same domain if you can avoid it. A hosting problem then does not take out both the form and the notification about it.
Spam: what works and what does not
An unprotected form receives automated submissions continuously.
A honeypot (a hidden field that humans never fill and bots do) is invisible, free, and stops a large share of it. Enable it first.
A time check, rejecting submissions completed in under a couple of seconds, catches more.
A CAPTCHA works and costs you real submissions, because some people cannot or will not complete it. Add it only when the first two are not enough.
What does not work is a maths question. Those were solved years ago and only inconvenience your visitors.
Confirm to the visitor, and mean it
A visible confirmation after submitting, and ideally an email to the sender.
Without it, people submit twice, then email you separately to ask whether it arrived, which is more support contact than the form saved.
Make the confirmation specific: "we have your message and will reply within one working day" is a promise you can keep. "Thank you" says nothing.
File uploads change the risk
A form accepting attachments is a form letting strangers put files on your server.
Restrict the accepted types to what you actually need, and set a size limit: noting that the PHP limits apply as well, and a file larger than those fails before your form sees it. There is more on raising them in How to Configure PHP Settings in cPanel.
More importantly, uploads must land somewhere that cannot execute code. A PHP file uploaded into a directory the web server will run is a compromised site, and file-type checks based on the extension are not sufficient on their own.
Validate on the server, not only in the browser
Browser validation is a convenience for the visitor. It can be bypassed entirely by anything that is not a browser, which describes every automated submission.
Any plugin worth using validates server-side as well. If you are building something custom, that is the half that matters.
What a busy form costs
Each submission runs the application, writes to the database and sends mail, and form pages cannot be cached usefully because of the token that protects them.
On a site receiving heavy automated submissions, that is real load spent on spam. Blocking it at the form is also blocking it from consuming your processes, which is a performance argument for the honeypot as much as a hygiene one. How to Monitor Your Hosting Resources walks through seeing it.
Test it properly, and again later
Submit the form yourself from outside your own network, and check the message arrives at the destination inbox rather than in spam.
Then test it again after any change to the site, the theme, or the mail configuration, and once a quarter regardless.
A broken contact form is the failure nobody reports. The people affected assume you received the message and are ignoring them, which costs more than the fault itself.
A form that accepts attachments creates a directory strangers write into, and one rule about it matters more than all the others. For that, see How to Set Up a File Upload Directory Safely.
A form notification that is accepted and then filed as spam produces no bounce and no warning. There is more on making that visible in How to Send Application Email Through a Relay Service.