Case Study: The Invisible Gateway | Stonegate Web Security

The Invisible Gateway

A Case Study in Email Authentication, Hidden Infrastructure, and Why Half Your Emails Might Be Disappearing

Introduction: The 50% Problem

The job posting was straightforward: a small business needed help configuring DKIM, DMARC, and SPF to improve email deliverability. They used Office 365 for email. Their domain was hosted through Wix. They wanted someone familiar with these systems.

Simple enough. These configurations typically take an hour or two.

Then came the details.

“About half of our customers and vendors are not receiving emails from us,” the client explained. “The other half seem to be receiving them.”

Half. Not all, not none—half. That’s an unusual failure pattern. When email authentication is completely broken, almost everything fails. When it’s working, almost everything succeeds. But half suggests something more subtle: a configuration that works for some recipients and fails for others, or an intermittent issue that depends on factors not immediately obvious.

The client had already attempted to fix the problem themselves. They’d made adjustments to their DNS records. They’d navigated to the Microsoft 365 admin center to enable DKIM but stopped short of making changes—they didn’t feel confident without prior knowledge. They knew enough to know they didn’t know enough.

What followed was an investigation that revealed hidden infrastructure the client didn’t know existed, authentication failures caused by security features working as intended, and the kind of layered complexity that turns a two-hour job into a forensic exercise.

Part One: The Starting Point

What They Had

The client’s setup appeared simple on the surface:

Email: Microsoft 365 (Office 365)
Domain: Originally registered through GoDaddy, now managed through Wix
Website: Hosted on Wix
Email sending: Exclusively through Office 365—no marketing platforms, no third-party senders

When I pulled their DNS records, the situation became clearer. They had an SPF record in place, which was good. But DKIM and DMARC were completely absent.

SPF alone is insufficient for modern email deliverability. It tells receiving servers which IP addresses are authorized to send mail for your domain, but it doesn’t cryptographically verify that messages haven’t been tampered with (DKIM) or provide policy instructions for handling authentication failures (DMARC). Many email providers—Gmail especially—now expect all three.

The 50% deliverability problem made sense in this context. Some receiving servers are lenient and will accept SPF-only authentication. Others are strict and will spam or reject messages missing DKIM and DMARC. The inconsistent results reflected inconsistent enforcement across different recipients’ email providers.

The Plan

The fix seemed straightforward:

Enable DKIM signing in Microsoft 365
Add the required DKIM DNS records pointing to Microsoft’s key servers
Create a DMARC record to tie everything together
Verify all three pass authentication checks

Two hours, maybe three if DNS propagation was slow. Standard work.

That’s not what happened.

Part Two: The First Failure

Gmail Says No

After enabling DKIM in Microsoft 365 and adding the necessary DNS records, I sent test emails to verify the configuration. The test to Gmail was rejected outright.

The bounce message pointed to SPF failure. But the SPF record looked correct—it included spf.protection.outlook.com, which is Microsoft’s standard SPF include for Office 365 tenants. This should authorize all of Microsoft’s sending infrastructure.

The failure indicated the email was sent from an IP address not covered by that include. But if Microsoft 365 was the only sender, and Microsoft’s SPF record was included, how could an IP be unauthorized?

I dug into the message headers from a successful delivery to another provider. The answer was in the routing: the email wasn’t going directly from Microsoft 365 to the recipient. It was passing through an intermediate server first.

The sending IP belonged to Proofpoint.

The Hidden Layer

Here’s what the client didn’t know: their Microsoft 365 account wasn’t a direct Microsoft relationship. It was bundled through GoDaddy, who had originally sold them the domain. GoDaddy’s Microsoft 365 offering includes Proofpoint Essentials as a bundled email security gateway.

This means every outbound email follows this path:

Microsoft 365 → Proofpoint Essentials → Final Destination

The client had no idea this intermediate hop existed. They’d never configured it, never seen a Proofpoint dashboard, never been told about it. It was just silently processing all their email as part of the GoDaddy bundle.

From an authentication perspective, this invisible gateway changed everything.

Why SPF Failed

The original SPF record used a strict -all qualifier, meaning “reject anything not explicitly authorized.” It authorized Microsoft 365’s IPs via the standard include. But the emails weren’t coming from Microsoft’s IPs—they were coming from Proofpoint’s IPs after Proofpoint processed them.

Gmail checked the sending IP, found it wasn’t in the SPF record, and rejected the message outright.

The immediate fix was to soften the SPF qualifier from -all (hard fail) to ~all (soft fail). This told receiving servers to accept messages from unauthorized IPs but treat them with suspicion rather than rejecting them entirely.

After this change, test emails started arriving. But they arrived with warnings—Gmail flagged them with authentication concerns. The emails were getting through, but something was still wrong. SPF was soft-failing because Proofpoint’s IPs still weren’t explicitly authorized. And DKIM had its own problems.

Part Three: The DKIM Mystery

Signed, Then Stripped

With SPF now passing, attention turned to DKIM. The configuration in Microsoft 365 was enabled. The DNS records were in place and resolving correctly. Microsoft’s systems showed DKIM signing as active.

But when I examined received messages, the DKIM signature was missing from the headers. Raw message inspection showed no DKIM-Signature header at all.

This created a contradiction: Microsoft claimed to be signing messages, but recipients weren’t seeing signatures. Either Microsoft’s dashboard was lying, or something was removing the signatures in transit.

The culprit was Proofpoint.

Security vs. Authentication

Proofpoint Essentials scans outbound email for threats, malware, and policy violations before releasing it to the internet. This is genuinely valuable security functionality—it’s the whole point of an email security gateway.

But that scanning process modifies messages. Proofpoint opens them, inspects them, sometimes adjusts headers or formatting, then sends them on. From a DKIM perspective, this is catastrophic.

DKIM works by creating a cryptographic hash of specified message components—headers, body, attachments. The sending server signs that hash with a private key. The receiving server retrieves the public key from DNS and verifies the signature. If even a single character has changed, the signature is invalid.

When Proofpoint modifies a message during inspection, the original DKIM signature becomes invalid. Rather than pass along a broken signature (which looks worse than no signature), Proofpoint strips it entirely.

This is normal behavior for secure email gateways. It’s also why the client’s DKIM appeared to be failing even though Microsoft was signing correctly.

The ARC Solution

The email industry anticipated this problem. Legitimate security tools need to modify messages, but those modifications break DKIM, which breaks DMARC, which hurts deliverability. Organizations were being forced to choose between security and authentication.

ARC—Authenticated Received Chain—was designed to solve this.

ARC works like a notarized chain of custody. Each server that handles a message can add an ARC set: a record of the authentication results at that point in transit, cryptographically signed to prevent tampering. Even if downstream modifications break the original DKIM signature, the ARC chain preserves evidence that DKIM was valid when the message left the originating server.

When Microsoft 365 sends a message, it adds the first ARC set:

ARC-Authentication-Results: i=1;
  spf=pass;
  dmarc=pass;
  dkim=pass header.d=[domain_redacted].com;

This is cryptographically sealed proof that SPF, DKIM, and DMARC all passed when Microsoft released the message. Even though Proofpoint later strips the DKIM signature, that ARC record survives.

Modern receiving servers (Gmail, Outlook, Yahoo, and most enterprise providers) understand ARC. When they see a missing DKIM signature but a valid ARC chain showing DKIM passed upstream, they honor that upstream result.

A note of caution: many popular email testing tools—including mail-tester.com and similar services—will report DKIM as failing in this scenario. They check for the presence of a DKIM signature at delivery and don’t evaluate the ARC chain. This can send you chasing a problem that doesn’t exist. If a testing tool shows DKIM failing but your emails are landing in inboxes without issues, inspect the raw headers yourself. Look for ARC-Authentication-Results showing dkim=pass upstream. The major email providers trust ARC; your testing tools may not.

Confirming the Chain

Verification required examining raw headers from test messages sent to multiple providers.

Gmail’s headers showed:

arc=pass (i=1 ... dkim=pass dkdomain=[domain_redacted].com)

Gmail cryptographically verified Microsoft’s ARC record, confirmed DKIM originally passed, and trusted that upstream result despite the missing signature.

Outlook’s headers showed:

arc=pass (... dkim=[1,1,header.d=[domain_redacted].com])

Same result: Outlook acknowledged no DKIM signature was present at delivery, but verified through ARC that DKIM had passed at the source.

The authentication chain was intact. DKIM was working. It just didn’t look like it was working unless you knew where to look.

Part Four: The Final Configuration

With the DKIM mystery solved—signatures were valid at origin and preserved via ARC—the remaining issue was the SPF warnings. The ~all soft fail was letting emails through, but receiving servers were still flagging them because Proofpoint’s IPs weren’t authorized.

The fix was explicit: add Proofpoint’s outbound sending domain to the SPF record. But here’s where documentation failed us.

Every guide for Proofpoint Essentials SPF configuration—including Proofpoint’s own documentation—recommends using a:dispatch-us.ppe-hosted.com. That’s the standard US dispatch server. I added it. SPF still soft-failed.

The actual sending hostname, visible in the email headers, was dispatch1-usg1.ppe-hosted.com—a GoDaddy-specific Proofpoint infrastructure variant that appears nowhere in standard Proofpoint documentation. GoDaddy bundles Proofpoint with their Microsoft 365 offering, and apparently routes through different servers than standalone Proofpoint Essentials customers.

Once a:dispatch1-usg1.ppe-hosted.com was added—the hostname I found in the Received: headers, not the one in the docs—SPF started passing cleanly. No more warnings. The authentication chain was finally complete.

The lesson: documentation tells you what should work. Headers tell you what’s actually happening. When they disagree, trust the headers.

Here’s what the final configuration looked like:

SPF Record

v=spf1 include:spf.protection.outlook.com a:dispatch1-usg1.ppe-hosted.com ~all

This record authorizes two senders:

Microsoft 365’s infrastructure (via the standard include)
Proofpoint’s outbound gateway (explicitly added to cover the hidden relay)

The ~all soft fail provides flexibility for edge cases while still indicating unauthorized senders should be treated with suspicion.

DKIM Records

selector1._domainkey.[domain_redacted].com → CNAME → Microsoft's key server

Microsoft 365 uses a CNAME chain for DKIM rather than direct TXT records. This allows Microsoft to rotate keys automatically without requiring customers to update DNS. The CNAME points to Microsoft’s key management infrastructure, which publishes the actual public key.

DMARC Record

v=DMARC1; p=none; rua=mailto:dmarc@[domain_redacted].com;

This DMARC record enables monitoring without enforcement:

p=none means authentication failures are reported but not rejected
rua specifies where aggregate reports should be sent

Starting with p=none is standard practice for new DMARC deployments. It allows the domain owner to receive reports and identify any legitimate senders that might not be properly authenticated before moving to stricter enforcement (p=quarantine or p=reject).

Part Five: Lessons

For Business Owners

You may have infrastructure you don’t know about. Bundled services—especially those from domain registrars and hosting providers—often include components that aren’t explicitly surfaced. Email security gateways, spam filters, and relay services can all affect authentication without appearing in your admin dashboards. If you’re troubleshooting email issues, ask your provider exactly what sits between your email system and the outside world.

Half-broken is a clue, not a mystery. When some emails work and others don’t, the inconsistency itself is diagnostic. Different recipients have different enforcement policies. The failures point to specific authentication gaps, not random gremlins.

SPF, DKIM, and DMARC are all required now. Ten years ago, SPF alone was often sufficient. Today, major email providers expect all three. If you’re only partially configured, you’re leaving deliverability on the table—and it will get worse over time as enforcement tightens industry-wide.

Test to multiple providers. Gmail, Outlook, Yahoo, and ProtonMail all handle authentication slightly differently. A message that passes at one provider might fail at another. Comprehensive testing means sending to multiple destinations and checking headers at each.

For Technical Readers

Always check for intermediate relays. Before diagnosing authentication failures, map the actual mail flow. The sending IP in received headers may not be what you expect. Trace the full path from origin to destination.

Documentation can be wrong for your specific setup. Bundled services often use different infrastructure than standalone products. The “official” SPF include for Proofpoint Essentials didn’t work here because GoDaddy routes through different servers. The correct hostname came from examining actual email headers, not following guides. When troubleshooting, the Received: headers are authoritative; documentation is just a starting point.

ARC is essential for understanding modern email authentication. If you’re troubleshooting DKIM failures for an organization using any kind of email security gateway, forwarding service, or mailing list, the DKIM signature at delivery may not reflect the signing status at origin. Check ARC headers before concluding DKIM is broken.

Hard SPF fails (-all) are dangerous with complex mail flows. If there’s any possibility of legitimate mail transiting through servers not in your SPF record, use soft fail (~all) until you’ve verified the complete topology. Strict SPF with missing authorized senders causes silent delivery failures.

Microsoft 365 DKIM uses CNAME indirection. Don’t look for TXT records directly at selector1._domainkey.yourdomain.com—follow the CNAME chain to find the actual key. This is by design and allows Microsoft to manage key rotation.

Test with raw headers, not inbox arrival. A message arriving in the inbox doesn’t mean authentication passed—it may have been borderline and only accepted due to other reputation factors. Always verify SPF, DKIM, DMARC, and ARC status in the raw headers to confirm clean passes.

The Bigger Picture

This engagement started as a routine configuration job: enable DKIM, add DMARC, verify SPF. Two hours, standard pricing.

It became a forensic investigation into hidden infrastructure, authentication mechanisms designed to survive that infrastructure, and the gap between what dashboards report and what actually happens to messages in transit.

The client’s emails are now authenticating correctly across all major providers. SPF passes at the edge (through Proofpoint). DKIM passes at origin (through Microsoft) and is preserved via ARC. DMARC passes because both underlying mechanisms align.

The 50% deliverability problem is resolved. The half of recipients who weren’t receiving emails were the half whose providers enforced strict authentication. With all three standards properly configured—and with the hidden Proofpoint relay properly accounted for—the authentication chain is complete.

Sometimes the simple jobs aren’t simple. The complexity isn’t in the standards themselves—SPF, DKIM, and DMARC are well-documented and widely supported. The complexity is in the hidden layers that sit between you and your recipients, silently modifying messages, stripping signatures, and adding hops that don’t appear in any dashboard you control.

Finding those layers, understanding their impact, and configuring around them is the difference between email that works and email that disappears.

This case study documents a real client engagement. Technical details have been generalized and client-identifying information has been changed to protect confidentiality while preserving the educational value of the investigation.