SPF, DKIM, and DMARC: stop attackers spoofing your business email

Here is an uncomfortable fact about email. Without a few specific settings in place, almost anyone can send a message that appears to come from your company's address, and it will land in your customers' inboxes looking entirely genuine. That is how a lot of invoice fraud and impersonation starts: not by breaking into your mailbox, but by forging your name on the envelope. Three DNS records, SPF, DKIM, and DMARC, are what stop this. They are not new, they cost nothing to set up, and most small businesses still have them missing or half-finished. Through 2025 the large mailbox providers also began enforcing them, which has turned a good idea into a practical necessity.

How Email Spoofing Works

Email was designed in a more trusting era, and the From address on a message is about as reliable as the return address handwritten on a paper envelope. Anyone can write whatever they like there. Nothing in the basic design of email checks whether the server sending a message claiming to be from your-firm.co.il has any right to do so. That is the hole. SPF, DKIM, and DMARC are three layers added on top to close it, each answering a slightly different question about whether a message is really from who it claims to be. Used together, they make forging your domain far harder than scribbling a name on an envelope.

SPF: Who Is Allowed to Send

SPF, the Sender Policy Framework, is a public list of the servers allowed to send email for your domain. You publish it as a DNS record, and it names your legitimate sources: Microsoft 365, the accounting system that emails invoices, the marketing tool, and so on. When a receiving mail server gets a message claiming to be from you, it checks whether the server it actually came from is on that list. If a stranger's server tries to send as you, it is not on the list, and the check fails. The catch is that SPF on its own is easy to sidestep in certain cases, which is why it is the first layer and not the whole answer.

DKIM: A Tamper-Proof Signature

DKIM, DomainKeys Identified Mail, adds a cryptographic signature to every message your systems send. Think of it as a wax seal that proves two things: the message genuinely came from your domain, and nobody altered it along the way. The receiving server checks the signature against a public key you publish in DNS. If it matches, the message is authentic and untouched. If someone forges a message or changes its content in transit, the seal breaks and the check fails. DKIM is harder to fake than SPF, and together the two cover far more ground than either does alone, which is the point of layering them.

DMARC: The Policy That Ties It Together

SPF and DKIM each run a check, but on their own they do not tell a receiving server what to do when a message fails. That is DMARC's job. DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, is the instruction you publish saying how strictly to treat mail that fails the other two. It has three settings. A policy of none means watch and report but deliver anyway. Quarantine means send failures to the junk folder. Reject means refuse them outright. DMARC also sends you reports on who is sending mail as your domain, which is how you find out what is genuinely going on behind the scenes.

Why a Policy of None Is Only a Starting Line

A great many businesses set up DMARC, choose the none policy, and stop there. That is understandable, because none is safe: nothing gets blocked, so nothing breaks. But it also means you are still not protected. A forged message that fails the checks is still delivered, just with a note in a report you may never read. The point of the none policy is to be a temporary observation phase, where you watch the reports, confirm your legitimate mail all passes, and then tighten to quarantine and finally reject. A DMARC record left on none for two years is monitoring an open door, not closing it.

The 2025 Change That Made This Urgent

For a long time these records were optional in practice, and you could ignore them without obvious consequences. That has changed. Through 2025 Microsoft began enforcing SPF, DKIM, and DMARC for domains sending large volumes of mail to Outlook and Hotmail addresses, following Google and Yahoo, who introduced similar rules a year earlier. High-volume senders without valid records now risk their mail being filtered to junk or refused outright. Even if your business sends nowhere near those volumes, the direction is clear: properly authenticated email increasingly reaches the inbox, and unauthenticated email increasingly does not. Getting this right is now about your own messages arriving as much as about stopping forgeries.

What This Protects, and What It Does Not

It is worth being honest about the limits. SPF, DKIM, and DMARC stop someone forging your exact domain, your-firm.co.il. They close a real and common attack, and that is valuable. What they do not do is stop everything. They cannot block a lookalike domain, where your-firm.co.il becomes your-firm-il.co.il and a busy eye reads them as the same. They do not protect your inbound mail from phishing sent to you. And they do nothing if an attacker logs into your actual mailbox with a stolen password, which is why MFA still matters just as much. Treat email authentication as one strong layer, not the entire defence.

Reading the Reports

The reporting side of DMARC is the part most people skip, and it is genuinely useful. Once you turn it on, you start receiving regular summaries of every server sending mail that claims to be your domain. The first time you read one, it is usually a surprise. You discover the marketing platform nobody told IT about, the old invoicing system still sending from a server that was never added to your SPF record, and sometimes the genuinely malicious sender forging your name. Those reports are how you build an accurate SPF record, and how you reach the point where you can safely switch on enforcement without accidentally blocking your own legitimate mail.

Doing It on Microsoft 365

If you run Microsoft 365, you already have most of what you need. Microsoft publishes SPF guidance for your domain, can sign your outbound mail with DKIM once you enable it for your custom domain, and DMARC is a single DNS record you add yourself. The common mistakes are predictable: leaving DKIM switched off because it is not enabled by default for custom domains, forgetting to add a third-party sender such as your CRM or accounting tool to the SPF record, and never publishing DMARC at all. None of these is hard to fix. They are simply tasks that need doing deliberately rather than assumed to be handled by the platform.

Rolling It Out Without Breaking Email

The mistake to avoid is rushing straight to a reject policy and discovering that half your legitimate mail, the invoicing system, the booking tool, the newsletter, was never properly authenticated and is now being bounced. The safe path is staged. First, list every system that sends mail as your domain. Publish an accurate SPF record covering all of them and enable DKIM. Then turn on DMARC with a none policy and read the reports for a few weeks, until you are confident every real sender passes. Only then move to quarantine, and finally to reject. Done this way, the protection ratchets up step by step and no genuine message is ever lost in the process.

Getting your email authentication right

SPF, DKIM, and DMARC are not complicated, but they are easy to get subtly wrong, and a half-configured setup gives you a false sense of safety while still letting forgeries through. NetFortress sets up and manages email authentication for Israeli SMBs, almost always on Microsoft 365, taking domains safely from no protection to full enforcement without disrupting legitimate mail. If you are not sure whether your domain can be spoofed today, ask us for a review and we will check your records and tell you exactly where you stand.