Most businesses take email security seriously. They filter malicious links and attachments, apply anti-phishing policies, protect user accounts with multifactor authentication and train employees to recognise suspicious messages.
That is all important. But it addresses only part of the problem.
An attacker doesn’t always need to compromise your Microsoft 365 tenant or gain access to an employee’s mailbox. In some cases, the attacker can simply send a message that appears to come from your business’s domain. To the recipient, the message may look like a genuine invoice, payment instruction, password reset or senior management request.
Your email platform may be well protected, while your domain can still be impersonated.
Why is Domain Impersonation Possible?
Email was designed to move messages between systems. It wasn’t originally designed to guarantee that the person shown in the From field really sent the message.
That creates an important distinction between two types of email security:
- Inbound email security helps detect and block malicious messages sent to your users.
- Domain authentication helps prevent attackers from sending messages that falsely claim to come from you.
DMARC sits in the second category. It helps the owner of a domain define how receiving mail systems should handle messages that claim to come from that domain but cannot be authenticated correctly.
So What Exactly is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on two existing email-authentication standards: SPF and DKIM.
|
SPF Identifies the systems authorised to send email for a domain. |
DKIM Uses a cryptographic signature to help verify that a message is authentic and has not been altered. |
DMARC Checks alignment, provides reporting and tells receiving systems what to do when authentication fails. |
The important part is that DMARC adds both policy and visibility. It allows a domain owner to receive reports about the systems sending email on its behalf and to tell participating receiving systems how to treat messages that fail the required checks.
SPF and DKIM provide evidence. DMARC turns that evidence into a decision.
Having a DMARC Record Does Not Necessarily Mean You Are Protected
A common mistake is to check that a DMARC record exists and assume the job is finished. The policy linked to your DMARC record really matters.
p=none |
p=quarantine |
p=reject |
|
The domain receives monitoring information, but the policy does not ask receiving systems to quarantine or reject failing messages. This is where businesses typically start when deploying DMARC. |
Messages that fail DMARC can be treated as suspicious and may be directed to spam or quarantine. Enforcement has begun, but the messages are not necessarily rejected. |
Receiving systems are instructed to reject messages that fail DMARC. When this is correctly implemented, it is the strongest protection against exact-domain impersonation. |
The better question is not simply “Do we have DMARC?” It is “What policy are we enforcing, across which domains, and do we understand every legitimate sender?”
Why Not Just Switch DMARC to Reject?
Because businesses rarely send email from only one system.
Alongside Microsoft 365, legitimate email may be sent by marketing platforms, CRM systems, finance applications, service desks, HR platforms, websites and specialist cloud services. Each source needs to be identified and correctly authenticated.
Moving directly to rejection without understanding those senders can block genuine business email. Remaining indefinitely in monitoring mode creates the opposite problem: the business collects information but does not reach the policy that provides the strongest protection.
The Implementation Challenge
The aim is to identify legitimate senders, fix authentication problems, and move toward enforcement without disrupting genuine mail flow.
This Is Not a Theoretical Issue
A recent review examined the publicly available email-authentication posture of 50 UK-based businesses across various industries. No names or domains are included here; the purpose of the exercise was to understand the overall pattern.
30 of 50 had not reached full DMARC enforcement
21 of 50 had no DMARC record or were operating at p=none
26 of 50 had an identified SPF issue
The important point is not that every business was in the same position. They were spread across four different stages: no DMARC record, monitoring only, quarantine and reject. That is why DMARC is better understood as a managed journey towards enforcement than as a one-off DNS change.
Why DMARC Matters Beyond Your Own Inbox
Protecting Customers, Suppliers and Partners
If an attacker impersonates your domain to target somebody else, the fraudulent message carries your business’s name. Even though your own systems may not have been breached, customers and suppliers may associate the incident with your brand. DMARC helps reduce the opportunity for exact-domain impersonation to be used against the people who trust you.
Supporting Reliable Delivery
Correctly authenticated email gives receiving platforms clearer evidence that legitimate messages really come from an authorised source. Poorly maintained SPF, DKIM or DMARC configurations can contribute to authentication failures and make delivery harder to diagnose.
Meeting Changing Sender Expectations
Major mailbox providers have introduced authentication requirements for bulk senders. DMARC should therefore be considered not only as a security control, but also as part of maintaining trustworthy and supportable email delivery.
What Does Good Look Like?
- Discover: Identify every owned domain and every service legitimately sending email on the business’s behalf.
- Authenticate: Configure and validate SPF and DKIM for authorised sending sources.
- Monitor: Use DMARC reporting to understand genuine and unauthorised traffic, then resolve legitimate failures.
- Enforce: Progress deliberately from monitoring towards quarantine and reject, based on evidence rather than guesswork.
- Maintain: Review the position as applications, suppliers, domains and sending services change.
DMARC is not something to configure once and forget. New applications and suppliers can introduce new sending sources. Domains can be registered, retired or left unused. Authentication therefore needs an owner and an ongoing operating process.
How Do You Know Where You Stand?
A useful first step is to review the public email-authentication configuration for your domains. This can establish whether DMARC is present, what policy is published and whether obvious SPF or configuration issues exist.
That initial view will not answer every question. Public DNS cannot, by itself, confirm that every legitimate sender is known or correctly aligned. But it can quickly show whether a business has no DMARC record, remains in monitoring mode or has progressed to enforcement.
What Does Node4 Recommend?
Do not assume that protecting Microsoft 365 means nobody can impersonate your domain. Treat inbound email security and domain authentication as related but distinct controls.
Review all domains, understand which services send email on your behalf and confirm the policy currently being enforced. If a domain is at p=none, that does not mean the work has failed. It means the business has visibility but still needs a controlled plan for reaching enforcement.
Start With Evidence
Node4 can assess your publicly visible email-authentication posture, help identify gaps across DMARC, SPF and DKIM, and define the work required to progress safely towards enforcement.
Because the important question is not whether a DMARC record exists. It is whether your domains are understood, your legitimate senders are authenticated, and unauthorised messages are being prevented from trading on your name.
.png?noresize)
