Check a missing business email in three places: the sending system, the delivery record and the receiving mailbox. A website’s success message does not prove an enquiry arrived. Spout’s business-email setup starts from K600, confirmed in your written quote; diagnosing an existing delivery fault needs a scope based on the evidence, not a guessed repair.
Is the problem your mailbox or your website form?
Send a normal message to the business address from an independent mailbox. Then submit a clearly labelled test through the website, using details you are authorised to use. Keep the time, recipient and subject for each test. These are two different routes and should be checked separately.
If normal email arrives but the form enquiry does not, the form’s sending route deserves attention. If neither arrives, check the mailbox and domain configuration before rebuilding the form. If only one staff member cannot see the message, investigate their access, folders and rules as well.
Avoid a vague report that email is broken. Give the person helping you a specific test and the stage where the evidence stops. That makes it easier to distinguish a website problem from a mailbox issue without changing several working systems at once.
What evidence should you collect before changing settings?
Our recommended evidence sheet follows the message through the journey. It is a diagnostic aid, not a technical access request for every member of staff.
| Stage | Evidence to request | What it establishes |
|---|---|---|
| Customer submission | Test time and expected destination | What the customer attempted |
| Website handling | Whether the application accepted and recorded the submission | Whether the website processed the request |
| Sending service | Delivery result or a specific failure message | What the sender attempted to deliver |
| Receiving system | Whether the destination accepted the message | Whether it reached that system |
| Staff mailbox | Inbox, spam, rules and access checked | Whether the intended person can find it |
Do not publish mail logs or customer messages in a public support thread. Share only the relevant evidence with the authorised person investigating it. Remove unrelated customer details from screenshots and keep account passwords out of the conversation.
What do SPF, DKIM and DMARC mean for an owner?
These are ways receiving systems assess whether messages using your domain are legitimate. SPF identifies permitted senders. DKIM adds a verifiable domain signature. DMARC connects authentication with the domain people see in the From address and defines how failures are handled.
Google recommends all three, while its minimum requirements differ for ordinary and bulk senders to personal Gmail accounts. Authentication can improve delivery, but it does not guarantee inbox placement. See Google’s sender guidelines, checked 19 October 2026.
For the owner, the useful action is an inventory of legitimate sending systems: staff mail, website enquiries, order notifications and any authorised mailing service. Ask your administrator to check each one before tightening domain policy. A change that helps one sender can expose an overlooked dependency elsewhere.
Why can staff email work while website enquiries fail?
Your staff mailbox and website may send through different services. A successful reply from a staff account therefore does not prove that the site’s messages use the same configuration or permissions. Ask the implementer to identify the actual sending route for the form.
Use the website’s own domain for its sending identity where properly configured, and keep the customer’s address in the reply route. Let the administrator verify the exact arrangement against your email service. Copying a stranger’s DNS settings into your domain is not a diagnosis.
Also check the destination saved in the form. A previously used address can remain in a website even after the contact page has been updated. Test the address customers actually reach, rather than relying on the one printed beside the form.
How do you avoid losing enquiries during the repair?
Give customers an alternative contact route while the fault is investigated. A monitored phone or WhatsApp number is useful when it is clearly presented and someone owns the response. Do not claim the form is restored until an authorised receiver has found the test message.
If the website keeps a submission record, compare it with the inbox to identify any messages needing a response. Handle those records according to the business’s access and retention rules. If no record exists, be honest about what can be recovered rather than reconstructing customer messages from guesswork.
Name a person to close the gap. They should know which enquiries have been checked, which need a reply and which remain uncertain. That operational step is separate from correcting the technical fault, and matters just as much to a customer waiting for an answer.
What proves that the fix worked?
Repeat the original test through the same route, then try a second appropriate destination if that is within the agreed scope. Confirm the message appears where staff expect it and that replying reaches the test sender. Keep the evidence with the resolved support request.
Check the error path too. A customer should not receive a confident success message when the application knows sending failed. Agree how the website handles that situation and how the business learns that it needs attention. Do not expose private technical details to the customer while explaining the next step.
Our business-email service covers setup; hosting and website care may be relevant to the website side. Bring the test time, expected address and any actual error message when you request help with email delivery. That evidence gives the review a useful starting point.
Spout Team. Prepared with AI assistance; sources checked on 19 October 2026.