Does Having a DMARC Record Mean Your Domain Is Protected?

When someone checks a domain and sees that a DMARC record exists, it can be easy to assume that the domain is protected.

That is not always the case.

DMARC is not just a yes-or-no setting. The policy matters, the sending services matter, and the way SPF or DKIM aligns with the visible From address matters.

A DMARC record using p=none can be useful because it allows reports to be collected. However, it normally tells receiving mail systems not to change how they handle messages because of the DMARC policy.

Stronger policies such as p=quarantine and p=reject ask receiving systems to take action when messages fail DMARC. Those policies can help reduce direct spoofing, but they should normally be introduced only after legitimate sending services have been reviewed.

The useful question is therefore not only:

Do we have a DMARC record?

The better question is:

What is the DMARC record asking receiving mail systems to do?

This guide explains the difference between monitoring and enforcement, why SPF or DKIM passing is not always enough, and what should normally be reviewed before a domain moves to a stricter DMARC policy.

Use the links below to jump to the section most relevant to your question.

• The common misunderstanding
• What p=none actually means
• Why monitoring still matters
• Why enforcement cannot simply be copied
• Why SPF or DKIM passing may not be enough
• How to move towards enforcement safely
• What DMARC does not protect against
• How this fits into layered security
• Related guides
• When to seek help
• Further Guidance and Support

Many people check a domain and see that DMARC exists.

That can create the impression that the domain is protected.

However, a DMARC record can exist in different states. Some records are mainly used for monitoring. Others ask receiving mail systems to treat failing messages with caution or reject them.

This means a domain can be:

• technically configured with DMARC;
• collecting useful reports;
• still not asking receivers to block or quarantine failing messages.

That is why the policy value matters.

A DMARC record should be read alongside SPF, DKIM and the real list of services that send email for the domain. A technically valid record can still be unsuitable if it does not match the real email environment.

For example, a small organisation may use Microsoft 365 for normal email, a website form for enquiries, an invoicing platform for payment reminders and a marketing system for newsletters. Each system may send email in a different way.

A checker may show that DMARC exists, but that does not by itself confirm that every legitimate sender is aligned or that failing messages are being rejected.

The main DMARC policy is controlled by the p value.

A record such as:

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com

means the domain has a DMARC policy and can collect aggregate reports.

That is useful during discovery because the domain owner can start to understand which systems are sending email using the domain.

However, p=none is monitoring only. Messages that fail DMARC are not rejected because of the DMARC policy.

In plain English:

p=none helps you see what is happening.
It does not normally ask receivers to stop failing messages.

This can be a sensible starting point, especially where a domain has never been reviewed before or where several services send email on behalf of the organisation.

It should not be confused with enforcement.

If a domain remains permanently at p=none, it may look configured, but it is normally still asking receiving systems to report rather than act.

Monitoring is not wasted effort.

Before a domain moves to a stronger policy, the organisation needs to understand what sends email using the domain.

For example, a small business or charity may send email through:

• • Microsoft 365 or Google Workspace;
  • website contact forms;
  • invoicing systems;
  • booking platforms;
  • CRM systems;
  • helpdesk systems;
  • marketing tools;
  • suppliers or third-party services.

Each of these may need to be checked before the domain moves to a stricter DMARC policy.

If a legitimate sender is missed, genuine email may fail DMARC after enforcement is applied. That could affect contact forms, invoices, booking confirmations, ticket updates or marketing messages.

Monitoring helps identify the legitimate sending sources first.

It can also show whether unknown systems are trying to use the domain. That information can help the organisation decide whether the current record is enough, whether senders need to be corrected, and whether a stronger policy can be introduced safely.

The aim is not simply to publish a strict-looking DNS record. The aim is to make sure the policy matches how the domain is actually used.

It may be tempting to copy a strict-looking DMARC record from a generator, a blog post or another organisation.

That can be risky.

A record using p=reject, sp=reject, strict SPF alignment and strict DKIM alignment may be suitable for a dedicated sending domain where all legitimate sending services have already been reviewed.

It may not be suitable for a main business domain used by several systems.

For example, the same domain may be used for:

• normal staff email;
• website forms;
• invoice reminders;
• booking confirmations;
• CRM messages;
• marketing emails;
• supplier-managed services.

A strict policy is useful only when it matches the real email environment.

If a domain moves too quickly to p=reject, legitimate email may be disrupted. If a domain stays indefinitely at p=none, it may remain easier to impersonate directly.

The practical work is to close the gap between visibility and enforcement safely.

That means identifying senders, checking SPF and DKIM, correcting alignment issues, and then deciding whether p=quarantine or p=reject is appropriate.

DMARC does not only ask whether SPF or DKIM passed somewhere.

It asks whether the passing result aligns with the domain shown in the visible From address.

That is the part that often causes confusion.

A recipient may see:

accounts@example.com

But the technical sending path may use a different domain.

For example, a third-party platform might use:

bounce.thirdpartyplatform.example

Or it might sign the message using:

thirdpartyplatform.com

Those technical values may be valid for the sending platform, but they may not align with the domain the recipient can see.

If neither SPF nor DKIM produces an aligned pass, DMARC fails.

This is why SPF passing somewhere is not always enough, and DKIM passing somewhere is not always enough. DMARC needs at least one passing result to align with the visible From domain.

This becomes particularly important where a business uses marketing tools, CRM systems, booking platforms, helpdesk systems or website forms. Those services may send email that appears to come from the organisation, but they may need custom DKIM, sender configuration or return-path changes before DMARC alignment works properly.

The visible From address is the identity DMARC is trying to protect.

A stronger DMARC policy should normally be introduced in stages.

The aim is not to move to p=reject as quickly as possible regardless of risk. The aim is to move towards enforcement when the organisation understands who sends email for the domain and can confirm that legitimate messages are passing SPF or DKIM with alignment.

A practical sequence is:

1. 1. Confirm SPF and DKIM are configured for the main email provider.
   2. Identify all systems that send email using the domain or its subdomains.
   3. Publish or review a DMARC monitoring policy using p=none and aggregate reporting.
   4. Review reports to identify legitimate and unknown sources.
   5. Correct SPF, DKIM and alignment issues for legitimate senders.
   6. Consider p=quarantine when reports show normal mail is passing.
   7. Move to p=reject only when the organisation is confident that legitimate senders are aligned.
   8. Review the record periodically because email platforms, DNS providers and business systems change.

Dedicated sending subdomains are often easier to secure than a main business domain.

For example, if mail.example.com is used only by one marketing platform, it may be easier to configure strict authentication and a stronger policy for that subdomain once testing is complete.

Main domains used for normal person-to-person email usually need more care. Forwarding, aliases, website forms and third-party platforms can all affect authentication results.

This is why DMARC should be treated as part of an email security review rather than a single DNS value to copy.

DMARC is useful, but it is not complete email security.

It helps reduce unauthorised use of a domain in the visible From address, but it does not stop every email-based attack.

DMARC does not stop attackers using:

• • lookalike domains;
  • compromised real accounts;
  • free email addresses;
  • display-name tricks;
  • malicious links;
  • unsafe attachments.

It also does not prove that an email is safe.

A message can pass SPF, DKIM and DMARC and still contain a harmful link, a malicious attachment or a fraudulent request if it was sent from a compromised legitimate system.

DMARC also does not replace mailbox protection. Spam filtering, anti-malware scanning, safe links, safe attachments, user reporting and account protection still matter.

It does not replace multi-factor authentication, conditional access, strong passwords, device protection or careful administration.

It also does not replace backup and recovery planning. If a mailbox or business system is compromised, the organisation may still need to recover data, review access and restore normal operation.

The practical view is that DMARC reduces one important risk. It should sit within wider email security and layered protection, not replace them.

A DMARC record is one part of email security.

It works with SPF and DKIM to help receiving systems decide whether a message is authorised to use a domain.

MTA-STS deals with a different issue: protecting mail transport between mail servers where supported.

Mailbox protection, user awareness, account security, backup and recovery planning then address other risks that DMARC does not solve.

This matters for small organisations because email problems are rarely isolated from the wider working environment. A domain may be used by Microsoft 365, Google Workspace, a website, a CRM, a booking system, an invoicing system and suppliers.

Security is also not a single product or setting. It normally depends on several layers working together: reducing exposure, checking identity, protecting devices, filtering harmful content, monitoring unusual behaviour, and being able to recover if something goes wrong.

This guide is not a permanent checklist. Technology changes, suppliers change, email platforms change, and attackers adapt their methods.

The practical message is that email validation should be reviewed periodically as part of wider security and continuity planning.

The guides below provide related background and more detailed explanations. They are useful where the issue involves email authentication, wider security controls, or recovery planning.

• • Email validation and security explained
    A broader guide to SPF, DKIM, DMARC and MTA-STS.
  • How to read a DMARC record and choose the right policy
    A more detailed guide to DMARC record values, alignment settings, reports and safe policy changes.
  • What is layered security and why does it matter?
    A wider explanation of why one control should not be treated as the whole security plan.
  • How do cyber attacks usually start in small businesses?
    A plain-English guide to common starting points for cyber attacks.
  • Cloud Storage vs Backup. Why Sync Is Not Backup
    A guide explaining why backup and recovery planning remain important even when cloud services are used.

It may be worth seeking help if the domain has a DMARC record but you are not sure whether it is monitoring or enforcing.

It may also be worth reviewing the setup if Microsoft 365 or Google Workspace is used alongside website forms, CRMs, marketing tools, booking platforms, invoicing systems or helpdesk platforms.

Typical situations include:

• • the domain has stayed at p=none for a long time;
  • you want to move towards p=quarantine or p=reject;
  • reports show SPF, DKIM or alignment failures;
  • legitimate messages are going to junk or being rejected;
  • third-party suppliers send email using your domain;
  • you are not sure which services send email on behalf of the organisation;
  • a checker reports DMARC but the policy does not appear to be enforced.

If your domain has a DMARC record but you are not sure whether it is only monitoring or actually enforcing a policy, the next step is to review the record alongside the services that send email for the domain.

The review should normally consider the DNS records, the mail provider, third-party senders, SPF, DKIM, DMARC alignment, reporting evidence and the risk of disrupting legitimate email.

Evening Computing helps small organisations, professionals and charities understand practical IT and security issues in plain language.

A guide can explain the principles, but DMARC decisions should be based on the real email environment, the services sending mail, DNS records, SPF and DKIM alignment, and the organisation’s tolerance for delivery risk.

If you would like help reviewing email validation, DNS records or wider security arrangements, please get in touch and tell us which domain, mail provider and sending services are involved.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
15 July 2026