Practical technology
Email sent does not always mean email delivered
When a quotation or website enquiry goes missing, begin by asking what “sent” means in that system. The website may have queued the message, or a mail server may have accepted it for processing. Neither observation alone proves that the recipient received it in the inbox. A useful investigation follows one message through the stages instead of changing several settings at once.
Collect a bounded example
Use a non-sensitive test with an agreed recipient. Record the approximate sending time, sending address, destination and any error or bounce reference. Ask the administrator to inspect the relevant mail log without exposing mailbox contents, credentials or customer information in public support screenshots.
In a fictional small business, staff email works but invoice messages fail. This suggests checking the invoice system’s sending route first rather than immediately moving all staff mailboxes. It is a starting hypothesis, not a diagnosis.
Map the real senders
List staff mail, website contact forms, invoicing software and other authorised sending services. Google’s SPF guidance stresses accounting for the actual senders for a domain. Adding a record copied from an unrelated setup can leave out the very service that needs permission.
SPF and DKIM support email authentication, while DMARC adds a domain policy and alignment checks. Follow current instructions for the providers you actually use. Record the existing settings and agree verification before making changes; this article is not a domain-specific DNS prescription.
Check the receiving result
Look for an explicit rejection, delayed delivery or filtering outcome. If a test reaches spam, it has reached the recipient’s mail system but has not achieved the intended inbox placement. Authentication is relevant, but it does not guarantee that every message will reach the inbox.
Keep the test small and change one understood factor at a time. After a correction, compare the same sending route again and document the result. If the original evidence is missing, report that limitation rather than declaring a provider faulty or a repair complete.
Your next step
A practical checklist
- Identify the exact application and sending route.
- Retain a test time and any error or bounce reference.
- List all authorised services sending for the domain.
- Check authentication against current provider guidance.
- Confirm the recipient-side result after the change.