How to set up DMARC enforcement without breaking your email

For any UK SME, email remains the backbone of business communication. It is also, regrettably, the primary route for cyber-attacks. Sophisticated criminals routinely employ "spoofing"—impersonating your domain to send fraudulent emails to your clients, suppliers, or even your own staff. If your business has not implemented Domain-based Message Authentication, Reporting, and Conformance (DMARC), your domain is, in effect, an open invitation for these bad actors. While DMARC enforcement might seem a complex technical undertaking, overlooking its implementation is a significant oversight that jeopardises your brand reputation and could attract the attention of the ICO regarding data protection. This guide will clarify the process, detailing how to move from a vulnerable position to full DMARC enforcement without disrupting your legitimate business communications.

What DMARC actually means

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol. Its fundamental purpose is to protect your domain from being used fraudulently by others. It builds upon two older, foundational email security mechanisms: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

Think of it this way: SPF is a public list of all the servers authorised to send mail using your domain. If an email claims to be from your domain but originates from a server not on that list, SPF flags it. DKIM, on the other hand, provides a digital signature for each email sent. This signature confirms two things: that the email genuinely came from your domain (or an authorised third-party sender) and that its content has not been altered since it was sent.

DMARC takes these two concepts a step further. It instructs receiving mail servers on what to do when an email claiming to be from your domain fails either SPF or DKIM checks. Critically, it also provides a reporting mechanism, sending detailed feedback to your organisation about who is sending email using your domain, whether legitimately or maliciously. In essence, DMARC allows you to declare, "If mail from my domain doesn't pass these specific security checks, here's what you should do with it, and please tell me about it."

Why it matters for UK SMEs

Implementing DMARC is not merely a technical exercise; it is a critical commercial and regulatory imperative for UK SMEs. The ramifications of an unprotected domain extend far beyond technical inconvenience.

Firstly, there is the reputational damage. If criminals successfully spoof your domain to launch phishing attacks or invoice fraud schemes, your clients, suppliers, and partners will lose trust. Rebuilding that trust can be a lengthy and expensive endeavour, potentially impacting future business relationships and sales. Your brand, which you have worked hard to establish, becomes associated with scams.

Secondly, the financial impact can be direct and severe. Invoice fraud, where criminals impersonate your business to redirect payments, can result in significant financial losses for your clients or even for your own accounts department. Beyond direct fraud, there are the costs associated with incident response, forensic investigations, and potential legal fees if a breach occurs or if your domain is implicated in a wider criminal enterprise.

From a regulatory perspective, the Information Commissioner's Office (ICO) takes a dim view of organisations that fail to implement appropriate security measures. While DMARC is not explicitly mandated by GDPR, it forms a crucial part of an overall robust cyber security posture. Failing to protect your domain, which could lead to data breaches via phishing or impersonation, demonstrates a lack of "appropriate technical and organisational measures" under GDPR Article 32. This could result in significant fines and penalties. Furthermore, the National Cyber Security Centre (NCSC) strongly advocates for DMARC implementation, noting its effectiveness in reducing email-borne threats. Achieving Cyber Essentials certification, increasingly a requirement for government contracts and supply chains, is significantly bolstered by comprehensive email security, of which DMARC is a key component.

Finally, an unprotected domain creates operational disruption. Dealing with the fallout from a spoofing incident—responding to concerned clients, investigating fraudulent emails, and managing your email provider's potential blacklisting of your domain—diverts valuable staff time and resources away from core business activities. It is a proactive defence that prevents a multitude of reactive problems.

How to set up DMARC enforcement, a practical walkthrough

Implementing DMARC effectively requires a methodical, phased approach. Rushing this process is a common pitfall that can lead to legitimate emails being blocked, causing significant business disruption.

The Foundational Pillars: SPF and DKIM

Before you can even consider DMARC, you must ensure your Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records are meticulously configured. These are the primary authentication methods DMARC relies upon.

• SPF (Sender Policy Framework): This is a simple DNS TXT record that lists all the mail servers authorised to send email on behalf of your domain. It looks something like v=spf1 include:_spf.microsoft.com include:sendgrid.net -all.

  • v=spf1: Denotes the SPF version.
  • include:domain.com: Authorises mail servers specified by another domain's SPF record. Essential for services like Microsoft 365, Google Workspace, or marketing platforms.
  • ip4:192.0.2.1: Authorises specific IP addresses.
  • ~all (Softfail): Suggests that emails from unlisted servers should be treated with suspicion but not necessarily rejected. This is often a starting point.
  • -all (Hardfail): Explicitly states that emails from any server not listed are unauthorised and should be rejected. This is the desired end state for security. Crucially, SPF records have a limit of 10 DNS lookups. Exceeding this will cause SPF to fail, even for legitimate senders. Many organisations inadvertently break this by adding too many include statements.

• DKIM (DomainKeys Identified Mail): This adds a cryptographic signature to your outgoing emails. It involves generating a pair of keys: a private key, kept secret by your sending server, and a public key, published in your domain's DNS as a TXT record. When an email is sent, the private key signs the email's headers and body. The receiving server then uses your public key (retrieved from DNS) to verify the signature. If the signature matches, the email's authenticity and integrity are confirmed. Most major email providers (Microsoft 365, Google Workspace) provide clear instructions on how to enable and configure DKIM for your domain. It is not always enabled by default.

If SPF and DKIM are not correctly configured for all legitimate sending services, moving to DMARC enforcement will inevitably result in your own business-critical emails being rejected or quarantined by recipients. We always recommend starting with a thorough audit of your current DNS records to ensure these foundational elements are robust and accurate before proceeding.

The DMARC Policy Hierarchy Explained

DMARC functions by instructing receiving mail servers on the action to take if an email fails authentication checks. This instruction is set through a "policy" (the p= tag) within your DMARC DNS record.

• p=none (Monitoring Mode): This is the essential starting point. It tells receiving servers to deliver emails even if they fail SPF or DKIM authentication, but critically, to send a report back to you. These reports (known as aggregate reports, or rua reports) contain invaluable data about who is sending email from your domain and whether it's passing or failing authentication. This phase is purely about gathering intelligence.

• p=quarantine: Once you have a clear understanding of your email ecosystem, you can escalate. This policy instructs receiving servers to place emails that fail authentication into the recipient's junk or spam folder. It's a soft enforcement, preventing fraudulent emails from reaching the inbox but still allowing for review if a legitimate email is mistakenly flagged.

• p=reject: This is the ultimate goal, representing the highest level of DMARC enforcement. When p=reject is in place, emails that fail authentication are blocked entirely and never reach the recipient's mail server or inbox. This provides the strongest defence against impersonation and phishing, ensuring that any spoofed email pretending to be from your domain is dropped before it can cause harm.

The common error many IT professionals make is attempting to jump directly to p=reject. This is rarely successful without comprehensive preparation and almost guarantees legitimate emails will be lost. The transition must be gradual, data-driven, and meticulously monitored.

The Implementation Strategy: The "Monitor-Only" Phase

The most crucial step in establishing DMARC without disrupting your email flow is the "Monitor-Only" phase (p=none). This period is not about blocking mail; it is solely about data collection and analysis.

When you publish a DMARC record with p=none and include a rua tag (e.g., rua=mailto:[email protected]), you will begin to receive XML reports from major email providers (such as Microsoft Outlook, Gmail, and Yahoo). These raw XML files are, frankly, difficult to parse and interpret manually for any UK SME. For this reason, we strongly recommend using a dedicated DMARC monitoring platform (e.g., DMARCian, PowerDMARC, OnDMARC). These tools ingest the XML reports, process them, and present the data in an easily digestible dashboard format, showing:

1. Which services and IP addresses are sending email ostensibly from your domain.
2. Whether these emails are passing or failing SPF and DKIM authentication.
3. The volume of traffic from each sender, helping to distinguish legitimate traffic from potential malicious activity.
4. Crucially, whether the emails are achieving DMARC alignment (more on this shortly).

You should remain in this p=none phase for at least 30 to 60 days. This duration is necessary to capture the full cycle of your business email patterns, including monthly newsletters, quarterly reports, automated system alerts, and any other periodic communications. On a recent DMARC implementation project for a 60-user Surrey-based manufacturing firm, we found over a dozen third-party services attempting to send email on their behalf, none of which were correctly configured for SPF or DKIM. Without the dedicated monitoring phase, moving straight to enforcement would have crippled their operations, blocking crucial supplier communications and automated order confirmations.

Identifying and Fixing "Shadow IT" and Alignment Issues

During your monitoring phase, the DMARC reports will invariably expose "Shadow IT"—legitimate services that your staff or departments have signed up for and are using to send emails on behalf of your domain, often without the IT department's explicit knowledge or configuration. This might include:

• CRM platforms (e.g., Salesforce, HubSpot) sending sales or support emails.
• Marketing automation tools (e.g., Mailchimp, Dotdigital) for campaigns.
• HR or payroll software sending automated payslips or benefit notifications.
• Internal ticketing, project management, or support systems.
• Event registration platforms.

If these services are not correctly listed in your SPF record or are not configured to sign emails with DKIM using your domain, they will consistently fail authentication once you move to an enforcement policy. Use your DMARC monitoring dashboard to identify these senders. For each, you will need to:

1. Contact the vendor to obtain their specific SPF include strings or IP addresses.
2. Follow their instructions for setting up DKIM for your domain. This usually involves adding a specific CNAME record to your DNS.
3. Update your domain's SPF and DKIM DNS records accordingly.
4. Monitor the DMARC reports to confirm that these previously failing services are now consistently passing SPF and DKIM authentication and achieving DMARC alignment. This verification step is non-negotiable before proceeding.

DMARC also requires alignment. This means that the "Header From" domain (what the recipient sees) must match the domain used in the SPF check (the "Return-Path" or "Mail From" domain) and/or the domain in the DKIM signature. There are two alignment modes:

• Relaxed alignment (recommended for most SMEs): The organisational domain (e.g., yourdomain.com) must match. So mail.yourdomain.com would align with yourdomain.com.
• Strict alignment: The exact domain must match. mail.yourdomain.com would not align with yourdomain.com. Many third-party senders, especially marketing platforms, send emails from their own subdomains (e.g., bounces.mailchimp.com) but put your domain in the "Header From" address. If they don't also sign with DKIM for your domain or include your domain in their SPF, DMARC will fail. Ensure your email service providers are configured to support DMARC alignment for your domain.

Gradual Enforcement: The Shift to Quarantine and Reject

Once your DMARC reports consistently show that 100% of your legitimate email traffic is passing both SPF and DKIM authentication with proper alignment, you are ready to begin enforcing your policy. This should still be a gradual process.

1. Start with a percentage (pct) for p=quarantine: You can use the pct tag in your DMARC record to apply the policy to only a fraction of failing mail. For example, p=quarantine; pct=25 means only 25% of emails that fail authentication will be sent to spam; the remaining 75% will still be delivered (under p=none).
2. Monitor and increase: Carefully watch your DMARC reports after setting the pct tag. If your legitimate traffic remains unaffected, gradually increase the percentage: 50%, then 75%, and finally 100%. This allows you to catch any unforeseen issues with a limited impact.
3. Move to p=reject with pct: Once p=quarantine; pct=100 is stable and you are confident no legitimate emails are being incorrectly quarantined, you can begin the transition to p=reject. Again, start with a small percentage, e.g., p=reject; pct=10. This means 10% of failing emails will be outright rejected, while the remaining 90% will be quarantined.
4. Iterate to full p=reject: Monitor the reports closely. If no legitimate emails are being rejected, gradually increase the pct to 25%, 50%, 75%, and finally p=reject; pct=100. This is the "Gold Standard" of email security. It ensures that any spoofed email pretending to be from your domain is dropped entirely, protecting your brand from being used in phishing campaigns targeting your partners or customers.

This iterative, data-driven approach minimises risk and ensures your legitimate communications remain uninterrupted. It's a bit like testing the water before jumping in: prudent and significantly less likely to result in an unpleasant surprise.

Common mistakes we see

Even with good intentions, we frequently observe several recurring mistakes when UK SMEs attempt DMARC implementation:

1. Jumping straight to p=reject or p=quarantine: This is the most common and damaging error, almost certainly leading to legitimate emails being blocked or sent to spam.
2. Incorrect SPF record configuration: Overlooking the 10-lookup limit, missing legitimate sending services, or having incorrect syntax can cause SPF to fail even for authorised senders.
3. Neglecting DKIM for all sending services: Many organisations configure DKIM only for their primary mail provider (e.g., Microsoft 365) but forget to enable it for marketing platforms, CRM systems, or other third-party senders.
4. Ignoring DMARC reports: Setting p=none but failing to use a monitoring tool or review the reports means the critical data-gathering phase is wasted.
5. Underestimating "Shadow IT": Many legitimate services send emails on behalf of a domain, and if these are not identified and configured, they will cause DMARC failures.
6. Not understanding DMARC alignment: Assuming SPF or DKIM passing is enough without verifying that the "Header From" domain aligns with the authenticated domains.
7. Setting ruf (forensic reports) without caution: Forensic reports can contain sensitive email content and generate a huge volume of data, which can be a privacy and management nightmare for SMEs. They are rarely necessary for initial enforcement.

Key Takeaways

• DMARC is fundamental: It is a critical layer of defence against email spoofing and phishing, essential for your brand reputation, financial security, and regulatory compliance.
• Patience and data are paramount: DMARC enforcement is a phased process, not a quick fix. Rushing will almost certainly disrupt your legitimate email communications.
• SPF and DKIM are non-negotiable prerequisites: These foundational protocols must be correctly configured and maintained for DMARC to function effectively.
• A DMARC reporting tool is essential: Interpreting raw DMARC XML reports is impractical for most SMEs. Invest in a dedicated monitoring platform for clear visibility.
• Regular review is necessary: Your email ecosystem evolves. New services, changes to existing ones, or updates to your DNS records require periodic review of your SPF, DKIM, and DMARC configurations.

When to call in help

Implementing DMARC correctly demands a detailed understanding of DNS, email authentication protocols, and careful monitoring. If your internal IT team is already stretched, lacks specific expertise in these areas, or if the potential for disrupting business-critical email flow is a concern, bringing in external specialists is a pragmatic decision. An experienced provider can ensure a systematic approach, minimise risks, and accelerate the journey to full DMARC enforcement, allowing your team to focus on core operations.

To take the next step

Book a Discovery Call