Anatomy of a Bypass: When a 'Clean' Reputation Report Is a Lie

The alert landed in the queue with a thud. Not a literal one, of course, but the kind of psychic weight that tells you this is either a massive false positive or something clever. A user had reported a textbook credential harvesting attempt: an urgent 'Action Required: Verify Your Annual Bonus Details' email, complete with a link to a fake login portal.

Instinctually, I pulled the headers, expecting the usual smoking gun. A blatant SPF fail. A DKIM signature mismatch from a sloppy forwarder. An IP on a dozen blacklists. But there was nothing. Green checkmarks all the way down. The domain reputation tools showed no history of abuse. SPF, DKIM, and DMARC all returned 'pass'.

This is the kind of phish that gives security teams nightmares. It's not the loud, obvious attack that gets caught by every filter. It's the quiet one, the one that looks legitimate on the surface. The one that requires you to stop trusting your dashboard and start connecting the dots yourself.

The All-Green Dashboard Deception

When you're triaging dozens of alerts an hour, you develop a reliance on at-a-glance verdicts. Pass/fail. Green/red. It’s a necessary shortcut. But attackers know this, and they design their campaigns to exploit that very efficiency. This email was a masterclass in it.

Every primary email authentication mechanism gave the message a clean bill of health. The machine's verdict was unequivocal: This is a legitimate email. The security gateways saw no reason to quarantine it, let alone block it. The user's report was the only reason it was on my screen.

Authentication-Results: mta.example.net; dkim=pass header.d=rewards-portal.co; spf=pass (sender IP is 198.51.100.24) smtp.mailfrom=alerts@rewards-portal.co; dmarc=pass action=none header.from=rewards-portal.co

Look at that line. It's what every well-configured domain administrator strives for. SPF passed because the sending IP was explicitly listed in the domain's SPF record. DKIM passed because the cryptographic signature in the header was valid and the message body was unaltered. And DMARC, the supposed protector against impersonation, also returned a 'pass' because the SPF and DKIM domains aligned with the `From:` header.

On paper, this email is more technically sound than half the legitimate marketing mail I see. But the headers don't tell the whole story. They tell you *what* happened, but they don't tell you *why* or *who* made it happen. That's where the real analysis begins.

Deconstructing the 'Pass' Verdicts

A 'pass' verdict doesn't mean 'trustworthy.' It's a statement about technical compliance, not intent. Most SOC analysts learn this the hard way, but it's a lesson worth repeating. The attacker in this incident perfectly manipulated each protocol to say exactly what our filters wanted to hear.

SPF: A Self-Issued Permission Slip

A passing SPF check, governed by RFC 7208, only confirms that the sending IP address is authorized by the domain's owner. The problem? The attacker *was* the domain's owner. They registered `rewards-portal.co` themselves, so they could add any IP they controlled to their SPF record. A `v=spf1 ip4:198.51.100.24 -all` directive on a domain you control is just you giving yourself permission. It's a valid check against third-party impersonation, but it's completely circular as a trust signal when the domain owner is the adversary.

DKIM: The Unbroken, Albeit Malicious, Seal

Similarly, a DKIM pass (RFC 6376) simply proves two things: the signing domain (seen in the `d=` tag of the DKIM-Signature header) is aligned with the `From:` header, and the message hasn't been modified in transit. The attacker generated their own DKIM keys, published the public key in their DNS, and signed their own malicious email. The signature was cryptographically perfect. DKIM prevents in-transit tampering, like a mail gateway adding a footer and breaking the body hash, but it offers zero judgment on the original content.

The DMARC p=none Smokescreen

This was the first real crack in the facade. DMARC (RFC 7489) has a policy directive, the `p=` tag, that tells receivers what to do with failing messages. Legitimate organizations quickly move to `p=quarantine` or `p=reject` to actually enforce their policy. This domain, `rewards-portal.co`, was using `p=none`. This is 'monitoring mode'. It translates to: 'Tell me if authentication fails, but deliver the email anyway.' For a sender, it offers visibility. For an attacker, it's the perfect way to look compliant without facing any consequences if their setup is imperfect or gets routed through a problematic forwarder. It's the email security equivalent of putting up a 'Beware of Dog' sign for a chihuahua. It's technically a sign, but it carries no real threat.

Pivoting from Email to Infrastructure

Once you see the weakness in the authentication layer, the next step is to investigate the foundation it's built on. Who is this sender, and where are they operating from? The email itself is just the payload; the infrastructure is the weapon system.

The Suspiciously Young Domain

A quick WHOIS lookup on `rewards-portal.co` was the next major flag. The domain was registered 18 days ago. This is a classic indicator of a phishing campaign. Threat actors register domains and let them 'age' for a couple of weeks. Why? Because many reputation systems automatically flag or heavily scrutinize mail from Newly Registered Domains (NRDs), typically defined as anything under 7 or 14 days old. By waiting just a bit longer, they slide past this first, coarse filter. It demonstrates patience and an understanding of how security stacks work.

Tracing the Autonomous System

Next, I pivoted to the sending IP from the `Received` header: `198.51.100.24`. A reverse DNS lookup was uninformative, returning a generic ISP hostname. But looking up the IP's parent ASN (Autonomous System Number) told a different story. It belonged to a small, obscure hosting provider known colloquially as a 'bulletproof' or, more charitably, 'low-cost' VPS provider with a history of lax abuse response. While the specific IP wasn't on a blacklist, the neighborhood was questionable. Legitimate businesses don't typically send corporate mail from these corners of the internet. They use established ESPs or their own well-managed mail infrastructure on reputable network blocks.

Reconstructing the Attacker's Playbook

With these pieces, we can move from triage to threat intelligence, reconstructing the adversary's likely sequence of operations. This isn't guesswork; it's a logical progression based on the evidence.

First, the attacker registers the domain, `rewards-portal.co`, likely using a registrar that accepts cryptocurrency and offers WHOIS privacy. They immediately point it to a cheap virtual private server rented from that low-reputation hosting provider.

Second, within a day, they perform the 'compliance dance'. They configure a mail server, generate DKIM keys, and publish the necessary DNS records: an SPF record authorizing their server's IP, the DKIM public key, and a `p=none` DMARC record. This entire process takes maybe an hour. They might even set up an MTA-STS (RFC 8461) policy, though its absence is more common and another small signal.

Third comes the 'aging' phase. For the next two to three weeks, the domain sits mostly dormant. The threat actor might send a handful of non-malicious emails to free mail accounts they control (Gmail, Outlook.com) to simulate normal activity. This 'warming' process establishes a neutral reputation. There are no sudden volume spikes, no bounces, nothing to alert a reputation engine that something is amiss.

Finally, the attack is launched. The email, with its urgent social engineering and pristine technical record, is sent to the target list. By the time it hits our gateway, the domain is just old enough to evade NRD filters, the IP is clean, and every authentication check passes. It was designed from the ground up to defeat automated, checklist-based defenses.

From Checklists to Context: An Aggregated Trust Score

The failure here wasn't in any single protocol. SPF, DKIM, and DMARC all did exactly what they were designed to do. The failure was in a triage model that treats these signals as independent booleans instead of correlated data points in a larger model of trust.

Let's review the signals, not as pass/fail, but as weights on a scale.

Domain Age < 30 days (+10 risk points)
DMARC policy is p=none (+15 risk points)
ASN has poor reputation (+20 risk points)
SPF/DKIM pass but self-issued (+5 risk points)

Individually, none of these might cross a blocking threshold. A `p=none` policy is common for new domains. Young domains aren't always malicious. But together? A young domain, using a non-enforcing DMARC policy, sending from a shady ASN is a pattern. It's a clear and present indicator of malicious intent. This is the difference between checking boxes and analyzing context.

The operational takeaway is that your security stack needs to think like an analyst. It must be capable of correlating these seemingly low-severity signals. It needs to understand that a 'pass' from an 18-day-old domain is not the same as a 'pass' from a 10-year-old financial institution. Context is everything.

The takeaway

Relying on individual pass/fail verdicts from email authentication protocols is an invitation for sophisticated attackers to bypass your defenses. They are masters of mimicry, creating campaigns that are technically perfect but strategically malicious. Your triage process, whether human or automated, must evolve to match.

Trust is not a boolean. It's a calculated score based on a mosaic of evidence. The most dangerous phish isn't the one with a glaring error; it's the one that looks just right. Building a richer, aggregated view of risk by correlating signals like domain age, DMARC policy stringency, and ASN reputation is essential. It's a core principle we've built into tools like MailSleuth.AI, because spotting the pattern is how you stop the attack before the user even has a chance to click.