Why your business emails land in spam: SPF, DKIM and DMARC

Your invoice is not competing with spam for attention: it is competing for trust, and the records in your domain decide who believes the sender.

The invoice went out at the start of the month the way it has for a year, and this time it landed in the client's spam folder, so the quarter's cash flow quietly bent around it. Nothing about the sender changed. No scam, no blacklist drama, no complaint. This is the most ordinary deliverability failure there is, and it happens to legitimate companies constantly, which is why it deserves an explanation rather than a shrug.

Receiving mail servers cannot read intentions. They see a domain claiming to send mail, and they ask a narrow question: who is authorized to speak for this domain, and can the claim be verified? The answer lives in the domain's records. SPF lists the senders allowed to send on the domain's behalf. DKIM attaches a cryptographic signature proving the message was not altered and truly came from where it says. DMARC tells the receiver what to do when those two fail, and reports back to the domain owner what is being sent in its name.

The chain breaks in ordinary ways. A new tool starts mailing on the company's behalf, a billing system, a helpdesk, a recruiting platform, and nobody tells the domain's records about it, so its mail arrives unsigned and unauthorized. A bought list goes out once and poisons the domain's reputation with every dead address it bounces against. Bounces pile up unhandled, and the receivers draw the obvious conclusion: whoever sends this mail is not watching it.

What makes the failure cruel is that it is invisible from inside. Your sent folder looks perfect, while the messages are delivered into a folder nobody opens, answered by nobody, until a client mentions the invoice you never knew arrived. The fix, meanwhile, is unglamorous and mostly configuration: one aligned, verified sending path per domain, every tool that sends in the domain's name declared and signed, bounces processed instead of ignored.

You do not need to become a mail engineer; you need to ask whoever runs your email a short list of questions. Which tools send as us today, and are all of them authorized and aligned? Who reads the DMARC reports, and what did they say last month? What happens to a bounce? If the answers are vague, the invoices are still at risk, however carefully the invoices themselves are written.

We configure this chain for every domain we set up, for our own entities and for clients, because a company whose mail cannot be trusted has a problem no design can repair. Deliverability is not a feature you add when it breaks; it is part of owning a domain, the way locking the door is part of owning an office.