IP Address: 2a0a:9302:1:628::1
This page shows DMARC authentication failure data for this IP address. Learn more about this data.
Geolocation Information
- Country:
- RU Russia
- Region:
- Moscow
- City:
- Moscow
- Coordinates:
- 55.7487, 37.6187
WHOIS Information
- Network Name:
- PSERVERS-CLOUD-HOSTING
- Owner:
- ORG-IP78-RIPE
Analysis
This IP was observed generating a single DMARC authentication failure on April 21, 2026. With only one data point, the event is better read as a single suspicious observation than a sustained campaign. Every message observed from this source failed both SPF and DKIM verification. Receiving mail providers applied a reject disposition, refusing delivery outright.
The address has no reverse DNS record. Legitimate mail infrastructure almost always publishes a PTR record, because major receivers (Gmail, Microsoft 365, Yahoo) penalize or reject mail without one, and because it is a baseline operational hygiene expectation. Its absence, combined with authentication failure, is consistent with a host being used to originate spoofed mail rather than one misconfigured by a legitimate operator. The ::1 host portion of this IPv6 address is notable: cloud providers typically allocate a full /64 to each customer, and low-suffix addresses like this are what default provisioning scripts assign to fresh virtual machines, a pattern more consistent with a short-lived abuse host than a deliberately configured mail relay.
Geolocation places the host in Moscow, Russia, within infrastructure operated by ORG-IP78-RIPE. Sanctions, regional routing policies, and limited abuse-response channels in this jurisdiction mean upstream takedown through the provider is typically slow or unavailable. Receiver-side filtering is the most reliable mitigation.
The address is registered to ORG-IP78-RIPE (PSERVERS-CLOUD-HOSTING), an enterprise network operator. Concentrated authentication failures on enterprise address space can indicate either a compromised internal host being used as an unauthorized sending relay, or an organization knowingly or unknowingly operating as a spam source.
Across the wider PSERVERS-CLOUD-HOSTING network, 35 distinct IPs have been associated with 38 authentication failures over 49 observed messages, spanning 2 countries. Most observed IPs on this network contribute to the failure count, suggesting the range as a whole warrants elevated scrutiny.
For IPv6 addresses, per-address blocking provides minimal protection. Cloud providers and large networks typically allocate a full /64 prefix (containing approximately 18 quintillion addresses) to each customer. An attacker assigned a /64 can rotate through effectively unlimited addresses within the same prefix at no cost. Blocking should target the /48 or /64 prefix rather than the individual address.
If your domain appears in the From header of mail from this address, treat it as probable spoofing. Verify that your SPF record does not authorize this host, directly or through nested include mechanisms, and that no DKIM selector you publish has been issued to it. If both checks come back clean, the receiver's reject action is doing its job.
Your DMARC policy posture matters more than any IP-level response here. The enforcement action applied to this mail indicates your policy is already providing protection. Maintaining p=reject across all your domains closes the gap for attackers who manage partial alignment. Domains that remain at p=none long-term tend to be impersonated repeatedly, because the cost to the attacker of attempting is effectively zero.
Blocking this individual address has limited durability: an attacker can rotate to another address in the same /24 subnet at effectively zero cost. More durable responses include monitoring aggregate DMARC reports so new sources are visible as they emerge, tightening SPF to remove overly permissive include chains or +all mechanisms, and ensuring DKIM is signing every legitimate outbound stream so alignment failures are unambiguous. The formal abuse contact for ORG-IP78-RIPE is listed in RIPE WHOIS records, though response from this jurisdiction is typically slow or unavailable due to regional routing policies.
External Reputation Lookups
Look up this IP in external threat intelligence and reputation databases (opens in new tab):