Why does the new Microsoft SNDS portal only offer WHOIS authorization?
Published 23 Jul 2026
Updated 23 Jul 2026
10 min read
Summarize with
The new Microsoft SNDS portal often offers only WHOIS-based authorization because its access workflow now appears to derive eligible contacts from the registered owner of the IP address or netblock. It no longer consistently derives abuse@ or postmaster@ recipients from the IP's reverse DNS domain. A correct PTR record still matters for mail delivery, but it does not guarantee that an rDNS-based address will appear in the authorization picker.
When the address list contains only a carrier, hosting provider, cloud provider, or ESP contact, the practical route is to ask that organization to approve or delegate the range. There is no reliable DNS change that forces the new picker to offer a domain mailbox. Some users still see abuse@ choices, so the behavior is not uniform across every registry, IP range, or existing authorization.
What a clean PTR does not prove
A PTR such as mail.email.example.com proves which hostname reverse DNS returns. It does not prove that the requester owns the IP allocation. SNDS authorization now appears to put more weight on allocation ownership than hostname control.
I would treat this as observed portal behavior, not a formally documented promise that rDNS authorization has been permanently removed. Microsoft can change the selection logic, and transient registry lookup failures can also produce a shorter or incorrect address list.
Why the authorization choices changed
SNDS exposes reputation and complaint data for sending IPs, so Microsoft needs evidence that a requester has authority over those IPs. The older workflow could use addresses connected to the reverse DNS domain. The migrated workflow appears to query IP registry ownership data first and build the recipient list from the returned organization or network contacts.
That design is stricter for customers using dedicated IPs inside a larger allocation. The customer can control the sending domain, DKIM keys, PTR hostnames, and campaign system while the ESP or upstream network still owns the address block. WHOIS therefore points to the provider, not the customer operating the mail stream.
Earlier rDNS-based path
- Identity: The PTR hostname connected the IP to a domain.
- Recipient: A role mailbox at that domain could receive approval.
- Control: The sender could often complete access without its upstream.
- Weak point: Hostname control did not always prove netblock ownership.
New WHOIS-led path
- Identity: Registry data identifies the allocated network holder.
- Recipient: A listed network contact receives the request.
- Control: Customers often depend on the ESP or upstream provider.
- Weak point: Privacy, stale contacts, and lookup limits can block approval.
Microsoft SNDS request access screen with WHOIS-based authorization contacts.
Use the current Microsoft SNDS portal and confirm that the address list stays the same for one IP and the corresponding range. If it does, the result is tied to Microsoft's current ownership lookup rather than a formatting problem in the request.
What WHOIS-only authorization means
The key question is who controls the allocation, not who controls the PTR. A dedicated IP can be dedicated operationally while remaining part of an ESP-owned or carrier-owned netblock. If the provider is the registry holder, SNDS can reasonably send authorization there even when every PTR in the assigned subset points to the customer's domain.
|
|
|
|---|---|---|
PTR | Hostname control | Often insufficient |
WHOIS | Allocation holder | Primary contact source |
Delegation | Granted authority | Practical customer path |
Existing access | Earlier approval | Keep while valid |
Ownership signals that affect the practical authorization route.
Private or redacted WHOIS adds another problem. Microsoft can receive a proxy address, an upstream abuse desk, a generic organization contact, or no usable recipient. Registry APIs can also rate-limit automated queries. That can explain an empty list, a stale list, a surprising list, or a temporary error, but only Microsoft can confirm the cause of a specific lookup.
Do not change PTR records as a shortcut
Changing a production PTR solely to influence authorization can create forward-confirmed reverse DNS failures, disrupt provider configuration, and complicate reputation analysis. The new picker can ignore the change anyway. Use provider delegation or corrected registry data instead.
For a deeper ownership caveat, the explanation of private WHOIS impact covers why public contact data and operational control can diverge.
How to get access now
Start by preserving any working authorization. Existing access can continue until Microsoft expires it or the underlying range changes. Record the authorized ranges, account owner, approval recipient, and renewal date now. This prevents a later portal change from turning into an emergency.
- Confirm the range: Match every sending IP to its provider, allocation, and PTR hostname.
- Test both scopes: Request one IP and then the smallest valid range to compare recipients.
- Capture evidence: Save the displayed recipients, timestamp, range, and any portal error.
- Contact the owner: Ask the ESP or upstream to approve access or delegate the IP range.
- Escalate precisely: Give Microsoft the account, IP range, registry, expected contact, and exact error.
For ESP-managed dedicated IPs, delegation is the cleanest operational route when the ESP controls WHOIS. Ask for a repeatable process, not a one-time favor. The request should name the customer's Microsoft account, exact CIDR or IPs, required access period, and internal owner for renewals.
Flowchart for requesting Microsoft SNDS access through a WHOIS contact.
If the portal returns an unexpected fault, retry later before changing DNS. Test a single IP, use a clean browser session, and avoid submitting many ranges at once. Reports suggest a small request batch limit, but the observed limit is not a reliable ownership rule. A repeated failure with the same range deserves a support case.
Checks to run before escalation
Before escalating, verify that each IP has a stable PTR and that the returned hostname resolves forward to the same IP where the provider supports that setup. Confirm that the sending domain publishes valid SPF, signs with DKIM, and has a DMARC record. These checks will not unlock SNDS, but they separate an access-control problem from an email authentication problem.
A broad domain health checker can expose broken authentication or DNS records before the provider and Microsoft investigate. Keep the results with the SNDS screenshots so each party sees the same technical state.
Also compare the IP allocation against your service contract. "Dedicated IP" can describe exclusive sending use without transferring registry ownership. That distinction often explains why the customer expects its own mailbox while the portal selects the ESP.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Once DNS is clean, reproduce the authorization request and write down the exact sequence. Include whether one IP and the encompassing range show identical contacts. If the address list changes between attempts without any registry update, mention that instability in the support case.
Check the new SNDS URL before diagnosing an old bookmark or retired workflow. A valid account in the current portal removes one common source of misleading errors.
Minimum support case details
- Account: The Microsoft account used for the request.
- Network: The exact IP or CIDR and its registry.
- Evidence: Screenshots of recipients and the full error.
- Expectation: The correct allocation contact and why it should apply.
Monitor deliverability while access is pending
SNDS access is useful, but waiting for authorization should not pause monitoring. Keep watching authentication pass rates, complaint signals available through your sending system, bounce codes, domain policy, and IP or domain blacklist (blocklist) status. A real message test also reveals header alignment and routing problems that a portal access request cannot show.
Send a controlled message through the affected dedicated IP and inspect it with the email tester. Repeat after DNS or provider changes so the evidence reflects the actual production route.
For most teams, Suped is the best overall DMARC platform for this workflow because it turns aggregate authentication data into detected issues and concrete steps to fix them. Suped does not replace SNDS authorization. It covers the domain-level evidence and ongoing controls that remain available while network ownership is being resolved.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC monitoring keeps SPF, DKIM, and DMARC results together, while real-time alerts surface changes that need attention. Hosted DMARC supports staged policy management, and hosted SPF or SPF flattening helps teams manage senders while staying within lookup limits.
- Authentication: Track SPF, DKIM, DMARC policy, and sending-source changes.
- Reputation: Use blocklist monitoring for domain and IP blacklist checks.
- Operations: Route automated findings and repair steps to the responsible owner.
- Scale: Manage multiple client domains through Suped's MSP dashboard.
The practical boundary stays clear: SNDS reports Microsoft's IP-level view, while Suped connects authentication, deliverability signals, blocklist status, and policy management around the domains using those IPs. Keeping both workstreams documented makes it easier to prove whether a problem belongs to DNS, the sending platform, the Microsoft portal, or the network owner.
Views from the trenches
Best practices
Document every authorized IP range, account owner, recipient, and renewal date in one register.
Ask the netblock owner for a repeatable approval process before existing access expires.
Capture the selected contacts and exact error before retrying or opening a support case.
Verify PTR, forward DNS, SPF, DKIM, and DMARC before treating the issue as authorization.
Common pitfalls
Assuming a dedicated sending IP means the customer also owns its registry allocation.
Changing production PTR records to influence a picker that can ignore reverse DNS entirely.
Submitting many ranges repeatedly when the portal is returning temporary lookup faults.
Waiting for SNDS access while leaving authentication and blacklist monitoring unattended.
Expert tips
Compare one IP with its smallest valid range to expose contact-selection differences.
Give the ESP the Microsoft account, exact CIDR, access period, and renewal owner upfront.
Preserve current authorizations and test them before a portal or provider migration date.
Keep registry ownership evidence beside DNS results so escalation stays narrowly scoped.
Marketer from Email Geeks says the migrated portal frequently relies only on WHOIS contacts, leaving senders dependent on upstream approval.
2026-07-15 - Email Geeks
Marketer from Email Geeks says some ranges still show an abuse mailbox, but choices that appeared before migration can disappear.
2026-07-15 - Email Geeks
Plan around network ownership
WHOIS-only choices usually mean Microsoft is authorizing the registered network holder rather than the operator of the PTR domain. If your ESP or upstream owns the allocation, ask it to approve or delegate access. If your organization owns the allocation, correct stale registry contacts and retry after the update propagates.
Do not rebuild working reverse DNS to chase an authorization option that the new portal does not display. Preserve current access, collect evidence, escalate repeated lookup errors, and keep authentication plus blacklist (blocklist) monitoring active. That approach protects the mail stream while Microsoft or the network owner resolves the access path.
