Stop spoofing and phishing with SPF, DKIM and DMARC

There is a particular frustration that comes with discovering someone has sent an email in your company’s name that you never wrote. It might be a fake invoice. A request to change bank details. A “CEO” asking for an urgent payment. Or a phishing email that looks just convincing enough to trick a customer.

You didn’t send it. But your domain did.
For UK SMEs, email remains the primary business channel. It carries contracts, invoices, payroll data, client instructions, customer queries and supplier negotiations. That makes it both indispensable and exposed.

Phishing remains the most common starting point for wider compromise. It opens the door to credential theft, account takeover, ransomware deployment and invoice fraud. And in many cases, the damage starts not with a breach of your mailbox but with someone successfully spoofing your domain. That is where SPF, DKIM and DMARC come in as the foundation of domain-level email security.

Why email security still matters more than most SMEs realise

Email is high-volume, trusted and largely unchallenged. Staff expect it to work, customers rely on it, and finance teams act on it. That combination makes it the perfect attack surface.

Phishing causes financial loss and operational disruption. A single fraudulent bank detail change can cost tens of thousands. A compromised mailbox can quietly monitor conversations for weeks before striking. A spoofed domain can damage brand credibility overnight.

Many SMEs assume Microsoft 365 or Google Workspace will handle this. And those platforms do include strong anti-spam and anti-phishing filtering. But filtering protects recipients. It does not necessarily protect your domain from being impersonated elsewhere.
If someone can send email that appears to come from your domain, external filtering alone does not fix that. Domain authentication is your responsibility.

SPF: authorising who can send for your domain

SPF, or Sender Policy Framework, is often the first step.

At its core, SPF is a DNS TXT record that lists which servers are allowed to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourdomain.co.uk, it checks your SPF record to see whether the sending IP address is authorised.

If the sending server is not listed, SPF can signal failure. That sounds simple. But reality is rarely simple.
Most SMEs send email from multiple services such as Microsoft 365, CRM platforms, marketing tools, invoice systems, HR systems, cloud apps etc. Sometimes legacy on-premise servers still lurking quietly in the background.

Every one of those legitimate senders must be authorised in your SPF record. Miss one, and legitimate mail may fail authentication. Include too broadly, and you weaken protection.
SPF does help reduce spoofing, particularly crude attempts that originate from unauthorised servers. It can also improve deliverability because receiving systems gain confidence that your domain is well-managed.

But SPF has structural limitations.

One of the most common is forwarding. If an email is forwarded through another system, the original sending IP may not match the forwarding server. SPF can fail even when the message is legitimate. That creates false positives and delivery headaches.
Operationally, SPF also requires discipline. Whenever a new third-party platform is introduced that sends email on your behalf, the SPF record must be updated. Without change control, records become stale or exceed DNS lookup limits, leading to unexpected failures.

DKIM: proving the message hasn’t been altered

DomainKeys Identified Mail, or DKIM, takes a different approach.

Rather than checking the sending server, DKIM attaches a cryptographic signature to each message. When your mail server sends an email, it signs certain headers and body content using a private key. The corresponding public key is published in DNS.

When the recipient’s server receives the email, it retrieves your public key and validates the signature. If the signature matches, the message is confirmed as authentic and unaltered in transit.

Unlike SPF, DKIM survives forwarding. Because the validation is based on message content rather than IP address, forwarded mail can still pass DKIM checks.

For Microsoft 365 and Google Workspace users, DKIM must be explicitly enabled and correctly configured. That involves generating keys, publishing DNS records and ensuring the correct selector is used.

Key length matters. 2048-bit keys are now recommended for stronger cryptographic resilience. Some providers still default to 1024-bit keys, which are increasingly discouraged.
Common setup issues include mismatched selectors, DNS propagation delays and signing misalignment when multiple sending systems are involved.

There is also a caveat. DKIM confirms a message was authorised and unaltered, but it does not confirm intent. A legitimately compromised account can still send malicious mail with valid DKIM signatures. There is also a theoretical replay risk, where a valid signed message could be reused in certain attack scenarios.
DKIM strengthens authenticity. It does not prevent abuse alone.

DMARC: turning authentication into policy

DMARC is where SPF and DKIM become enforceable. Without DMARC, even failed SPF or DKIM checks may not lead to action. DMARC allows domain owners to publish a policy instructing receiving servers what to do when authentication fails.

At its simplest, DMARC answers two questions:

• Did SPF or DKIM pass?
• Did the authenticated domain align with the visible “From” address?

Alignment is critical. It ensures that the domain visible to the recipient matches the domain validated by SPF or DKIM. This prevents attackers from passing authentication using unrelated domains while spoofing yours.

DMARC policies operate in three modes.

1. “None” monitors without enforcing.
2. “Quarantine” suggests suspicious mail be treated as spam.
3. “Reject” instructs receiving servers to block unauthenticated messages outright.

Many organisations stop at monitoring. Moving to “p=reject” is what materially reduces spoofing and branded impersonation. But that step should only happen after careful preparation.

Before enforcing, you must inventory all legitimate senders.
CRM tools. Marketing platforms. Finance systems. Legacy devices. Absolutely everything.

Publishing SPF, DKIM and DMARC records requires controlled change management. DNS TXT records must be accurate. Mail flow must be tested. Authentication headers should be examined to confirm alignment.

Done properly, DMARC enforcement significantly reduces the ability for attackers to spoof your domain. Done hastily, it can interrupt legitimate email.

Using DMARC reports to detect abuse

One of DMARC’s most valuable features is reporting.
Receiving mail servers send aggregate reports detailing which IP addresses are sending mail claiming to be from your domain, whether authentication passed and what actions were taken.

These reports can reveal:

• Unauthorised sending sources
• Spoofing attempts from overseas IP ranges
• Misconfigured internal systems
• Forgotten third-party services

They can also expose shadow IT – systems sending email without central oversight.
Interpreting DMARC reports requires analysis. They arrive in XML format and often need specialised tools to visualise trends.

But they offer visibility that many SMEs have never had.

Patterns can be turned into action: tightening SPF, rotating DKIM keys, escalating policy from monitoring to reject, and blocking lookalike domains.

Ongoing monitoring protects domain reputation and improves deliverability over time.
Email authentication is much bigger than a one-time project, it’s ongoing maintained control.

Business email compromise and account takeover

Domain spoofing is only one part of the problem. Business Email Compromise (BEC) often involves legitimate accounts. Attackers gain access through phishing or credential theft and then operate quietly.

Invoice fraud is common. Perhaps a supplier’s bank details appear to change or payroll diversion requests are made. Conversation threads are hijacked at just the right moment.

Attackers frequently create hidden mailbox rules to divert responses. They set silent forwarding to external accounts. They monitor payment cycles before striking.

Multi-Factor Authentication and conditional access policies are foundational defences. They reduce the risk of credential-based compromise and restrict risky logins.
But when compromise is suspected, speed matters.

Immediate steps should include session revocation, password reset, token invalidation, mailbox rule review and sign-in log analysis. In Microsoft 365, that means investigating Azure AD sign-in logs, disabling suspicious accounts and reviewing audit trails.
Layered defences extend beyond authentication. Secure email gateways, advanced anti-phishing policies, impersonation detection and user awareness all contribute.

Where Do You Stand Today?

SPF, DKIM and DMARC directly influence whether criminals can send email in your name.
Many UK SMEs assume these are configured correctly because mail appears to flow. That assumption can mask gaps.

• Are all legitimate senders accounted for?
• Is DKIM enabled and using strong keys?
• Is DMARC enforcing rejection or merely observing?
• Are reports being reviewed and acted upon?