The High Cost of Bad Email Hygiene: How Secure Vendors Get Undermined by Their Customers

Executive Abstract

When a long-standing customer failed to configure basic email authentication, a secure vendor was forced to choose between preserving its security posture or continuing business as usual. This case study explores the operational and cybersecurity implications of bypassing DMARC enforcement in Microsoft 365, and why email trust is only as strong as the weakest party in the relationship. Security isn’t just a configuration; it’s a shared responsibility.

Introduction

In a recent engagement, HUME-IT investigated a silent but business-critical failure experienced by one of our clients, a reputable vendor providing recurring services to a long-standing customer. For years, this customer submitted purchase orders via email, forming the basis of fulfillment workflows and monthly revenue targets.

Then the orders stopped arriving.

There were no error messages, no bounces, no visible disruptions. However, behind the scenes, Microsoft 365 Defender was silently quarantining the emails. The reason? The customer’s misconfigured email authentication caused their messages to fail SPF and DMARC validation, triggering Microsoft’s anti-spam enforcement.

The vendor’s systems were working exactly as intended. Yet, they were faced with a choice: to remain resolved in maintaining their security posture or to weaken their defenses to continue doing business.

This case highlights a persistent and growing risk. Even well-secured organizations can be undermined by the weak practices of their external partners. When the partner is a customer, the pressure to accommodate often outweighs strict enforcement.

What is it?

Modern email security relies on three key authentication standards:

• SPF (Sender Policy Framework): Specifies authorized sending mail servers.
• DKIM (DomainKeys Identified Mail): Cryptographically signs messages to prove sender legitimacy.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Directs recipient mail systems to reject, quarantine, or allow emails that fail SPF or DKIM.

Since mid-2023, Microsoft 365 Defender has strictly enforced DMARC policy. When an inbound email fails both SPF and DKIM alignment, and the sender’s domain has a DMARC policy of quarantine or reject, Microsoft assigns a high Spam Confidence Level (SCL), often quarantining the message, regardless of allow-list or trusted sender settings.

That’s exactly what happened here. The vendor’s customer:

• Had no SPF record (spf=none),
• Used a DKIM signature that didn’t align with the “From” address domain,
• And lacked DMARC alignment, leading Microsoft 365 to treat the message as untrustworthy.
  

The result: Microsoft 365 classified the messages as high-risk spam (SCL=5+), silently quarantined them, and never notified the vendor’s end users. The purchase orders vanished without a trace.

The vendor’s administrators later discovered that end-user quarantine notifications had been silently disabled, meaning no alerts were generated when messages were quarantined. As a result, their IT staff had been manually accessing the quarantine console throughout the day to check for missing emails. This manual burden, combined with unexplained message loss, was what ultimately prompted the vendor to reach out to HUME-IT.

Why does it matter?

This incident reveals two intersecting issues. First, it highlights a flaw in how modern email security systems enforce trust. Second, it shows the cascading risks introduced when organizations override those controls for the sake of operational continuity.

Microsoft 365 Defender performed as expected. It detected messages that failed DMARC and assigned a high spam score. Yet this rigid enforcement occurred without context about the relationship between sender and recipient, or the criticality of the communication.

To maintain operations, the vendor implemented a transport rule to force delivery from the customer's domain, effectively bypassing Microsoft’s anti-spam and anti-phishing protections. While technically effective, this creates a significant security vulnerability.

Because the customer’s domain lacks SPF or DMARC alignment, any third party can spoof that domain. By overriding spam confidence logic, the vendor inadvertently created a trusted path for malicious traffic, which now:

• Bypasses content filters,
• Avoids quarantine,
• Lands directly in users’ inboxes, and
• Carries the implicit authority of a legitimate business partner.

This opens the door for phishing, malware, or even business process compromise. A spoofed message could redirect funds, manipulate purchase orders, or deploy ransomware. The risk is not theoretical, it is structural and immediate.

Furthermore, once such a bypass is in place, standard audit and detection mechanisms are weakened. Messages delivered with a forced SCL=-1 will not be flagged, scored, or logged in traditional anti-phishing reports, complicating response and containment.

This is the true cost of prioritizing operational continuity over security. It is not just a risk to confidentiality or compliance. It is a risk to the core trust model that underpins business communication.

The Business Impact & Larger Implication

For HUME-IT’s client, the vendor, every missed email represented lost time, money, and credibility.

POs submitted by their customer were silently intercepted. The vendor’s fulfillment team remained unaware until follow-ups from the customer revealed that weeks of orders had gone unanswered. This prompted a forensic investigation of mail flow, header inspection, and ultimately the discovery of DMARC misalignment as the cause.

To restore communications, the vendor, guided by HUME-IT, implemented a targeted transport rule in Microsoft 365 using PowerShell. This rule forcibly set the Spam Confidence Level to -1 for the misconfigured sender domain, bypassing Microsoft’s filtering logic and allowing messages through.

While the rule solved the problem, it also created an exception to a well-hardened mail environment. And with that exception came risk.

The broader implications are worth examining:

• The vendor upheld strong security hygiene. Their platform followed Microsoft’s best practices and enforced authentication rigorously. No fault lay in their configuration.
• The customer, by contrast, failed to meet basic security standards. And yet, it was the vendor who had to absorb the risk to maintain the relationship.
• A report was provided outlining the customer’s authentication failures. Whether the customer took corrective steps to address their outbound configuration remains unknown. The resolution was operational in nature, but it did not reflect a mutual improvement in security posture.
• The vendor ultimately prioritized service delivery over strict adherence to security posture. For this customer, the business need outweighed the security risk, and that’s the core of the dilemma.

This is not a failure of judgment. It’s a reflection of reality.

Security and IT operations exist in service of business outcomes. Each organization must define its own tolerances, its own balancing point between safeguarding posture and delivering value.

But in the B2B space, this calculation becomes more complex. Vendors face unique pressure to meet the expectations of their clients, and those expectations rarely include being educated on SPF, DKIM, or DMARC. There’s an implicit imbalance: the vendor is expected to “make it work,” even when the customer introduces risk.

There are no easy answers. What this case illustrates is that secure posture is not just technical, it’s relational. And unless security maturity becomes a shared responsibility between businesses, the operational burden will always fall disproportionately on those who do it right.

What Can I Do About It?

The ideal path forward is built on partnership. In the best-case scenario, the secure vendor identifies the problem, documents the cause, and communicates the issue to the customer. The customer then remediates their authentication posture by aligning SPF, DKIM, and DMARC. The security exception is retired, and the business relationship continues without compromising risk boundaries.

But not every scenario plays out that way.

To support both secure posture and business continuity, consider the following actions:

For Secure Organizations (like vendors):

• Enable end-user quarantine notifications so important messages are not lost silently.
• Conduct regular message trace reports for high-value communication partners.
• Audit and document all transport rules and filtering exceptions, clearly labeling them as temporary controls tied to specific business cases.
• Establish a time-bound risk exception framework, where operational overrides are reviewed and renewed only with justifiable business drivers.
• Communicate expectations to customers about basic email authentication hygiene. Offer clear remediation steps and provide resources for implementation.
• Escalate persistent issues through business relationship channels, not just IT, to ensure visibility and accountability.

For Customers (the senders of email):

• Publish and maintain a valid SPF record that reflects all outbound mail sources.
• Ensure DKIM signatures align with the From address domain.
• Set DMARC to p=none temporarily until full alignment is confirmed, then progress to quarantine or reject.
• Test outbound email authentication regularly, especially if using third-party relays or automation tools.
• Collaborate with vendors when delivery issues occur. Be proactive in reviewing headers and coordinating on validation failures.

For Both Parties:

• Vendors should define and maintain internal policies for handling security exceptions, including when it is appropriate to override filtering behavior for customer communications. These should be part of internal governance and risk review processes.
• Where possible, communicate expectations clearly to customers about authentication requirements and the security impact of misconfigured email infrastructure. Even if not formalized, setting the expectation fosters accountability.
• For strategic or regulated partnerships, consider documenting mutual responsibilities related to email security posture. While not always practical, this can be essential in environments with elevated risk or compliance requirements.

Conclusion: Bottom Line

Security professionals often speak of defending systems, platforms, and data. However, this case shows that the more subtle and persistent challenge lies in defending operational integrity without compromising security principles.

A secure vendor wasn’t breached. They didn’t misconfigure their systems. Their controls worked. But they still suffered an operational breakdown because a trusted customer failed to meet minimum authentication standards.

In response, the vendor had to make a hard but familiar choice: maintain a strong security posture and risk losing key business communication, or weaken that posture, document the exception, and keep the relationship intact.

There is no one-size-fits-all answer. Security is not absolute, it’s contextual. And it must be evaluated against the goals and risks of the business it supports.

In the B2B landscape, this tension is especially pronounced. Vendors are under pressure to deliver, while their clients often lack the technical maturity to uphold their side of the security equation. That asymmetry creates quiet risk, operational overhead, and complex tradeoffs, often made under pressure, without clear visibility into what comes next.

The takeaway? Secure configurations are necessary, but not sufficient. Mature security posture must include mechanisms for evaluating, negotiating, and, when needed, temporarily accepting risk for the sake of operational continuity. But that acceptance should always come with a call to action.

Security isn’t just something you enforce. It’s something you expect, especially from those who depend on you.

References

1. Microsoft: Use DMARC to validate email
2. Microsoft: Anti-spam protection in Microsoft Defender
3. RFC 7489: Domain-based Message Authentication, Reporting & Conformance (DMARC)
4. HUME-IT client engagement, April 2025 (anonymized)