Why your business email keeps landing in spam

Deliverability problems feel personal, and that is the trap. You rewrite the subject line, add a plain-text part, remove the word "free", and nothing changes — because the receiving server was never judging your prose. It was judging your domain.

Start with the headers

Every delivered message carries the receiving server's verdict in its headers. In Gmail, open the message, use the three-dot menu and choose Show original; in Outlook, open the message properties and look at the internet headers. You are looking for a block like this:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@crm.example designates 203.0.113.10)
         smtp.mailfrom=bounce@crm.example;
       dkim=pass header.i=@yourdomain.com header.s=selector1;
       dmarc=fail (p=NONE sp=NONE) header.from=yourdomain.com

That example is the single most common failure in a small business: SPF passed for somebody else's domain, DKIM passed for the sending platform, and DMARC failed because neither aligned with yourdomain.com, which is what the recipient sees. The mail was authentic. It just was not authentic for your domain, and receivers treat that combination with suspicion.

The six usual causes

Sending "as" your domain from a platform

Almost every CRM, newsletter tool and helpdesk will offer two options: send with the platform's domain in the From line, or send as your own domain. The second looks far more professional and is where the alignment problem starts.

If you choose it, you must authenticate the domain inside that platform. Most provide a DKIM key and a set of CNAME or TXT records for exactly this. Configure them, wait for the platform to verify, and only then switch the From address. If the platform cannot sign for your domain, do not put your domain in From — use a subdomain you control for that channel, and keep your main domain for mail that genuinely comes from you.

Reputation and reverse DNS

If the message authenticates cleanly and still lands in junk, the question moves from identity to reputation. Two things are worth checking. First, whether the sending IP has a reverse DNS entry that matches what the server claims to be — relevant if you run your own mail server, irrelevant if you use a hosted provider. Second, whether your domain or IP appears on a public blocklist; Spamhaus and the major providers publish their own lookup tools, and each listing has its own removal process. Do not pay a "delisting service" to do something the blocklist does for free.

A new domain or a newly assigned IP starts with no history, and some receivers are cautious about it for a few weeks. That is not a bug to be worked around; it is a reason to start sending small volumes of genuinely wanted mail first.

What you cannot fix from your side

Receiver-side scoring is not published, and individual users marking your mail as junk is invisible to you. Nor does a DMARC policy improve your own deliverability: p=reject tells receivers what to do with mail that fails for your domain, which protects your customers from being fooled, not you from being filtered. Those are different problems that get sold together constantly.

A triage order that saves time

1. Get headers from a message that failed, and read Authentication-Results.
2. If DMARC failed on alignment, fix the sending platform's authentication. That is the whole job, and no copywriting will help until it is done.
3. If SPF failed, check for a second SPF record, the ten-lookup limit, and the sender's authorisation.
4. If everything passed, look at reputation, blocklists and reverse DNS.
5. Only then look at content: link shorteners, image-only messages, mismatched link and sender domains, and attachments that receivers dislike.

The first three steps are DNS and configuration work, which is also the part an external assessment can see. The explainer on the three records covers the mechanics, and the control catalog lists the five email controls this project evaluates — SPF strength, SPF validity, DMARC enforcement, DKIM presence and MX posture.

What SMB Scanner Lite checks here

These are the controls from this area that the assessment evaluates from outside, without credentials and without touching anything private. Each one returns a status and, for every conclusive result, the record, header or handshake that produced it.

Only assess domains you own or are authorised to test — see responsible use. The published recorded assessment shows how a result and its evidence appear in a report, and the control catalog lists all 22 controls with their weights. Reference detail for this topic lives in SPF, DKIM and DMARC: how email authentication actually works.