Why Legitimate Business Emails End Up in Spam, and How to Tell Why

Spam filters judge evidence, not intentions

Your message is perfectly legitimate and the recipient's mail provider has no way of knowing that. Internet email was designed so that the sender is not verified by default, so anyone can put any From address on a message. Everything else is the provider weighing evidence: can this sender prove a link to the domain it claims, what has mail from this domain and these servers done before, and how do recipients react to it.

Microsoft describes its inbound checks as going beyond SPF, DKIM and DMARC to use sender reputation, sender history, recipient history and behavioural analysis. Google's Postmaster Tools reports on authentication, domain and IP reputation and the rate at which recipients mark mail as spam. None of the large providers publishes how those signals are weighted, so anyone offering a precise formula for staying out of junk is guessing.

One distinction is worth making early. A message in the junk folder was accepted and then judged. A message that bounces was refused outright. Google says unauthenticated mail might be marked as spam or rejected with a 5.7.26 error, and Microsoft's consumer Outlook service has used a 550 5.7.515 rejection for high-volume senders that miss its authentication requirements. The root cause is often the same, just with a harsher outcome.

The usual culprit: the mail does not prove it belongs to you

Three checks do most of the work. SPF publishes a list of servers allowed to send mail for a domain. DKIM adds a cryptographic signature that proves the message was signed by a domain and not altered in transit. DMARC then asks that at least one of those checks passes and that the domain it passed for matches the domain in the From address. That match is called alignment.

Alignment is where legitimate mail usually trips. Many services send using their own domain behind the scenes. The envelope sender (the technical return address used between mail servers, which recipients never see) belongs to the service, and the DKIM signature uses the service's domain too. SPF and DKIM both pass, yet neither is for your domain, so DMARC fails. Microsoft lists this as a leading alignment failure: a non-Microsoft service sends on your behalf, SPF passes for the service's domain, and DMARC fails because nothing is signed or sent as you. A message can pass every individual check and still fail DMARC, rather like presenting a perfectly valid passport that belongs to someone else.

Forwarding is the other classic. When a server forwards a message it changes the sending server, which breaks SPF. DKIM can survive forwarding if the body is not modified, which is why having it in place matters. Mailing lists and services that alter messages in transit can break both.

SPF records that fail without anyone noticing

SPF is the easiest of the three to break quietly, because every new tool tends to add another entry to the same record. A receiving server will only follow so many DNS lookups while evaluating it. The standard (RFC 7208) caps these at 10, and going over produces a permanent error rather than a pass. Microsoft documents the same limit and notes that a record with fewer than 10 include entries can still exceed it, because each include can point to further includes.

A few other slips produce the same result. A domain must publish only one SPF record, and multiple records cause a permanent error. Each subdomain needs its own SPF record, since subdomains do not inherit the parent's. Microsoft also lists simple syntax errors that invalidate a record, such as a trailing full stop after a domain name, an equals sign instead of a colon after include, or a space after the colon.

Microsoft's advice for services outside your direct control, such as bulk mailers, is to send from a subdomain. It protects the reputation of your main domain from what those services do and gives each sender its own lookup allowance. Where you must reduce lookups, Microsoft says to replace an include with fixed IP addresses only if the vendor has a stable, documented set, and not to flatten Microsoft 365's own include, because its sending addresses change frequently.

What the big providers now expect

Mailbox providers have tightened their rules in the last few years, and the basic rules reach smaller senders than many people assume. The details below come from each provider's own documentation, and they do change, so check the current pages before relying on a number.

• Google (sending to personal Gmail accounts): since February 2024 all senders need SPF or DKIM, valid forward and reverse DNS, TLS and a user-reported spam rate below 0.3% in Postmaster Tools, and Google advises aiming for below 0.10%. Senders of around 5,000 or more messages a day to Gmail accounts must additionally have both SPF and DKIM, a DMARC record (a policy of none is acceptable) with the From domain aligned to SPF or DKIM, and one-click unsubscribe for marketing and subscribed mail.
• Google counts messages from the same primary domain together, so subdomain volume adds to the parent's total, and Google says bulk sender status does not expire if your volume later falls.
• Yahoo: all senders need SPF or DKIM, valid forward and reverse DNS and complaints below 0.3%, which Yahoo calculates from mail delivered to the inbox, so your own figures may differ. Bulk senders need both SPF and DKIM, a DMARC policy of at least none that passes, and an unsubscribe mechanism honoured within two days.
• Microsoft (consumer Outlook.com, Hotmail and Live addresses): requirements for SPF, DKIM and DMARC were announced for domains sending more than 5,000 messages a day. Independent reporting of Microsoft's May 2025 update says non-compliant messages are rejected rather than sent to Junk. We could not read Microsoft's announcement text directly, so treat that detail as provisional.

When authentication is clean and mail still goes to junk

If SPF, DKIM and DMARC all pass and aligned, the question moves to reputation, which comes down mostly to what recipients do with your mail. Complaint rates are the number providers publish. Google's guidance for senders is to mail only people who want it, confirm they opted in, check periodically that subscribers still want your messages, consider removing people who never open them and make unsubscribing simple.

That guidance is aimed at newsletters and marketing, but the principle covers ordinary business mail too: a cold list, a stale customer database or an old mailing that people keep reporting damages the domain's standing for everything else sent from it. That is another good reason to keep marketing on its own subdomain.

One more thing worth ruling out, in our judgement, if the problem began suddenly: a compromised mailbox or a rogue sending application using your domain. That is a security incident, not a deliverability tweak, and your DMARC aggregate reports (covered below) are one place it shows up.

Find out which problem you actually have

This is read-only. It needs a message that reached someone's junk folder and, for the DNS checks, any Windows PC with PowerShell. Nothing here changes mail or DNS. Replace YOUR_DOMAIN with the domain in the From address.

1. Ask the recipient for the full message headers of a message that landed in spam. Most mail programs have a view-source or show-original style option, though the label varies by program, so we have not named a specific menu.
2. In the headers, find the Authentication-Results line. Note whether spf, dkim and dmarc say pass or fail. Microsoft's format also shows the domain each check used: smtp.mailfrom for SPF, header.d for DKIM and header.from for the From address. Other providers word it differently, but the three domains are what matter.
3. Compare the domains. If SPF and DKIM pass but both belong to a service's domain instead of yours, you have an alignment problem, and DMARC will fail. If everything passes and aligns, skip to the reputation section above.
4. Check your published SPF record. This reads public DNS only. You should see exactly one string beginning with v=spf1. Two means a permanent error for every receiver.
   powershellCopy

   Resolve-DnsName -Name YOUR_DOMAIN -Type TXT | Select-Object -ExpandProperty Strings

5. Check your DMARC record. No result means you have not published one, which Google and Yahoo require of bulk senders.
   powershellCopy

   Resolve-DnsName -Name "_dmarc.YOUR_DOMAIN" -Type TXT | Select-Object -ExpandProperty Strings

6. Count the lookups in the SPF record: each include, a, mx, exists and redirect costs at least one, and the RFC also counts ptr. Then check each included record for further includes. If the total is near or above 10, you have found a likely cause. A positive result for any step in this sequence gives you a specific thing to fix; a clean result across all of it points towards reputation.

What to change, in what order

Work from the cheapest, most reversible fix. Most of these are DNS or sending-service settings, so they should be made by whoever manages your domain, and a mistake in a DNS record can affect all of your outbound mail, not just the problem sender.

Where the finding was misalignment for a particular service, the fix lives in that service's settings: have it sign with a DKIM key for your domain or send with your domain in the envelope sender. Its own documentation will give the exact records. If SPF is over its lookup limit, move third-party senders to subdomains first, and consolidate tools before replacing includes with fixed IP addresses.

If you have no DMARC record, publish one with a policy of none and an address for aggregate reports. That changes nothing about delivery on its own, and the daily reports show every system sending as your domain, including ones you forgot. Move to quarantine or reject only once those reports show your legitimate senders aligned. Microsoft recommends doing this gradually, starting with lower-volume domains and using the pct tag, because a stricter policy applied too early gets good mail rejected. Note that none only monitors. It tells receivers to take no action against mail that fails DMARC, so it does not protect against someone spoofing you.

Allow lists on the recipient side are a workaround, not a fix. If you are the recipient's administrator in Microsoft 365, Microsoft's advice is to use a scoped allow entry or authenticated relay rather than allowing an entire sending domain.

What is still uncertain

Provider filtering is not published, so a fully authenticated sender with decent complaint rates can still land in junk occasionally, and we cannot tell you why for a specific message. Thresholds and enforcement behaviour have also moved in recent years, particularly at Microsoft, so confirm the current provider pages before you plan around any figure here. We have not tested the commands above against a live domain, so run them as read-only checks and compare the output with your own records.