SPF, DKIM and DMARC: how to secure your company email
Without SPF, DKIM and DMARC anyone can send emails impersonating your domain. We explain these three mechanisms simply and show how to deploy them.
Imagine someone sending your customers emails from [email protected] — with a fake invoice and a new bank account number. They didn’t break into your mail; they simply impersonated your domain, because email by design allows it. The protection against this is three mechanisms: SPF, DKIM and DMARC. They sound technical, but the idea is simple and deployment is within every company’s reach. This article explains them without jargon and shows how to turn them on.
Why this is a problem at all
Email was created in an era when trust was the default — the protocol lets you put any address in the “from” field. It’s like sending a letter with any sender on the envelope. So without extra safeguards, anyone can send a message that looks like it came from you. That’s the basis of phishing, invoice fraud (BEC) and brand impersonation. SPF, DKIM and DMARC are three layers that together let recipients check whether a message really came from you.
The three mechanisms, simply explained
SPF (Sender Policy Framework) — who may send on behalf of your domain. SPF is a DNS record on your domain that says: “emails from this domain are sent only by these servers” (e.g. your mail provider’s servers). The recipient’s server checks whether the message came from an allowed address. It’s like a list of people authorised to send letters in your name.
DKIM (DomainKeys Identified Mail) — a digital signature on the message. DKIM adds a cryptographic signature to every sent message, tied to your domain. The recipient verifies that signature with a key published in your DNS. If it matches, they can be sure the message really came from you and wasn’t altered in transit. It’s like a seal on the envelope.
DMARC — what to do when verification fails (and a report). DMARC ties SPF and DKIM together: it tells recipient servers what to do with a message that fails verification — nothing (p=none, monitoring only), quarantine (p=quarantine, to spam) or reject (p=reject). On top of that, DMARC sends you reports on who is sending emails in your domain’s name — invaluable for detecting abuse. It’s an enforcement policy plus an alarm system.
How to deploy it step by step
Deployment happens in your domain’s DNS settings (at your registrar or mail provider):
-
Start with SPF. Set a TXT record pointing to the servers that legitimately send your mail (your mail provider will give a ready value, e.g. for Microsoft 365 or Google Workspace). End it with an
-allrule (hard-fail the rest) after verifying you missed nothing. -
Enable DKIM at your mail provider. In the Microsoft 365 / Google Workspace / other provider panel you turn on DKIM signing and publish the given key in DNS. It’s usually a few clicks.
-
Roll out DMARC in stages. Start with
p=noneand a reporting address (rua=) — for a few weeks observe who sends in your name and make sure legitimate mail passes. Then move top=quarantine, and ultimatelyp=reject. Staging protects against accidentally blocking your own messages. -
Check the result. Our security scanner verifies the presence of SPF, DMARC and DKIM for a domain in seconds.
A key note: SPF and DKIM alone, without DMARC in enforcement mode, don’t fully protect — only DMARC with a quarantine/reject policy really blocks impersonation. Many domains have SPF and DKIM but DMARC set to p=none, i.e. observation only — that’s not enough.
Common mistakes
- DMARC stuck at
p=noneforever. Observation alone blocks nothing. You have to move to enforcement eventually. - SPF with
+allor too broad. It opens the domain to sending via any server — worse than no SPF. - Forgotten senders. Newsletters, CRM systems, invoicing — if they send in your domain’s name, they must be included in SPF/DKIM, otherwise legitimate mail will start landing in spam after you tighten the policy. That’s why the
p=nonereporting stage is so important.
Frequently asked questions (FAQ)
Does a small company really need SPF, DKIM and DMARC? Yes. Without them, anyone can impersonate your domain and defraud your customers and partners — which hits your reputation even if you weren’t hacked. Deployment is one-off and free (beyond the configuration time), and it protects the brand and improves your emails’ deliverability.
What’s the difference between p=none and p=reject?
p=none means monitoring only — messages impersonating you still reach recipients, you just get reports. p=reject (or quarantine) actually blocks such messages. Real protection only comes with enforcement; p=none is a transitional stage for gathering data, not the goal.
Could deployment block my own mail?
It could, if you set a hard policy immediately without accounting for all legitimate senders (CRM, newsletter, invoicing). That’s why you start with p=none and reports: for a few weeks you see who sends in your name, complete SPF/DKIM, and only then tighten the policy.
How do I check whether my domain is protected?
Fastest with our scanner, which checks SPF, DMARC and DKIM. You can also use public record-analysis tools. If DMARC is at p=none or a record is missing — there’s room to improve.
I run a company and want to deploy this correctly — can you help? Yes. Configuring SPF/DKIM/DMARC accounting for all senders and safely moving to enforcement is a typical part of a security audit and support. Deployed well, it protects your brand from impersonation and invoice fraud. Get in touch.
Summary
SPF, DKIM and DMARC are three layers that together answer the question “did this message really come from you”: SPF says who may send, DKIM signs the messages, and DMARC decides what to do with fakes — and reports abuse. Deployment is one-off, free and within every company’s reach, and it protects your brand and customers from impersonation. The key is reaching DMARC enforcement (quarantine/reject), not stopping at monitoring alone.