How to stop criminals sending email as your business: SPF, DKIM and DMARC

Why does this matter for a Kenyan business?

The attack is not sophisticated. Someone sends an email that appears to come from your address — to a guest confirming a booking, to a supplier chasing an invoice, to your own accounts clerk — and changes the bank or till details. The money moves once and does not come back. It costs the attacker nothing, needs no access to your systems, and works precisely because the recipient trusts the name in the From line.

Kenya's national computer incident response team, KE-CIRT, detected 4.56 billion cyber threat events in the fourth quarter of 2025 — a 441% rise on the previous quarter — and 3.37 billion in the first quarter of 2026. Serianu puts Kenyan cybercrime losses at roughly USD 230 million, about KES 29.9 billion, across 2024 and 2025.

What makes this the first thing to fix is not the threat number, though. It is the economics: the fix is three DNS records, it costs nothing but attention, and nothing has to be installed on a single machine. There is no other control in security with that ratio.

What is SPF, and what does a good one look like?

SPF — Sender Policy Framework, RFC 7208 — is a single TXT record at your domain listing which servers are allowed to send mail for it. A receiving server looks up the record and checks whether the machine connecting to it appears in the list.

The three rules that break SPF in practice

1. Exactly one SPF record. Two TXT records beginning v=spf1 is a permanent error, and a permanent error is not a fail — many receivers simply stop evaluating. If you add a provider, merge its include: into the record you already have.
2. Ten DNS lookups, maximum. Each include:, a, mx, exists, ptr and redirect= costs a lookup, and so does everything they in turn include. Exceed ten and the result is again a permanent error. Four include: terms can quietly be eleven lookups.
3. SPF does not authenticate what the recipient sees. This is the one that matters. SPF checks the envelope sender — the address used in the SMTP conversation, recorded as Return-Path — not the From: header shown in the mail client. An attacker can pass SPF perfectly for a domain they own while writing your domain in the From line.

SPF also breaks on forwarding: when a message is forwarded, the forwarding server's address is not in your list, so SPF fails through no fault of yours. That is not a reason to skip it. It is the reason DKIM exists.

What is DKIM?

DKIM — DomainKeys Identified Mail, RFC 6376 — has your sending server cryptographically sign each message. The signature covers the message body and a chosen set of headers, and travels with the message in a DKIM-Signature header. You publish the matching public key in DNS; a receiving server reads the d= (domain) and s= (selector) tags from the signature, looks up the key and checks it.

Because the signature is carried inside the message, DKIM survives forwarding as long as the message is not modified in transit. That makes it the more robust of the two, and it is why a domain with both SPF and DKIM ends up with far fewer false failures than one with SPF alone.

Turn it on everywhere that sends mail as you, not just at your mailbox provider. The booking engine that sends confirmations, the accounting package that sends invoices and the newsletter tool all offer DKIM, usually as a checkbox and a DNS record. Every sender you miss becomes a failure you will have to explain to yourself later, in a report.

What is DMARC, and why is it the one that works?

DMARC — RFC 7489 — does three things none of the others do. It ties SPF and DKIM results to the From: domain the recipient actually sees, through a rule called alignment. It tells receiving servers what to do when that check fails. And it asks them to send you reports about mail claiming to be from you.

A message passes DMARC if either SPF passes and the envelope domain aligns with the From domain, or DKIM passes and the signing domain aligns with the From domain. One is enough. Relaxed alignment, the default, accepts a match on the organisational domain; strict alignment requires an exact match.

How do I read a DMARC report?

Aggregate reports arrive as compressed XML attachments, usually once a day, from each participating receiver — Google, Microsoft, Yahoo and others. Each one lists the source IP addresses that sent mail claiming to be from your domain, how many messages each sent, and the SPF and DKIM results with their alignment.

You are looking for three groups.

Sources you recognise, passing

Your mailbox provider, mostly. Nothing to do.

Sources you recognise, failing

The interesting group, and usually the largest at first: the booking engine, the invoicing tool, the mail-merge plugin somebody in sales installed. Fix each by enabling DKIM at that provider, or by adding it to SPF — then check the next report to confirm it now passes in alignment. This is the whole job.

Sources you do not recognise

Some are forwarders — a guest forwarding a confirmation to a colleague — which fail SPF harmlessly and are the reason to have DKIM. The rest is mail sent as you by people who are not you. That is the volume your policy will eventually stop.

Send rua to a mailbox a person opens, or to a report-processing service that renders the XML into something readable. One caution: if you send reports to an address at a domain you do not control, that domain must publish an authorisation record for yours — a TXT record at yourdomain._report._dmarc.theirdomain containing v=DMARC1. Report processors document this; if reports never arrive, it is the first thing to check.

The staged rollout, week by week

Publishing p=reject on day one is the classic way to break your own invoicing and spend an afternoon explaining it. Go in stages, and let the reports tell you when to move.

Once you are at reject and stable, MTA-STS (RFC 8461) and TLS reporting are the sensible next records — they protect mail arriving at your domain rather than mail leaving it. They are a genuine improvement and a much smaller one than what you have just done.

The mistakes we see most

1. Two SPF records. Almost always because a new provider's setup guide said "add this TXT record" and nobody merged it. The result is a permanent error, and a permanent error protects nobody.
2. More than ten DNS lookups. Silent, and invisible unless you count. Trim providers you no longer use — the marketing tool from three years ago is still in there.
3. +all, or a stray ?all. This authorises the whole internet to send as you. It is usually a copy-paste from a troubleshooting thread that was never reverted.
4. DMARC published, reports going nowhere. p=none with no rua, or a rua pointing at a mailbox nobody has opened since it was created. You have the record and none of the value.
5. Staying at p=none forever. This is the big one. A domain at p=none is measured, not protected, and a great many businesses stop here believing they are done. Nothing changes for an attacker until the policy is quarantine or reject.
6. A weaker DMARC record on a subdomain. Subdomains inherit the apex policy unless a record of their own says otherwise, so publishing p=none at booking.yourdomain while the apex is at reject reopens exactly the door you closed.

What about a domain that sends no email?

Old trading names, campaign domains, the misspelling you bought defensively — these are attractive precisely because nobody watches them. Three records, ten minutes, and they can no longer be used to send anything.

How do I check what I have today?

Four commands. They read public DNS records, which is the same thing every mail server on the internet does to find you, and they touch nobody's servers.

If reading DNS output is not your idea of an afternoon, our free snapshot reads exactly these records for you and returns a plain-language report on what they say. It is free, a person writes it, and it arrives in one to two business days. We read public records — DNS, mail records, certificate transparency logs and the domain registry. We never connect to your website or servers, never log in, and never test your defences. This is not a penetration test.

Who should do this work?

Whoever controls your DNS: your hosting provider, your domain registrar's control panel, or your IT provider. If you have a competent IT provider, send them this page. Most of what is described here is under an hour of actual change for someone who does it regularly, plus a few weeks of reading reports — and many providers simply have not been asked to look.

If you would rather it were done for you, Reconesys sells this as a fixed-price piece of work — the Email and Domain Shield sprint, USD 199, about KES 25,700 — where we make the records correct, clean up stray DNS entries, and re-check afterwards to show it worked. Prices are in US dollars with the shilling equivalent at about 129 shillings to the dollar; you are billed in shillings.

Start with the free snapshot either way, because it tells you where you actually stand before anyone spends money. See a worked sample report, what the free snapshot covers, or what the fix sprints cost.

One caveat we would rather state than have you assume: fixing your mail records stops other people sending as you. It does not protect a mailbox that has been broken into, it is not monitoring, and it does not make your business compliant with the Data Protection Act — although it is squarely the kind of measure regulation 32 of the General Regulations has in mind.