Email infrastructure and deliverability, operated end to end.
Gmail, Yahoo and Microsoft now reject unauthenticated bulk mail outright. We run the platforms and the authentication that get your mail delivered, on dedicated IPs we manage inside the EU.
Email deliverability is the share of a sender's messages that reach the inbox rather than spam or outright rejection. In 2026 it rests on three things you operate rather than write: authentication (SPF, DKIM, DMARC), the reputation of the IPs and domain you send from, and recipient engagement. Argus Root runs all three as a managed service on dedicated IPs inside the EU, for senders whose volume makes inbox placement a business risk rather than a configuration detail.
In short
- Sending 5,000+ messages a day to personal inboxes makes you a bulk sender at Gmail, Yahoo and Microsoft — and the classification is permanent, even if volume later drops.
- Non-compliance is rejection at the SMTP level, not spam-folder placement: Gmail moved to permanent rejections in November 2025, Microsoft enforced from May 2025.
- Keep the spam complaint rate below 0.1% and never at 0.3%, measured across all your mail to a provider, not per campaign.
- One-click unsubscribe (RFC 8058) is required on marketing mail and must be honoured within two days.
- Fully authenticated mail still lands in spam more than 30% of the time — reputation and engagement decide placement, and a dedicated IP must be warmed over weeks.
The gate has closed.
Gmail and Yahoo have required authentication from bulk senders since February 2024. Microsoft Outlook joined in May 2025, and in November 2025 Google moved from temporary delays to permanent rejections. Unauthenticated bulk mail is now turned away at the door.
| Requirement | Gmail | Yahoo | Microsoft Outlook |
|---|---|---|---|
| SPF + DKIM | Required | Required | Required |
| DMARC (aligned) | Required, p=none accepted | Required | Required, min p=none |
| One-click unsubscribe (RFC 8058) | Required on marketing | Required | Required |
| Spam complaint ceiling | <0.1% target, 0.3% cliff | <0.3%, stricter calculation | Low, tracked in SNDS |
| Failure mode | Permanent rejection since Nov 2025 | Rejection / spam | Hard rejection since May 2025 |
| Applies to | 5,000+/day to personal inboxes | Significant volume | Bulk senders |
In plain terms, the rules describe a single sender that providers can verify and hold to account. SPF lists the servers allowed to send for your domain; DKIM signs each message so tampering shows; DMARC ties the two to your visible From address and tells providers what to do when they fail. A valid reverse-DNS record on the sending IP and a From domain that aligns with the authentication complete the identity. Miss any one and the mail is treated as unverified, which in 2026 means rejected rather than merely filtered.
The complaint ceiling is where compliant senders still come unstuck. The figure is measured across all of your sending to a provider rather than per campaign or per tool, so marketing through one platform and transactional mail through another are judged on the combined rate. Google publishes 0.3% as the hard line and treats 0.1% as the working ceiling; Yahoo calculates more strictly, counting only inbox-delivered mail, so a sender comfortable at Gmail can be over the line at Yahoo without realising it.
Getting it wrong is expensive to undo. A domain that repeatedly crosses the line risks a listing on a blocklist such as the Spamhaus DBL, which is felt across corporate filters worldwide rather than at a single mailbox provider, and recovering a damaged reputation takes weeks of disciplined sending. The cheaper path is to clear the gate correctly the first time and stay inside the limits continuously, which is the work this service exists to do.
Does authentication get you into the inbox?
Passing SPF, DKIM and DMARC gets your mail through the door. It does not get it into the inbox. Across 2025, fully authenticated mail still landed in spam more than 30% of the time, because once a provider confirms who you are it weighs how recipients treat you: opens, replies, deletions and complaints.
That is the part you cannot fix with a record in your DNS. It takes a clean IP and domain reputation, steady sending volume, list hygiene, and complaint monitoring against each provider's own data. It is operational work, run continuously, and it is where most senders quietly lose the inbox.
Owned infrastructure, or a shared ESP.
Underneath every sending program is one decision: do you own the reputation you send on, or rent a share of someone else's?
A managed email service such as SendGrid or Mailgun is quick to start and fine at low volume, but most plans put you on a shared IP pool, which means your inbox placement is shaped by every other sender on the same addresses. When a neighbour on the pool sends badly, your mail pays for it, and you cannot see or choose who you are pooled with. Amazon SES is cheaper at scale and sends from a managed pool by default. In each case the reputation you depend on is partly out of your hands, and deliverability is something you can only influence rather than control.
Owning the infrastructure means running your own mail-transfer agent on dedicated IPs, so the reputation reflects your sending and no one else's. It gives you control of deliverability and of the data, and at volume it costs a fraction of a managed plan. The price of that control is expertise: IP warmup, bounce and feedback handling, authentication, monitoring, and someone on call when an address gets listed. That is the gap most senders cannot cross alone, and it is the gap we fill.
We run the owned model as a managed service. You get the control, the data ownership and the economics of running your own platform, without hiring the deliverability engineer or carrying the pager yourself. The reputation is yours; the operating burden is ours.
| Shared ESP | Owned, run by us | |
|---|---|---|
| Reputation | Shared with the pool | Yours alone |
| IP control | Little to none | Dedicated and warmed |
| Data | On the provider's cloud | Inside the EU, on our metal |
| Cost at scale | Climbs steeply | A fraction, at volume |
| Expertise needed | Hidden in the price | Ours, run for you |
| Best when | Low volume, simplicity | Steady volume, control, data |
What we run for you.
The full sending stack, operated as one service rather than handed off across vendors.
Deliverability audit
A test send from each of your services, mapping authentication gaps, alignment problems and blacklist exposure before anything changes.
Authentication
SPF, DKIM and DMARC set up and aligned to your From domain, with a path from p=none to enforcement, plus BIMI where it earns its place.
Dedicated IPs & warmup
Dedicated sending IPs on our own PowerMTA platform, warmed on a schedule so you own your reputation instead of sharing someone else's.
Sending infrastructure
PowerMTA tuned for throughput and compliance: rate shaping per provider, bounce and feedback-loop handling, one-click unsubscribe headers.
Monitoring
Google Postmaster Tools v2, Yahoo Sender Hub and Microsoft SNDS watched together, with complaint rates tracked against each provider's own numbers.
List hygiene & engagement
Suppression, re-engagement and removal of contacts who have stopped opening, so volume does not drag your reputation down.
We run PowerMTA ourselves.
Most "deliverability" offers resell a slot on a shared ESP and put their logo on the dashboard. When the IP pool sours, you inherit a reputation you never controlled. We operate the mail platform, the dedicated IP block and the monitoring under our own name, inside the EU, so the reputation you send on is one we tune and answer for.
# dedicated source IP + DKIM signing for this pool <virtual-mta pool-eu-1> smtp-source-host 203.0.113.21 mail.example.com domain-key /etc/pmta/dkim/s1.example.com.pem,s1,example.com </virtual-mta> # warm slowly, shape per provider — raise as reputation builds <domain gmail.com> max-msg-rate 90/h max-smtp-out 4 backoff-to-normal-after 30m bounce-after 4d12h </domain> <domain yahoo.com> max-msg-rate 60/h dkim-sign yes </domain>
Why must a dedicated IP be warmed up?
A dedicated IP gives you a reputation that is yours alone, but a fresh one carries no history, and a mailbox provider treats an unknown address sending at volume as a risk. Pushed hard from the first day, a new IP gets throttled or filtered within days. The answer is warmup: raising volume on a graduated schedule over weeks, starting with your most engaged recipients, so the providers see a sender that grows the way a real business does and build trust in it rather than suspicion.
The same applies to a new sending domain, which earns reputation separately from the IP. We warm both together, hold the early volume to engaged contacts, and watch the provider signals as we ramp, slowing the schedule when complaints rise rather than forcing through a problem. A dedicated IP only pays off above a certain steady volume, because reputation fades without consistent sending; below that, a shared pool is the better choice, and we say so rather than place a dedicated IP that would sit half-idle and cold.
Reputation is a pattern, not a setting.
Mailbox providers judge a sender on behaviour over time rather than on any single message. A sudden spike in volume, a drop in engagement, a rise in complaints, a burst of bounces from a stale list: each reads as a change in pattern, and the providers respond by holding more of your mail back. Good deliverability is a discipline of consistency, sending steady volume to people who want the mail and removing those who have stopped engaging before they sour the numbers.
Part of that discipline is keeping streams apart. Transactional mail, the receipts and resets people expect and open, earns strong engagement and a clean reputation; marketing mail is more variable. Sent from the same domain and IP, a rough marketing campaign can drag your password-reset emails into spam with it. We separate the streams onto their own domains and IPs so a problem in one cannot contaminate the other, which is the architecture a serious sending program needs and a single shared account rarely provides.
What does it cost to own your sending?
Owning the infrastructure changes the economics at volume. A managed ESP bundles the software, the IPs, the deliverability work and the support into one bill that climbs with every thousand messages, and at high volume that can run into four figures a month. A self-hosted platform on dedicated servers costs a fraction of that to operate, which is why the shift toward owned and hybrid infrastructure has accelerated as mail-transfer agents such as PowerMTA and KumoMTA have matured.
The honest part is that the saving is not free. Standing up owned infrastructure takes an upfront investment and a period of running the old and new paths in parallel during migration, and operating it well takes the expertise and monitoring that a managed plan hides inside its price. We carry that for you. Where reliability is paramount we keep a managed path as a thin fallback for the rare occasion the primary has trouble, so you get owned economics for the bulk of your mail and a safety net for the edge cases. We tell you where the crossover sits for your volume rather than push owned infrastructure at a scale that does not yet justify it.
Who runs on owned infrastructure?
Product and SaaS teams sending transactional mail at volume rely on it, because a receipt, a verification code or a password reset that lands in spam erodes the trust the product is built on, and these senders need both reliability and the stream separation that protects it. Marketers and e-commerce senders come to it when their campaigns are large enough that a shared pool's neighbours threaten placement. Agencies and publishers reach it when they are consolidating sending off a patchwork of shared accounts onto a single reputation they control.
The common thread is volume and stakes high enough that deliverability has become a business risk rather than a configuration detail. Senders below that point are usually well served by a shared ESP, and we will tell you if that is you rather than sell you a platform you do not need. The ones who benefit are those for whom a few points of inbox placement translate into real revenue, and who would rather own the reputation behind their mail than rent a share of someone else's.
Deliverability you can see.
Reputation is invisible until mail starts missing, which is why we watch the providers' own signals continuously and report them back to you. Google Postmaster Tools shows domain reputation and spam rate as Gmail sees it; Microsoft SNDS and Yahoo's sender tools do the same for their networks; DMARC aggregate reports reveal authentication as the wider world sees it. Read together, they give an early picture of trouble forming rather than a post-mortem after a campaign has gone out half-blind.
What you get is a clear view of where your sending stands rather than a black box with a logo on it: the complaint rates against each provider's threshold, the placement trend, the blocklist status and the authentication results. When a number moves the wrong way we act on it and tell you, rather than wait for you to notice open rates sliding. Visibility is part of owning the reputation, and it is the part a shared platform tends to hide.
Questions buyers ask.
What are the 2026 bulk-sender requirements?
What spam complaint rate is safe?
Do transactional emails need one-click unsubscribe?
Why do authenticated emails still land in spam?
Do I need a dedicated IP?
Where is the infrastructure operated?
What is the difference between PowerMTA and KumoMTA?
How long does IP warmup take?
Should transactional and marketing email be separated?
At what volume should I move off a shared ESP?
Can you migrate us off our current ESP without losing deliverability?
Do you keep a managed fallback in case the platform has trouble?
Is BIMI worth setting up?
How do you measure inbox placement?
Can you handle both transactional and marketing sending?
What happens if one of our IPs gets blacklisted?
Do you support cold or outbound email?
Should we get a deliverability audit first?
Can you work with our existing ESP rather than replace it?
Send us your domain. We'll tell you what's broken.
We test your authentication, alignment and blacklist exposure, then report what is failing before you commit to anything. If the fix is a record you can add yourself, we will say so.