Postmortem: The Phish with Valid SPF a SEG Couldn't Stop

The alert looked benign at first. Just another user-reported phish that the Secure Email Gateway (SEG) had correctly delivered to the inbox. It had no malicious payload, no known bad URLs, and a clean SPF pass. Case closed? Not quite. The sender purported to be the CFO of a new key vendor, asking for an urgent review of an attached invoice link. Everything about the social engineering was textbook, yet the technical verdict from the SEG was 'clean.'

This is the kind of incident that keeps analysts up at night. It’s not the obvious malware or the loud, block-and-tackle spam campaign. It’s the quiet phish that follows just enough of the rules to slip through automated defenses. The machine saw a valid technical signal and made a bad judgment call.

Let’s dissect how a threat actor used a perfectly valid SPF record to lend legitimacy to their campaign, bypass a SEG, and land a credential harvester right in front of a high-value target. More importantly, we'll walk through the other, weaker signals that, when correlated, painted a clear picture of malicious intent.

Anatomy of the Spear Phish That Landed

The email was simple and effective. The subject line read, "Urgent: Overdue Invoice [INV-2024-9812] for Q2 Services." The sender name was crafted to appear as the CFO of a company in our supply chain, a name any accounts payable employee would recognize. The body of the email was short, polite, and conveyed urgency, explaining that their payment portal was down and asking the recipient to review the invoice via a new 'secure document portal' link.

The link, of course, led to a credential harvesting page skinned to look like a Microsoft 365 login. The SEG scanned the link and found nothing—it was hosted on a freshly provisioned server and hadn't been flagged by any threat intelligence feeds yet. No malware, no known bad signature. From the SEG's perspective, this was just an email from a new sender with a link.

The most critical piece of the puzzle was the sender's domain. It wasn't the vendor's actual domain, but a lookalike. Think `vendor-corp.com` instead of `vendor.com`. Close enough to pass a hurried glance. The attacker had full control of this domain, which is the key to understanding how they defeated the first layer of email authentication.

Header Analysis: That 'SPF Pass' Was a Red Herring

When we pulled the headers, the smoking gun seemed to point toward innocence. The `Authentication-Results` header, the first place any analyst looks, was clear.

Authentication-Results: seg.ourcompany.com; spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=billing@vendor-corp.com;

An SPF `pass` verdict feels authoritative. But what does it actually mean? According to RFC 7208, Sender Policy Framework (SPF) only validates one thing: that the IP address sending the email is authorized to send mail on behalf of the domain specified in the `MAIL FROM` command of the SMTP conversation. This address, also known as the envelope sender or Return-Path, is often invisible to the end-user. It's a path for bounces, not a declaration of identity.

The Critical Gap: Authentication vs. Alignment

The attacker registered `vendor-corp.com`, set up a mail server at `203.0.113.10`, and then published an SPF record for `vendor-corp.com` that said, `v=spf1 ip4:203.0.113.10 -all`. Of course it passed. They controlled the domain, the IP, and the DNS record. It was a self-fulfilling prophecy.

This is where DMARC (RFC 7489) becomes so important. DMARC introduces the concept of 'alignment.' For a DMARC pass, not only must SPF (or DKIM) pass, but the domain used for SPF authentication (the `Return-Path` domain) must align with the domain the user sees in the `From:` header. In this case, since the attacker used `billing@vendor-corp.com` as both the `From:` address and the `Return-Path`, DMARC would technically find the domains in alignment. The problem isn't a technical failure of the protocol; it's that the entire identity is fraudulent. The SEG saw alignment for a garbage domain and assigned it trust it hadn't earned.

Pivoting to Domain Reputation: The NRD Signal

Since the header authentication checks led to a dead end, the next pivot is always to external reputation. If an email's technicals are sound but the intent feels wrong, investigate the infrastructure behind it. For us, that started with a simple `whois` lookup on the sender's domain, `vendor-corp.com`.

The result was immediate and damning. The `Creation Date` was less than 24 hours ago. This is what we call a Newly Registered Domain (NRD), and it's one of the most powerful indicators of malicious activity. Think about it operationally: what legitimate enterprise registers a new domain on a Tuesday and uses it for critical financial communication on a Wednesday? Almost none. Businesses need time to set up infrastructure, propagate DNS, and warm up IP addresses.

Attackers, on the other hand, treat domains as disposable ammunition. They register one, use it for a few hours until it's burned (i.e., added to blocklists), and then move on to the next one. An NRD has no history, no reputation to ruin. For a SEG that relies heavily on historical data to build reputation scores, an NRD is a ghost. It presents a blank slate, which many systems incorrectly interpret as 'neutral' or 'harmless' rather than 'deeply suspicious.' This is a catastrophic failure of logic.

Correlating Weak Signals into a Strong Verdict

The NRD was a huge red flag, but one signal is a finding, not a conclusion. A solid security analysis requires correlating multiple data points. A single weak signal can be an anomaly; three or four of them moving in the same direction is a verdict. So we kept digging.

ASN, rDNS, and the Lack of Policy

First, we looked at the sending IP, `203.0.113.10`. An ASN lookup showed it belonged to a small, low-cost VPS provider in a jurisdiction known for lax abuse policies. Major corporations do not send their financial correspondence from budget hosting providers. They use established enterprise email services like Microsoft 365 or Google Workspace, or their own dedicated, reputable mail exchangers. This IP's 'neighborhood' was a strong negative signal.

Next, the reverse DNS (rDNS) for the IP was a generic, provider-assigned name like `10-113-0-203.vps-provider.net`. A legitimate mail server would typically have a descriptive rDNS record that matches its forward DNS, like `mail.vendor.com`. Generic rDNS isn't a smoking gun by itself, but combined with the NRD and the low-reputation ASN, it contributes to a profile of disposability and haste.

Finally, we checked the domain's other DNS records. The attacker had an SPF record, but there was no DKIM signature (RFC 6376) in the headers and, critically, no DMARC record published in DNS. The lack of a DMARC policy is telling. It signals that the domain owner is unwilling to state an enforcement policy (`p=quarantine` or `p=reject`) for messages that fail authentication. Legitimate organizations work hard to deploy DMARC to protect their brands. Attackers don't, because their domains are meant to be thrown away.

Playbook: Augmenting SEG Alerts with Reputation Triage

This incident exposes a fundamental flaw in relying solely on automated SEG verdicts for sophisticated threats. We can't afford to implicitly trust a `pass` on a single authentication check. Analysts need a simple, repeatable playbook for when their gut tells them a 'clean' email is dirty.

First, validate the basics in the headers. Look at the `Authentication-Results`. If SPF passed, what domain was validated in the `smtp.mailfrom`? Does it match the human-readable `From:` header domain? If they match, the next step is crucial.

Pivot immediately to the `From:` domain's reputation. Run a `whois` and check the creation date. Is it an NRD? A domain created within the last 30-90 days that is being used for financial or sensitive communication should be considered guilty until proven innocent.

Then, expand the investigation to the sending infrastructure. Identify the source IP from the `Received` headers. Check its ASN reputation and its rDNS. Is it a disposable VPS or a trusted enterprise mail provider? Is the rDNS generic or professional?

Finally, check for the presence and strength of other policy records. Does the domain have a valid DKIM signature? Does it have a DMARC record, and if so, is the policy `p=none` or something stronger? The absence of these is as much a signal as their presence. This entire process builds a 'reputation score' in your head that is far more reliable than the SEG's binary pass/fail.

The takeaway

A Secure Email Gateway is designed to filter the torrent of commodity threats, and it does that job well. But it's not an intelligence engine. In this case, it saw a technically valid SPF record and stopped thinking, letting a well-crafted phish sail right through. The system checked a box, but failed the logic test.

The real defense is a combination of automated filtering and sharp human analysis. The analyst's value is in correlating the weak signals the machine discards—domain age, ASN reputation, rDNS, and policy gaps. Don't just trust the `spf=pass`. Question the identity behind it. A quick, on-demand triage process that pulls together these disparate signals, often with the help of specialized tools like MailSleuth.AI to accelerate the header and reputation analysis, is what separates a near-miss from a full-blown incident.