Why your business email lands in spam
You sent the quote and they never saw it. Deliverability is not luck — it is three DNS records, and the reasons they fail are always the same handful.
You sent the quote on Sunday. On Wednesday the client says they never received it. You resend it, they find it in spam, and everyone agrees email is unreliable and moves the conversation to WhatsApp.
Email is not unreliable. What happened is that a receiving server could not confirm the message genuinely came from your company, so it filed it where unverified mail goes. That verification is three DNS records and a handful of habits, and once they are right the problem does not come back.
Filters judge identity first, content second
The instinct is to blame the wording — too many links, the word "offer", an attachment. Content matters at the margin, but the first question a receiving server asks is far more basic: is this sender really who it claims to be?
Anyone in the world can put your address in the "From" field. Nothing in the email protocol prevents it. So receivers check three things you publish in DNS to decide whether to believe the header. Publish none of them and every message you send is a claim with no evidence behind it — which is exactly what a spammer's message looks like.
SPF — who is allowed to send as you
SPF is a public list of the servers permitted to send mail for your domain. The receiver compares the connecting server against your list.
Where it goes wrong, in order of how often we see it:
- Two SPF records. The most common fatal error. A domain may publish exactly one; two records is not "more permissive", it is invalid, and the check fails outright. This usually happens when a second provider is added and pastes in its own record instead of merging.
- A sender nobody remembered. Mail leaves your company from more places than you think — the mail host, the website's contact form, the invoicing system, the newsletter tool, the CRM. Every one of them needs to be in the record or its mail is unauthenticated.
- Too many lookups. SPF allows ten DNS lookups; chained
include:statements blow past that quietly, and everything after the limit fails. - Ending in
?allor nothing. A record that authorises everyone tells the receiver nothing. Use~allwhile testing and-allonce you are sure the list is complete.
DKIM — the signature that survives forwarding
DKIM signs each message with a private key held by your mail server; the matching public key sits in DNS. The receiver verifies the signature and knows the message was not forged or altered in transit.
It matters more than SPF in one specific case: forwarding. When a message is forwarded, the connecting server is no longer yours and SPF breaks, but a DKIM signature still checks out. Given how often mail is forwarded to a personal address in practice, an unsigned domain loses deliverability in exactly the situations that matter.
Each sending system gets its own key and its own selector. Adding a newsletter tool means adding its DKIM record too — not reusing the mail server's.
DMARC — the instruction, and the report
DMARC tells receivers what to do when SPF and DKIM fail, and — the underrated half — asks them to send you reports about mail claiming to be from your domain.
Roll it out in three stages, never in one:
p=nonewith a reporting address. Changes nothing about delivery; starts the reports flowing. Leave it for a few weeks and read them: they will show you the sending systems you had forgotten.p=quarantine. Failures go to spam rather than the inbox. Watch for anything legitimate landing there.p=reject. Forged mail is refused at the door. Only get here once the reports are clean — otherwise you are the one being blocked.
Publishing p=reject on day one, before the sender list is complete, is the fastest way to stop your own invoices from arriving.
The failures that are not DNS
- A brand-new domain sending in volume on day one. New domains have no reputation. Start with normal correspondence and build up; do not launch a thousand-recipient campaign from a domain registered last week.
- One message to a large list, sent from the business mailbox. Bulk mail belongs on a system built for it, with an unsubscribe link. Sending it from your day-to-day mailbox risks the reputation of every message you send.
- A list you bought. Nothing damages a domain faster than complaints from people who never asked to hear from you.
- Free-mail identity mismatch. Sending as
you@gmail.comwhile claiming to be your company creates exactly the mismatch filters look for — one of several reasons a business address on your own domain is worth the small monthly cost.
Symptom to cause
| What you are seeing | Where to look first |
|---|---|
| Some recipients get it, others never do | SPF incomplete, or missing DKIM on one sending system |
| Fine everywhere except one large provider | DMARC alignment, or that provider weighting reputation harder |
| Worked for years, broke recently | A second SPF record added by a new tool, or a provider change |
| Only forwarded mail disappears | No DKIM — SPF alone cannot survive a forward |
| Everything to spam, suddenly, all recipients | Domain or server IP reputation; check whether you are on a blocklist |
| Only campaign mail affected | Bulk sending from a mailbox not meant for it |
Test it properly
Do not judge deliverability by whether one message reached one colleague's inbox. Send a message to an address on a provider you do not control, open the received message's full headers, and look for three words: spf=pass, dkim=pass, dmarc=pass. Anything else is your answer.
Then check the same for every system that sends on your behalf — the website form, the invoicing system, the newsletter. Each one is a separate test, because each one is a separate sender.
The checklist
- Exactly one SPF record, listing every system that sends as you
- DKIM signing enabled, with its own key per sending system
- DMARC published, starting at
p=nonewith reports going somewhere a human reads - Reverse DNS set on the sending server
- Bulk mail sent from a bulk platform, with unsubscribe
- Headers of a real test message showing three passes
- A calendar reminder to re-check after adding any new tool that sends email
Or let it be someone else's job
All of this is standard, and all of it is fiddly enough that it is usually configured once and then quietly broken by the next tool someone signs up for. Business email on your own domain from us ships with SPF, DKIM and DMARC configured, reverse DNS set, and the migration from your current provider handled — including the part where we check the records afterwards rather than assuming.
The test of a mail setup is not that it sends. It is that a stranger's server believes it.