Why Your Business Email Goes to Spam
A contractor in Kenmore sent a quote on a Tuesday morning. The customer called Friday to ask why he had never heard back. There was no bounce, no error, no red exclamation mark, and the sent folder showed the message leaving at 9:14. That is what it looks like when business email goes to spam, and the cause is almost never the wording of the quote.
The message that failed quietly
A bounce is good news. A bounce means a receiving server looked at your message, decided against it, and said so out loud. You get an error code, a reason, and a chance to fix it before you lose the customer. Filing to spam is the other outcome. The receiving server accepts the message, reports success back to your server, and then quietly decides where to put it. Nobody writes to tell you.
That silence is why these problems run for months. Quotes go out. Invoices go out. Appointment confirmations go out. The sent folder fills up and everything looks normal from your side, because from your side it is normal. The failure happens on a server you do not control, after your part of the job is finished.
Say you send 40 quotes a month and one in ten is filed as spam. That is four quotes a month nobody read, 48 in a year, and not one warning about any of them. The owner concludes the market is soft or the prices are too high. The prices were fine.
A bounce is a conversation. Filing to spam is a silence you have to go looking for.
Business email goes to spam because of records, not wording
Before a filter reads a word of your message, it asks a simpler question. Did this message come from a server that the domain in the From line says is allowed to send for it. That question is answered by three records that live in your domain's DNS, not in your email and not on your website.
SPF is a list of the servers allowed to send mail as your domain. DKIM is a signature added to each message, checked against a key published in your DNS. DMARC is your instruction about what should happen when those checks fail, plus an address where the daily reports go. All three are text records. None of them cost anything. Most small business domains have one of the three, half filled in, left over from whoever built the website.
This is why the usual advice does not work. Taking the word free out of a subject line does not rescue a message that failed authentication. Neither does adding a plain text version, or trimming the images, or writing shorter. A message that claims to come from an address it is not authorized to use is not a borderline case that good writing can save. It is, by the only definition a mail server has, a forgery.
The form on your website is lying about who sent it
Here is the most common version of this. A visitor fills out the contact form. The form emails you, and to make replying easy, whoever built it set the From address to the visitor's own address. So a message claiming to be from someone@gmail.com leaves a web server in a data center that gmail.com has never authorized to send anything.
Gmail publishes a DMARC policy. So do Yahoo and Outlook.com. Those form messages are exactly the shape of the forgery that policy exists to stop, and they are treated accordingly. Meanwhile the form appears to work, because the code runs and the page says thank you. Nothing about a successful form submission tells you the mail arrived.
The version of that form that behaves sends from an address on your own domain and puts the visitor in the Reply-To line. Same convenience, no forgery. There is a second failure hiding behind the first. A form that delivers to a mailbox sitting on the same server it sends from never leaves the building, so it looks perfectly reliable for years, and then stops arriving the week you move the mailbox to Microsoft 365 for small business and the mail has to cross the open internet for the first time.
Nothing about a successful form submission tells you the mail arrived.
Most businesses have more senders than they think
A typical shop sends mail as its own domain from six places. The mailbox people actually type in. The website form. The invoicing software. The newsletter tool. The booking or scheduling app. The copier in the back that scans to email. Six senders, one SPF record, and usually only the mailbox was ever listed in it.
Every one of those vendors showed a DNS record on its setup page. Somebody clicked past it, because the tool worked without it. It did work, for a while, on the recipients whose filters were feeling generous that month. Adding a service that sends mail on your behalf is a change to your DNS whether or not anyone treats it as one.
There is also a ceiling. SPF allows a maximum of ten DNS lookups when a receiving server evaluates it, and every vendor you include costs at least one. Stack enough tools and the record stops being merely incomplete and becomes invalid, at which point everything under it fails at once, including the senders that were working yesterday.
Adding a tool that sends mail as you is a DNS change, whether anyone treated it as one or not.
You cannot authenticate a domain you do not own
Plenty of Buffalo businesses run on a free address. yourshop@gmail.com, or a roadrunner address from a cable account that has changed hands twice. None of this article applies to those. SPF, DKIM and DMARC are published by the owner of a domain, and you do not own gmail.com. What you send is authorized under Google's rules for Google's users, and the reputation you build belongs to a pool you share with everybody else.
The step up is business email on your own domain, which is not mainly a branding decision, even though that is how it usually gets sold. It is the point at which you can make statements about your own mail that receiving servers will believe.
One trap comes with the upgrade. People buy the domain mailbox, then forward everything into their personal Gmail and reply from there, because the phone is already set up that way. Now the From line says your domain and the sending server is Google's. Unless Google is listed in your SPF and the signing is configured on that side, your reply fails the same check the contact form failed. The message that mattered most is the one that got filed.
The fix does not look like anything for a while
Records travel on their own schedule. A DNS record with a time to live of 86400 seconds is cached for a full day, so a correction made Monday morning may not be seen everywhere until Tuesday morning. Reputation moves slower than that. A domain that spent two years sending unauthenticated mail does not get its standing back in an afternoon.
DMARC is worth publishing even at p=none, which enforces nothing at all. The value is the report address. Within a week you have a list of every server on earth sending mail as your domain and whether it passed, which is usually the first honest inventory a business has ever had of its own senders. That list routinely turns up a service somebody forgot they were paying for.
Content does matter, after the records pass. Link-heavy layouts get weighed. A brand new domain gets weighed. Sending 400 messages in one burst from a mailbox that normally sends 12 a day gets weighed hard. But all of that is weighed on messages that have already proved who sent them. Working on the wording first is sanding a board you have not cut yet.
The quote the contractor sent on Tuesday was written fine. It was priced fine, it was on time, and the customer wanted the work. It failed because a line of text on a domain nobody had looked at since the site went live said, in effect, that no server was authorized to send as that business, and a filter took the domain at its word. That is the whole of it. It is fixable, and it does not get fixed by rewriting the quote.
More from the blog
- What Unlimited Hosting Really Means
- The First Hour When Your Site Goes Down
- What a Traffic Spike Actually Does
All posts are on the blog. For the step by step versions, see the domain and hosting guides.