A convincing fake email from your own domain can do more damage than a blocked spam message ever will. This DMARC implementation guide explains how to stop criminals impersonating your business while protecting legitimate email that keeps your operations moving.
For UK SMEs, email is often where trust is won or lost. A fraudulent invoice, altered bank detail request or fake message from a director can trigger financial loss, data exposure and difficult conversations with customers. DMARC gives your organisation a practical way to tell receiving mail systems which messages are genuinely authorised to use your domain.
What DMARC does for your business
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It works alongside two existing email controls: SPF and DKIM. SPF identifies the services allowed to send email for your domain. DKIM adds a signed digital marker to emails, allowing receiving systems to verify that a message has not been changed in transit.
DMARC brings these controls together. It checks whether SPF or DKIM passes and, crucially, whether the domain being checked aligns with the visible address your recipient sees in the From field. That alignment is what makes DMARC effective against direct domain impersonation.
You then publish a policy in your domain’s DNS records. The policy instructs receiving email providers what to do when a message fails DMARC checks. You can begin by monitoring failures, move to sending suspicious messages to quarantine, and eventually reject them altogether.
The business benefit is straightforward: fewer opportunities for criminals to trade on your name. It can also improve the likelihood of legitimate email reaching recipients, especially when major providers apply stronger authentication expectations to business senders.
Before you publish a DMARC record
The technical change itself is small. The investigation before enforcement is where most of the work sits. Many businesses send email from more places than they realise, particularly after years of adding cloud tools, marketing platforms and specialist systems.
Start by agreeing who owns the project. This should include whoever manages your domain DNS, Microsoft 365 or other email platform, and the teams responsible for customer communications. Finance, marketing, HR and operations may each use services that send as your domain without involving IT on a day-to-day basis.
Create an inventory of every legitimate sender. Common examples include:
- Microsoft 365 mailboxes and shared mailboxes
- CRM, marketing and newsletter platforms
- Finance, payroll and HR systems
- Website forms, booking tools and ecommerce platforms
- Helpdesk, monitoring and document-signing services
Do not rely solely on what staff remember. Review DNS records, procurement records, application settings and email headers from recent messages. Ask suppliers whether their service supports custom DKIM signing and what SPF entries it requires. A platform that sends email on your behalf but cannot authenticate correctly may need configuration changes before your policy becomes stricter.
This discovery stage matters because a reject policy can prevent real messages from being delivered if a legitimate service has been missed. That is not an argument for delaying DMARC indefinitely. It is a reason to implement it in controlled stages.
Set up SPF and DKIM first
DMARC is not a replacement for SPF and DKIM. Both need attention, although DMARC only requires one of them to pass with aligned domains. In practice, configuring both gives you more reliable protection and fewer delivery problems.
Your SPF record is a DNS text record listing authorised sending infrastructure. Keep it accurate and avoid adding providers simply because a setup guide tells you to. Every included service expands the group allowed to send as your domain. SPF also has a limit of ten DNS lookups, so an overgrown record can fail even when it appears correct.
DKIM is generally the more dependable long-term control because it validates a signed message rather than relying on the sending server’s IP address. Enable DKIM for Microsoft 365 and for third-party services wherever possible. Check that the signing domain aligns with the address used in the visible From field. A passing signature from an unrelated supplier domain may not satisfy DMARC alignment.
If you use several related domains, decide which are actively used for email and which should never send it. A parked or defensive domain is still valuable to criminals. It should normally have a restrictive DMARC policy rather than being left unprotected.
DMARC implementation guide: start in monitoring mode
Your first DMARC record should normally use the policy `p=none`. This does not ask receiving systems to block mail. It asks them to send reports so you can see who is using your domain and whether messages pass authentication.
A basic record is published at `_dmarc.yourdomain.co.uk` as a DNS TXT record. It includes a version, a policy and an address for aggregate reports. Those reports are XML files, which are useful but not particularly friendly to read without a reporting service or technical support.
Allow enough time to gather meaningful data. Two to four weeks is often sensible, but the right period depends on your business cycle. A logistics firm may need to see communications across busy operational periods. A professional practice may need to include month-end invoicing, recruitment activity or client campaigns. The goal is to find irregular but legitimate senders before enforcement begins.
During this period, review three things: authorised sources that are failing, unknown sources attempting to use the domain, and whether failures are caused by SPF, DKIM or alignment. Correct the genuine sources first. Unknown sources may be phishing, but investigate before making assumptions, especially where suppliers or regional teams operate independently.
Move from visibility to protection
Once legitimate services consistently pass DMARC, increase the policy to `p=quarantine`. This asks receiving providers to treat failed messages with caution, often placing them in spam or junk folders. It is a useful intermediate stage because it reduces exposure while allowing you to spot any unexpected impact.
Some organisations apply quarantine gradually using the `pct` tag, which applies the policy to a percentage of failing mail. This can be helpful where email flows are complicated, but it should not become a permanent comfort blanket. A low percentage leaves much of your domain available for abuse.
When reporting shows that valid email is correctly authenticated, move to `p=reject`. Receiving systems are then asked to reject messages that claim to come from your domain but fail DMARC. This is the point at which the strongest protection against direct spoofing is achieved.
Keep monitoring after enforcement. New software, mergers, website changes and supplier replacements can all introduce unauthenticated email. DMARC is a business control that needs ongoing ownership, not a one-off DNS task.
Common problems that delay enforcement
The most common issue is treating DMARC as an IT-only exercise. A marketing team may launch a campaign tool, or finance may adopt an invoicing platform, without realising it sends mail as the corporate domain. Clear approval processes help prevent this recurring problem.
Forwarded email can also complicate SPF, because forwarding changes the route a message takes. DKIM often survives forwarding better, which is another reason to configure it carefully. Mailing lists can create similar behaviour. Test real messages rather than relying only on a supplier’s documentation.
Subdomains require attention too. Your main DMARC policy can apply to them by default, but some organisations use subdomains for marketing, support or transactional email and need separate policies. Make this an intentional decision. A forgotten subdomain can become an easy impersonation route.
Finally, DMARC cannot stop every form of email fraud. Attackers can use lookalike domains, compromised accounts or convincing social engineering. It works best alongside multi-factor authentication, email filtering, secure backup, and staff awareness training that gives people confidence to question unusual requests.
Decide how your organisation will manage DMARC
Technically confident organisations may manage the records and reports themselves, provided there is a named owner and a process for reviewing changes. Others will prefer a managed service, particularly where Microsoft 365, multiple suppliers and limited internal IT time make reporting harder to interpret.
The right approach depends on your email estate and risk profile. A small business with one Microsoft 365 tenant may need focused setup and periodic checking. A regulated firm, multi-site operation or company handling sensitive financial requests may benefit from continuous monitoring and expert support. MSnet can help businesses assess their email estate, configure authentication correctly and keep the protection working as systems change.
A properly enforced DMARC policy is one less thing for your team to worry about when criminals try to impersonate your business. Start with a clear picture of what sends email for you, make legitimate services accountable, and let every policy change be guided by evidence rather than guesswork.