Md Riaz Uddin

Your own email provider can flag you as a spammer. It scores your sending rhythm, not just your content. Here's my observation from a sales-community thread last week: A three-person outbound team posted that their reply rate had dropped from around 20% to somewhere between 5 and 10% after connecting their mailboxes to a sequencing tool. Their suspicion was the tool itself. Most replies in the thread agreed. I'd look somewhere less satisfying first: the rhythm change. Before the tool, each mailbox sent maybe 20 emails a day, typed by a human, spread across the day. After the tool, the same mailboxes pushed 100 or more, machine-paced, in tight bursts. Same domain, same people, same copy. Google and Microsoft both watch that pattern from inside the mailbox. A sudden jump in volume and pacing looks, to their models, like an account takeover or a spam operation. The provider doesn't block you. It quietly starts treating your mail with suspicion, and receiving servers follow its lead. The tool didn't cause that. The step change did. The same tool introduced over six weeks of gradual ramp would likely have kept the reply rate intact. If your team's numbers slid right after wiring up any sending tool, pull the daily send counts per mailbox for the two weeks before and after. If the line looks like a cliff, you've found your suspect. It isn't the vendor.

This month I scanned the email security records of 36 funded B2B SaaS companies. All 36 were missing the same control. Not most. All 36. I keep waiting to find the exception. Four weeks of scans now, and the streak is intact. The control is MTA-STS, a standard that forces other mail servers sending to your domain to use a verified, encrypted connection rather than allowing fallback to plain text. Without it, mail can still arrive over an unencrypted path, and an attacker positioned between the sending and receiving servers can read it or quietly redirect it. The attack even has a boring name: a downgrade. Everything else in these scans varies. Some domains have strict spoofing policies and some have none. Some records are tidy, others carry years of accumulated tool clutter. This one control is the constant. I think I know why. The standard is from 2018. Most of these companies set up their email records before that, or copied a checklist written before that. Nothing visibly breaks without it, and no alert ever fires. The gap just sits there, readable by anyone who checks, including the people you'd least want checking. The IT lead at one of these companies isn't careless. They closed the checklist that existed at the time and moved on to louder fires, which is what I'd have done too. The problem is that the checklist changed and nobody's job was to notice. Two places this surfaces later. 1. An enterprise customer's security questionnaire, which increasingly asks whether mail to your domain is encrypted in transit. 2. An audit, where "we've never re-read our own email records" is not a fun sentence to say out loud. The check takes ten minutes, and it's free: any MTA-STS lookup tool will tell you whether the record exists. Deploying it takes an afternoon, most of which is waiting on DNS. 36 domains is one narrow segment, not a study: Series A and B B2B SaaS. But if your company fits that description, the odds say this paragraph is about you. When did anyone last check which controls were added to the standard after your records were written?

We rewrote the sequence six times. Still ~3%. The fix was sitting in someone else's queue... A few years back, before ReplyKit, I ran an SDR team at a B2B SaaS company. Reply rate had settled around 3% and stayed there through everything we threw at it. And we threw a lot. Shorter emails. New subject lines. Different send windows. A/B tests on the opener that I defended in meetings with real conviction. Every experiment produced a decimal-point wiggle, and every Monday the number was back at ~3. The low point was me presenting a slide with three competing theories about our copy. None of them, it turned out, were the answer. What actually moved the number was my subsequent investigation. Turned out our email authentication records had drifted out of shape, and the domain was quietly failing checks at some of the biggest mailbox providers. As a result, a chunk of our mail was being filtered before any human saw it. The fix was a set of DNS changes. IT made them in under an hour once I prioritized our request to solve those. Reply rate soared over the following weeks. Same list. Same sequence. The sixth rewrite of the copy, to be fair to us, was better than the first. It just wasn't the variable. Two things I took from that, and both are a little uncomfortable. One: I'd spent six weeks in the wrong meeting. The problem lived in DNS, and I didn't have the vocabulary to even suspect it. Two, and this is the one I think about more now: the person who could fix it in an hour had no idea we had a problem. On IT's side, there was no problem. No alert had fired. My request read as one more odd request from Sales. That gap, where the team feeling the pain can't see the cause and the team owning the cause can't feel the pain, is most of why email problems stay unsolved at otherwise well-run companies. These days I sit on the technical side of that gap. But I keep the 3% slide in mind. If your outbound numbers slid and the copy debates aren't moving them, the variable might not be in the deck. And if you're in IT, and Sales just filed a strange ticket about email, it's realer than it reads.

"Monitoring mode" isn't a security answer. It's a waiting room. Some teams wait years. There's a common belief in IT teams that publishing DMARC at p=none means email authentication is handled. The record exists, the checklist item is green, the security questionnaire gets a yes. I want to push back on that gently, because the caution behind it is correct. p=none is the right first step. Moving straight to enforcement without reading the reports breaks real mail: forwarded messages, mailing lists, the one billing system nobody remembered sends email. Teams that sit at p=none aren't lazy. They're being careful with something fragile. But p=none tells receiving servers, in plain words: when mail fails our authentication checks, deliver it anyway. As a spoofing defense it's a smoke alarm wired to a mailbox nobody opens. It observes the fire. It's also the single most common finding in the domain scans I run. Not missing DMARC. Parked DMARC. Last Wednesday, two of the fifteen domains I scanned sat at p=none. The version of careful that actually finishes takes about 90 days. Read the aggregate reports for a month, fix the legitimate senders that fail, move to quarantine, watch, then move to reject. That's the whole staircase. The new standard published this spring even added a testing tag to make the climb safer. Monitoring is step one, and it was never the destination. If your record has said p=none since 2023, the monitoring finished a long time ago. The decision is the part that's still waiting.

Your email setup has a hard limit of 10. (Most teams hit it the week a new tool ships.) Single observation from last week's scans ↓ One domain I checked, a B2B SaaS whose product you'd plausibly find in your own stack, was sitting at exactly 10 DNS lookups in its SPF record. SPF is the record receiving servers use to check which services may send mail as your domain, and the standard caps it at 10 lookups. At 11, receivers start returning errors, and mail from every tool on the record, not just the newest one, starts failing checks. Here's how a domain gets there ↓ Every platform that sends mail on your behalf asks for an include line during setup: the CRM the helpdesk the sequencer the billing system the marketing tool Each include spends one or more lookups from the same budget of 10. Nobody tracks the running total, because each department is just following their own vendor's setup guide. So the domain sits at 10, technically fine. Then someone in another department signs a new tool, pastes the setup line from the vendor's docs, and authentication quietly breaks for everything at once. No alert fires. The first symptom is usually someone in Sales asking why bounces doubled this week. If you own a domain: the check takes one minute on any SPF checker, and the count to look for is under 10 with room to spare. If you're in Sales and bounces just doubled: ask IT what got installed that week.