Email misconfiguration: the silent risk hiding in your business inbox

Email misconfiguration is one of the most common and consistently underestimated exposures in a business technology environment. Most organisations discover it only after a fraud attempt, a supplier impersonation attack, or a failed audit. By that point, the domain has often been active and unprotected for years. The infrastructure works. Messages send and receive. Nothing looks broken. That functional appearance is precisely what makes this class of risk so persistent.

This article addresses what misconfiguration actually means in the context of email authentication, how attackers exploit it, what it costs businesses when it goes wrong, and what a well-governed domain looks like in 2025.

Working email does not mean secure email

Delivery is not the same as authentication. An organisation can send and receive thousands of emails a day with no SPF record, no DKIM signing, and no DMARC policy in place, and experience no visible disruption whatsoever. The mail flows. The users do not complain. The helpdesk sees nothing.

The problem is not operational. It is structural. Without authentication records, any third party can send email that appears to come from your domain. Attackers do not need access to your mail server, your Microsoft 365 tenant, or any of your user accounts. They only need your domain name, which is public information.

This is why email misconfiguration sits in a different category from most IT risks. It does not trigger alerts. It does not appear in endpoint detection logs. It does not generate a support ticket. It waits.

For an IT Director at a regulated UK business, the exposure is not hypothetical. Financial services firms, law firms, and professional services organisations are high-value targets for business email compromise precisely because their clients expect to receive payment instructions, contract documents, and sensitive communications by email. A spoofed invoice from a credible-looking domain is not a sophisticated attack. It is an exploitation of missing configuration that most organisations could address in hours.

The standard is not perfection. It is having the authentication layer in place at all.

What email misconfiguration actually looks like

Three DNS-based authentication standards form the foundation of secure email: SPF, DKIM, and DMARC.

SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorised to send email on behalf of your domain. If a server not on that list attempts to send an email claiming to be from your domain, receiving mail servers can identify the discrepancy.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages. The receiving server checks that signature against a public key published in your DNS. If the signature does not match, the email has either been tampered with in transit or was never sent from an authorised source.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receiving mail servers what to do when a message fails either check. A DMARC policy of p=none monitors without enforcing. A policy of p=quarantine routes failing messages to spam. A policy of p=reject blocks them entirely. Without a DMARC record, receiving servers make their own decisions about what to do with messages that fail authentication checks, which means the outcome is unpredictable and inconsistent across email providers.

Beyond these three, additional standards exist that are increasingly relevant for regulated organisations. MTA-STS (Mail Transfer Agent Strict Transport Security) enforces encrypted connections between mail servers. TLS-RPT (TLS Reporting) provides visibility into connection failures and potential interception attempts. BIMI (Brand Indicators for Message Identification) allows organisations with a DMARC policy of p=quarantine or p=reject to display a verified logo in supporting email clients, providing a visible trust signal for recipients. Most major mailbox providers also require a Verified Mark Certificate to activate logo display.

Misconfiguration is not always an absence. It can also be an incorrect SPF record that does not include all authorised sending sources, a DKIM selector that has expired or was never activated, or a DMARC policy left at p=none indefinitely because nobody took responsibility for moving it to enforcement.

How attackers exploit a misconfigured domain

The attack vector is straightforward. An attacker identifies a domain with no DMARC policy or a policy set to p=none. They send an email from their own server, populating the From header with your domain. The receiving mail server checks for a DMARC record, finds either nothing or a monitoring-only policy, and delivers the message.

The recipient sees your domain in their inbox. They have no technical signal that anything is wrong.

From that position, the attacker has a number of options. They can impersonate your accounts payable team and issue a payment instruction to a supplier. They can impersonate a senior partner and request a document transfer. They can impersonate your IT department and direct a staff member to a credential harvesting page. None of these require compromising a single account. They require only that your domain has no enforcement policy in place.

For organisations in financial services and legal, the exposure is compounded by the nature of the relationships involved. Clients routinely expect to receive time-sensitive instructions by email. The social engineering component of a spoofing attack is made significantly more credible by the professional context.

Phishing attacks that succeed almost always begin with a deceptive email. That deception is made substantially easier when the target organisation has provided no authentication signal for receiving servers to act on.

The business cost: spoofing, fraud, and reputational damage

The financial exposure from a successful email spoofing attack is direct and potentially significant. Fraudulent payment instructions that succeed result in funds transferred to attacker-controlled accounts. Recovery rates for these transfers are low, particularly where the transfer has moved internationally before the fraud is detected.

The reputational cost is harder to quantify but often more lasting. When a client receives a fraudulent email purportedly from your firm, the question they ask is not only "what happened to my money" but also "why was your domain being used to defraud me." The answer that your SPF record was misconfigured or your DMARC policy was never set to enforcement is not reassuring.

For professional services and financial services firms, where client relationships are the primary commercial asset, that reputational damage affects retention and referrals long after the immediate incident is resolved.

There is also a regulatory dimension. Firms operating under Financial Conduct Authority (FCA) oversight, those processing payment card data under Payment Card Industry Data Security Standard (PCI DSS) requirements, and organisations seeking or maintaining ISO 27001 certification are all expected to maintain controls over how their communications infrastructure can be exploited. An email domain with no enforcement-level DMARC policy represents a demonstrable gap in those controls.

PCI DSS version 4.0 introduced strengthened requirements around anti-phishing controls, including email authentication standards. Organisations in scope for PCI DSS compliance should treat DMARC enforcement as an expected control, not an optional one.

Why Microsoft 365 leaves you partially exposed by default

Microsoft 365 handles a great deal for organisations that rely on it. Licensing, identity management, mailbox provisioning, spam filtering, and the broader productivity suite all function without the organisation needing to manage mail server infrastructure directly. That convenience creates a reasonable assumption that the security fundamentals are also handled.

They are not, and the distinction matters.

Microsoft 365 does not configure SPF records for custom domains by default. When an organisation sets up a custom domain in Microsoft 365, SPF must be created manually in the domain's DNS settings. Microsoft publishes the required record values, but the act of creating and publishing the record is the customer's responsibility.

DKIM signing is available within Microsoft 365 but is not enabled for custom domains out of the box. Organisations must activate DKIM signing in the Microsoft 365 Defender portal and publish the associated CNAME records to their DNS. Until those steps are completed, Microsoft 365 signs outbound messages using a fallback policy under the tenant's onmicrosoft.com domain, not the organisation's own domain. That signing is not visible to the recipient, does not satisfy DMARC alignment for the custom domain, and does not prevent spoofed email appearing to originate from the organisation's address. The practical exposure is the same as unsigned email from the recipient's perspective.

DMARC is entirely the customer's responsibility. Microsoft 365 provides no DMARC record and enforces no DMARC policy on behalf of custom domain customers. The organisation must create the DNS record, define the policy, configure a reporting mailbox, and take responsibility for moving the policy from monitoring to enforcement.

This is not a criticism of Microsoft 365. It reflects the correct architectural position for a platform that cannot make DNS changes on behalf of its customers. The responsibility lies with the organisation, or with their managed service provider on the organisation's behalf.

The practical consequence, observed consistently across organisations that have not had their email domain configuration reviewed, is a gap between what an IT team believes Microsoft 365 handles and what it actually does. That gap is exactly where email misconfiguration persists.

What UK regulated businesses need to have in place

For IT Directors and senior IT buyers at UK regulated organisations, the baseline is no longer a matter of internal discretion. Several frameworks and regulatory contexts establish clear expectations.

Cyber Essentials, the UK government-backed certification scheme overseen by the National Cyber Security Centre (NCSC), addresses controls over network boundaries and permitted systems. The NCSC's own guidance strongly recommends implementing SPF, DKIM, and DMARC as part of a secure email configuration, and assessors for Cyber Essentials Plus may review email authentication as part of technical assessment. Organisations seeking certification should treat these controls as expected practice.

NCSC Mail Check provided a free domain health monitoring service used by thousands of UK public sector and regulated industry organisations for years. The NCSC began winding down Mail Check in 2025, removing DMARC aggregate reporting, DKIM checks, and TLS-RPT features in March 2025, before retiring the service entirely on 31 March 2026. Organisations that had been relying on it for email domain monitoring were left without visibility progressively over that period.

PCI DSS 4.0 strengthened expectations around anti-phishing controls, including the implementation of DMARC, for organisations in scope. Acquirers and assessors increasingly treat DMARC enforcement as an expected control rather than a recommended one.

ISO 27001 requires organisations to identify and control risks to the confidentiality, integrity, and availability of information assets. An unprotected email domain that can be spoofed without restriction represents a documented risk to all three. Organisations pursuing or maintaining ISO 27001 certification should treat DMARC enforcement as part of their control set.

The minimum a regulated UK business should have in place, in order of priority, is an SPF record that correctly identifies all authorised sending sources; DKIM signing enabled and verified for all outbound mail; and a DMARC policy that has progressed from p=none monitoring to at least p=quarantine, with a clear plan and timeline for reaching p=reject.

Beyond the minimum, MTA-STS and TLS-RPT add meaningful visibility into connection-level threats that DMARC alone does not address.

How to find out if your domain is at risk

The starting point is a domain check. DNS records are publicly queryable, which means the presence or absence of SPF, DKIM, and DMARC records for any domain can be assessed without any access to the organisation's systems, mail server, or Microsoft 365 tenant.

What a domain check cannot tell you on its own is whether what is present is correct. An SPF record that lists the wrong sending sources, a DKIM selector that has expired, or a DMARC policy where the reporting mailbox is unmanned all represent functional misconfiguration that a raw DNS lookup will not surface without analysis.

Conosco offers a free Email Domain Security (EDS) report that goes beyond a raw record lookup. It checks SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT, and returns a contextualised assessment of what is in place, what is missing, and where the configuration is present but not effective. The report is reviewed by a Conosco specialist before it is sent, so the findings come with context rather than a score that requires decoding.

For IT Directors who want to understand their organisation's exposure without commissioning a full security audit, the EDS report is the right starting point.

Request your free EDS report

FAQ

What is email misconfiguration and why does it matter for businesses?

Email misconfiguration refers to DNS-level authentication records that are absent, incomplete, or incorrectly set. The three core standards are SPF, DKIM, and DMARC. When these are not in place, anyone can send email that appears to come from your domain. Recipients have no technical signal that the message is fraudulent. For businesses in financial services, legal, or professional services, this creates a direct vector for impersonation fraud, where attackers send payment instructions or contract documents using your domain name without needing access to any of your systems.

What is the difference between SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) is a DNS record that defines which mail servers are permitted to send email on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages, allowing receiving servers to verify the message has not been altered and originates from an authorised source. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and specifies what receiving servers should do when a message fails either check: monitor only, quarantine, or reject. All three are required for a complete email authentication posture.

Does Microsoft 365 configure email security automatically?

No. Microsoft 365 does not configure SPF records, DKIM signing, or DMARC policies for custom domains by default. SPF must be created manually in the domain's DNS settings. DKIM signing must be activated in the Microsoft 365 Defender portal and the associated DNS records published. DMARC is entirely the customer's responsibility. This is an appropriate division of responsibility, but it means organisations that have not taken active steps to configure email authentication may be operating without these protections in place, regardless of how long they have been on Microsoft 365.

What can happen if my business domain has no DMARC record?

Without a DMARC record, receiving mail servers have no instruction from your domain on how to handle messages that fail SPF or DKIM checks, and spoofed email will reach inboxes. With a DMARC policy set to p=none, the situation is the same from a delivery perspective: spoofed email still reaches inboxes, though the domain owner does receive aggregate reports. In both states, fraudulent emails impersonating your domain are likely to reach recipients. Attackers can use your domain to send payment fraud instructions to your clients, impersonate senior staff internally, or direct recipients to phishing pages. The attack requires no access to your systems. The consequences can include direct financial loss, client relationship damage, and regulatory scrutiny.

Is email domain security part of Cyber Essentials?

Cyber Essentials, the UK government-backed certification scheme, does not name SPF as a standalone pass/fail control in its technical requirements document. However, the NCSC recommends email anti-spoofing controls as part of a secure baseline, and organisations undergoing Cyber Essentials Plus technical assessment may have their email configuration reviewed. Treating SPF, DKIM, and DMARC as part of your certification preparation is strongly advisable.

How can I check if my email is properly configured?

DNS records are publicly queryable, so the presence of SPF, DKIM, and DMARC records for any domain can be checked using freely available tools. However, a raw lookup only tells you what records exist, not whether they are correct, complete, or effective. Conosco's free Email Domain Security (EDS) report checks SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT, and returns a contextualised assessment reviewed by a specialist. It does not require access to your systems, mail server, or Microsoft 365 tenant. The report is the starting point for understanding whether your domain is properly protected.