A fraudulent email that appears to come from your finance director can be more damaging than a noisy spam campaign. It may ask for a bank-detail change, a rushed payment or a Microsoft 365 password reset, and it can reach a supplier or colleague before anyone has reason to question it. In the DMARC versus SPF discussion, the key point is that neither control should be treated as a complete answer on its own.
SPF, DKIM and DMARC are email authentication standards. Used properly, they make it much harder for criminals to send messages that impersonate your organisation’s domain. They also give receiving mail systems clearer instructions on what to do when a message fails authentication.
For a UK business handling client data, payments or regulated information, this is practical protection rather than technical housekeeping. It helps protect your reputation, reduces the opportunity for business email compromise and gives customers more confidence that genuine messages from your domain are genuine.
DMARC versus SPF: the practical difference
SPF stands for Sender Policy Framework. It is a DNS record that lists the mail servers and services allowed to send email on behalf of your domain. When a receiving server gets a message claiming to be from your business, it can check whether the sending server is on that approved list.
For example, if your business sends email through Microsoft 365, SPF can authorise Microsoft 365 to send mail for your domain. If you also use a CRM platform, payroll provider or marketing system that sends messages using your domain, those services may need to be included too.
SPF is useful, but it has a significant limitation. It checks the technical return path, sometimes called the envelope sender, rather than necessarily the address a recipient sees in the From field. A criminal may still be able to present an email as coming from your visible domain while using a different return path. SPF on its own does not give receiving systems a clear policy to reject that impersonation.
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on SPF and DKIM by checking whether they align with the visible From address. It then tells receiving mail systems what to do when authentication fails.
That distinction matters. SPF says, in effect, “these systems are allowed to send”. DMARC says, “if an email claims to be from our domain and cannot prove it, handle it according to our policy”.
Where DKIM fits in
DKIM, or DomainKeys Identified Mail, is the other part of the picture. It adds a digital signature to outgoing email. The recipient’s email system checks that signature against a public key published in DNS, helping confirm that the message was authorised and has not been altered in transit.
DMARC can pass if either SPF or DKIM passes and aligns with the visible From domain. This is why treating the decision as simply DMARC versus SPF can be misleading. In a sound configuration, SPF and DKIM work together, while DMARC applies the policy and provides reporting.
DKIM is particularly valuable because SPF can fail during legitimate email forwarding. A forwarded message may be sent on by a server that was never included in your SPF record. A correctly configured DKIM signature can still give DMARC a route to pass that message.
What DMARC adds that SPF cannot
A DMARC record allows you to publish one of three policy levels. A policy of `p=none` asks receivers to monitor failures but take no enforcement action. `p=quarantine` asks them to treat failing messages with suspicion, often placing them in junk. `p=reject` asks them to refuse failing messages that claim to be from your domain.
The end goal for most organisations is reject, because it offers the strongest protection against direct domain spoofing. However, moving there too quickly can cause genuine messages to fail, particularly where old applications, outsourced platforms or departmental tools are sending email without the right configuration.
DMARC also generates reports. These show which services are sending email using your domain, whether they pass SPF and DKIM, and where unauthorised activity may be occurring. For a business leader, the reports are less about reading raw XML files and more about gaining a reliable view of an often-overlooked risk: who can send as your company?
This visibility can uncover forgotten systems. A booking platform, website form, scanner, legacy server or third-party supplier may be sending messages in your name without anyone in the business realising it. That is why DMARC deployment needs ownership and review, not just a record pasted into DNS and forgotten.
A sensible route to enforcement
The safest approach is phased. Start by identifying every legitimate source of email. This usually includes Microsoft 365 or Google Workspace, but may also include marketing platforms, finance applications, support desks, website hosting, multifunction printers and line-of-business systems.
Next, configure SPF carefully. Your record should authorise real senders and nothing else. Avoid creating several SPF records for the same domain, as this can cause checks to fail. SPF also has a limit of ten DNS lookups, so adding every provider without review can create its own delivery problems.
Then enable DKIM wherever your email providers support it. Microsoft 365 and many established cloud services provide a method to set this up, although the exact DNS entries vary by provider. Make sure the signing domain aligns with the From domain used in your outbound messages.
Once SPF and DKIM are in place, publish DMARC with `p=none`. Review reports over a meaningful period, particularly if your business has monthly billing cycles, seasonal campaigns or different operational teams sending communications. Correct any legitimate failures before increasing enforcement.
When the data is clean and understood, move gradually to quarantine and then reject. You can apply a percentage setting during the transition, allowing the policy to affect only a proportion of failing mail while you monitor the result. This is less dramatic than switching everything at once and gives the business room to deal with exceptions.
For organisations without the internal capacity to interpret reports or troubleshoot DNS changes, managed email protection can take that pressure away. The important thing is clear accountability: somebody should be watching the reports, validating new email services and maintaining the records as your systems change.
Common mistakes that create avoidable risk
The most common mistake is assuming SPF alone stops spoofing. It is a worthwhile control, but without aligned DKIM and DMARC enforcement, it leaves gaps that criminals can exploit.
Another is setting a strict DMARC policy before checking all authorised senders. This can affect legitimate invoices, appointment reminders or customer communications. The commercial impact may be felt before the technical cause is obvious, especially if messages are sent by a supplier outside your usual IT process.
Businesses also sometimes protect only their main domain while leaving closely related domains unprotected. A criminal may register a lookalike domain, which DMARC cannot prevent, or exploit an unused domain you already own. Domain monitoring, sensible registration practices and staff awareness still matter.
Finally, DMARC does not stop every dangerous email. It will not prevent a criminal from using a free email address, a compromised supplier account or a lookalike domain. It also does not protect an employee who enters credentials into a convincing phishing site. Effective protection combines authentication with email filtering, multi-factor authentication, secure password practices and practical phishing awareness training.
Choosing the right level of support
A technically confident organisation may be able to manage SPF, DKIM and DMARC itself, provided it has an accurate inventory of email services and time to review changes. Others will benefit from an expert-led setup and ongoing monitoring, especially where Microsoft 365, business-critical applications and multiple third parties are involved.
MSnet helps businesses treat email authentication as part of a wider protection plan, rather than an isolated DNS task. That approach connects the technical controls with the people and processes that keep email safe day to day.
The useful question is not whether to choose DMARC or SPF. It is whether your business can confidently prove which systems send in its name, block messages that should never carry its identity and respond quickly when that picture changes. Getting that right is one less thing to worry about when your team is busy running the business.