Your Emails Keep Landing in Everyone's Spam Folder? Here's Why — and How to Fix It

You send an invoice and the customer swears it never arrived. You find out later it was in their junk folder the whole time. Or your appointment reminders stopped landing, or a quote you sent a new client went straight to spam while the same email to your own address looks perfect. For a small business this is a genuinely expensive problem — it doesn't look like a computer fault, it looks like you never followed up.

This is the send-side problem, and it's worth being clear that it's the mirror image of the more familiar one. If mail is not arriving in *your* inbox, that's a different guide. This one is about mail you send landing in other people's spam. The good news is that the causes are a short list, they're diagnosable rather than mysterious, and the fix for most small businesses is a handful of settings done once — not a monthly subscription to something.

First, work out which of the three problems you actually have

These all get described as "my emails go to spam," but they have completely different causes, so spend a minute placing yours before you change anything. One: it happens to everyone, on every message, all the time. Two: it only happens with one company or one recipient — your mail reaches most people fine, but everything you send to one client's office disappears. Three: it started suddenly, on a date you can roughly name, after years of working.

Problem one is almost always authentication or your From: address — the technical sections below. Problem two is usually that one recipient's mail filter, not you, and the fix is on their end. Problem three is the most informative of the three: something changed. A new website, a new booking or invoicing app, a switch of email provider, a domain renewal, or somebody edited your DNS records. Work out what changed that week and you've usually found it.

The rule almost nobody told small businesses about

Here's the thing that catches people out. Most business owners assume spam filtering is a vague judgement call about your wording — that if you avoid the word "free" you'll be fine. That hasn't been true for a while. As of February 1, 2024, Google publishes actual, specific requirements that apply to every sender emailing personal Gmail accounts, at any volume. Not just marketers. Everyone.

For all senders, Google requires that you set up SPF or DKIM authentication for your sending domain; that your sending domain or IP has valid forward and reverse DNS records, with the sending IP matching the IP of the hostname in the PTR record; that mail is transmitted over a TLS connection; that messages are formatted according to the standard for internet messages (RFC 5322); that you don't impersonate Gmail From: headers; and that your spam rate as reported in Google's Postmaster Tools stays below 0.3%.

Two of those are worth translating. Almost all of the DNS and TLS items are your email provider's job, and if you use Google Workspace, Microsoft 365, or a competent host, they're already handled — which is exactly why "just use a real email provider" is such good advice. The spam-rate one is yours, though, and Google's own list of top sender issues is blunter than the headline number: it warns that a spam rate above 0.1% can already increase spam classification. The published ceiling is 0.3%; the number where you start feeling it is lower.

The 5,000-a-day line — and the trap hidden in it

Above a certain volume the requirements get stricter. Google defines a bulk sender as anyone sending close to 5,000 messages or more to personal Gmail accounts within a 24-hour period, counted across the same primary domain. Bulk senders must additionally publish a DMARC record for their sending domain, make sure the domain in the From: header aligns with either the SPF domain or the DKIM domain, and support one-click unsubscribe with a clearly visible unsubscribe link on marketing and subscribed messages.

Most small businesses read "5,000 a day" and stop reading, which is a mistake, because of a detail buried in Google's FAQ: senders who meet that criteria at least once are permanently considered bulk senders, and bulk sender status doesn't have an expiration date. One newsletter blast, one announcement to a customer list you'd built up over ten years, one enthusiastic morning with a mail-merge — and the stricter rules apply to you from then on. If you've ever done a big send, assume you're in this category.

Microsoft did the same thing on its side. Since May 5, 2025, domains sending 5,000 or more messages to Microsoft's consumer mail services — Outlook.com, Hotmail, Live.com and MSN — must pass both SPF and DKIM, publish a DMARC record (a minimum policy of `v=DMARC1; p=none` is enough), and have at least one of SPF or DKIM aligned with the From: domain. Mail that doesn't is refused outright with a bounce reading "550 5.7.515 Access denied, sending domain does not meet the required authentication level." That one is useful precisely because it's so specific — if you've seen that string in a bounce message, you now know exactly what to fix.

And note what non-compliance means generally. Google's guidance is that messages failing the requirements experience disruptions including temporary and permanent rejections, as well as delivery to spam. So the same underlying fault can show up as junk-foldering for one recipient and a hard bounce for another, which is why the symptoms often look inconsistent.

The most common small-business cause: your From: address isn't telling the truth

If you only check one thing, check this one. A huge share of small-business deliverability problems come down to a system sending mail *as* an address it has no right to send as — and modern filters treat that as exactly what it looks like.

Google names the worst version of it directly: Gmail From: header impersonation is when a message carries an @gmail address in the From: header but wasn't actually sent from a Gmail server, and Google calls it a common form of email abuse by spammers. So if your website contact form, quoting tool, booking system, CRM or invoicing app is configured to send from yourbusiness@gmail.com, you have built something that is technically indistinguishable from spoofing — and it will be filtered like it.

The same trap has a subtler form that catches well-meaning web developers. Plenty of contact forms are set up to send the notification email *from the visitor's own address*, so that hitting Reply goes back to them. It feels helpful and it wrecks your authentication, because your web host is now sending mail claiming to be from a domain it isn't authorised to send for. The correct pattern is the same in every one of these apps: send from a real mailbox on your own domain that you control, and put the customer's address in the Reply-To field instead. You keep the convenient reply behaviour and lose the spoofing signature.

One related nuance, because it explains a case that otherwise looks broken: alignment isn't required for forwarded or mailing-list messages — what the standards call indirect mail. If your message goes to someone whose work address auto-forwards everything to a personal account, it can be handled differently along the way. That's a known wrinkle, not something you've misconfigured.

SPF, DKIM and DMARC in plain English

These three acronyms come up in every article on this subject and are almost never explained in a way a business owner can act on. They're all just entries you (or whoever manages your domain) publish in DNS — the same place your domain's website address lives.

SPF is a published list of the servers allowed to send email for your domain. DKIM adds a cryptographic signature to each message so the receiver can verify it genuinely came from your domain and wasn't altered on the way; Google requires a DKIM key of 1024 bits or longer for mail to personal Gmail accounts. DMARC is the instruction that ties the two together — it tells receiving servers what to do when a message claiming to be from you passes neither check, and it gives you a reporting address. A policy of `p=none` means "don't block anything, just tell me what's happening," which is why it's the recommended starting point and why both Google and Microsoft accept it as the minimum.

What to do with that: you do not need to hand-write these. Every serious email provider publishes the exact records for you to paste, and generates DKIM keys on request — it is a documented setup page in Google Workspace and Microsoft 365, not a custom engineering job. The work is in knowing every service that legitimately sends as your domain (your mail provider, your newsletter tool, your invoicing software, your website) and making sure all of them are covered, because an SPF record that lists your mail provider but not your invoicing app will quietly fail exactly the invoices you most want delivered.

The causes that aren't technical at all

Authentication gets all the attention, but Google's own published list of top sender issues is mostly about behaviour, and these are the ones that bite businesses whose DNS is already perfect.

Sending to people who didn't clearly opt in is top of the list — Google is explicit that recipients should explicitly opt into getting messages, and a list you assembled from business cards or bought from anyone is a spam-complaint generator. Ramping volume up quickly causes deferrals and throttling, so the classic "we finally emailed our whole customer list for the first time in three years" send is close to worst-case: a brand-new sending pattern, at volume, to people who don't remember you. Sporadic spikes hurt for the same reason, particularly on newer domains.

Two more worth naming. Deceptive presentation is penalised specifically — Google calls out using emoji to fake a verification badge and adding "Re:" to a message that isn't a reply, both of which some sales-outreach guides still recommend. And shared infrastructure means shared reputation: if you send through a cheap shared host or a bulk platform where other senders are behaving badly on the same IP or domain, you inherit their problem. That's one of the strongest practical arguments for sending business mail through a mainstream provider rather than whatever came free with your web hosting.

How to diagnose it properly instead of guessing

Don't start changing settings blind. There are four cheap checks that will nearly always tell you which of the three problems you have.

Read the bounce, if there is one. A rejection message contains a status code, and those codes are specific — the 550 5.7.515 above tells you authentication, full stop. Second, send a test message to an address you control at each of the big providers (a Gmail address and an Outlook.com address), then open the received copy and look at the message details. Both Gmail and Outlook let you view the original message headers, and they will plainly state whether SPF, DKIM and DMARC passed or failed. That single test separates "my authentication is broken" from "my authentication is fine and this is a reputation or content problem," which are entirely different repair jobs.

Third, if you send any real volume, set up Google's Postmaster Tools for your domain. It's free, and it shows your actual spam-complaint rate and authentication pass rates — the exact numbers the rules are written against. Google lists not using it as one of its top sender issues for a reason: without it you are guessing at a number that is being measured whether you look at it or not. Fourth, when only one recipient is affected, just ask them to check their junk folder and, if your mail is there, to mark it as not spam and add you to their contacts. If that fixes it for them, you've confirmed the problem was that one mailbox's filter and not your domain.

That last fix is worth understanding correctly, because people over-rely on it. Marking a message "not spam" teaches that one recipient's filter about you. It does nothing for the next person, and it is not a substitute for fixing authentication. It's a targeted repair for the one-recipient case, not a strategy.

Be careful what you buy to solve this

Search this problem and you will be sold to, hard. The results are dominated by email-marketing platforms and deliverability suites writing for companies that send hundreds of thousands of messages a month, and the advice is priced accordingly: ongoing DMARC monitoring subscriptions, "deliverability audits," reputation dashboards, and paid "email warm-up" services that send fake conversations back and forth to manufacture a sending history.

A business sending a few dozen invoices and quotes a week does not need any of that. For most of our clients, the entire fix is: use a real email provider on your own domain, publish the SPF and DKIM records that provider hands you, add a DMARC record set to p=none, point every app that sends on your behalf at a real mailbox instead of spoofing a Gmail address, and stop mailing people who never asked. That's a one-time job, and once it's right it stays right unless somebody changes the domain.

The other thing to be wary of is anyone who contacts *you* about it. "Your domain has failed a security check" emails, urgent messages about your DMARC record, and cold calls offering to fix your email reputation are a well-worn pretext for getting access to your DNS or your mailbox — and DNS access is a serious thing to hand over, because it controls where your mail goes. Nobody legitimate learns about your email problem before you do. If you get one of those, treat it the way you'd treat any unsolicited pop-up or call claiming your computer has a problem.

The bottom line

If your mail goes to spam for everyone, start with your From: address and your authentication — is every app that sends for you sending from a real mailbox on your own domain, and do SPF, DKIM and DMARC pass on a test message? If it started on a particular date, find what changed that week. If it's one recipient only, it's their filter, and marking it not spam fixes it.

And if you've ever done a single large send, remember that you're permanently in the stricter category at Google whether it feels like it or not. That one detail explains a lot of "we never changed anything and it just started happening" cases.

How we can help

Email deliverability sits in an awkward gap — it's not really a computer problem, so nobody at the shop looks at it, and it's not really a marketing problem either, so the marketing company points at the IT side. Meanwhile your invoices are in a junk folder. It's also one of those jobs where the diagnosis takes twenty minutes and the guessing takes six months.

We handle small-business email for companies across Southern California and the Coachella Valley: setting up Google Workspace and Microsoft 365 properly on your own domain, publishing the SPF, DKIM and DMARC records your provider needs, tracking down which website form or invoicing app is sending mail that fails authentication, and moving businesses off the free-with-hosting mailboxes that cause most of this. If your mail is landing in spam and you don't know why, we can usually tell you which of the three problems you have from a single test message.