SPF, DKIM and DMARC explained
SPF, DKIM and DMARC sound technical, but the job is simple: they tell recipients’ mail servers that an email from your domain really was sent by you. Without them you risk both ending up in the spam filter and letting others send fake mail in your name.
In short
- The three standards solve two things at once: deliverability to the inbox and protection against abuse of your domain.
- SPF lists which servers may send on your behalf, DKIM signs the mail cryptographically, and DMARC ties them together with a policy and reporting.
- Roll DMARC out in steps — start with monitoring, move to quarantine, and finish with rejection.
- Most mistakes come from forgotten third-party senders or a policy that never gets past monitoring.
Why email authentication matters
Email was invented without any built-in way to prove who the sender is. So in principle anyone can put your company name in the sender field. Recipients’ mail servers have to guess whether a message is genuine — and they guess far better when you tell them what is allowed.
It is about two things at the same time. One is deliverability: making sure your offers, invoices and replies actually land in the inbox instead of in spam or being rejected outright. The other is security: making sure fraudsters cannot send fake mail that appears to come from you to your customers, suppliers or your own staff.
The large mail providers keep tightening their requirements. Missing authentication increasingly means your mail is filtered out before anyone sees it. SPF, DKIM and DMARC are the three standards that together give the recipient a clear answer to whether a message can be trusted.
SPF — which servers may send for you
SPF (Sender Policy Framework) is a list of the servers allowed to send mail on behalf of your domain. The list is published as a single text record in your DNS — the same address book that tells the internet where your domain lives.
When a message arrives, the recipient’s server looks up your SPF record and checks whether the sending server is on the list. If it is, one of the signs of authenticity is in place. If it is not, that is a warning sign. On its own, however, SPF does not prove that the content itself is unchanged — that is DKIM’s job.
The most important thing is that the list is complete. If you use Microsoft 365 for daily mail, a newsletter tool and perhaps a CRM or invoicing system that sends on your behalf, they all need to be included. If one is forgotten, its mail is treated as suspicious.
DKIM — a digital signature on every message
DKIM (DomainKeys Identified Mail) adds an invisible, cryptographic signature to every message you send. The signature works like a sealed stamp: it proves both that the mail came from your domain and that it has not been altered on the way.
It relies on a key pair. The private key sits with your mail provider and is used to sign every outgoing message. The public key is published in your DNS so the recipient can verify that the signature matches. If it matches, the recipient knows the content is intact and genuinely came from you.
DKIM survives better than SPF when a message is forwarded, because the signature travels with the mail itself rather than depending on which server delivers it. That is why the two standards complement each other — and why you want both in place, not just one.
DMARC — the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the rule that ties SPF and DKIM together. It tells the recipient’s server what to do if a message fails the checks — and it also asks for reports so you can see who is sending in your name.
DMARC has three levels, and the order matters. Start with p=none, where nothing is blocked but you receive reports and gain an overview of your own and external senders. Then move to p=quarantine, where failing mail lands in spam. Finish with p=reject, where fake mail is refused outright before it arrives.
The step-by-step rollout is the whole point. If you jump straight to rejection, you risk blocking your own legitimate mail because a sender was not set up correctly. By beginning with monitoring, you can fix the issues calmly before the policy starts blocking anything.
Common mistakes — and how Webits sets it up
Most problems are not caused by the technology itself but by details in the setup. A missing record, a forgotten sender or a policy that never gets past monitoring is enough to leave both deliverability and protection working less well than they should.
At Webits, email authentication is part of the mail hosting and DNS we manage. We map all your senders, create the right records, roll DMARC out in steps and read the reports until the policy can safely be set to rejection — and keep an eye on it afterwards.
- A missing or incorrectly configured SPF, DKIM or DMARC record in DNS.
- Too many DNS lookups in the SPF record, so it stops working.
- Forgotten third-party senders such as a newsletter tool, CRM or invoicing system.
- A DMARC policy left on p=none forever without any real protection.
- Nobody reading the DMARC reports, so errors and abuse are never discovered.
Next steps
Use our guide to choosing the right process, or read about how Webits works with IT automation and system integrations. A concrete assessment starts with your current workflow, not with a particular tool.