Clean IP, Dirty SPF: Triaging Conflicting Reputation Signals

The alert lands in your queue. An email from a potential new vendor, `new-saas-inc.com`, with an attached quote. The user flagged it as suspicious, but it passed the initial automated filters. Your security gateway gives its IP address a squeaky-clean reputation score. Everything looks fine on the surface.

But you dig into the headers. The domain was registered three days ago. The SPF record ends in `~all`. There is no DMARC record. The IP is clean because it belongs to a massive cloud provider, a digital haystack where good and bad actors coexist. Is this a legitimate, fast-moving startup with sloppy email hygiene, or is it a targeted phishing campaign warming up a new domain?

This is the core of modern email triage. It's not about finding a single 'bad' signal. It's about interpreting a chorus of conflicting signals to make a confident block or allow decision, fast.

The Cloud Provider's Cloak: Clean IP, Weak Auth

The most common conflict an analyst faces is a reputable IP address paired with dangerously permissive authentication. An IP from a major cloud provider or a reputable email service provider (ESP) will almost always have a neutral-to-positive reputation. But that reputation belongs to the provider's entire network block, not the specific tenant sending the email.

Threat actors know this. They can spin up a virtual server or an account on a popular ESP for a few dollars, effectively borrowing its IP reputation to bypass blocklists. Their temporary tenancy doesn't tarnish the provider's entire /24 block. This makes IP reputation a weak signal for legitimacy when dealing with large, multi-tenant platforms.

Decoding the `~all`

The real story is in the authentication results. When you see an SPF `softfail` verdict, it's because the domain's policy uses the `~all` mechanism. Per RFC 7208, a softfail result means the domain owner has explicitly stated that while the sending IP isn't on their approved list, they don't have the confidence to recommend rejection. It’s an admission of uncertainty.

For an analyst, `~all` is a giant red flag. It tells you the sender either doesn't fully understand their own mail flow or they're too afraid of breaking legitimate mail from forwarders and legacy systems to implement a proper `-all` (fail) policy. Either way, it creates a security gap that attackers can and will drive a truck through. It neuters the primary purpose of SPF, which is to provide a definitive list of authorized senders.

The Missing DMARC Policy

The problem is compounded when you check for DMARC (RFC 7489) and find nothing. A missing DMARC record, or one set to `p=none`, is a declaration of indifference. The domain owner is telling the world's mail servers, "I have no enforcement policy for messages that fail authentication and alignment. Do what you want."

Authentication-Results: mta.example.net; spf=softfail (sender IP is 198.51.100.25) smtp.mailfrom=user@new-saas-inc.com; dkim=pass (signature was verified) header.d=new-saas-inc.com; dmarc=none (no DMARC record found) — A typical `Authentication-Results` header with conflicting signals

This header tells a story. DKIM passes, which is good—it means the message content hasn't been altered since it was signed. But SPF soft-fails, and DMARC isn't there to enforce any action. This is the email security equivalent of a state-of-the-art lock on an interior door while the front door is wide open with a sign that says, "Please come in."

Domain Squatting or Digital Transformation?

Here’s another classic scenario. An email arrives from `trusted-partner.net`, a domain you know has been around for over a decade. The domain age gives it a veneer of legitimacy. Automated tools might even score it favorably based on that single data point.

But a quick check of its DNS history reveals something interesting. For ten years, it was hosted on one set of nameservers and IP addresses. Last week, it was moved to a completely new Autonomous System (AS) number, one associated with a 'bulletproof' hosting provider known for harboring malicious infrastructure.

This is a critical conflict. Is it a legitimate, if clumsy, infrastructure migration? Or did a threat actor purchase an expired, aged domain to bypass reputation filters that heavily weight domain age? The latter is a common tactic. Attackers buy up domains with good history, let them sit dormant, and then 'activate' them for a campaign, moving them to their own infrastructure. The new ASN is the tell. A move from a well-known corporate hosting environment to an obscure, high-risk ASN is almost never a good sign.

Your triage process must involve checking not just the current state but the recent historical changes. A sudden, unexplained change in a domain's hosting DNA—its IP, its ASN, its nameservers—is a more powerful indicator of potential compromise or malicious repurposing than the domain's age alone.

Authentication Passed. The Payload Failed.

Perhaps the most insidious conflict is when the email's technical wrappers are perfect, but its contents are toxic. The email passes SPF. It passes DKIM. It even has a strict `p=reject` DMARC policy, and the message passes DMARC alignment checks. The `From:` header domain, the DKIM signing domain (`header.d`), and the SPF-validated envelope sender domain are all in perfect harmony.

This is the calling card of a Business Email Compromise (BEC) attack originating from a genuinely compromised account. The attacker isn't spoofing anything. They are logged into a real employee's mailbox (`finance@legit-vendor.com`) and are sending mail through the vendor's legitimate mail server. Of course it passes authentication—it's authentic.

The conflict here isn't in the headers; it's between the headers and the body. While the authentication signals are all green, a URL in the email body is flagged on a major URI blacklist like SURBL or URIBL. The link points to a credential harvesting page hosted on a completely unrelated, malicious domain.

Header reputation is not payload reputation.

This scenario proves why you cannot stop at the `Authentication-Results` header. An analyst's workflow must account for the payload. The conflict between a perfectly authenticated sender and a malicious link is the signal. It tells you the account itself is the source of the compromise, which elevates the incident from a simple phishing attempt to a potential partner compromise that requires a different response playbook.

A Weighted Triage Model: Prioritizing the Gaps

Given these conflicting signals, you can't just tally up the good and bad. You need a mental model that weights signals based on how difficult they are to fake and how much they reveal about the sender's intent and competence.

The Hierarchy of Trust Signals

Think of it as a hierarchy. At the bottom, you have the least trustworthy signals. At the top, the most definitive.

IP Reputation sits at the bottom. As discussed, in a world dominated by massive, shared cloud platforms, a 'clean' IP is a weak and often misleading signal of a sender's legitimacy. It’s a starting point, not a conclusion.

In the middle are signals like domain age and SPF records. A brand-new domain is highly suspicious, but an old domain can be purchased. A `~all` SPF record is a significant sign of poor security hygiene. It’s a louder signal than a clean IP.

At the top of the hierarchy is DMARC with a `p=reject` policy. A domain owner willing to implement a strict rejection policy is making a strong, verifiable statement. They are confident in their mail-sending sources and are actively telling receivers to reject any forgeries. This is the strongest positive signal in email authentication. Conversely, the complete absence of DMARC on a business domain in this day and age is a powerful negative signal.

Weighting the Evidence

Your decision matrix should look something like this: A brand-new domain with a weak SPF record and no DMARC is almost certainly malicious, regardless of its IP reputation. An aged domain with a strict DMARC policy sending an email that passes all checks is almost certainly legitimate, even if a link scanner briefly misfires on a URL shortener. The conflict is resolved by prioritizing the stronger, more intentional signals over the weaker, more circumstantial ones.

The takeaway

The analyst's job is not to trust the green checkmark from an automated tool, but to actively hunt for the one red flag that invalidates all the positive signals. A single significant gap—a permissive SPF record, a sudden ASN change, a blacklisted URL in the payload—can and should outweigh a dozen weaker, positive indicators like IP reputation.

This is fundamentally an exercise in risk assessment. A permissive signal like `spf=softfail` from a massive software company might be a known, frustrating configuration you have to live with. The same signal from a new, unknown 'financial services' domain is an immediate, high-confidence threat indicator. Tools like MailSleuth.AI can surface these disparate signals—domain age, ASN history, authentication results—in one place, but the final judgment call on how to weigh them remains a human one. That's the job.