How to stop your emails going to spam

Business email lands in spam for four reasons, and nearly always for several at once: the domain is not authenticated with SPF, DKIM and DMARC; mail leaves through the shared IP of a hosting account, where the reputation is set by other people; nobody reads the bounces, so dead addresses keep getting written to; and the content has the shape of advertising even when it is a quote. That is also the order in which to fix it.

Start by reading the headers of an email of yours that already arrived, because three lines in there say what is failing. What cannot be fixed is the promise: no configuration guarantees the inbox. What you do get is to stop handing out reasons and, above all, to find out what is not arriving instead of assuming it did.

How do I know whether my emails are arriving?

Right now, you probably do not. Mail that is sent and not delivered almost never comes back as an error: the receiving server accepts it, files it under junk, and that is that. From your side it looks exactly like a perfect send.

The cheapest check takes five minutes. Ask someone outside the company, on one of the large providers, to forward you a message of yours exactly as it arrived, and open the original message. Among the headers there are three lines with the SPF, DKIM and DMARC results. A fail or a none tells you where the work is before you touch anything in DNS.

The check that actually changes things is keeping a log. If a quote goes out through a system that records whether it was delivered, bounced or rejected, you stop arguing with the client about whether you sent it.

How do you fix it, step by step?

1. Read the headers of an email of yours that arrived. Three lines with SPF, DKIM and DMARC. That is the diagnosis, and it costs five minutes.
2. List everything that sends email in your name. Server, web form, invoicing, newsletter, CRM, phone system. Whatever is missing from this list is what breaks later.
3. Publish one single SPF record with all those senders. Only one: a second record makes the existing one fail. Mind the ten DNS lookup limit.
4. Turn on DKIM in every service that sends for you. It signs the message, so it survives forwarding, which is where SPF breaks.
5. Publish DMARC as p=none with reports and read them for a month. You will discover systems sending in your name that you did not know about. Only then move to quarantine and later reject.
6. Separate automated mail and log deliveries and bounces. A sending provider with its own reputation, ideally on a subdomain, and one named person checking bounces weekly.

Step five is the one people skip out of impatience, and the only one that shows you reality. A month of DMARC reports is worth more than any audit.

What does each of the three records actually do?

They get confused constantly because all three are published in DNS and sound alike. They do different things:

The last row is the one that surprises people. You can have all three records perfect and still land in spam because you share an IP with somebody blasting out advertising.

Why do they reach some clients and not others?

Because there is no central decision. Every receiving provider scores mail with its own signals: authentication, your domain's history, how many people mark your messages as junk, whether the message resembles others that were.

When somebody tells me "this client never gets my emails", there is nearly always a specific, boring explanation. The client's server keeps its own blocklist. Or someone there once marked a message as spam and since then the whole domain goes to the junk folder. Or the mail carries an attachment of a type that server refuses.

None of those can be solved by looking from your end. They are solved with a send log that says delivered or bounced, and with the text of the bounce, which usually explains the reason quite clearly.

What about the content of the email?

It matters less than people think, but it matters. What gets penalised is not particular words but the overall shape of the message: one enormous image and four words, shortened links that hide where they go, a subject line in capitals with exclamation marks.

Two things are always worth getting right. First, that the sender is a person or a named area rather than a noreply address: nobody replies to a noreply, and that generates no good signal at all. Second, that commercial mail can be unsubscribed from in one click. Every person who marks you as spam instead of unsubscribing costs you reputation for months.

Quotes and invoices rarely fall because of content. They fall because of authentication and IP.

When is all this NOT worth doing?

• When you send twenty emails a day from a large provider. With SPF and DKIM properly set you are already where you need to be. A separate sending provider is overkill.
• When the problem is the list, not delivery. If you write to bought addresses or to contacts from six years ago, no configuration fixes that. Clean the list first.
• When nobody is going to read the bounces. A log with no owner becomes another screen nobody opens. Before building it, decide whose job it is and which day of the week they do it.
• When something else is more urgent. If quotes take three days to go out, their landing in the inbox is not your bottleneck.

What mistakes get made most often?

• Publishing two SPF records. A new tool gets added and a second TXT record is created instead of extending the existing one. The result is that both fail.
• Setting DMARC to reject on day one. Legitimate mail from the website form or the invoicing software gets thrown away, and nobody notices until a client complains.
• Sending campaigns from the main domain. A campaign that collects complaints drags down the reputation of the mail you use to talk to clients.
• Launching a subdomain with a ten thousand send. A brand new domain with no history starting at high volume is the exact profile of a spammer. Warm it up over a few weeks.
• Trusting read receipts. They depend on the recipient agreeing to send one, and the pixel fires when images load. The data lies in both directions.

Frequently asked questions

Are SPF, DKIM and DMARC enough to reach the inbox?

No. They are the entry requirement, not the guarantee: without them some providers will not even look at you, but with them mail can still go to spam if your domain has little reputation, if you send from an IP shared with others, or if the content looks like advertising. Nothing guarantees the inbox, and anyone promising you otherwise is selling smoke.

Should automated mail go out from a separate subdomain?

Yes, as soon as there is volume. If invoices, reminders and the newsletter leave through their own subdomain, a campaign that collects complaints will not drag down the reputation of the mail you use to talk to clients. The trade-off is that the subdomain starts with no reputation and has to be warmed up over a few weeks, raising volume gradually.

Why do my emails reach some clients and not others?

Because every receiving provider decides on its own, with its own signals. There is usually a pattern: mail lands fine at small domains and badly at large ones, or badly at one particular client whose server keeps its own blocklist. A delivery log is what turns that suspicion into a fact with a name and a date on it.

Are read receipts any use?

Very little, and they lie. They depend on the recipient agreeing to send one, and the tracking pixel marketing tools use only fires when images are downloaded, so it marks as read messages nobody opened and as unread others that were. To know whether an email arrived, look at the delivery log of your sending provider, not at a read receipt.