Missing enquiries, repeated sign in prompts and bounced invoices quickly become business problems. Changing the email platform is rarely a useful first diagnosis. We need to know which mailbox, app and sender are involved.
Support can focus on one person’s Outlook setup or on the domain configuration used by the whole business. Website forms and other systems that send email on your behalf need to be included when they are part of the fault.
Describe the failure in enough detail to follow it
A useful request might say that messages sent from the website stopped arriving after a hosting change, while ordinary mail still works. Another might say that only one supplier receives a delivery failure notice. These examples point to different checks.
Keep the time, sender, recipient and error available through an agreed private method. A redacted failure notice or message header can help establish what happened. Repeatedly sending the same message without checking the error rarely adds useful evidence.
Separate the mailbox from the app
If email works in your browser but fails in a desktop app, the mailbox may be healthy. We check the account, app configuration and device before changing the domain. If the whole team is affected, we review service status, licences and the records that route mail.
Send the full error message and the time it occurred. A delivery failure notice is more useful than a screenshot saying that a message did not arrive.
Keep domain changes controlled
Mail routing and sender authentication depend on domain records. We check existing senders, including your website forms and accounting software, before adjusting them. A record change made for one system can affect another.
We agree on access with the domain owner, record the starting configuration and verify sending and receiving after the change. Email authentication reduces some spoofing risks but does not guarantee delivery.
Sort shared addresses and departing staff
An address such as accounts or enquiries needs a clear owner and appropriate access. We help work out whether a shared mailbox, group or separate account suits the task. When someone leaves, the handover should address their mailbox, access and any business records that need to be retained.
Understand routing, identity and inbox placement
The domain’s mail routing records tell other systems where to deliver incoming mail. Sender authentication records help a recipient check whether a service is authorised to send for the domain. Those are related jobs, but changing one does not repair every kind of email failure.
We review known senders before a change to SPF, DKIM or DMARC. Microsoft documents how these standards work together. Authentication can help reduce spoofing; recipient filtering and sender reputation still influence whether a legitimate message reaches the inbox.
What the handover should include
The agreed handover should identify the mail service, the domain owner, approved sending systems and any records changed. We check sending and receiving through the relevant paths rather than relying on one message between staff.
If the recipient’s provider or another vendor must investigate, we explain the evidence and next step. Ongoing monitoring or a broader security review needs its own scope.
