Could someone send an email pretending to be your business?
Your business probably sends email from more places than you realise.
Microsoft 365 or Google Workspace may handle everyday communication, but invoices, marketing campaigns, support tickets, recruitment messages and password resets could all come from different systems.
To the recipient, they appear to come from the same company domain.
But how does their email provider know which messages are genuine? More importantly, what happens when somebody else tries to send email using your domain?
That is where DMARC comes in.
Some organisations still have no DMARC record. Others have published one but left it set to p=none, where it provides useful information without asking receiving mail servers to block anything.
These are different positions, but neither gives you an enforced DMARC policy.
What does DMARC actually do?
DMARC helps receiving email providers determine whether a message claiming to come from your domain is genuine.
It works with two existing authentication methods:
- SPF helps confirm whether the sending system is authorised.
- DKIM adds a digital signature that can be checked by the recipient’s email provider.
DMARC checks whether at least one of these passes and aligns with the domain shown in the From address. If the message fails, your published policy indicates what you would like the receiving provider to do with it.
Without DMARC, you have not published that policy. You are also missing the reporting that can reveal which services are using your domain and whether their messages are authenticating correctly.
Having DMARC does not always mean you are protected
There are three main DMARC policies:
p=nonecollects information but does not request action against failed messages.p=quarantineasks receiving systems to treat failed messages as suspicious.p=rejectasks receiving systems to reject failed messages.
A policy of p=none is often called monitoring mode. It is a sensible place to begin because it lets you understand your email traffic without immediately disrupting genuine messages.
The problem is when it becomes the permanent destination.
If a fraudulent message fails DMARC while your policy remains at p=none, the receiving server is not being asked to quarantine or reject it.
Visibility is valuable. It is not the same as enforcement.
A record can exist without working properly
Looking up your DNS records can tell you whether SPF, DKIM and DMARC have been published. It cannot always tell you how an email from a particular service behaves when it is actually sent.
A real message may reveal that:
- The sending service is not applying a valid DKIM signature.
- SPF or DKIM is not aligned with the visible From address.
- The SPF record has exceeded its permitted lookup limit.
- The sending server has incomplete forward or reverse DNS.
- Encryption is not being negotiated correctly during delivery.
- The message would fail your current DMARC policy.
This is why checking that a record exists is not enough. You also need to know whether it works when a genuine email leaves your infrastructure.
Why not move straight to p=reject?
Because genuine email can fail too.
Your everyday business email might be configured correctly while a payroll provider, marketing platform or invoicing system is not. Moving directly to p=reject could result in legitimate messages being blocked.
Before enforcing DMARC, you need to identify every approved service sending email on your behalf and check that it is authenticating correctly.
DMARC reporting can uncover forgotten systems, configuration errors, old platforms and services introduced without IT involvement. Once those senders are understood and any problems have been corrected, the policy can be strengthened gradually.
The aim is not to reach p=reject as quickly as possible. It is to reach it without disrupting legitimate business communication.
It is not a one-off task
Email environments change.
New suppliers are added, platforms are replaced and marketing or finance teams introduce new services. Domains and subdomains can also be left behind after a project ends or an application is retired.
A DMARC policy that works today may not remain healthy without oversight.
Good DMARC management means:
- Maintaining visibility across active domains and subdomains.
- Monitoring authentication results.
- Reviewing newly identified sending sources.
- Correcting SPF and DKIM alignment problems.
- Controlling who can send email on the organisation’s behalf.
- Working progressively towards an enforced policy.
This supports both security and deliverability. Google, Yahoo and Microsoft now treat email authentication as a basic requirement for organisations sending messages at scale.
What DMARC cannot do
DMARC helps protect your exact domain from unauthorised use. It cannot prevent someone registering a similar-looking domain and using that instead.
For example, DMARC may protect:
yourcompany.co.uk
It cannot stop an attacker registering:
your-company-support.co.uk
Those lookalike domains require separate monitoring and action. DMARC is an important part of email security, but it is not a complete answer to every form of impersonation or phishing.
Find out how your email is performing
ITB can provide a free email authentication report using a real test message from one of your sending services.
The report checks whether DMARC, SPF and DKIM are working in practice, alongside related checks covering TLS, MTA-STS, BIMI and forward-confirmed reverse DNS.
It gives you a clear starting point: what is working, what is missing and where further investigation may be needed.
If you would like us to arrange a report for your domain, email [email protected] or speak to your usual ITB contact.