Why your contact form emails go missing or land in spam

Use your own contact details and a short, harmless message that you will recognise. Do not enter a customer's information. If someone else looks after the website, agree the test with them first so they know which enquiry to investigate.

Write down the page address, submission time and what appeared after you pressed send. Take a screenshot without personal information. Check whether the form rejected a field, stalled on a security check or showed success. These are different faults and need different fixes.

If the form has a submissions area, look for your test there. Not every website stores enquiries, so an empty or missing submissions area is not proof that nothing was sent. Ask your web person whether the website saves submissions and, if so, where.

• Confirm the notification destination is your current business address, not an old address or the person who originally built the site.
• Check the actual mailbox through its provider's website, as well as the email app on your phone.
• If the form sends a receipt to the visitor, check that separately. A visitor's receipt does not prove that your business notification arrived.

Search all folders for the test's time, subject or sender. Include spam, junk, the bin and archived mail. A workplace email service may also have a quarantine area that only an administrator can see. Ask them to check it before assuming the message disappeared.

Review rules that move, delete or forward incoming messages. Check whether another connected email app is archiving or deleting them. Gmail's missing-mail guidance also recommends checking storage, because a full account may stop receiving email.

If you find the notification in spam, mark it as wanted and add the genuine sender to your contacts if your provider supports that. This may help your own mailbox, but it does not repair the website's sending setup or guarantee that customer confirmations will arrive elsewhere.

Some forms put the visitor's email address in the From field. That makes your website look as though it is sending on behalf of someone else's domain. It normally has no permission to do that. Mail services can treat the message as impersonation and reject it or put it in spam.

Use a From address on a domain that your sending service is authorised to use. Put the visitor's validated address in Reply-To, the setting that tells your email app where replies should go. Your web person can usually change these separately in the form or sending service.

Changing the displayed sender name does not authenticate the address. A name such as Website enquiries can help you recognise the message, but the domain behind the email address still needs the right sending setup.

A fictional business, Acme Ltd, sends its notifications from [email protected] through an authorised service. Alex's address goes in Reply-To. Staff can reply to Alex without the website pretending to send from Alex's email provider.

These are email authentication settings. SPF lists services allowed to send for a domain. DKIM adds a digital signature that receiving services can check. DMARC checks whether the domain in the visible From address matches a domain authenticated by SPF or DKIM, and publishes instructions for handling failures.

The settings live in DNS, the records that connect your domain to services. Your normal business emails can work while the website's notifications fail, because the website may use a different sending service that has not been configured correctly.

Google requires SPF or DKIM for all senders to personal Gmail accounts. Its requirements for senders exceeding 5,000 messages a day are stricter. Google recommends setting up SPF, DKIM and DMARC regardless of volume. Those are Gmail's rules, not a claim that every small contact form must meet the bulk-sender requirements.

Ask your web person to follow the actual sending provider's domain-verification instructions and check a received test message's authentication results. Do not copy another business's DNS records or change the records that route your normal mailbox without checking their purpose. Authentication helps delivery, but does not guarantee inbox placement.

Find out whether the form uses the hosting server's mail function, an authenticated mailbox connection or a dedicated service for automated emails. These arrangements have different settings and logs. Installing a mail plugin is not enough if its credentials, sending domain or destination are wrong.

SMTP is the protocol used to transfer email between mail servers. A form can use an authenticated SMTP connection or a sending service's API, a software connection. Either can work. The useful question is whether the configured service accepts the message and gives you information when it cannot deliver it.

Check that the sending account is active, its credentials still work and it has not reached its allowance. A service for automated emails, often called transactional email, can make delivery easier to monitor. It still needs correct authentication and someone to respond to failures.

Ask for the log entry matching your test, rather than a general assurance that email is working. A form can accept an enquiry before an email service has accepted the notification. The email service can then accept a sending request before the receiving mail server accepts the message.

For example, Resend's sent event means its API request succeeded. Its delivered event means the recipient's mail server accepted the email. Neither event proves that the message appeared in the inbox rather than spam. Other providers may use different labels, so read their definitions.

• If there is no sending attempt, investigate the form's validation, security check and notification settings.
• If sending failed, check the logged reason, such as an unverified domain, invalid credentials or a sending limit.
• If the receiving server rejected the message, check the bounce reason and destination address. A bounce is a delivery failure report.
• If delivery is delayed, check the stated cause and the provider's retry policy before repeatedly submitting the form.
• If the receiving server accepted it, investigate mailbox filtering or quarantine with the recipient's provider.

Do not turn off spam protection for everyone just to get one test through. If a genuine submission fails a security check, investigate that check. Your form should validate entries and limit automated abuse. Otherwise unwanted submissions can use up your sending allowance and make real enquiries harder to find.

For important enquiries, consider saving submissions securely so a failed notification does not leave email as the only copy. That is a design choice, not a feature every existing site has. Restrict access, collect only what you need and set a deletion schedule. Update your privacy information to describe the handling of enquiries.

A visible email or phone alternative gives customers another route while a fault is investigated. Agree who receives delivery-failure alerts and who checks any saved enquiries. Keeping copies without checking them does not solve missed follow-ups.

Repeat the agreed test after the fix and trace it through the form, sending service and mailbox. If customers receive confirmations, test those using addresses you control with more than one email provider. Do not assume one successful delivery proves that every provider will accept future messages.

Give your web person the page address, test time, result shown on screen and where the message did or did not appear. Ask them to record the cause and the change they made. Repeat a test after changes to hosting, the form, the sending account or domain settings.