What Is DMARC and Why Does It Matter for UK Businesses?
A practical guide for UK businesses — explaining what this means, why it matters, and what you should do about it.
Overview
43% of UK businesses experienced a cybersecurity breach or attack in the past 12 months, equating to approximately 612,000 businesses (DSIT Cyber Security Breaches Survey 2025). 67% of medium businesses and 74% of large businesses reported breaches in 2025.
Learn moreWhat Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication protocol that gives domain owners control over how receiving mail servers handle emails that claim to come from their domain but fail authentication checks. As a critical component of any cybersecurity and email security strategy, DMARC builds on two earlier standards — SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) — to prevent criminals from spoofing your business's email domain.
In practical terms, without DMARC, anyone can send an email that appears to come from yourcompany.co.uk. The recipient's email system has no way to verify whether the email genuinely originated from your organisation or was sent by a criminal impersonating your domain. With DMARC set to enforce, those fraudulent emails are rejected before they ever reach inboxes. According to the DSIT Cyber Security Breaches Survey 2025, 85% of breaches experienced by UK businesses involved phishing (DSIT 2025), and domain spoofing is a key enabler of phishing attacks targeting your customers, suppliers, and staff.
The NCSC recommends DMARC for all UK organisations and has made it a requirement for UK government email domains. DMARC implementation has also been identified as a key control by the Cyber Essentials scheme and is increasingly required by cyber insurance policies as a condition of coverage.
How DMARC Works with SPF and DKIM
DMARC does not operate in isolation — it builds upon and ties together two existing email authentication standards. Understanding how SPF, DKIM, and DMARC work together is essential for effective implementation.
SPF (Sender Policy Framework)
SPF is a DNS record that lists the mail servers authorised to send email on behalf of your domain. When a receiving mail server receives an email claiming to be from yourcompany.co.uk, it checks the SPF record published in your domain's DNS to see whether the sending server's IP address is on the approved list. If the sending server is not authorised, SPF fails. SPF prevents attackers from sending emails from unauthorised servers using your domain name, but on its own it has limitations — it only checks the envelope sender address (the Return-Path), not the From header address that the recipient actually sees.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outbound emails. This signature is generated using a private key held by your mail server and can be verified by receiving mail servers using a corresponding public key published in your DNS records. DKIM provides two important assurances: it confirms that the email was sent by an authorised server, and it confirms that the email content has not been tampered with in transit. If the email has been modified after sending, or if it was not signed by an authorised server, DKIM verification fails.
How DMARC Ties Them Together
DMARC adds two critical capabilities that SPF and DKIM alone do not provide. First, it introduces alignment — requiring that the domain in the visible From header matches the domain authenticated by SPF or DKIM. Without this alignment requirement, an attacker could send an email that passes SPF (because they control the envelope sender) but spoofs a different domain in the From header that the recipient sees. Second, DMARC tells receiving mail servers what to do when an email fails authentication — whether to deliver it anyway, quarantine it, or reject it outright. Without DMARC, receiving servers may accept emails that fail SPF or DKIM checks, offering no protection despite the authentication infrastructure being in place.
DMARC Policy Levels
DMARC is implemented as a DNS TXT record and offers three policy settings, designed to be adopted progressively as you gain confidence in your email authentication configuration.
- p=none (Monitor) — Emails that fail authentication are still delivered normally, but DMARC aggregate and forensic reports are sent to the addresses specified in the DMARC record. This monitoring mode is used during initial deployment to understand your legitimate email flows — identifying all services and systems that send email using your domain — before applying enforcement. No emails are blocked at this stage.
- p=quarantine — Emails that fail DMARC authentication are delivered to the recipient's spam or junk folder rather than the inbox. This provides partial protection and is used as an intermediate step, allowing you to verify that all legitimate sending sources are correctly authenticated before moving to full enforcement. Any legitimate emails that are incorrectly quarantined indicate gaps in your SPF or DKIM configuration that need to be resolved.
- p=reject — Emails that fail DMARC authentication are rejected outright by the receiving mail server and never delivered. This is the recommended final state and provides full protection against domain spoofing. The NCSC recommends that all UK organisations aim to reach p=reject as their DMARC policy.
Why UK Businesses Need DMARC
Without DMARC at p=reject, your domain can be freely used by criminals to send phishing emails that appear genuine. This creates risk in multiple directions. Your customers may receive fraudulent invoices or payment redirect requests that appear to come from your business. Your suppliers may be targeted with business email compromise (BEC) attacks using your domain. Your own staff may receive internal-looking phishing emails from external sources that bypass the natural scepticism they might apply to emails from unknown senders.
The financial impact of email-based attacks is substantial. The average cost of a data breach for UK organisations was £3.4 million in 2024 (IBM 2024), and BEC attacks — which frequently exploit domains lacking DMARC enforcement — are among the most financially damaging forms of cybercrime. According to the DSIT Cyber Security Breaches Survey 2025, 43% of UK businesses experienced a cybersecurity breach or attack in the past 12 months, with email remaining the primary attack vector.
Beyond security, DMARC enforcement improves email deliverability for your genuine emails. Major email providers including Google and Microsoft now use DMARC compliance as a positive signal in spam filtering decisions. Emails from domains with DMARC at p=reject are more likely to reach inboxes than emails from domains without DMARC, because the receiving server has confidence in the email's authenticity. Google and Yahoo introduced requirements in 2024 mandating that bulk senders implement DMARC, further demonstrating the industry-wide move towards authentication enforcement.
Implementation Steps
Implementing DMARC is a structured process that should be approached methodically to avoid disrupting legitimate email delivery.
Step 1: Audit Your Email Sending Sources
Before publishing any DMARC record, identify every service and system that sends email using your domain. This includes your primary email platform (Microsoft 365, Google Workspace), marketing email tools (Mailchimp, HubSpot), CRM systems (Salesforce, Dynamics 365), transactional email services, helpdesk and ticketing systems, and any other application that sends email on your behalf. Missing a legitimate sending source will cause those emails to fail authentication once enforcement is applied.
Step 2: Configure SPF and DKIM
Publish an SPF record that includes all authorised sending servers. Configure DKIM signing for your primary email platform and all third-party sending services. Each third-party service will have its own DKIM configuration process — typically involving publishing a CNAME or TXT record in your DNS that the service uses to sign outbound emails.
Step 3: Publish DMARC at p=none
Publish a DMARC record with p=none and specify an email address to receive aggregate reports. Monitor these reports for four to eight weeks to verify that all legitimate email sources are passing authentication. The reports will show which emails are passing and failing SPF, DKIM, and DMARC alignment, allowing you to identify and resolve any gaps.
Step 4: Move to Quarantine
Once monitoring confirms that all legitimate sources pass authentication, change the DMARC policy to p=quarantine. Monitor for a further two to four weeks to confirm that no legitimate emails are being incorrectly quarantined. Address any issues that arise.
Step 5: Enforce with p=reject
Change the DMARC policy to p=reject. At this point, any email that fails DMARC authentication will be rejected by receiving mail servers. Your domain is now protected against spoofing. Continue monitoring DMARC reports to ensure ongoing coverage as your email sending services evolve.
Monitoring and Ongoing Management
DMARC is not a set-and-forget configuration. Your email sending landscape changes over time — new marketing tools are adopted, CRM systems are changed, staff configure new services that send email using your domain. Without ongoing monitoring, these changes can create gaps in your SPF and DKIM records that cause legitimate emails to fail authentication under a p=reject policy, or that go undetected under a weaker policy.
AMVIA provides ongoing DMARC monitoring as part of the managed email filtering and email security service. We review DMARC aggregate reports regularly, alert you to authentication failures that may indicate either a misconfiguration or a spoofing attempt, and update your SPF and DKIM records as your email sending infrastructure evolves. Only 14% of UK businesses have a formal incident response plan (DSIT 2025), and DMARC monitoring provides an early warning system for email-based attacks against your domain.
How AMVIA Implements and Manages DMARC
AMVIA configures DMARC, SPF, and DKIM records for UK SMEs, manages the phased progression from p=none through p=quarantine to p=reject, and provides ongoing monitoring to ensure your domain remains protected as your business and its email sending services evolve. The typical implementation timeline is four to eight weeks for businesses with straightforward email configurations, with additional time required for organisations using multiple marketing platforms, CRMs, or third-party sending services. Contact AMVIA on 0333 733 8050 to discuss DMARC implementation for your business.
Key Points
What you need to know.
Why It Matters
43% of UK businesses experienced a cybersecurity breach or attack in the past 12 months, equating to approximately 612,000 businesses (DSIT Cyber Security Breaches Survey 2025).
How It Works
67% of medium businesses and 74% of large businesses reported breaches in 2025.
UK Requirements
Relevant UK regulations, standards, and compliance considerations.
Getting Started
Practical first steps for businesses of any size.
Key Considerations
Assess your current position and identify gaps
Understand relevant UK regulations and standards
Implement appropriate technical controls
Train staff on security awareness
Review and update regularly
Consider managed service options for specialist areas
Frequently Asked Questions
SPF publishes a DNS record listing the mail servers authorised to send email from your domain. DKIM attaches a cryptographic signature proving the message has not been altered in transit. DMARC ties both together by enforcing domain alignment and instructing receiving servers to quarantine or reject emails that fail authentication. All three must be configured correctly; without DMARC, failed SPF or DKIM checks may still be delivered.
At p=none, DMARC only monitors — fraudulent emails spoofing your domain are still delivered to recipients. Moving to p=reject instructs receiving mail servers to block those emails outright. Since 85% of businesses that experienced a breach identified phishing as the attack vector (DSIT 2025), and domain spoofing enables many of those attacks, reaching p=reject is the only policy level that actively protects your customers and partners.
It can, if those services are not included in your SPF record or configured with DKIM signing before enforcement begins. This is why implementation follows a phased approach: four to eight weeks at p=none to audit all legitimate sending sources — marketing platforms, CRM tools, helpdesk systems — then p=quarantine for testing, and finally p=reject once every authorised sender passes authentication cleanly.
Need Help With This?
AMVIA can assess your current position and recommend practical next steps.
Related Resources
Protect your business → Get Cybersecurity Assessment