DMARC in Practice: From Monitoring to Enforcement

SPF and DKIM help receiving mail servers verify where an email came from and whether it carries a valid digital signature. But how should those servers handle messages that claim to come from your domain and fail authentication?

That is where Domain-based Message Authentication, Reporting and Conformance (DMARC) comes in.

DMARC allows a domain owner to publish a policy that tells receiving servers how to handle messages that fail DMARC checks. It also supports reporting, helping businesses identify legitimate email services, authentication failures and potential attempts to impersonate their domains.

For businesses sending invoices, quotations, payment reminders and customer notifications, DMARC is an important part of protecting their email identity.

The key is implementing it carefully. Moving directly to a strict policy without understanding every legitimate sending source can disrupt business communications. A staged rollout helps you strengthen protection without accidentally blocking genuine email.

1. What Does DMARC Actually Do?

DMARC builds on SPF and DKIM. It checks whether a message passes at least one of those authentication mechanisms with the required alignment to the domain shown in the email's visible From address.

It also lets domain owners specify how receivers should handle messages that fail DMARC evaluation.

DMARC has three main policy settings:

These policies are instructions to receiving mail systems, not an absolute guarantee of how every provider will handle every message. Receivers may apply their own policies and local handling rules.

DMARC also supports aggregate reports that show authentication results for messages claiming to use your domain. Depending on the reporting provider, these reports can help identify sending sources, alignment failures and possible spoofing.

2. Start with Monitoring: Publish p=none

The safest starting point for most domains is a monitoring policy.

With p=none, you can collect information about email authentication without immediately asking receivers to quarantine or reject messages that fail DMARC.

This matters because a business may use more sending services than it realizes, including:

• Business email hosting.

• Accounting and invoicing platforms.

• Customer relationship management (CRM) systems.

• Marketing newsletters.

• Website contact forms.

• Transactional email services.

• Support ticketing systems.

• Applications configured by individual employees.

A message may appear to come from your domain even though a third-party platform sends it. Unless that platform is configured correctly, it may fail authentication or alignment.

Publish a DMARC DNS Record

DMARC records are published as TXT records in DNS, usually at the _dmarc subdomain.

A basic monitoring example is:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace example.com with your domain and use a real reporting mailbox or an appropriate DMARC reporting service.

The rua tag specifies where aggregate reports should be sent. The reporting destination must be configured to receive them. If you use an external reporting service, check whether it requires additional DNS authorization.

This is an illustrative record, not a complete configuration for every business. Existing DMARC records should be updated rather than creating multiple records for the same domain.

3. Read Aggregate Reports and Identify Every Sending Source

Publishing a record is only the beginning. The real work is understanding the reports.

Aggregate reports are generally XML files or data presented through a reporting dashboard. They can show information such as:

• The IP addresses that sent messages claiming your domain.

• The volume of messages observed.

• SPF and DKIM authentication results.

• Whether SPF and DKIM align with the visible From domain.

• The DMARC policy applied to the messages.

Reports typically summarize activity over a reporting period. They do not necessarily contain the full message body or identify the individual person who sent an email.

Build a Sending-Source Inventory

As reports arrive, compare the sending IP addresses and authentication results with the services your business uses.

Do not automatically add every reported IP address to SPF. An unknown source may be an attacker impersonating your domain, and unnecessary SPF entries can authorize senders that should not be trusted.

Likewise, do not assume every authentication failure is malicious. A legitimate service may be misconfigured, or forwarding may affect the authentication results.

4. Understand Alignment: Why Passing SPF or DKIM Is Not Enough

One of the most common DMARC misunderstandings is confusing authentication with alignment.

SPF checks whether the sending server is authorized for the domain used in the SMTP envelope sender. DKIM checks a digital signature associated with a signing domain.

DMARC then compares the authenticated domain with the domain in the visible From header.

For example, an invoicing service might send a message that displays:

From: billing@example.com

But its underlying sending domain could be:

mailer.invoice-platform.example

SPF may pass for the platform's domain. However, if that domain does not align with example.com, SPF does not satisfy DMARC on its own.

DKIM can satisfy DMARC when the message has a valid signature and the signing domain aligns with the visible From domain.

Why DKIM Is Particularly Valuable

Email forwarding can break SPF because the forwarding server may not be authorized by the original sender's SPF record. A valid DKIM signature may survive forwarding, provided the message is not altered in a way that invalidates the signature.

This makes properly configured, aligned DKIM especially useful for business email. However, DKIM is not infallible: signatures can fail, and DMARC can also pass through aligned SPF.

The goal is not to rely on one mechanism blindly. Configure both SPF and DKIM where possible, then confirm that at least one aligned mechanism consistently passes for each legitimate sending service.

For more detail, see the DKIM guide and SPF Records Explained: Stop Email Spoofing.

5. Move from Monitoring to Quarantine

Once reports show that your legitimate sending sources are identified and correctly configured, consider moving to quarantine.

For example:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

This policy requests that messages failing DMARC be treated as suspicious. Depending on the receiving provider, messages may be sent to spam or placed in quarantine.

Before making the change, confirm that:

• Every legitimate sending service has been identified.

• SPF or DKIM passes with alignment for each service.

• Invoices, password resets and transactional notifications have been tested.

• Website forms and automated application emails have been checked.

• Recent reports do not show unexplained failures from known business systems.

• You have a way to receive and review new reports after the policy changes.

A quarantine policy can be introduced gradually using the optional pct tag, which specifies the percentage of applicable messages to which the policy should be applied. Support and interpretation can vary, so check your reporting and receiving environment before relying on percentage-based rollout.

Keep monitoring after the change. If legitimate messages start failing, identify and correct the underlying authentication or alignment issue rather than simply weakening the policy without investigation.

6. Move to Reject When You Are Ready

The strictest standard DMARC policy is:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

This requests rejection of messages that fail DMARC. It is intended to make domain impersonation more difficult by giving receiving mail systems a clear instruction for handling unauthenticated messages.

For businesses, that can help reduce the risk of attackers sending fraudulent invoices, payment-change requests or other messages that appear to come from the company's domain.

However, a strict policy must be based on evidence. If an invoicing platform is still sending messages that fail DMARC, legitimate invoices could be rejected by receiving systems that follow the policy.

Before enforcement, review your reports and test the business-critical sending paths. Make sure that changes to vendors, email systems or DNS will trigger a review of the configuration.

Important: DMARC protects the use of your domain in email authentication. It does not stop every phishing attempt, compromised mailbox or lookalike domain. Attackers may still use similar-looking domains or send messages from a legitimate account they have compromised.

7. Common DMARC Mistakes to Avoid

Publishing Multiple DMARC Records

A domain should have one valid DMARC record at _dmarc. Multiple competing records can cause receivers to treat the configuration as invalid.

Moving Straight to p=reject

Strict enforcement without reviewing legitimate sending sources can disrupt invoices, support messages and application notifications. Monitor first and resolve failures before tightening the policy.

Treating SPF or DKIM Pass as Automatic DMARC Pass

Authentication must also satisfy the relevant alignment requirement. Inspect the DMARC result, not just the individual SPF and DKIM results.

Authorizing Unknown Senders

Do not add unfamiliar services to SPF or configure their DKIM keys until you have confirmed that the service is legitimate and approved to send on your behalf.

Ignoring Reports After Enforcement

Your email environment changes over time. New software, new vendors and changes to sending infrastructure can introduce authentication failures. Continue reviewing reports after moving to quarantine or reject.

Expecting DMARC to Fix Every Delivery Issue

DMARC can help authenticate your domain and reduce spoofing, but it does not guarantee inbox placement. Sender reputation, message content, recipient filtering and other technical factors still affect delivery.

8. A Practical DMARC Rollout Plan

Use the following stages to implement DMARC in a controlled way.

Stage 1: Discover

1. List all services that send email using your domain.

2. Check the existing SPF and DKIM configuration.

3. Confirm that your domain has one valid DMARC record.

4. Set up an aggregate reporting destination.

Stage 2: Monitor

1. Publish a DMARC policy with p=none.

2. Review aggregate reports over several reporting cycles.

3. Identify legitimate sending sources and investigate unknown sources.

4. Correct SPF, DKIM and alignment issues.

5. Test invoices and other business-critical messages.

Stage 3: Enforce Gradually

1. Move to p=quarantine once legitimate sending sources are accounted for.

2. Review reports and investigate unexpected authentication failures.

3. Test email delivery after major configuration changes.

4. Move to p=reject when the evidence supports stronger enforcement.

5. Continue monitoring reports and document future DNS changes.

The timeline depends on your email volume, reporting frequency and the complexity of your sending environment. Two to four weeks can be a useful initial monitoring period, but it does not guarantee that every sending source has been discovered. Low-volume services may require a longer observation period.

Frequently Asked Questions

Does DMARC Stop Email Spoofing Completely?

No. DMARC helps receiving systems identify messages that impersonate your domain and fail authentication. It cannot prevent every phishing attempt, lookalike-domain attack or message sent from a compromised legitimate account.

What Is the Difference Between p=none, p=quarantine and p=reject?

p=none requests monitoring without DMARC-specific enforcement. p=quarantine requests suspicious handling for failing messages, while p=reject requests rejection. The final handling depends on the receiving system.

How Long Should I Monitor DMARC Before Enforcement?

There is no universal deadline. Start by collecting reports across normal business activity and resolving failures from legitimate sending sources. A few weeks can be a useful starting point, but complex or infrequently used services may require longer.

Does DMARC Improve Email Deliverability?

Correctly configured DMARC can improve domain authentication and help establish trust with receiving providers. It does not guarantee inbox placement, and a poorly implemented enforcement policy can disrupt legitimate mail.

Do I Need SPF and DKIM If I Have DMARC?

Yes. In practice, you should configure SPF and DKIM for your legitimate sending sources. DMARC evaluates whether at least one of these mechanisms passes with alignment; it does not replace either mechanism.

Conclusion

DMARC is most effective when it is introduced as a managed process rather than a one-time DNS change.

Start with monitoring, identify every legitimate sending source, resolve authentication and alignment problems, and then progress to quarantine and reject when your reports support the decision.

For businesses that rely on invoices, payment reminders and customer notifications, this process helps protect the company's email identity while reducing the risk of disrupting genuine communication.

If your business uses SteboHost business email hosting, review the available DNS configuration and support options before changing your policy. Make sure every sending service is correctly authenticated, and verify any automatic setup claims against the actual service configuration.

The goal is straightforward: make legitimate email verifiable and give receiving systems a clear policy for messages that impersonate your domain.