SPF, DKIM and DMARC Explained for UK Businesses

Reviewed 18 August 2026.

SPF, DKIM and DMARC are DNS-based email controls that work together to make it harder for criminals to impersonate your domain. SPF identifies permitted sending systems, DKIM attaches a verifiable signature to messages, and DMARC checks that the visible From address aligns with those results before telling receiving services what to do.

They reduce domain spoofing and improve accountability, but they are not a complete email-security product. They do not stop every phishing message, clean an infected device or guarantee that legitimate mail is safe.

SPF, DKIM and DMARC at a glance

Control	Question it answers	Where it is configured	Main limitation
SPF	Is this sending server authorised for the envelope domain?	A TXT record in DNS	Forwarding can break SPF, and the visible From address may be different
DKIM	Does this message have a valid signature from the signing domain?	A public key in DNS; private key held by the sender	A valid signature does not by itself prove the visible From domain is aligned
DMARC	Does SPF or DKIM pass in alignment with the visible From domain?	A TXT record at _dmarc.yourdomain	Poor discovery can cause legitimate mail to fail when enforcement begins

How SPF works

Sender Policy Framework (SPF) publishes the systems allowed to send mail for a domain. A typical record might authorise Microsoft 365 plus a marketing platform. Receiving mail systems compare the connecting server with that policy.

A domain should have one valid SPF record. Multiple separate SPF records can cause a permanent error. SPF also has a limit on DNS-based lookups, so repeatedly adding suppliers without removing old ones can make the record fail. Maintain an inventory of every legitimate sender instead of treating the record as an append-only list.

SPF evaluates the envelope sender used during delivery. That can differ from the address a person sees in the From field, which is why SPF alone does not adequately prevent visible-domain impersonation.

How DKIM works

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to selected message headers and content. The sending platform holds a private key; receiving services retrieve the matching public key from your DNS and verify that the signed content has not been altered.

DKIM records use a selector, allowing a domain to have different keys for Microsoft 365, Google Workspace, a newsletter service and other senders. Rotate keys where the platform supports it, and remove selectors that are no longer used.

A DKIM pass confirms that the message was signed by the stated signing domain and survived verification. DMARC adds the crucial check that this domain aligns with the visible From address.

How DMARC brings them together

Domain-based Message Authentication, Reporting and Conformance (DMARC) requires either aligned SPF or aligned DKIM to pass. Alignment means the authenticated domain matches, or is an allowed organisational-domain relation to, the address the recipient sees.

A DMARC record also publishes a policy:

• p=none requests reports but does not ask receivers to block failing messages.
• p=quarantine asks receivers to treat failures as suspicious, often placing them in spam.
• p=reject asks receivers to reject messages that fail DMARC.

Reporting addresses can receive aggregate data showing which services send as your domain and whether they pass. Those reports are operational evidence: they help find forgotten services, forwarding behaviour, mistakes and attempted impersonation.

A safe rollout plan

Do not jump straight to p=reject on an established domain without understanding every legitimate sender. A controlled rollout looks like this:

1. Inventory senders. Include staff mail, websites, CRM, invoicing, helpdesk, monitoring, booking, payroll, marketing and any supplier sending on your behalf.
2. Fix SPF. Keep one valid record, remove obsolete services and confirm the policy stays within technical limits.
3. Enable DKIM. Configure signing in each supported platform and verify the selector records.
4. Publish DMARC in monitoring mode. Use a reporting mailbox or service capable of processing aggregate XML reports.
5. Review and classify sources. Identify legitimate, unknown and malicious senders. Fix alignment for approved services.
6. Move gradually to enforcement. Use quarantine or percentage controls where appropriate, monitor the effect, then progress to reject.
7. Maintain the configuration. Update records when suppliers change and review reports for new failures.

The NCSC provides practical guidance and a free email security and anti-spoofing service for UK organisations. Its tools can help check records and monitor reports.

Microsoft 365 and Google Workspace considerations

Both platforms support SPF, DKIM and DMARC, but enabling them in the admin console is only part of the job. Your website forms, accounting system, ticketing tool and marketing platform may send mail separately. Each sender must authenticate correctly or stop using your main domain in its visible From address.

For Microsoft 365, enable DKIM for each custom domain after the required DNS records are present. For Google Workspace, generate the domain key in the Admin console, publish the selector record and then start authentication. In both cases, verify actual message headers rather than assuming a successful setup screen proves every route is aligned.

Common configuration mistakes

• Publishing several SPF records. Merge authorised sources into one policy.
• Forgetting third-party senders. Website forms and business apps are frequent causes of DMARC failure.
• Using an overly broad SPF policy. Authorise only genuine sources and remove old suppliers.
• Enabling DMARC enforcement without reports. Reporting helps distinguish attacks from broken legitimate mail.
• Assuming SPF pass equals DMARC pass. The authenticated domain must align with the visible From domain.
• Leaving DMARC at p=none forever. Monitoring provides visibility, but enforcement provides the anti-spoofing outcome.
• Ignoring subdomains. Decide deliberately how they should be used and protected.
• Never reviewing the setup after launch. New applications and suppliers change the sending landscape.

What these controls do not solve

A criminal can register a lookalike domain, compromise a genuine mailbox or send a malicious message from an otherwise authenticated service. That is why businesses still need MFA, secure devices, filtering, patching, staff awareness, payment-verification procedures and incident response.

DMARC protects use of your domain; it does not make every message from your domain trustworthy if an authorised account has been taken over.

How to check whether your domain is protected

1. Look up the SPF record at the root of the sending domain.
2. Check the DKIM selector used by a real message and inspect its authentication result.
3. Look for a DMARC TXT record at _dmarc.yourdomain.
4. Confirm reports are reaching a monitored destination.
5. Send test messages through every important platform and inspect SPF, DKIM and DMARC results in the headers.
6. Review whether the DMARC policy is monitoring, quarantining or rejecting failures.

A green result for one Microsoft 365 email does not prove your newsletter, website and invoicing mail are correctly configured. Test the whole sending inventory.

Frequently asked questions

Do I need all three: SPF, DKIM and DMARC?

Yes, in most business environments. SPF and DKIM provide authentication signals; DMARC aligns them with the visible From domain, adds reporting and publishes an enforcement policy.

Will DMARC stop spam coming into my inbox?

DMARC mainly protects domains from being impersonated. Your inbound email service should also use filtering, reputation, malware scanning and user-reporting controls.

Can DMARC block legitimate email?

Yes, if legitimate senders are missing or misaligned when enforcement is enabled. Inventory, reporting and a staged rollout reduce that risk.

How long does implementation take?

Simple domains may be configured quickly, but established businesses should monitor long enough to observe normal sending patterns. The duration depends on the number of platforms, mail volume and how quickly suppliers can correct alignment.

Should I use my main domain for bulk marketing?

Consider a clearly related subdomain and configure it properly. This separates some operational reputation while keeping the sender recognisable. It is not a substitute for consent, list quality or authentication.

Need a careful rollout?

ACA Tech Solutions can inventory your senders, correct DNS records, enable signing, interpret DMARC reports and move toward enforcement without guessing. Ask us to review your email security or include it in a free IT health check.