Start with one real delivery problem
A quotation that reaches spam can delay a sale. An invoice that disappears can create unnecessary follow-up work. Before changing providers or repeatedly resending, collect one example: the sender, recipient, sending time, subject and any error message. Ask whether the message was rejected, arrived in spam or cannot be found. These are different outcomes.
Keep a copy of the original message and its full headers if available. Share diagnostic information privately with your provider, rather than posting customer correspondence online. A specific example is much more useful than a general report that email is not working.
Identify every system that sends for your domain
Your team’s mail app may be only one sender. A website form, invoicing platform and newsletter tool can each send independently. Make a short inventory and test each route separately. A successful test from your own mailbox does not prove the invoice platform is configured correctly.
Ask your provider to check authentication for each route. SPF identifies authorised sending infrastructure, DKIM adds a domain signature, and DMARC checks alignment with the visible sender domain. Google recommends configuring all three. Have existing senders reviewed before tightening a DMARC policy so legitimate messages are not unexpectedly affected.
Look beyond the words in the message
Authentication is important, but it is not a guaranteed inbox pass. Google’s guidance also covers sending infrastructure, reputation and recipient complaints. Your hosting provider may need to investigate issues with a shared sending IP. Changing a subject line alone will not repair those problems.
For your own review, use an accurate sender name and a subject that describes the actual message. Check that contact details, links and attachments are expected by the recipient. Avoid presenting a new message as an existing reply. If a PDF is unusually large, ask whether a smaller version or an agreed document-sharing method would be more practical.
Run a controlled test
Send a normal, short business message through the affected system to a test recipient who has agreed to help. Record the time and result, then change one relevant setting at a time with your provider. This makes it easier to tell whether a fix worked.
For ongoing newsletters, use a permission-based list and an easy way to opt out. Remove addresses that repeatedly fail. Keep routine customer correspondence and bulk campaigns operationally distinct, with appropriate tools and clear ownership.
Know what to send your provider
Prepare the domain, sending application, affected recipient provider, approximate starting date and one recent example. Mention any recent DNS, hosting or invoicing-platform changes. Do not send your mailbox password in an ordinary support message.
OnHypp can review the agreed hosting and domain configuration scope and help identify the next action. Some issues need the sending platform or receiving organisation to investigate. The useful goal is a documented diagnosis and a measurable improvement, rather than a promise that every message will always reach the inbox.
Distinguish spam placement from message rejection
When a customer says an email was not received, first identify what actually happened. A message may have been accepted into Spam, rejected by the receiving server, delayed for retry or never sent successfully from the originating application. These cases have different evidence and fixes. Ask for the sender address, destination, local sending time and any returned error text. The absence of a bounce notice does not prove inbox delivery. Do not resend confidential invoices repeatedly while investigating, because duplicate messages can confuse customers and increase the appearance of suspicious activity. Start with one controlled test that can be traced end to end.
List every service that can send with your domain
A business domain may send mail from employee accounts, web contact forms, an accounting system, CRM notifications, booking reminders and a newsletter platform. Different systems can use different sending infrastructure even when the visible From address looks similar. Build a sender inventory before changing SPF or DMARC; otherwise, a change designed to improve delivery may block a legitimate service. Record whether a platform sends through authenticated SMTP, its own service or a dedicated transactional relay. Ask each application owner to confirm test messages and any recent configuration changes. This prevents the website developer and email administrator from troubleshooting different systems as if they were one server.
Understand SPF without treating it as a deliverability guarantee
SPF tells receiving systems which infrastructure a domain authorises for a particular envelope sender identity. It does not mean a properly authorised message will always appear in the Inbox. Mistakes include multiple SPF TXT records for the same domain, omitting an actual authorised sending service or creating lookup chains that exceed protocol limits. Do not paste an SPF example from a different business: the correct record depends on the real sender inventory and the domain used during SMTP delivery. Ask the responsible administrator to validate the resulting record and controlled test, especially after switching accounting systems or moving the web server.
Understand what a DKIM signature can and cannot establish
DKIM adds a cryptographic signature to selected message headers and body content, allowing a receiver to check whether the signed parts still match the signing domain's published key. A valid signature is a useful authentication signal, not proof that the sender is an honest business or that a payment request is safe. Multiple applications may sign with different selectors and keys; an older key can be retired incorrectly if the sender inventory is incomplete. Review how the chosen service publishes and rotates keys. When investigating a complaint, examine the receiving system's authentication results rather than assuming that seeing a DKIM DNS record means every message is signed.
Understand DMARC alignment and rollout risks
DMARC evaluates alignment between the visible From domain and authenticated SPF or DKIM identities, then lets the domain owner publish a handling policy and request reports. A strict policy should not be imposed simply to make an online checker show a perfect score. Start by collecting evidence about legitimate senders, understand failures, correct application configurations and progress carefully according to organisational risk. Forwarding and mailing lists can complicate alignment results, so one failure does not automatically mean the sender is malicious. DMARC can reduce some spoofing risks, but it cannot stop an attacker who already controls a real authorised account.
Check sender reputation and sending behaviour
Authentication is only one element of inbox placement. Receiving providers may also consider reputation, user complaints, sending consistency, suspicious links, malware and whether recipients actually wanted the messages. A new domain should avoid abruptly sending large promotional batches without consent and proper unsubscribe handling. Keep genuine transactional mail distinct from marketing where the application and service support that separation. Repeatedly emailing inactive or mistyped addresses creates avoidable delivery problems. When an issue affects one destination provider but not another, compare the evidence before changing your entire DNS configuration. No one can promise that all legitimate email will bypass spam filters.
Review message formatting and risky attachments
An invoice email may be technically authenticated but still trigger filtering because it contains a suspicious attachment, deceptive hyperlink or unexpected change in payment instructions. Keep subject lines accurate and use clear company contact details instead of urgent claims designed to provoke a click. Avoid sending password-protected executables or unfamiliar compressed files without prior agreement. Verify that hyperlinks visibly lead to the intended official domain. If a supplier unexpectedly requests a new bank account, confirm it through a previously trusted channel rather than replying to the same email. These practices help reduce risk, but a well-written message cannot compensate for a compromised sending account.
Collect complete delivery evidence without sharing secrets
Ask for a representative test message, its exact sending time and the delivery or rejection result. Where authorised, examine the original message headers and the receiver's Authentication-Results to learn whether SPF, DKIM and DMARC passed for that message. Compare a successful delivery with a failed one sent from the same application. Keep customer addresses, private invoices, session cookies and administrator passwords out of public support tickets or AI prompts; redact them before sharing diagnostics. A support request saying only 'email goes to spam' gives little information. A short timeline with message IDs and error codes is far more actionable.
Avoid breaking email when changing website hosting
Moving a website to a different managed hosting environment normally involves its web DNS and application files, not a necessary move of every business mailbox. MX records and mail authentication records should be recorded, preserved and tested independently. Some website contact forms still send through the old server or an SMTP mailbox; those integrations need their own transition plan when the site moves. Do not remove DNS entries merely because they appear unfamiliar to the new website developer. A successful homepage load and valid SSL certificate are not evidence that quotation emails or password-reset notifications are delivering correctly. Test the important application-to-email paths separately.
Separate phishing incidents from ordinary spam filtering
When an employee reports suspicious mail, distinguish two questions: was an unwanted external message filtered, or did somebody actually access a legitimate company account? Evidence of compromise includes unexpected sent messages, unfamiliar forwarding rules, login alerts and changes to recovery information. These require account containment and an incident procedure, not merely a DNS tweak. Protect affected records, revoke sessions and investigate with the appropriate authorised administrator. Changing hosting plans does not correct negligent password sharing, missing MFA or approval of a fraudulent payment request. Make staff security awareness and independent payment verification part of the business process.
Agree who manages DNS, mailboxes and applications
A website company, email host and accounting software vendor may each control one part of delivery. Write down which party manages DNS, who authorises an SPF change, who can reset an employee's account and who investigates a failed application notification. A managed web-hosting product can reduce server-maintenance work without assuming responsibility for every external mail platform. OnHypp's standard Biz/Power range focuses on professional email and ordinary websites; its optional managed application-hosting tiers do not automatically include the same mailbox capacities. This separation should be explicit before diagnosing delivery failures or proposing an upgrade.
Use a disciplined resolution checklist before declaring success
Close a deliverability ticket only when the original failure mode has been tested with the responsible system. For an invoice sent from accounting software, test an actual authorised invoice-template message to representative external domains, check its authentication results and confirm the recipient can see it. For a contact form, test the form submission, server-side response and receipt separately. Keep a before-and-after record of DNS values and the reason for each change. Avoid promising universal Inbox placement, because receiving systems ultimately control filtering. If the issue persists, escalate with sanitised message headers and evidence instead of repeatedly altering unrelated records.
Check the results using the actual sending application
To confirm a fix, test the application that caused the original problem rather than sending only a message from an administrator's mailbox. Website form notifications, invoicing systems and staff mail can use different servers and authentication paths. Record the time, authorised test address, delivery result and relevant configuration changes. If two senders use the same domain but only one fails, do not assume the whole mail service is broken. Investigate the affected sending flow, review appropriately sanitised logs, and obtain permission before modifying DNS records.