Why Business Emails Go to Spam: A Practical Deliverability Checklist

Business emails usually land in spam because the receiving system does not have enough reason to trust the sender, the message or the sending pattern. Missing authentication is one cause, but a passing SPF record does not cancel poor reputation, stale recipient data, complaints, suspicious links or a recipient's own filtering policy.

Start by identifying the failure you actually have. A rejected message, a message accepted into spam and a message filtered by one company's gateway are three different problems. Changing DNS at random can make a working setup worse.

Why business emails go to spam

Mailbox providers assess several signals together:

• Authentication: whether SPF, DKIM and DMARC show that the sending system is authorised and aligned with the visible From address.
• Reputation: what recipient systems have learned about the sending domain, IP address and recent mail stream.
• Sending behaviour: sudden volume changes, inconsistent patterns, compromised accounts or a new application sending without the expected setup.
• Recipient quality: invalid, stale, purchased or uninterested addresses that create bounces and complaints.
• Message signals: misleading headers, broken HTML, risky links, unusual attachments or content that looks unlike the sender's normal mail.
• Recipient-side controls: a personal block, company quarantine rule, security gateway or local allow/block list.

If you are still setting up mail on your own domain, use the business email setup guide first. The checklist below assumes the mailbox can send and receive, but some outbound messages are being filtered.

First separate delivery failure from spam placement

Email delivery and email deliverability are related, but they are not the same result. Delivery means the recipient server accepted the message. Deliverability asks where the accepted message appeared: inbox, promotions, junk, quarantine or another filtered location.

That split prevents a common mistake: changing the hosting account because one recipient's security gateway quarantined a message, or rewriting a subject line when the message is failing DMARC.

Collect one useful test before changing anything

Send a normal, representative message from the affected source to test mailboxes at more than one provider. Do not use a subject and body that only say “test”. Keep the message simple, but make it look like the type of mail the business normally sends.

For each result, record:

• The exact sender and recipient addresses.
• The date, time and timezone.
• The subject line and message ID.
• Whether the mail was accepted, bounced, delayed, quarantined or placed in spam.
• The complete bounce text or full message headers.
• Which system sent it: Outlook, webmail, a website form, CRM, invoicing platform, helpdesk, newsletter tool or another application.
• Any recent DNS, hosting, website, mailbox or sending-platform change.

Roundcube users can follow the Allanux knowledge-base steps to view the full email header. Never send a mailbox password in a support request. Headers, timestamps and message IDs are useful; passwords are not.

Check every system that sends as your domain

Most businesses have more senders than they realise. Staff may use webmail or Outlook, while the website sends form notifications, WHMCS or another billing system sends invoices, a CRM sends follow-ups and a marketing platform sends campaigns. A clean mailbox setup does not automatically authenticate those other systems.

Build a sender inventory with one row for each source:

• Sending service or server.
• Visible From address and domain.
• Envelope sender or return-path domain where available.
• DKIM signing domain.
• Message type: staff, transactional, alert or marketing.
• Owner who can change the configuration.

Website forms deserve special attention. A form should not normally pretend to send from the visitor's Gmail, Outlook or corporate address. Use an authenticated address on the website's own domain as the From address and place the visitor's address in Reply-To. That preserves a usable reply flow without breaking alignment by impersonating a domain the website does not control.

Verify SPF, DKIM and DMARC without guessing

These controls solve different parts of sender identity:

• SPF lists which systems may send mail for the envelope-sender domain.
• DKIM adds a cryptographic signature that a receiving system can verify against a DNS key.
• DMARC checks whether the visible From domain aligns with a passing SPF or DKIM result and publishes a policy for failed mail.

The full header should show the Authentication-Results values for the actual message. A DNS lookup tool can confirm that records exist, but the received header shows what passed for that send.

Use the Allanux explainer if you need to understand what an SPF record authorises. Remember that SPF must account for every legitimate sending service. Adding a CRM or newsletter tool without updating the authorised sender path can leave that stream failing even while staff mail passes.

SPF, DKIM and DMARC are normally published as DNS TXT data. The DNS TXT record guide explains where that data fits. Do not paste a record copied from another company or publish a second SPF policy because a checker suggested it. Collect the current zone and the official value from each sending provider, then have the DNS owner make one controlled change.

Passing authentication improves trust and protects the domain from spoofing, but it does not guarantee inbox placement. Recipient providers still assess reputation, complaints, message quality and their own policies.

Match the fix to the type of email

Do not push a large marketing campaign through the same mailbox workflow used for quotes and client support. Yahoo recommends separating bulk or marketing streams from user and transactional mail because each stream develops its own reputation. Even where the infrastructure is shared, the sending purpose, DKIM domain, complaint handling and operating process should be deliberate.

Protect reputation with steady sending and clean recipient data

Mailbox providers learn from patterns. A new domain that sends a sudden large campaign, an old list with many invalid addresses, or a compromised mailbox that starts sending bursts can all look risky. The safe response is not an artificial “warm-up” scheme. Send legitimate, wanted mail at volumes the business can support and monitor the real outcomes.

• Stop sending to addresses that hard-bounce or no longer exist.
• Separate temporary failures from permanent failures and follow the sending platform's retry guidance.
• Suppress recipients who unsubscribe or report spam.
• Do not buy, scrape or reuse a list whose permission cannot be proved.
• Set clear expectations when someone subscribes: what they will receive and how often.
• Avoid jumping from occasional mail to a large send without checking the platform, authentication and list first.
• Review security if the sending pattern changed without authorisation.

For South African marketing mail, consent and opt-out handling are also compliance questions. The Information Regulator's guidance on section 69 of POPIA covers direct marketing by unsolicited electronic communication. Use appropriate privacy or legal advice for the campaign; do not treat a deliverability checklist as legal clearance.

Review the message after the technical checks

Content can contribute to filtering, but a list of forbidden “spam words” is not a complete diagnosis. Look at the whole message and the destination of every link.

• Use an honest sender name, From address and subject line.
• Avoid URL shorteners, unrelated tracking domains and links to a compromised website.
• Include a readable plain-text version when the sending platform supports it.
• Keep HTML valid and the message usable without loading every image.
• Do not attach large or unusual files when a secure, recognisable link is more appropriate.
• For marketing mail, make the unsubscribe path visible and functional.
• Test a simplified message only after saving the original evidence, so you can compare one change at a time.

If a plain message from the same source still lands in spam, changing adjectives is unlikely to repair failed authentication or a damaged sending reputation.

Check recipient-side filtering when the problem is isolated

If Gmail accepts the message but one client's Microsoft 365 tenant does not, or only one employee sees it in quarantine, ask that organisation's mail administrator to trace the message. Give them the sender, recipient, timestamp, subject and message ID. They can check gateway policy, quarantine events, tenant allow/block lists and user-level rules.

Do not ask every recipient to safelist the address before fixing a sender-side problem. A safelist may help one relationship, but it does not repair authentication, list quality or reputation across the wider mail stream.

A practical recovery order

1. Pause the affected bulk stream if complaints or bounces are rising. Continuing to send can deepen the reputation problem.
2. Collect a bounce or full header. Identify whether the message was rejected, accepted into spam or filtered by one recipient.
3. Inventory every authorised sender. Include staff mail, websites, CRMs, billing, helpdesk and marketing systems.
4. Fix authentication and alignment. Make controlled DNS and platform changes, then verify a newly received message.
5. Clean the recipient process. Suppress invalid, unsubscribed and complaining recipients; confirm how consent was obtained for marketing mail.
6. Resume legitimate mail steadily. Avoid sudden volume spikes and watch bounces, complaints and provider dashboards.
7. Escalate with evidence. Give the email host or recipient administrator the support packet, not a vague “email is broken” report.

Google Postmaster Tools can expose authentication, spam-rate, reputation and delivery-error signals for qualifying Gmail traffic. Microsoft and Yahoo publish their own sender guidance. These tools are evidence sources, not inbox guarantees.

When email hosting is part of the fix

An email host can control the outbound platform, account security controls, sending policies, server logs, DNS instructions and support path for hosted mail. A provider can also investigate a server or IP reputation issue that an individual mailbox owner cannot see.

The host cannot make a purchased list legitimate, correct a third-party CRM it does not manage, remove a recipient's quarantine rule or guarantee that every message will reach the inbox. Good email hosting reduces avoidable infrastructure problems; disciplined sending and correct authentication still matter.

If your current setup mixes personal mailboxes, website notifications and unsupported sending methods, review the Allanux Web email-hosting options and ask which part of the mail flow the service would control before you migrate.