SPF Passed. DKIM Passed. I Still Wouldn’t Click the Link.

An invitation landed in my inbox yesterday with a subject line designed to get my attention:

“Victor, Invitation to Speak at the TekSummit”

Given the amount of fraudulent recruiting, speaking, consulting, and business-development email circulating today, my first instinct was the same one I apply to almost every unsolicited opportunity:

Verify before engaging.

What made this email interesting was that it did not behave like the typical scam.

The organization was real.

The event was real.

The sender’s domain authenticated.

SPF passed.

DKIM passed.

The email address provided for prospective speakers could be independently verified through the organization’s legitimate web properties.

And I still would not click the links in the email.

That is what makes this worth examining.

The Email Looked Legitimate Because Much of It Was

The invitation said TekSummit was jointly hosted by GAO RFID, GAO Tek, and GAO Research and described a virtual technology event covering AI, IoT, RFID, BLE, testing, measurement, and industrial applications.

Independent verification supported those claims.

The message also invited me to submit a presentation proposal to:

Speakers-TekSummit@TheGAOGroup.com

Again, independent verification showed that this address is published by the organization for TekSummit speaker proposals.

Even the physical addresses in the signature corresponded with addresses associated with the organization.

This was not a crude impersonation using a Gmail account and a copied corporate logo.

Then I looked at the source.

Authentication Did Exactly What It Was Supposed to Do

The headers contained several encouraging results:

SPF_PASS

DKIM_VALID

DKIM_VALID_AU

The DKIM signature used mail.gaorfid.com, and the From, Sender, and Reply-To addresses were also associated with that domain.

That matters.

SPF helped establish that the sending infrastructure was authorized to send the message.

DKIM provided cryptographic evidence that the signed portions of the message had not been modified after signing and that the message was associated with the signing domain.

Those are valuable controls.

But neither control answered the question I actually cared about:

Should I click this link?

That is where things became much more interesting.

The Link Didn’t Go Where the Brand Suggested

The invitation was supposedly from GAO RFID regarding TekSummit.

But the links did not initially take me to GAO RFID, GAO Tek, GAO Research, or The GAO Group.

They went through a tracking domain:

orca.medilabsisli.com

That is a very different trust proposition.

The message therefore presented several distinct identities to the recipient.

The organization was GAO RFID.

The authenticated sender was under mail.gaorfid.com.

The sending host used another infrastructure domain.

The click-tracking system used medilabsisli.com.

The speaker contact address used TheGAOGroup.com.

Some of this can be perfectly normal in modern email marketing. Organizations routinely use third-party platforms for delivery, tracking, campaign management, bounce processing, and analytics.

But normal does not mean trustworthy by default.

And complexity has consequences.

Every additional domain becomes another trust relationship the recipient is expected to accept.

Then SpamAssassin Found Something

My mail server did not classify the message as spam. Its overall SpamAssassin score was only 0.8 against a threshold of 5.0.

But buried in the analysis was this:

URIBL_CT_SURBL

The explanation was more important:

“Contains an URL listed in the CT SURBL blocklist.”

The identified URI was the orca.medilabsisli.com tracking infrastructure.

What Is a SURBL Blocklist?

SURBL is a reputation system used by email-security and anti-spam systems to identify domains and URLs that have appeared in messages associated with spam, phishing, malware, or other forms of abusive email.

That distinction matters.

Traditional email blocklists often focus on the infrastructure sending the message—such as the reputation of an IP address or mail server. SURBL focuses on the web addresses contained inside messages. An email can therefore originate from an authenticated sender while still containing a URL whose domain has developed a problematic reputation.

A SURBL listing does not, by itself, prove that a particular email is malicious. Domains can appear on reputation lists because of abuse, compromised infrastructure, shared services, redirect systems, or other activity unrelated to the specific message being examined. Reputation data should be treated as a risk signal, not a verdict.

In this case, SpamAssassin reported that the orca.medilabsisli.com URL triggered its URIBL_CT_SURBL rule.

That did not establish that GAO RFID or the TekSummit invitation was malicious. It established something much narrower—and much more useful for making a security decision: the link introduced a reputation signal that warranted additional scrutiny.

And because I could verify the event and contact the organization without using that link, there was no reason to accept the additional risk.

Now we have a fascinating security situation.

The email authenticated.

The organization existed.

The event existed.

The speaker address checked out.

The server did not classify the message as spam.

Yet one of the systems evaluating URLs inside the message identified the tracking infrastructure as appearing on a reputation blocklist.

Does that prove the email was malicious?

No.

And that distinction is essential.

A domain can acquire a poor reputation for many reasons, particularly when shared infrastructure, bulk-mail systems, redirects, or compromised services are involved. A blocklist entry by itself does not establish malicious intent by the organization whose message contains the link.

But it does establish something else.

There is enough uncertainty that clicking is unnecessary risk.

Zero Trust Does Not Mean “Everything Is Malicious”

This is where zero trust is frequently misunderstood.

Zero trust does not mean assuming that everyone is a criminal.

It means refusing to grant trust merely because something looks familiar, authenticates correctly, or arrives through an expected channel.

The TekSummit invitation provides an excellent example.

I did not need to decide whether the email was malicious before deciding whether to click.

That is an important distinction.

The security decision was not:

“Can I prove this is a scam?”

The security decision was:

“Do I need to trust this link to accomplish my objective?”

The answer was no.

I could independently locate the organization.

I could independently verify the event.

I could independently verify the speaker email address.

And if I chose to pursue the invitation, I could initiate contact through those independently established channels.

The tracking link added no capability I actually needed.

So why assume its risk?

Authentication Is Not Reputation

This case also illustrates a distinction executives and boards should understand.

Authentication and reputation solve different problems.

SPF can tell us whether a sending server is authorized under the sender’s published policy.

DKIM can establish cryptographic association with a signing domain and protect signed message content against modification.

DMARC can establish policy and alignment around authenticated identities.

None of them establishes that the business proposition in the email is legitimate.

None guarantees that every linked destination is safe.

None proves that a third-party tracking service has not been compromised.

None establishes that the person asking you to take an action deserves your trust.

And none substitutes for independent verification.

A perfectly authenticated email can still contain a bad link.

In fact, compromised legitimate accounts and legitimate bulk-mail infrastructure can make malicious messages considerably more convincing precisely because authentication succeeds.

“SPF passed” should never be translated into “this email is safe.”

Those are completely different statements.

There Is a Business Lesson Here Too

Organizations spend enormous amounts of money on cybersecurity awareness while their marketing systems sometimes train customers to violate the very principles security teams are teaching them.

Think about the contradiction.

Security says:

Check the domain before clicking.

Marketing says:

Click this unrelated tracking domain so we can measure engagement.

Security says:

Be suspicious of redirects.

Marketing says:

We need redirects for attribution.

Security says:

Verify the organization independently.

Marketing says:

Use the convenient link in the email.

Security says:

Treat unexpected messages cautiously.

Marketing says:

Our campaign works better when the subject creates urgency or personal relevance.

Then organizations wonder why phishing simulations are so effective.

We have spent years teaching people that suspicious behavior is sometimes perfectly normal business behavior.

Attackers noticed.

The Better Standard

If I were advising an organization sending executive invitations, I would recommend a much simpler approach.

Keep branded links within domains the recipient can reasonably associate with the organization.

If third-party infrastructure is necessary, use branded subdomains and appropriate DNS delegation rather than exposing unrelated tracking domains whenever possible.

Make events independently discoverable.

Publish contact information on the corporate website.

Allow recipients to verify invitations without interacting with the original message.

And perhaps most importantly, design communications so that security-conscious recipients are rewarded for cautious behavior rather than penalized for it.

A legitimate email should survive independent verification.

This one did.

That is why I believe the underlying invitation is likely legitimate.

But I still didn’t click the links.

The Boardroom Takeaway

The lesson is not that every unfamiliar tracking domain is malicious.

The lesson is that technical authentication should never be confused with a trust decision.

SPF passed.

DKIM passed.

The organization checked out.

The event checked out.

The contact information could be independently verified.

And the safest path was still to leave the email links untouched and establish trust through another channel.

That is zero trust functioning exactly as intended.

You do not have to prove something is malicious before deciding not to trust it.

Sometimes the most defensible security decision is much simpler:

I don’t need to click that.