A finance director receives an email that appears to come from their own chief executive. The domain in the sender address is genuine, authentication passes, and the message asks for an urgent payment. In that scenario, does DMARC stop phishing? No. DMARC can prevent a criminal from impersonating a protected domain in many circumstances, but it cannot determine whether a legitimate mailbox has been compromised or whether a message is socially engineered.

That distinction matters when assessing phishing risk across a Microsoft 365 estate. DMARC is a valuable email authentication control and an essential part of domain protection. It is not a complete phishing defence programme. Organisations that treat it as one can be left with a material gap between blocking obvious impersonation and handling the messages that reach employees' inboxes.

Does DMARC stop phishing attacks?

DMARC stops a specific category of phishing: messages sent from unauthorised infrastructure that claim to be from a domain protected by a correctly configured DMARC policy. It builds on SPF and DKIM, then checks whether either authentication method aligns with the visible domain shown in the From field.

If an attacker sends a message claiming to be from `yourorganisation.co.uk`, but cannot pass aligned SPF or DKIM for that domain, a receiving email service can follow the published DMARC policy. With a policy of `p=reject`, the receiving service should reject the message. With `p=quarantine`, it should treat the email as suspicious, commonly placing it in junk. A `p=none` policy gathers reporting data but does not request enforcement.

For brand impersonation and direct domain spoofing, this is highly effective. It reduces the ability of criminals to use an organisation's trusted domain to target suppliers, customers and employees. It also improves visibility of authorised and unauthorised sending services through DMARC reporting.

However, phishing is an attack technique, not a single technical condition. Attackers adapt quickly when one route is closed.

What DMARC cannot prevent

DMARC does not inspect the intent of an email or judge the credibility of every business request. It validates domain authentication and alignment. That leaves several common attack paths outside its scope.

Compromised legitimate accounts

When an attacker gains access to a real Microsoft 365 mailbox, messages sent from that account can pass normal authentication checks. They may also sit naturally within an existing email thread, use the sender's normal signature and exploit information available in the mailbox.

Business email compromise frequently works this way. A DMARC policy cannot stop a fraudulent invoice request sent from a trusted supplier's compromised account, nor can it reverse the damage after a user has shared credentials or approved a payment.

Lookalike and newly registered domains

An attacker does not need to spoof `supplier.co.uk` if they can register `suppIier.co.uk`, substituting a visually similar character, or choose a plausible domain such as `supplier-payments.co.uk`. Their domain can have valid SPF, DKIM and DMARC records. Authentication will confirm that the sender controls that domain, not that the domain is the supplier your employee intended to deal with.

This is why security teams should distinguish between authentication and identity assurance. DMARC proves an email is authorised for a domain. It does not prove that domain is trustworthy.

Display-name impersonation and social engineering

Many phishing emails rely on a familiar display name while using an unrelated sender address. Others use believable language to persuade a recipient to scan a QR code, open a cloud-sharing link, call a fake helpdesk number or bypass a payment approval process.

These messages may not fail DMARC at all. The control has no reliable way to identify an unusual request made in a normal-looking conversation. Context, user reporting and analyst investigation remain necessary.

Malicious content from legitimate services

Phishing campaigns regularly use trusted platforms for file hosting, electronic signatures, collaboration invitations and marketing delivery. A message may authenticate correctly while directing the user to a credential-harvesting page hosted outside the organisation's environment. Security controls need to assess URLs, attachments, sender behaviour and reported messages, rather than rely on authentication results alone.

Why DMARC policy configuration matters

A DMARC record set to monitoring mode is not the same as a domain protected from spoofing. Many organisations begin with `p=none` to identify all legitimate sending sources, which is sensible. The problem arises when monitoring continues indefinitely and unauthenticated messages remain actionable for recipients.

Moving to enforcement requires careful work. Marketing platforms, customer relationship systems, ticketing tools, payroll providers and third-party mail services may all send on behalf of the organisation. Each needs correctly configured SPF or DKIM with domain alignment. Rushing to `p=reject` without this review can affect legitimate communications; never enforcing leaves the primary benefit unrealised.

A practical progression is to establish visibility, correct authorised senders, apply quarantine, then move appropriate domains to reject. Subdomains and inactive domains also need attention. Criminals often select neglected domains because recipients may recognise the organisation but administrators may not be monitoring their use.

DMARC should be applied to domains an organisation owns, including domains used for customer, partner and employee communications. It does not control the domains that attackers register or the legitimate third-party domains that later become compromised.

Pair authentication with an operational phishing defence

The most effective approach treats DMARC as a preventative layer within a wider phishing security lifecycle. Microsoft 365 protection, secure email controls and domain authentication should reduce the volume of malicious mail reaching users. But some messages will evade automated detection, particularly targeted attacks that use valid accounts and carefully prepared social engineering.

Employees need a simple, trusted method of reporting suspicious emails from Outlook. The objective is not to make every employee a security analyst. It is to capture signals quickly, before a single targeted message becomes a wider incident.

Those reports then need phishing triage. Security teams require a repeatable process to establish whether a message is malicious, identify affected users, understand the delivery route and assess whether credentials, payments or sensitive information may be at risk. A generic shared mailbox is rarely sufficient when report volumes rise or when time-critical investigations compete with other SOC work.

Remediation is the next control that DMARC cannot provide. If a malicious message has reached several inboxes, analysts need to locate related messages and remove them quickly. Where an employee has interacted with a link or attachment, the response may extend to account investigation, session revocation, password reset, endpoint checks and financial fraud procedures.

Real incident data should also improve defences. If users report repeated lookalike domains, security teams can tune controls, block indicators and brief the appropriate teams. If a supplier compromise creates a convincing invoice fraud attempt, finance verification processes may need strengthening. This is human risk management in practice: using observed behaviour and threats to reduce future exposure.

How to assess whether your DMARC programme is enough

For a UK organisation with formal security and compliance responsibilities, the useful question is not simply whether DMARC is present. It is whether the organisation can demonstrate effective protection against the phishing routes DMARC does not cover.

Review the DMARC policy and alignment status for every material domain, including whether enforcement is active. Then examine the operational evidence: how easily users report messages, how long triage takes, whether security teams can remediate delivered emails at scale, and how findings feed into awareness activity and technical controls.

Simulation-based training has a role here, provided it reflects relevant attack patterns and supports measurable improvement rather than becoming a compliance exercise. Employees should understand how to recognise unexpected requests, verify payment changes and report concerns without fear of making a mistake. Reporting early is often more valuable than trying to reach certainty alone.

For organisations using Microsoft 365, the integration between employee reporting, phishing analysis and inbox remediation deserves particular scrutiny. Controls that operate as disconnected tools can create delays precisely when attackers are trying to exploit urgency and confusion.

Wise Fish supports this operational model through specialist phishing protection, Cofense-enabled reporting and triage, and practical remediation workflows for UK organisations. The goal is not to replace technical email authentication, but to ensure a DMARC investment sits within a response capability that addresses the attacks authentication cannot see.

DMARC should be regarded as a necessary control for stopping unauthorised use of your domains, not as a promise that phishing has been solved. The stronger test is whether a convincing, authenticated malicious email can be reported, investigated and removed before it becomes fraud, account compromise or service disruption.