SPF, DKIM & DMARC for SMBs: Stop Domain Spoofing (2026)

SPF, DKIM and DMARC are DNS settings that let receiving mail servers reject messages that falsely claim to come from your domain. The work is mostly adding DNS records, and for most small businesses the direct cost ranges from nothing to a few hundred dollars. Despite that, many companies leave them unset or half-configured, and only find out when a customer receives a fake invoice sent in their name.

The From field of an email is written by the sender, freely. If your domain has no protection, anyone can send mail claiming to be "@yourcompany.com". The damage happens on the recipient's side, which means it can occur even when none of your own computers are compromised.

- Fake invoices and bank-detail change notices: a customer wires money to the attacker's account
- Messages impersonating the CEO: finance staff are instructed to make an urgent payment or send data
- Bulk spam sent in your name: your domain lands on block lists, and your legitimate mail stops arriving
- Support cost: staff time spent answering "did this really come from you?" enquiries

The third item hurts the business most. Once your domain's reputation drops, quotes and purchase orders stop reaching customers too. For diagnosing mail delivery problems, see First response when company email stops arriving.

The three work as a set. SPF and DKIM provide the evidence for judging whether a message is legitimate; DMARC states what to do when that judgement fails, and sends you reports.

A common misconception is "we have SPF, so we are covered". With SPF alone, the receiving side has no clear instruction to discard forgeries. Only the full set tells recipients that fakes may be thrown away.

DMARC specifies how failing messages should be handled. Jumping straight to the strictest setting risks blocking your own legitimate mail — notifications from booking systems, marketing platforms, and so on — so raising it in stages is standard practice.

Domains left at none for years are extremely common. none is an observation setting; it stops nothing. The control is only complete once you reach reject — make sure whoever manages your DNS understands that.

Since 2024, major mailbox providers have moved toward requiring SPF, DKIM and DMARC from senders above certain volumes. If you send newsletters or booking notifications, being unconfigured now risks the mail simply not being delivered. Even low-volume senders are affected, as receiving filters tighten each year and configured domains are increasingly treated as the baseline.

- 1. List everything that sends as your domain: office mail (Microsoft 365, Google Workspace), contact-form auto-replies, marketing platforms, invoicing and booking systems, plus mail sent on your behalf by accountants or web agencies
- 2. Check the current DNS records: whether SPF, DKIM and DMARC records exist and what they say — and confirm who holds the DNS management rights (registrar, hosting company, or agency)
- 3. Prepare a mailbox for DMARC reports: use a dedicated address or a report-analysis service rather than mixing them into everyday mail

Missing something in step 1 is what breaks legitimate mail later when you tighten the policy. In practice this is the most time-consuming part. Tracking down who owns your domain and DNS accounts is also covered in Account, password and MFA management.

Allow three to four months overall. Reading the reports properly during the none phase causes far fewer incidents than rushing to reject.

Writing the records once costs almost nothing. The cost sits in inventorying senders and reviewing reports through the move from none to reject. When requesting a quote, separate "configure the records" from "support us through to reject" explicitly.

- Two SPF records: a domain may have only one SPF TXT record; add to the existing one rather than creating another
- Adding a mail platform without updating DNS: make updating SPF/DKIM part of onboarding any new sending service
- Left at none forever: reports arrive but nobody reads them — assign an owner and a review cadence
- Unknown DNS ownership: the domain sits in a departed employee's personal account or with an unreachable vendor, so nothing can be changed
- Forwarding breaks verification: auto-forwarding to another address commonly fails SPF; prioritise DKIM, which usually survives forwarding

- Do you know who manages your domain's DNS?
- Have you listed every source that sends as your domain, including third parties sending on your behalf?
- Is there exactly one SPF record, covering all of those sources?
- Is DKIM signing enabled on your main sending platforms?
- Is a DMARC record published, with a report destination decided?
- Have you assigned an owner and cadence for reading the reports?
- Is the move to quarantine and then reject scheduled?
- Does adding a new mail platform trigger a DNS review?
- Do you have a contact point for customers reporting suspicious mail in your name? (Complete IT risk guide for small businesses)

SPF, DKIM and DMARC are decided by process rather than budget. The hard parts are not the records themselves but two things: finding every source that sends as your domain, and actually raising the policy to reject instead of stopping at none. Start by confirming who controls your DNS and putting your sending sources into a single table. For the broader ordering of security work, see First steps in security for small businesses.