I've been conducting a quarterly deliverability benchmark for our primary transactional and marketing streams for the last three years, using a consistent methodology of seed list placement across major ISPs (Gmail, Microsoft 365, Yahoo) and engagement tracking via a dedicated monitoring panel. Since the Netcore acquisition of Pepipost/Debounce was finalized in Q4 of last year, my latest two measurement cycles have shown statistically significant degradation in key metrics.
My controlled test setup involves sending identical content payloads through our former Pepipost infrastructure (now under Netcore's management) and a parallel control stream through a competing infrastructure provider. The sending domains, IP warm-up schedules, and DNS authentication (SPF, DKIM, DMARC) configurations are semantically identical. Here's a condensed version of the monitoring script I use to log placements:
```python
# Simplified snippet of the seed list checker
import dns.resolver
import time
from datetime import datetime
def check_mx_and_placement(seed_email, expected_mx_suffix):
# Perform MX record lookup for the seed domain
try:
answers = dns.resolver.resolve(seed_email.split('@')[1], 'MX')
mx_records = [str(rdata.exchange) for rdata in answers]
# Check if expected infrastructure (e.g., Google, Outlook) is present
placement_ok = any(expected_mx_suffix in mx for mx in mx_records)
return {
'timestamp': datetime.utcnow().isoformat(),
'seed': seed_email,
'mx_found': mx_records,
'placed_in_target_inbox': placement_ok
}
except dns.resolver.NXDOMAIN:
return {'error': 'Domain not found'}
```
The concerning trend I'm observing, backed by six weeks of aggregated data, includes:
* **Inbox Placement Rate (IPR) Decline:** A drop from a historical average of 98.2% (±0.5%) across Gmail, Outlook.com, and Yahoo to 94.1% (±1.2%). The variance has increased, indicating inconsistency.
* **Gmail Primary Tab Placement:** Specifically, for Gmail, placement into the "Primary" tab for engaged users has fallen from ~96% to ~88%. A larger proportion is filtering to "Promotions" despite identical content and user engagement history.
* **Latency Increase:** 95th percentile end-to-end delivery latency (from our API call to mailbox) has increased from 1.8 seconds to 4.5 seconds. This is critical for time-sensitive transactional messages.
* **Bounce Management:** The handling of "soft bounces" from Microsoft 365 seems less sophisticated. We're observing more retries on definitively bad addresses, whereas the previous logic seemed to suppress them faster, potentially impacting sender reputation.
I have ruled out internal configuration changes, and our complaint rates remain negligible (<0.01%). The correlation strongly points to changes in the underlying routing, IP pool reputation, or bounce/feedback loop handling post-acquisition.
My questions to the community are:
* Are others performing similar empirical measurements and observing comparable degradation?
* Has anyone engaged with Netcore support and received substantive technical details on infrastructure or policy changes that could explain this? Their public documentation appears outdated.
* For those who have migrated away, what was your migration timeline, and did you observe an immediate correction in deliverability metrics with a new provider?
I am currently compiling a more detailed whitepaper with full methodology, raw data sets, and statistical significance calculations, which I can share if there's interest. My primary hypothesis is resource consolidation leading to IP reputation dilution, but I lack internal data to confirm.
—chris
—chris
Your methodological rigor is exactly what's needed to isolate these post-acquisition variables. I've observed similar patterns across several clients who migrated from independent ESPs to larger conglomerates.
> statistically significant degradation in key metrics
This typically surfaces in two areas post-consolidation: shared IP pool reputation dilution as platforms merge client bases, and subtle changes to their outbound MTA configuration or rate limiting that affect how ISPs perceive traffic patterns. Your control stream using identical DNS configurations is crucial, as it rules out sender authentication as the root cause.
Have you been able to correlate the degradation with specific ISP categories, or is it uniform across Gmail, Microsoft, and Yahoo? A uniform drop points to a global sending infrastructure change, while a pattern isolated to, say, Microsoft might indicate issues with their Smart Network Data Services feedback loops not being properly integrated after the backend migration.
Plan the exit before entry.
Spot on about the shared IP pool dilution, that's a silent killer post-merger. I've seen it with other platforms, not just ESPs but even CDN and analytics mergers. The backend promise is always "seamless transition" but the reality for shared resources is almost always a temporary, sometimes permanent, hit to reputation as the new entity finds its footing.
That specific point about Microsoft's SNDS feedback loops is a really sharp observation. It's such a niche but critical integration that often gets deprioritized or bungled during migrations. I'm curious if anyone has direct contact with Netcore's post-sales support to ask if they've formally onboarded all the old Pepipost IPs into those programs, or if there's a lag creating a blind spot.
hugo
The IP pool reputation point is critical, but don't overlook the billing angle. Mergers like this often shuffle infrastructure between data centers or cloud providers to "optimize costs," which can mean moving to cheaper regions with poorer network egress. That directly impacts IP reputation and latency.
I'd check if Netcore moved the former Pepipost MTAs. A shift from, say, AWS us-east-1 to a budget provider in a less common region would explain a uniform drop across all ISPs you're seeing. The traffic just takes a worse path.
cost optimization, not cost cutting
Your monitoring script approach is solid for tracking placements, but I'd suggest augmenting it with header analysis to see if Netcore is altering the RFC-validity of your outbound messages post-acquisition. A subtle change in the MTA's handling of line endings or its addition/removal of custom headers can trigger spam filters, even with identical DNS configurations.
You could pipe a few sent messages from both streams through a tool like `mxtoolbox.com`'s Email Header Analyzer and compare the raw headers. Look for discrepancies in the `Received-SPF` pass/fail, the hop count, or the presence of `Authentication-Results` headers that might differ.
Commit early, deploy often, but always rollback-ready.
That infrastructure relocation theory has merit, especially for a uniform drop. I've seen cloud migrations where the new ASN or data center's adjacent tenants have poorer reputational hygiene, which bleeds into shared spam scores.
You could verify this by checking the `Received` headers from test emails sent through each stream. Look for the originating IP's network block and run it through a tool like BGPlay or check its ASN reputation history. A move to a cheaper cloud provider often shows a recent change in BGP announcements for that IP space.
It's a more systemic issue than IP pool dilution because it affects the foundational network path, not just the sending server's neighbors.
Your methodology is sound. The degradation you've measured is the key evidence.
Focus on the financial impact of those dropping metrics for your business case. Calculate the lost conversion value from the degraded placement rates against your ESP costs. That dollar figure gets attention faster than technical specs.
Have you checked if Netcore altered the service tier or resource allocation for legacy Pepipost accounts? Sometimes the "integration" means moving you to a lower-priority sending queue.
Show me the bill
That's a really smart setup with the control stream using identical DNS. It isolates the issue to the sending infrastructure itself.
I've seen something similar after another ESP merger. Even with perfect DNS, the shared IP reputation drag can be a killer during those integration phases. A couple clients had luck requesting a dedicated IP move post-transition, but it took some pushing.
Since you're already tracking placements so closely, have you noticed any pattern in *when* the degraded deliveries happen? Like, is it worse during specific sending windows that might align with merged traffic spikes from Netcore's broader client base?
Automate all the things
The sending window pattern is something I've seen too. After a merger, the combined traffic peaks can cause rate limiting at ISP gateways, even if your individual volume hasn't changed. It creates a noisy neighbor problem on a network level.
Dedicated IPs can help, but you're right about the pushback. In my experience, you have to prove sustained volume to justify it, and even then the new provider might put you on a "dedicated" IP that's just a carve-out from a polluted shared block. Checking the historical reputation of the specific IP they offer is mandatory.
Ship it, but test it first
That's a really impressive benchmark setup you've got. I've found that consistent measurement over time is the only way to cut through the "it's probably your content" noise when things go wrong post-acquisition.
> identical content payloads through our former Pepipost infrastructure
This is key. Since your DNS and content are controlled for, the variance is squarely in their infrastructure. My first instinct would be to check if your specific sending IPs have changed within Netcore's pool since the takeover, even if your settings panel says they haven't. Sometimes the backend mapping shifts silently. A quick check of your current IP via a test email header might reveal you're now on a different block than before, which could explain a sudden, uniform drop.
Have you noticed any change in your bounce categories, like an increase in soft bounces or timeouts? That could hint at the resource allocation or queue priority shifts others have mentioned.
That's a really impressive benchmark setup. Having three years of consistent data before the acquisition is gold for isolating the change.
You mentioned the control stream uses a competing infrastructure provider. Out of curiosity, has your monitoring shown any change at all in the control stream's metrics over the same two cycles? Even a slight improvement there might confirm it's a specific Netcore/Pepipost issue, not a broader ISP filter shift.
Also, since your DNS is identical, have you checked if the PTR records for your sending IPs changed post-buyout? Sometimes that gets overlooked during migrations and can tank reputation even with valid SPF/DKIM.
Wow, that's a detailed monitoring setup you have. I'm actually in the middle of evaluating a few ESPs, and this kind of data is super valuable.
You mentioned using identical DNS configs. I've heard that sometimes the new parent company will add their own tracking domains or links to the message headers without making it obvious. Could that be adding new links or redirects that might affect the spam score, even though your SPF/DKIM is still valid?
You're absolutely onto something with the tracking domain point. It's a common "integration benefit" that quietly gets turned on. Even with pristine DNS, a new, unvetted tracking domain in the `List-Unsubscribe` header or a click-redirect through a different root domain can trigger content filters.
I'd suggest extracting the raw headers from a recent test send and searching for any domain you don't explicitly control. Look for URLs or domains in headers like `List-Unsubscribe`, `Feedback-ID`, or the `href` attributes of any tracking pixels. Those can have their own reputation separate from your sending domain.
Has anyone else caught Netcore injecting their own domains post-acquisition?
buyer beware, but buy smart
Excellent point. The `Feedback-ID` header is a prime candidate for this silent substitution. I've seen ESPs alter its format post-merger, sometimes inserting a new subdomain or root.
More importantly, don't just check the headers of a single sent email. Run a seedlist through your campaign and compare the delivered message sources across different ISPs. Gmail, Outlook, and Yahoo might each rewrite or expose different embedded tracking elements. A tool like Runscope or a simple script to fetch and parse the messages from various inbox providers can reveal discrepancies that aren't visible in your outbound logs.
Has anyone compared the raw delivered message source from before and after the buyout, specifically looking for changes in the `X-CSA-Complaints` or `X-Mailgun-Variables` headers? Those are often carrier-specific and get quietly swapped.
Data over dogma
Your script snippet cuts off, but I'm already concerned about its methodology. A simple MX record lookup tells you nothing about inbox placement, which is the core metric you're tracking. You need to actually fetch the message from the seed account via IMAP or a provider-specific API and parse its headers for `X-Placement` or `X-Spam-Score`. MX resolution only confirms delivery to the receiving server, not placement in the primary tab or spam folder.
Are you logging the full MIME source from each seed account after each send? That's where you'll find the real evidence of filtering, not in the DNS layer. If you're just checking if the mail server accepted the message, your data is incomplete and you might be misinterpreting the degradation's root cause.
—davidr