If a customer finds your business email in junk, start by identifying which service sent it. A message from your mailbox, an invoice from an accounts platform and a website notification can show the same business address while travelling through different systems. Changing the mailbox provider before checking those routes can leave the original problem untouched.
For a small firm, the most useful first result is a clear description of the failure: which sender, which recipient, when it happened and what the receiving system recorded. Use that to decide who needs to investigate.
Establish what “not received” means
Ask the recipient to check junk and any quarantine available to them. Keep a rejection or delay notice if one arrived. A message that was rejected, a message waiting in quarantine and a message sitting in junk need different follow-up evidence.
Record the sending address, recipient address, approximate time and time zone, subject and sending application. Keep these details in the support case rather than posting customer correspondence publicly. Where a message contains confidential information, agree a suitable way to share the evidence with the provider.
If only website enquiries are missing, follow the contact-form delivery checks first. Confirm that the form created a submission and attempted a notification before treating the whole problem as spam filtering.
Compare the routes that work with the one that fails
Make a short list of the systems that send as your business. Include normal mailbox replies, website forms, invoicing, appointment reminders and any mailing service you actually use. Then compare a working message with a failing one from the affected route.
- Mailbox replies arrive, but invoices fail: collect an invoice-platform message and its sending details. Start with that platform’s domain-authentication setup.
- One recipient organisation is affected: ask its mail administrator for the rejection, quarantine reason or receiving trace. Keep examples that reach other organisations for comparison.
- Several services fail after a domain or DNS change: review the saved change record with the DNS administrator and each affected sender’s requirements.
- Messages arrive directly but fail after forwarding: tell the provider about the extra hop and retain an original received copy where possible.
These patterns identify a sensible starting point; they do not establish the cause by themselves. Avoid sending repeated identical tests to a frustrated customer. Use agreed test recipients and give each message a recognisable subject.
Get the original message, not just a screenshot
A screenshot of the junk folder shows the symptom but leaves out the transport evidence. Ask for the original message or full headers through an agreed private route. In desktop Gmail, the received message’s More menu has Show original. Other mail applications have their own header or message-source view.
Ask the provider to interpret the receiving system’s authentication results, sending server, message identifier and timestamp. If your sending platform offers a delivery log or message trace, match it to the same example. An accepted handover in a sending log does not tell you which folder the recipient eventually used.
Use a fresh message from the affected system when checking a change. Forwarding an old message to yourself introduces another route and can give you a different set of authentication results.
Check authentication without expecting it to settle everything
SPF, DKIM and DMARC help receiving systems assess whether a message is authorised to use a domain. A provider can check both the underlying results and whether the authenticated domain aligns with the address the customer sees. The multiple-sender checklist explains what to collect when several applications use your business identity.
Passing authentication does not guarantee inbox placement. Receivers also apply their own filtering and reputation decisions. Google’s sender guidelines describe requirements for personal Gmail recipients, with additional requirements for bulk senders; they are not a universal checklist for every receiving service.
If authentication passes and only one receiving organisation has a problem, give its administrator the specific example. If the provider identifies compromised sending or unexpected account activity, follow its account-security process before resuming normal sending.
Give the provider a small, usable support brief
Send one clear case covering the affected service, when the issue began, what changed, one failing example and one useful comparison. Ask the provider to say whether the problem occurred before handover, at acceptance or after acceptance, and what evidence supports that finding.
For a domain used by several services, attach a sender list with an owner for each route. If aggregate reporting is already available, the DMARC report guide shows how to turn authentication failures into a provider action list. Reports are a second view of the sending estate; a single troublesome message still needs its own evidence.
Agree the proposed change, who will make it, which routes will be retested and what success means. “A fresh invoice arrived and the receiver recorded the expected authentication” is a useful result. “The DNS checker is green” leaves the customer’s original problem unanswered.
Decide whether a change of service is justified
Replacing email hosting becomes a reasonable buying decision when the current service cannot meet the business’s requirements or provide the support needed. Compare mailbox management, shared work, recovery and migration arrangements using the business email hosting guide. Keep the diagnosis and sender inventory so a move does not recreate the same configuration gap.
If you are planning a website project in Formby, Freshfield or L37, outline the website and enquiry workflow, including any forms or platforms that send business mail. That gives the project discussion a concrete starting point alongside the work your email provider needs to handle.
