The conventional wisdom on email address validation is well-established and relatively simple: syntactic checks at the client side, followed by sending a confirmation link to the address in question. You cannot determine whether an email address is genuinely reachable without attempting delivery, and attempting delivery is precisely what a confirmation email does. The advice has been repeated so many times across Stack Overflow threads, RFC commentaries, and developer documentation that it borders on axiomatic.
Which makes the behaviour documented at milek7.pl/mailverifyspam/ all the more remarkable. Somebody, presumably with access to engineering resources and product requirements, decided to validate email addresses by routing them through what appears to be an operational spam network. This is not a theoretical concern or a contrived edge case. It is a live production system, triggered by filling in a sign-up form on a commercial product called Pangram.
The Mechanics of the Scheme
The validation flow is straightforward to reconstruct. When a user enters an email address into Pangram's sign-up form, the frontend fires a POST request to https://www.pangram.com/api/validate-email with the address as a JSON payload. Shortly after, the submitted address receives an unsolicited email. The email does not come from Pangram. It arrives from a sender domain like sifgoldenshine.com, with a subject line such as "Fact of the day: Magnetic", and a body that is a base64-encoded HTML message containing a Wikipedia-style paragraph about magnetic domains, hidden via CSS positioning tricks (position: absolute; left: -9999px).
The CSS hiding technique is a known spam obfuscation method. The idea is to include what appears to be benign, topically coherent text that might fool Bayesian content filters, while keeping it invisible to the human recipient. The fact that this content is present at all is a strong indicator that the sending infrastructure is purpose-built for spam delivery, not transactional or marketing email.
The sender domain rotation is extensive. The original post documents over two dozen domains in use, including names like ghostlygourd.com, hydroponicseeders.com, and platformerboss.com. This kind of domain churn is standard operational security for bulk unsolicited mail: it distributes sending reputation across many identities, making it harder for any single domain to accumulate enough negative signals to be universally blocked.
DNSBL Evasion and Delivery Persistence
The mail server logs reproduced in the original post reveal something particularly telling about the sophistication of this operation. When a delivery attempt from one IP address is rejected because that address appears on a DNS-based blocklist (in this case, both spam.spamrats.com and b.barracudacentral.org are cited), the system immediately retries from a different server on a different IP. The retry succeeds because the fallback IP has not yet accumulated a blocklist listing.
This retry-on-rejection behaviour is not something you build by accident. It requires:
- A pool of sending servers across multiple IP ranges, likely across multiple ASNs or hosting providers
- Real-time feedback from SMTP rejection codes, specifically parsing the 5xx response to identify DNSBL-based blocks versus other rejection reasons
- Orchestration logic that selects a clean IP for the retry
This is a meaningful engineering investment. The fact that some of these IPs are already listed on SpamRats and Barracuda Central is itself informative: those services list IPs based on observed spam behaviour. The infrastructure being used here has a documented history of sending unsolicited mail.
The logical contradiction at the heart of this scheme becomes apparent when you consider what "validation" means in this context. If the destination mail server accepts the message, the address is deemed valid. But acceptance is a function of the server's content filtering and IP reputation checks at that moment, not a property of the address itself. An address can be perfectly real and yet cause this validation to fail, simply because the receiving server has aggressive spam filtering. Conversely, a catch-all domain will accept mail for any address regardless of whether it corresponds to a real user. The signal being measured is not address validity; it is deliverability via a specific spam infrastructure to a specific server at a specific point in time.
The Third-Party SaaS Question
Pangram's actual transactional mail is sent through Mailgun, a legitimate ESP with standard deliverability tooling. This means the spam delivery is not an accidental misconfiguration of their own mail infrastructure. Something external is being called when that validation endpoint is hit.
The most plausible explanation, as the original author notes, is that Pangram is consuming a third-party email validation SaaS that uses this delivery-based approach. The email validation SaaS market is substantial and largely unregulated. Services in this space typically offer tiered validation: syntax checking, MX record lookup, SMTP handshake probing (connecting to the mail server and issuing a RCPT TO without completing the transaction, sometimes called a "catch-all check"), and in some cases actual delivery probing.
Delivery probing via actual message transmission is the logical terminus of this escalating verification arms race. If you want to know whether mail will be delivered, deliver mail. The problem, of course, is that this constitutes sending unsolicited email to addresses that have not consented to receive anything. The fact that the message is hidden via CSS and contains random educational content rather than a commercial offer does not change its legal or ethical status. Under GDPR, CAN-SPAM, and CASL, the consent requirements attach to the act of transmission, not to the content's commercial nature.
There is also the question of what happens to the address data once it enters this validation pipeline. An email validation SaaS that operates its own sending infrastructure has, by definition, collected and processed every address submitted to it. The privacy implications of routing user-submitted addresses through an unrelated third-party spam network are non-trivial, particularly for a product like Pangram that is presumably subject to standard data processing obligations.
Failure Modes and Systemic Implications
Beyond the immediate absurdity, this case illustrates a broader failure mode in how engineering teams evaluate third-party services. The validation endpoint presumably returns a boolean or a confidence score. From the perspective of the team integrating it, it is a black box that answers the question "is this email address valid?" The fact that answering that question involves sending spam is invisible at the integration layer.
This is a known problem in software supply chain security and has analogues in other domains: a dependency that performs unexpected network calls, a logging library that exfiltrates data, a font CDN that tracks users. The difference here is that the externality falls on third parties (the recipients of the spam) rather than on the integrating organisation's own users or infrastructure.
There is a reasonable argument that this represents a gap in how email validation APIs are described and marketed. If a service's documentation says "verify email addresses" and the mechanism is "send them spam", that gap between description and implementation is a material misrepresentation. Developers integrating such a service have no reasonable way to discover the underlying mechanism without the kind of traffic analysis documented here.
The broader implication is that any organisation using a third-party email validation API should audit what that API actually does. A simple test is sufficient: submit a monitored address, observe whether any mail arrives, and inspect the headers. If mail arrives from an unrelated domain with obfuscated content, the service is operating as a spam relay. The appropriate response is to terminate the integration immediately and evaluate the data processing implications of having already submitted addresses to it.
What Correct Validation Looks Like
For completeness: the correct approach to email validation at sign-up is to perform a syntax check against RFC 5321/5322 (or a well-maintained library that handles the edge cases), optionally check for MX records on the domain, and then send a confirmation email through your own legitimate sending infrastructure. The confirmation email serves as both the validation mechanism and the consent capture. Nothing else is needed. Nothing else is appropriate.
The scheme documented here is a cautionary example of what happens when the engineering goal (validate addresses) is pursued without adequate consideration of the mechanism, the legal context, or the third-party services involved. It also demonstrates that spam infrastructure continues to find novel integration points, and that the line between "email validation service" and "spam network" can be thinner than it appears from a developer's API documentation.