An email accepted by your website is not the same as an email received by the customer. To check confirmations, notices and automatic replies, follow the message from the application to a test inbox. Check the sender, the domain authentication and the provider's errors before blaming the form or changing hosting.
Imagine a language school: a student asks for information, the confirmation appears on screen and the team expects a notice to arrive. Nobody finds it. The next day, someone discovers the enquiry on logging into the dashboard. The website collected the data, but the customer service process was left half done. It is a hypothetical example, not a case from a meiika client.
The useful question is not whether to install another plugin. It is what we know about the missing message and where it stopped moving forward. This guide focuses on operational emails that the recipient expects; it does not suggest sending advertising to contacts without having reviewed the applicable conditions.
What does it really mean for an email to be sent?
Several outcomes tend to get confused. The form may have received the enquiry; the application may have requested the sending; a server may have accepted the message; the recipient's provider may have stored it. These are different steps, and a confirmation of the first does not prove the others.
The WordPress documentation on wp_mail, accessed on 11 October 2026, warns that a positive response does not confirm receipt. That distinction lets you ask for concrete proof: a log of the request, a message identifier and the result returned by the service used.
Nor should you confuse receipt with reading. A delivered message can go unnoticed or end up in a category the user does not check. Follow-up based only on opens adds another uncertainty. For a functional test, it is more useful to check the message in a controlled inbox than to interpret an isolated commercial signal.
Define what your interface promises. If it only confirms that the enquiry has been recorded, say so clearly. Do not announce an email confirmation when the system does not yet know the result of the sending. And avoid making the email the only copy of an important request: an internal way to look things up makes it easier to recover pending work.
Which identity does each tool send from?
Your usual mailbox, the form, the booking tool and the CRM may send along different paths even if they all show the same name. Take an inventory of each sender before touching the domain. The manual email that works does not show that sending from the website is configured the same way.
For each operational message, note its origin, the visible address, the sending provider and who receives the errors. Add the person responsible for that configuration. If an old agency still holds the service account, the problem is also one of continuity: you need to know who can review logs and renew access.
The reply-to address deserves a separate check. A form can send you a notice from a business account and use another address for replies. Review both fields with test data. Do not use someone else's identity as the sender just to make it look as if the notice comes directly from the visitor.
In the hypothetical school, enrolment emails go out from a platform and website enquiries go out from the hosting. A recent change could affect only the second path. The comparison helps narrow the investigation, without concluding that the platform, the student or the host is to blame before there is evidence.
What do SPF, DKIM and DMARC add?
SPF helps declare which systems may send for a domain. DKIM adds a signature the receiver can verify. DMARC links authentication to the visible sender domain and lets you express a policy. They are not three equivalent switches, and they do not replace checking that each legitimate sender is configured properly.
Gmail's guidelines for senders, accessed today, distinguish general requirements from requirements for high volumes. They recommend setting up all three mechanisms. That reference is useful for reviewing delivery to personal Gmail accounts; it should not be presented as an identical universal rule for every recipient.
Do not copy a DNS record you found in a tutorial without identifying your services. You could leave out a sender that the business does use. Ask the person responsible for a proposal based on the inventory and a later check with real test messages. Changing the policy without verifying legitimate sending can create a new problem.
Gmail's requirements and FAQ, accessed on 11 October, also clarify the role of alignment. You do not need to interpret every header to ask for a professional review. It is worth demanding an understandable result, though: what is happening, what fails, which service is affected and which change has been validated.
How do you investigate a message that does not arrive?
Start with a recognisable test, with no customers' personal information. Choose a controlled inbox and write a unique subject. Save the time, the origin and the result shown by the application. Then review the provider's log and the destination inbox, including the spam folder.
A log with a specific error guides you better than a series of resends. Keep the code and its description; whoever maintains the service can relate them to the relevant documentation. If there is no log, that absence is part of the diagnosis: perhaps you are looking at another sender, or the application did not start the sending.
- If the enquiry is not recorded, check the form and how it receives data first.
- If it is recorded but sending is not requested, check the notice logic.
- If the provider rejects the message, keep its response and the identifier.
- If it is accepted but does not appear, investigate the destination and the authentication.
Then repeat the test with a second agreed inbox, changing just one relevant condition. Do not turn the tests into a campaign or use emails taken from your database. A small, documented check makes it easier to compare results without bothering anyone.
How do you keep sending under control?
The diagnosis should end in a routine the team can maintain. Define where failures are checked, who reviews them and how pending requests are recovered. An automation that fails quietly for weeks is not fixed because someone managed to send an email once.
Keep operational notices separate from any commercial communication. A confirmation message should contain what its purpose needs and an understandable link. If there is another campaign, assess it separately. Technical authentication does not by itself determine whether a communication is permitted. This is general information, not legal or professional advice.
Before closing an incident, check the usual journey and an error situation. The team must be able to find the request when the email fails. If someone changes a booking, also verify the modification notice; it is not enough to test the initial confirmation and assume that all templates use the same route.
Keep a short record of the system: senders, owners, review date and tests carried out. Store access credentials somewhere suitable, outside that shared record. When you change tool or provider, review the inventory. Email configuration travels with changes in the business; it does not end when the website launches.
How have we approached it at meiika?
At meiika we present websites and custom systems as parts of a working journey. That is why a review can start from the result the team needs and from the dependencies between form, storage and notice, before choosing an additional tool.
This article describes a review criterion, not a result achieved for the school in the example. A specific assessment would need to identify your provider, the senders and the access available to their logs. We do not promise that an adjustment will guarantee the inbox on every service and for every recipient.