Practical guide ·
Why are our business emails going to spam — and what should we check first?
Collect a failed message and identify the service that sent it before changing settings. Delivery problems can involve authentication, reputation, mailing practices or the recipient’s filtering. A passing technical check is useful evidence, but cannot guarantee inbox placement. Diagnose one sending path at a time and preserve a baseline for comparison.
What evidence should we preserve?
Keep the sending time, sender and recipient domains, full message headers where available, and any rejection code. Distinguish a rejected message from one accepted into spam and one delayed in transit. These are different outcomes and can require different actions.
Use authorised examples with unnecessary personal data removed. “Our email is broken” is difficult to investigate; “invoices from this application were rejected by this recipient service at these times” gives the team a testable starting point.
Which system actually sends the message?
A company may send from its employee mailboxes, invoicing platform, CRM and newsletter tool. A successful test from a personal mailbox says little about the invoicing path. List the approved services and the domains each uses.
Check the message’s authentication results and domain alignment. SPF concerns authorised sending infrastructure; DKIM provides a domain-linked signature; DMARC connects authentication to the visible From domain and publishes a handling policy. DMARC at p=none provides monitoring rather than requesting quarantine or rejection.
| Observation | First evidence | Useful next check |
|---|---|---|
| Message rejected | Rejection code and timestamp | Sender requirements and sending path |
| Accepted into spam | Full headers and affected service | Authentication and reputation |
| Only one application affected | Application and sending-domain inventory | Its configuration and recipient list |
| Impersonation report | Original suspicious message | Exact-domain spoofing or lookalike domain |
Why can authenticated email still land in spam?
Authentication is one part of delivery. Google’s sender guidance also addresses reputation, complaint levels and sending practices. Correct authentication does not make an unwanted message wanted, and the recipient still controls its filtering.
In an illustrative case, employee messages arrive normally while a newly connected sales platform performs poorly. Investigating that platform’s domain, recipient list and sending pattern is more useful than changing every company mailbox. Separate technical faults from a campaign that recipients do not expect.
How should we make and verify changes?
Agree one change, an owner, a test window and rollback criteria. Record the result on the affected sending path. Avoid strengthening a domain policy before legitimate services have been identified and checked; an incomplete rollout can disrupt business mail.
Measure the original problem again using comparable examples. A DNS record being present is not the same as invoices reaching the intended recipient. Where several providers are involved, keep a shared incident timeline so each provider works from the same facts.
Why does business email land in Gmail or Outlook spam?
Separate a rejected message from one accepted into junk. Record the sending system, receiving service, time, message identifier and any delivery-status code. “Outlook” may mean the desktop application, a personal Outlook.com mailbox or an organisation's Microsoft 365 service; identify the actual receiving system before applying guidance.
Inspect the original message headers at the receiver. As a fictional diagnostic pattern, spf=pass for bounce.example.net does not establish alignment with a visible From domain of example.org. An aligned valid DKIM signature can still allow DMARC to pass. Read the identifiers and the receiver's evaluation together; a green DNS checker does not show which path a particular message took.
Even with authentication passing, delivery can be affected by recipient complaints, sending patterns, content, reputation and local recipient policy. Compare a small set of affected messages with legitimately delivered ones. Do not change every DNS setting at once: record a hypothesis, agree a bounded change and observe the result.
Google's requirements distinguish ordinary senders from higher-volume sending to personal Gmail accounts. Microsoft's Outlook.com guidance has its own requirements. Follow the relevant provider instructions rather than treating a bulk-marketing rule as an identical obligation for every individual business message. A missing Postmaster dashboard at low volume does not prove healthy reputation.
Download the Gmail and Outlook diagnostic record. It captures the original result, authentication identities, affected routes, planned correction and follow-up. Redact personal data before sharing headers externally. For a message that authenticates correctly but asks for new bank details, use the separate payment verification process.
Explore in detail: Who is sending email in your company's name.
How Dyasol can help
Dyasol’s email and domain audit reviews the agreed domains and signals and produces prioritised actions. Technical remediation and ongoing monitoring can be scoped separately; inbox placement is not guaranteed.
Sources and context
Examples are illustrative. Practical recommendations should be adapted to the organisation.