DMARC: Everything You Need to Know

Email remains one of the most important communication tools used by businesses.

It is also one of the most frequently impersonated.

Cybercriminals may send messages that appear to come from your company, directors, finance department or employees. These messages can be used to steal passwords, redirect payments, spread malware or persuade customers and suppliers to disclose confidential information.

DMARC helps protect your domain from this type of email impersonation.

It allows your organisation to tell receiving email providers how messages using your domain should be authenticated and what should happen when those checks fail.

However, DMARC is not simply a setting that should be switched on without preparation.

Your business must understand every legitimate system sending email from its domain, configure SPF and DKIM correctly, review authentication reports and gradually move towards an enforcement policy.

What Does DMARC Stand For?

DMARC stands for:

**Domain-Based Message Authentication, Reporting and Conformance.**

It is an email authentication standard that helps domain owners protect the domain shown in the visible From address of an email.

DMARC allows the owner of a domain to:

* Check whether messages using its domain are properly authenticated
* Tell receiving email systems how failed messages should be treated
* Receive reports showing who is sending email using the domain
* Identify legitimate services that are incorrectly configured
* Detect possible domain impersonation
* Reduce the effectiveness of certain phishing attacks

The current IETF DMARC specification is RFC 9989, published in May 2026. It replaced the original 2015 specification, RFC 7489, while aggregate and message-specific reporting are now covered separately by RFC 9990 and RFC 9991.

Why Is DMARC Important?

Without DMARC enforcement, criminals may be able to send an email that places your company’s domain in the visible From address.

The email may appear to come from:

* Your managing director
* Your finance department
* An employee
* A shared mailbox
* Your customer service team
* Your accounts department
* Your website
* A trusted business address

The attacker does not necessarily need access to your Microsoft 365 account to attempt this type of impersonation.

They may simply configure their own email system to claim that the message came from your domain.

A receiving email provider then needs to decide whether the message is genuine.

DMARC gives receiving providers more information to make that decision.

What Type of Attack Does DMARC Help Prevent?

DMARC is primarily designed to protect against direct domain spoofing.

This is where an attacker uses your actual domain in the visible From address.

For example, a criminal may send an email that appears to come from:

`accounts@yourbusiness.co.uk`

The message may ask a customer to pay an invoice into a different bank account.

If the message fails DMARC and your domain has a reject policy, the receiving provider can reject it before it reaches the customer.

DMARC can therefore help reduce the risk of:

* Business email compromise
* Payment diversion fraud
* Supplier impersonation
* Executive impersonation
* Phishing
* Fake password-reset messages
* Fraudulent invoices
* Malicious attachments
* Customer-targeted scams

DMARC is an important layer of email security, but it does not prevent every type of impersonation.

What DMARC Does Not Prevent

DMARC protects the authorised use of your domain.

It does not automatically prevent criminals from registering a similar-looking domain.

For example, if your domain were:

`hamiltongroup.co.uk`

An attacker might register something similar, such as:

`hamilton-group.co.uk`

or replace a letter with a similar-looking character.

DMARC on your genuine domain would not control the attacker’s separate domain.

DMARC also does not prevent:

* Display-name impersonation
* Lookalike domain attacks
* Messages sent from compromised genuine accounts
* Phishing sent from another legitimate domain
* Malware delivered through a trusted third party
* Employees clicking malicious links
* Fraud conducted through telephone calls or messaging platforms

This is why DMARC should form part of a wider email security strategy that includes anti-phishing protection, multi-factor authentication, employee awareness training and account monitoring.

How Does DMARC Work?

DMARC builds on two existing email authentication technologies:

* SPF
* DKIM

When an email arrives, the receiving provider checks whether SPF or DKIM has authenticated the message.

DMARC then checks whether the authenticated domain aligns with the domain displayed in the From address.

A message passes DMARC when at least one of the following is true:

* SPF passes and the SPF-authenticated domain aligns with the From domain
* DKIM passes and the DKIM signing domain aligns with the From domain

The message does not need to pass through both methods to pass DMARC.

However, configuring both SPF and DKIM correctly provides greater resilience.

What Is SPF?

SPF stands for Sender Policy Framework.

It uses a DNS record to identify the systems that are authorised to send email on behalf of a domain.

An SPF record might authorise:

* Microsoft 365
* A website server
* A marketing platform
* A customer relationship management system
* An invoicing platform
* A helpdesk
* A cloud application
* A specialist industry platform

When an email is received, the destination provider checks whether the sending server is authorised by the SPF record.

However, SPF alone does not fully protect the address that employees and customers see.

SPF normally checks the envelope sender or Return-Path address, which may be different from the visible From address.

DMARC adds the alignment requirement that connects SPF authentication to the visible sender domain.

What Is DKIM?

DKIM stands for DomainKeys Identified Mail.

It uses cryptographic signing to help confirm that an email was authorised by a particular domain and that important parts of the message were not altered after signing.

The sending service adds a DKIM signature to the email.

The receiving provider then retrieves the relevant public key from DNS and uses it to verify the signature.

A DKIM signature contains a signing domain, commonly shown as the `d=` value.

For DKIM to pass DMARC, this signing domain must align with the domain in the visible From address.

For example:

* Visible From domain: `yourbusiness.co.uk`
* DKIM signing domain: `yourbusiness.co.uk`
* Result: aligned

If a third-party marketing platform signs the message using its own unrelated domain, DKIM may technically pass but still fail DMARC alignment.

What Does DMARC Alignment Mean?

Alignment is one of the most important parts of DMARC.

It is possible for SPF or DKIM to pass individually while DMARC still fails.

This happens when the authenticated domain does not match or relate correctly to the domain in the visible From address.

For example:

* Visible From domain: `yourbusiness.co.uk`
* SPF-authenticated domain: `marketingplatform.example`
* DKIM signing domain: `marketingplatform.example`

SPF and DKIM may confirm that the marketing platform authorised the message.

However, neither result proves that the platform was authorised to use `yourbusiness.co.uk` in the visible From address.

DMARC therefore fails.

The current DMARC standard supports relaxed and strict alignment. Relaxed alignment allows related subdomains sharing the same organisational domain, while strict alignment requires the domains to be identical. The standard notes that relaxed alignment is sufficient for nearly all domain owners.

Relaxed Alignment

Relaxed alignment is the default.

With relaxed alignment, the organisational domains must match.

For example:

* Visible From domain: `yourbusiness.co.uk`
* DKIM signing domain: `mail.yourbusiness.co.uk`

These may align under relaxed mode because they share the same organisational domain.

Relaxed alignment is normally appropriate for most businesses because it allows legitimate subdomain-based email services to operate more easily.

Strict Alignment

Strict alignment requires an exact domain match.

For example:

* Visible From domain: `yourbusiness.co.uk`
* DKIM signing domain: `mail.yourbusiness.co.uk`

This would not align under strict mode because the domains are not identical.

Strict alignment can provide tighter control, but it may also create problems for legitimate email systems if it is introduced without careful planning.

What Is a DMARC Record?

A DMARC policy is published as a TXT record in your domain’s DNS.

For a domain such as:

`yourbusiness.co.uk`

The record is normally published at:

`_dmarc.yourbusiness.co.uk`

A basic monitoring record might look like this:

`v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.co.uk`

This tells receiving providers:

* The record uses DMARC version 1
* The current policy is monitoring only
* Aggregate reports should be sent to the specified address

DMARC should normally begin in monitoring mode while the organisation identifies all legitimate email sources.

What Are the Three DMARC Policies?

DMARC has three main policy options:

* None
* Quarantine
* Reject

Each policy tells receiving providers how the domain owner would prefer failed messages to be treated.

The receiving provider ultimately controls delivery, but the published DMARC policy is an important instruction.

DMARC Policy: None

A policy of:

`p=none`

means the domain is in monitoring mode.

Receiving providers are not being asked to quarantine or reject messages purely because they fail DMARC.

The purpose is to collect reports and understand how the domain is being used.

A monitoring record may look like this:

`v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.co.uk`

This is normally the safest starting point for an active business domain.

It allows the organisation to identify:

* Microsoft 365 email
* Website messages
* Marketing platforms
* Invoicing systems
* Customer relationship management platforms
* Helpdesk systems
* Scanners and multifunction devices
* Unapproved sending services
* Possible domain abuse

The current DMARC specification recommends beginning with `p=none` and aggregate reporting so that overlooked systems and third-party senders can be identified before enforcement begins.

However, `p=none` does not provide full enforcement.

It gathers information, but it does not ask providers to block spoofed messages.

DMARC Policy: Quarantine

A policy of:

`p=quarantine`

asks receiving providers to treat failed messages as suspicious.

Depending on the provider, the message may be:

* Sent to the Junk Email folder
* Placed in quarantine
* Marked as suspicious
* Given additional spam filtering
* Delivered with a warning

An example record might be:

`v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.co.uk`

Quarantine can be used as an intermediate stage between monitoring and full rejection.

However, legitimate senders should already be properly aligned before the policy is changed.

DMARC Policy: Reject

A policy of:

`p=reject`

asks receiving providers to reject messages that fail DMARC.

An example record might be:

`v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourbusiness.co.uk`

This provides the strongest protection against direct spoofing of your domain.

The objective for most established business domains should normally be to reach an enforcement policy once legitimate email sources have been reviewed and corrected.

Microsoft recommends a gradual rollout, beginning with monitoring and ultimately working towards `p=reject` across active custom domains and subdomains.

Moving directly to reject without preparation could cause genuine messages to be blocked.

What Are DMARC Aggregate Reports?

Aggregate reports provide information about messages that have used your domain.

They are normally sent to the address specified by the `rua` tag.

For example:

`rua=mailto:dmarc-reports@yourbusiness.co.uk`

Aggregate reports may show:

* Which systems sent email using your domain
* The IP addresses of sending services
* How many messages were observed
* Whether SPF passed
* Whether DKIM passed
* Whether DMARC passed
* Which policy was applied
* Whether domains were aligned

These reports are usually supplied as XML files.

Although they contain valuable information, they can be difficult to read manually.

A DMARC monitoring platform can convert the XML data into a clearer dashboard.

The organisation can then identify legitimate services, configuration problems and possible unauthorised senders.

What Are DMARC Failure Reports?

Failure reports, sometimes called forensic reports, relate to individual messages that fail DMARC.

They are requested using the `ruf` tag.

For example:

`ruf=mailto:dmarc-failures@yourbusiness.co.uk`

However, not every receiving provider sends these reports.

They may also contain message headers or potentially message content and personal information. The current failure-reporting standard specifically warns organisations to consider the privacy implications before requesting, creating or processing these reports.

Microsoft 365 sends aggregate reports in supported circumstances but does not send DMARC forensic reports, even when a `ruf` address is present.

For many businesses, aggregate reporting provides the most useful and consistent source of DMARC information.

What Do the Main DMARC Tags Mean?

A DMARC record can contain several tags.

Common tags include:

### `v`

Identifies the DMARC version.

The value should be:

`v=DMARC1`

 `p`

Specifies the policy for the domain.

Possible values are:

* `none`
* `quarantine`
* `reject`

`rua`

Specifies where aggregate reports should be sent.

For example:

`rua=mailto:dmarc-reports@yourbusiness.co.uk`

`ruf`

Requests message-specific failure reports.

For example:

`ruf=mailto:dmarc-failures@yourbusiness.co.uk`

Not all providers supply these reports.

`adkim`

Controls DKIM alignment.

The usual values are:

* `r` for relaxed
* `s` for strict

Relaxed is the default.

`aspf`

Controls SPF alignment.

The usual values are:

* `r` for relaxed
* `s` for strict

Relaxed is the default.

`sp`

Specifies a separate policy for existing subdomains.

For example:

`sp=reject`

If this tag is not included, subdomains normally inherit the main domain policy unless they publish their own DMARC record.

 `np`

The current DMARC standard includes an `np` tag for mail using nonexistent subdomains.

This can help address attackers attempting to send from invented addresses such as:

`accounts@random-subdomain.yourbusiness.co.uk`

`t`

RFC 9989 introduced the `t` testing tag.

The previous `pct` percentage tag was removed from the updated standard because implementations did not apply percentage values consistently. The new `t=y` setting indicates that a quarantine or reject policy is being tested rather than fully applied.

Businesses should be aware that some provider documentation and existing DMARC tools still refer to the older `pct` method. For example, current Microsoft 365 guidance continues to document percentage-based rollout. This means changes should be planned with the behaviour of the actual email providers and reporting tools involved rather than made solely by copying a generic record.

Why Can’t You Just Publish `p=reject` Immediately?

A business may send email from more systems than it realises.

Microsoft 365 may be the main email service, but other systems could also use the company domain.

These may include:

* Website contact forms
* Marketing platforms
* Accounting software
* Customer relationship management systems
* Helpdesk platforms
* HR applications
* Booking systems
* Security products
* Printers and scanners
* Industry-specific applications
* Automated reporting systems
* Customer portals
* Survey platforms
* Electronic signature services

If these systems are not configured correctly, changing directly to `p=reject` may cause legitimate messages to be rejected.

This could affect:

* Invoices
* Customer notifications
* Password resets
* Website enquiries
* Marketing messages
* Support updates
* Appointment confirmations
* Automated reports

The correct approach is to identify and authenticate legitimate systems before enforcement.

A Safe DMARC Implementation Process

DMARC should be implemented as a managed process rather than a single DNS change.

Step 1: Identify Every Sending Service

Create an inventory of every system authorised to send email using your domain.

Speak to:

* Marketing
* Finance
* Sales
* HR
* Customer service
* Operations
* Website administrators
* Application suppliers

Do not assume the IT team already knows about every platform.

Departments may have created cloud services independently.

Step 2: Review SPF

Confirm that your SPF record authorises legitimate sending services.

Check for:

* Missing platforms
* Old services that are no longer used
* Duplicate entries
* Incorrect mechanisms
* Excessive DNS lookups
* More than one SPF record
* Unnecessary IP addresses

There should normally be one valid SPF record for each sending domain.

Adding every supplier to SPF is not always the best solution. DKIM alignment may be a more suitable option for some services.

Step 3: Configure DKIM

Enable DKIM signing for Microsoft 365 and supported third-party platforms.

Where possible, each service should sign email using your domain or a dedicated subdomain that aligns with the visible From address.

DKIM is particularly valuable for forwarded messages because SPF commonly fails after forwarding.

However, DKIM can also fail if an intermediary modifies signed parts of the message.

Step 4: Publish a Monitoring Policy

Begin with:

`p=none`

and configure an aggregate reporting address.

Allow enough time to collect meaningful data.

The required monitoring period will depend on email volume and how often individual platforms send messages.

A system that only sends monthly invoices may not appear during the first few days.

Step 5: Analyse DMARC Reports

Review the reports to identify:

* Expected Microsoft 365 traffic
* Known third-party services
* Authentication failures
* Alignment failures
* Unknown senders
* Old systems
* Forwarded messages
* Potential abuse

Do not classify every unknown source as an attacker immediately.

The source may be a legitimate platform that has not been documented.

Step 6: Correct Legitimate Senders

Work with each supplier to configure:

* SPF authorisation
* Custom DKIM signing
* An aligned return-path domain
* A dedicated sending subdomain
* Correct From addresses

Microsoft advises using a dedicated subdomain for third-party or bulk email services so that issues with those services do not affect the reputation of normal employee email from the main domain.

For example, marketing messages might use:

`news.yourbusiness.co.uk`

while employee email continues using:

`yourbusiness.co.uk`

Step 7: Move to Enforcement

Once legitimate sources are consistently passing DMARC, move towards:

* `p=quarantine`
* Then `p=reject`

Continue monitoring after each change.

A DMARC record is not something that should be configured once and forgotten.

New cloud services, website platforms and suppliers can introduce new email sources.

DMARC and Microsoft 365

Microsoft 365 supports SPF, DKIM and DMARC, but each technology must be configured correctly for your custom domains.

A Microsoft 365 business should normally confirm:

* SPF includes the correct Microsoft 365 service
* DKIM signing is enabled for custom domains
* The DKIM signing domain aligns with the From domain
* A DMARC record exists in public DNS
* Aggregate reports are being reviewed
* Third-party senders are separately assessed
* Unused domains have protective records
* The organisation’s `onmicrosoft.com` domain is considered

Microsoft explains that custom-domain DMARC records are created through the organisation’s DNS provider rather than through the Microsoft 365 admin portal. It also recommends configuring SPF and DKIM before enforcing DMARC.

Simply using Microsoft 365 does not mean DMARC has automatically been configured for your custom business domain.

DMARC for Marketing Platforms

Marketing platforms are a common source of DMARC problems.

A platform may send a message displaying:

`marketing@yourbusiness.co.uk`

while using its own domain for SPF and DKIM authentication.

In that situation:

* SPF may pass
* DKIM may pass
* DMARC may still fail

This happens because neither authenticated domain aligns with the visible From domain.

The platform should ideally support:

* Custom DKIM signing
* A custom return-path domain
* A dedicated sending subdomain
* Clear domain-authentication instructions

A reputable email platform should provide DNS records that allow the organisation to authenticate its sending domain properly.

DMARC and Website Contact Forms

Website-generated email is another common problem.

A contact form may attempt to send a message from the visitor’s email address through your website server.

For example, the visitor enters:

`customer@gmail.com`

and the website then sends a message claiming to come from that Gmail address.

This message may fail Gmail’s DMARC policy because your website server is not authorised to send email for Gmail.

A better configuration is normally:

* From: an address using your own authenticated domain
* Reply-To: the visitor’s submitted email address

This allows the website to authenticate the message using a domain it controls while still allowing employees to reply to the visitor.

DMARC and Forwarded Email

Email forwarding can create authentication problems.

SPF checks the server that delivered the message.

When an email is forwarded, the forwarding server may not be included in the original sender’s SPF record.

This can cause SPF to fail.

DKIM may continue to pass if the message remains unchanged, but forwarding services, mailing lists and security gateways sometimes modify the message.

This can break the DKIM signature as well.

Authenticated Received Chain, known as ARC, can help receiving providers understand the original authentication result before the message was modified or forwarded.

Forwarding should be considered when reviewing DMARC failures so that legitimate indirect email is not mistaken for malicious activity.

DMARC for Subdomains

DMARC policies can apply to subdomains.

For example:

* `marketing.yourbusiness.co.uk`
* `invoices.yourbusiness.co.uk`
* `support.yourbusiness.co.uk`

Subdomains can be useful for separating different email services.

This can provide:

* Clearer reporting
* Separate sending reputations
* Easier supplier management
* Reduced risk to the main domain
* More targeted DMARC policies
* Simpler troubleshooting

The main domain can use a strong reject policy while a new marketing subdomain is introduced and monitored separately.

A subdomain can also publish its own DMARC record when a different policy is required.

DMARC for Domains That Do Not Send Email

Domains that are not used for email should still be protected.

An unused or defensive domain may be attractive to attackers because nobody expects legitimate messages from it.

A no-send domain can publish a reject policy such as:

`v=DMARC1; p=reject`

The domain should also have a suitable SPF record indicating that no systems are authorised to send email.

Microsoft specifically recommends a reject DMARC policy for registered domains that should never send mail.

Businesses should review all domains they own, not only their main website and email domain.

DMARC and Email Deliverability

Correct email authentication can improve trust in legitimate messages.

It demonstrates that the organisation has taken steps to verify its email sources and protect its domain.

However, DMARC does not guarantee delivery to the Inbox.

Providers may also consider:

* Sender reputation
* Spam complaint rates
* Message content
* Mailing-list quality
* Bounce rates
* Recipient engagement
* Sending volume
* Unsubscribe practices
* Previous malicious activity

A message can pass SPF, DKIM and DMARC and still be placed in Junk.

DMARC is an important requirement, but it is only one part of email deliverability.

DMARC Is Becoming a Delivery Requirement

Major mailbox providers have strengthened authentication requirements for organisations sending large volumes of email.

Google requires senders transmitting around 5,000 or more messages per day to personal Gmail accounts to use SPF, DKIM and DMARC. Yahoo requires bulk senders to implement SPF, DKIM and a valid DMARC policy. Microsoft has also introduced SPF, DKIM and DMARC requirements for domains sending more than 5,000 messages per day to Outlook.com consumer addresses.

This means email authentication is no longer only a cybersecurity recommendation.

For some organisations, it is also necessary to maintain reliable delivery.

Even businesses below these thresholds should configure authentication correctly because their domains can still be spoofed.

Common DMARC Mistakes

DMARC can fail to provide the expected protection when it is poorly configured.

Common mistakes include:

* Leaving the domain at `p=none` indefinitely
* Moving directly to `p=reject`
* Not enabling DKIM
* Assuming SPF alone is sufficient
* Failing to check alignment
* Forgetting website-generated email
* Missing marketing platforms
* Not protecting subdomains
* Ignoring unused domains
* Sending reports to an unmonitored mailbox
* Publishing multiple DMARC records
* Entering an invalid reporting address
* Failing to review reports
* Retaining old authorised services
* Using strict alignment without testing
* Copying a record from another business

A DMARC record should reflect the organisation’s actual email environment.

There is no universal record that is correct for every business.

Does DMARC Stop Someone Hacking Your Email Account?

No.

DMARC helps prevent unauthorised systems from successfully impersonating your domain.

It does not secure an employee’s actual mailbox.

If a criminal steals an employee’s Microsoft 365 password and gains access to their account, messages may be sent through the genuine authorised email system.

Those messages could pass SPF, DKIM and DMARC.

Businesses still need:

* Multi-factor authentication
* Conditional Access
* Strong password management
* Anti-phishing protection
* Login monitoring
* Endpoint security
* Employee awareness training
* Incident response procedures

DMARC protects the domain.

Account security protects the people and systems authorised to use it.

Both are required.

How Often Should DMARC Be Reviewed?

DMARC should be monitored continuously and reviewed whenever the business changes its email systems.

A review may be needed when:

* A new marketing platform is introduced
* The website is replaced
* A new accounting system is implemented
* Microsoft 365 is migrated
* A supplier begins sending email
* A new domain is registered
* The organisation changes DNS provider
* Email delivery problems appear
* A merger or acquisition takes place
* A business application is retired

Periodic reviews can also identify forgotten services that continue to use the company domain.

Is DMARC Worth Implementing for a Small Business?

Yes.

Small businesses can be attractive targets for impersonation because criminals may assume their email security is less mature.

A fraudulent message sent to one customer or supplier could cause:

* Financial loss
* Reputational damage
* Customer complaints
* Payment diversion
* Data disclosure
* Contract disputes
* Time-consuming investigations

DMARC is relevant whether the organisation has five employees or five thousand.

The complexity of implementation will depend more on the number of sending platforms than the number of employees.

A small organisation using Microsoft 365 and one website may have a relatively simple setup.

A larger organisation with several marketing, finance and customer platforms will require more planning.

DMARC Should Be Part of a Wider Email Security Strategy

DMARC is an important control, but it should not be implemented in isolation.

A strong business email security strategy should include:

* SPF
* DKIM
* DMARC
* Multi-factor authentication
* Conditional Access
* Anti-phishing policies
* Safe-link protection
* Attachment scanning
* Impersonation protection
* Mailbox auditing
* User awareness training
* Secure password management
* Incident response planning
* Regular security reviews

The aim is to protect both outgoing and incoming email.

DMARC helps other organisations identify fake messages using your domain.

Your own email security must still protect employees from malicious messages using other domains.

How Hamilton Group Can Help

Hamilton Group helps businesses secure their email domains and Microsoft 365 environments.

We can review how your organisation sends email, identify authentication gaps and create a controlled path towards DMARC enforcement.

Our services can include:

* SPF reviews
* DKIM configuration
* DMARC implementation
* DMARC report monitoring
* Microsoft 365 security reviews
* Third-party sender identification
* Marketing platform authentication
* Website email configuration
* Subdomain planning
* Protection for unused domains
* Anti-phishing policies
* Multi-factor authentication
* Conditional Access
* Microsoft Defender for Office 365
* Cybersecurity awareness training

We can help your business move from monitoring to enforcement without unnecessarily blocking legitimate email.

DMARC is not simply a DNS record.

It is an ongoing process of understanding who sends email using your domain, correcting authentication problems and preventing criminals from impersonating your organisation.

Call Hamilton Group today on 0330 043 0069 to discuss how DMARC, SPF and DKIM can help protect your business, customers and suppliers from email impersonation.