"Did you get my quote?" is a sentence that costs South African businesses real money. The quote went out on Tuesday. The customer never saw it. By the time anyone phones to follow up, the work has gone to someone whose email arrived. The message wasn't lost — it was sitting in a junk folder, filed there by a machine that had no way to prove your email actually came from you.

Whether your email reaches an inbox or a junk folder is not luck. It is decided by three DNS records most businesses have never heard of, and at least one of them is probably wrong on your domain right now.

Why good email gets junked

Receiving mail servers judge every message on three things: authentication (can the sender prove the mail genuinely comes from the domain it claims?), reputation (does this domain have a history of sending wanted mail?), and content (does the message itself look like spam?). Content gets all the folklore — don't write FREE in capitals, and so on — but in practice it is the least of your problems. Authentication is the gate, and it is the one factor entirely under your control.

The reason it matters so much is fraud. Email's original design lets anyone put any address in the From field, the way anyone can write any name on the back of an envelope. Spammers and phishers impersonate legitimate domains constantly, so the big mail providers now demand proof. Since 2024, Google and Yahoo have required authentication outright for anyone sending in volume: mail that fails is rejected or junked regardless of how legitimate the business behind it is.

The three records, in plain language

  • SPF is a published guest list. It is a DNS record on your domain naming the servers allowed to send email on its behalf — your mail provider, your accounting system, your newsletter tool. Mail from a server not on the list fails the check.
  • DKIM is a tamper-proof signature. Your sending service signs each message with a private key, and receivers verify it against a public key in your DNS. A valid signature proves the message came from you and was not altered in transit.
  • DMARC is the instruction sheet. It tells receiving servers what to do with mail that fails SPF and DKIM — deliver it anyway, quarantine it, or reject it — and asks them to send you reports on who is sending mail in your name.
SPF says who may post letters for you, DKIM seals each envelope so nobody can tamper with it, and DMARC tells the post office what to do with letters that arrive unsealed from strangers. Miss one and the whole story falls apart.

Where it breaks for small businesses

The classic failure is not the main mailbox. Microsoft 365 and Google Workspace largely handle their own sending, which lulls everyone into thinking the domain is fine. The failures come from everything else that sends email as you: the accounting package emailing invoices, the website's contact and order forms, the CRM sending follow-ups, the newsletter platform, the booking system. Each of these is a separate sender that needs to be added to your SPF record and given its own DKIM key.

Miss one, and that system's mail fails authentication quietly. This is why "our emails are fine, but customers say the invoices go to spam" is such a common report. The invoices are coming from a server your domain has never vouched for. It is also why the problem often starts the week after a new tool is adopted — the tool works, the mail sends, and nobody thinks about DNS at all.

The ten-minute check

Send an email from your own domain to a free checking service such as mail-tester.com, or use MXToolbox to look up your domain's SPF, DKIM and DMARC records directly. Then do the same from your invoicing system. If any check comes back red — no SPF, missing DKIM signature, no DMARC record — you have found where your "missing" quotes have been going.

Getting DMARC right without breaking things

DMARC is the record businesses fear, because a strict policy applied carelessly can junk your own legitimate mail. The safe path is gradual. Start at p=none with a reporting address: nothing changes about delivery, but the reports show you every service on the internet sending mail as your domain — including the ones you forgot about, and the ones you never authorised. Fix the legitimate senders until they all pass. Then tighten the policy to quarantine, and finally reject, at which point only authenticated mail carries your name. That last step is not just deliverability; it makes your domain dramatically harder to impersonate in invoice-fraud and phishing attempts against your own customers.

The mistakes that undo it all

Two technical traps catch most DIY attempts. A domain may only have one SPF record — a second one, often pasted in by a helpful plugin's instructions, invalidates both. And SPF allows at most ten DNS lookups; every "include" a tool asks for spends some of that budget, and going over fails the whole record silently. If your SPF record has grown by accretion over years of tools, it is worth flattening deliberately rather than appending one more include and hoping.

The organisational trap is ownership. These records live in DNS, which is often held by whoever built the website, while email problems land on whoever runs operations. Decide who owns the domain's email health, give them access, and have them re-check it whenever a new system starts sending mail.

Boring, and worth it

Email deliverability is unglamorous plumbing, which is exactly why it gets skipped and exactly why fixing it pays. An hour of DNS work is often the difference between quotes that arrive and quotes that vanish — and unlike advertising, it keeps working for free. If your business runs on quotes, invoices and confirmations, few technical fixes return more for less.