The Recruiter Looked Real. The Email Header Told a Different Story.

The email looked professional.

It addressed me by name. It accurately described my cybersecurity governance and technology leadership background. It referenced enterprise architecture, digital transformation, financial stewardship, and even my experience managing budgets exceeding $70 million.

The sender appeared to be an executive recruiter using a professional-looking corporate domain.

There was just one problem.

That wasn’t the identity that actually sent the email.

The Message That Caught My Attention

The email arrived with this visible sender:

baasitdigital@executivecareersconnect.com

The signature identified the sender as:

Baasit Digital
Independent Executive Recruiter

The subject line was equally plausible:

Cybersecurity Governance & Technology Executive Leadership Opportunity

The opening paragraph demonstrated enough familiarity with my professional background to make the message appear targeted:

“Your cybersecurity governance and technology executive leadership background stood out…”

It went on to reference my work in cybersecurity governance, enterprise architecture, P&L responsibility, budgeting, systems integration, and digital transformation.

Then came the supposed opportunity.

The recruiter said they were working on:

“Finance & Accounting, Accounts Payable, and Procurement leadership opportunities…”

That was the first thing that didn’t make sense.

Someone who had supposedly examined my background closely enough to identify very specific aspects of my career was simultaneously suggesting Accounts Payable leadership as a logical fit.

Perhaps it was simply poor recruiting.

Perhaps not.

So instead of responding, I examined the email header.

The Envelope Told a Different Story

Email has more than one concept of a sender.

The address most people see in their email application is the RFC 5322 From: address. Think of it as the name printed on the outside of a letter.

But SMTP also has an envelope sender. That identity is used during the actual mail transaction and commonly appears in the received message as the Return-Path.

The visible sender was:

From: baasitdigital@executivecareersconnect.com

The Return-Path was:

Return-Path: <baasitdigital0@gmail.com>

Those are not the same domain.

The receiving server recorded the same Gmail address as the SMTP envelope sender:

envelope-from <baasitdigital0@gmail.com>

That immediately changed the nature of the investigation.

The email wasn’t simply arriving from the corporate identity displayed to me. Underneath that presentation was a Gmail identity:

baasitdigital0@gmail.com

Google Confirmed the Delivery Path

The Received: headers provided another important piece of evidence.

The message traveled through Google’s mail infrastructure, including this transaction:

by smtp.gmail.com with ESMTPSA

That final A matters.

ESMTPSA indicates authenticated SMTP submission over TLS.

In other words, this wasn’t simply an arbitrary server on the Internet pretending to be Gmail. The message was submitted through Google’s authenticated mail infrastructure.

The basic delivery path was:

Authenticated Gmail submission → Google mail infrastructure → my hosting provider → my mailbox

That does not establish who the human sender was.

It does establish something important about the technical origin of the message.

The visible corporate-domain identity and the SMTP envelope identity were different.

But SPF Passed

This is where the example becomes particularly useful from a cybersecurity perspective.

My mail server reported:

SPF_PASS

Someone casually reviewing the header might stop there.

SPF passed. Therefore, the sender must be legitimate.

Not so fast.

SPF does not necessarily authenticate the address displayed to the person reading the email.

SPF evaluates the SMTP envelope identity.

In this case, that identity was associated with:

gmail.com

The message was being transmitted through Google’s infrastructure.

There is nothing surprising about Google being authorized to send Gmail.

So an SPF pass here tells us that the infrastructure was authorized for the SMTP identity being evaluated.

It does not tell us that:

baasitdigital@executivecareersconnect.com

was authenticated merely because that was the address displayed in the From: field.

That distinction is critical.

My Spam Filter Saw the Mismatch Too

Interestingly, the receiving mail system detected exactly what had caught my attention.

SpamAssassin reported:

HEADER_FROM_DIFFERENT_DOMAINS

Its explanation was straightforward:

“From and EnvelopeFrom 2nd level mail domains are different”

It also identified the underlying sender as a freemail account:

FREEMAIL_FROM

with:

baasitdigital0(at)gmail.com

Another rule noted that the freemail envelope sender ended in a digit:

FREEMAIL_ENVFROM_END_DIGIT

None of these indicators independently proves malicious activity.

Together, however, they provide context.

And context matters enormously in social engineering.

Where Is the Corporate DKIM Signature?

I then looked for another authentication mechanism: DKIM.

DomainKeys Identified Mail allows a domain to cryptographically sign email so recipients can verify that the message was authorized by the signing domain and was not improperly altered after signing.

The header contained Google’s infrastructure signature:

d=1e100.net

What I did not find in the supplied header was a conventional domain-aligned DKIM signature such as:

d=executivecareersconnect.com

That matters because DMARC relies on alignment.

For the visible From: domain to authenticate under DMARC, either SPF or DKIM must pass in a way that aligns with that domain.

Here, the identities visible in the header told a different story:

Envelope identity: gmail.com

Visible From identity: executivecareersconnect.com

Those are different organizational domains.

And I found no domain-aligned DKIM signature in the message header demonstrating authentication by executivecareersconnect.com.

That does not prove the sender lacks control of the corporate-domain address. Gmail can legitimately be configured to send mail using another address.

But it means the evidence available to me did not establish the corporate identity merely because that identity appeared on my screen.

That distinction is important.

Then I Looked at the Recruiting Domain

The technical evidence made the recruiting organization’s identity worth examining more closely.

The domain executivecareersconnect.com was registered on July 21, 2026.

The email arrived on August 27.

That makes the domain roughly five weeks old at the time I received the solicitation.

A recently registered domain is not evidence of fraud. Every legitimate business domain was new once.

But domain age becomes relevant when combined with other signals.

The website associated with the domain presents what appears to be an established executive-search operation and makes substantial claims about executive appointments, international market coverage, and senior leaders advised.

Again, there may be legitimate explanations.

But when a very young domain presents substantial organizational credentials while unsolicited recruiting email is actually being submitted through a Gmail identity underneath a different visible sender, verification becomes prudent rather than paranoid.

The Personalization Wasn’t Proof Either

There is another lesson here.

The email knew a surprising amount about me.

That would once have been a meaningful credibility signal.

It isn’t anymore.

Most of the information referenced in the message can be obtained from my public professional profile.

Generative AI can transform that information into highly personalized correspondence in seconds.

An attacker no longer needs to send:

“Dear Sir, I have an exciting executive opportunity.”

A modern social-engineering message can say, in effect:

“I noticed your cybersecurity governance work, your enterprise architecture experience, your consulting leadership, your P&L responsibility, and your $70 million technology budget experience.”

That sounds researched because it was researched.

The mistake is assuming research establishes identity.

It doesn’t.

Public information can personalize a message.

It cannot authenticate the person sending it.

Personalization Has Become Cheap. Authentication Has Not.

That may be the most important lesson from this incident.

For years, security-awareness programs taught people to look for poorly written emails, generic greetings, grammatical mistakes, implausible stories, and obvious inconsistencies.

Those indicators still exist.

But generative AI has dramatically reduced the cost of producing polished, contextualized social engineering.

A sophisticated-looking message can now be assembled from public information at essentially zero marginal cost.

The recipient therefore needs to evaluate something AI cannot manufacture quite as easily:

verifiable identity.

Who actually sent the message?

What infrastructure delivered it?

What domain authenticated it?

Does the technical identity align with the identity being presented?

Does the organization have an independently verifiable history?

Does the supposed opportunity make professional sense?

Those questions are becoming more important than whether the email sounds professional.

This Is Why Headers Still Matter

Most email users will never inspect a complete message header.

That is understandable. Headers are ugly.

They are filled with server names, timestamps, IP addresses, cryptographic signatures, message identifiers, routing information, and authentication results.

But underneath that complexity is something extremely valuable:

evidence.

The body of an email tells you the story the sender wants you to read.

The header tells you something about how the message actually traveled.

That does not mean headers reveal everything. They don’t.

A legitimate organization can use third-party email infrastructure. Marketing platforms can create complicated delivery paths. Google Workspace, Microsoft 365, CRM systems, mailing services, forwarding systems, aliases, and security gateways can all make email authentication more complicated than a simple domain comparison.

The goal isn’t to declare every mismatch malicious.

The goal is to investigate mismatches rather than ignore them.

What I Did Next

Nothing.

I didn’t click anything.

I didn’t provide additional contact information.

I didn’t send my résumé.

I didn’t ask for the job description.

And I didn’t respond to the recruiter.

That is sometimes the most appropriate incident response.

The objective of a suspicious recruiting message may not be immediately obvious. The first email may simply establish engagement.

Once someone responds, the conversation can move elsewhere.

A recruiter may ask for a résumé.

Then a phone number.

Then compensation information.

Then identity information supposedly required by a client.

Then perhaps a Teams, Zoom, Telegram, Signal, or WhatsApp conversation.

The attack does not necessarily occur in the first message.

The first message may simply open the door.

I chose not to open it.

The Bigger Cybersecurity Lesson

There is a governance principle buried in this small incident.

Claims are not evidence.

A display name is a claim.

An email address shown in an email client is a claim.

A professional signature is a claim.

A polished website is a claim.

A detailed understanding of someone’s career is a claim.

A statement that someone represents an executive opportunity is a claim.

Each may be completely legitimate.

But none should automatically be confused with verification.

The same principle applies far beyond phishing and recruiting scams.

Organizations make cybersecurity claims every day:

“We review privileged access.”

“We monitor third parties.”

“We test our incident response plan.”

“We govern AI.”

“We maintain appropriate oversight.”

The governance question is always the same:

What evidence demonstrates that the claim is true?

That is what made this particular email interesting to me.

The message told one story.

The underlying evidence told me to ask more questions.

And I trusted the evidence.

Boardroom Takeaway

AI is making social engineering more convincing because personalization is becoming inexpensive, scalable, and extraordinarily good.

Organizations should therefore reconsider security-awareness programs built primarily around spotting spelling mistakes, strange wording, and obviously fraudulent messages.

The next generation of social engineering may be grammatically perfect, professionally written, personally relevant, and contextually accurate.

The question employees need to learn to ask is no longer simply:

“Does this email look suspicious?”

It is:

“What evidence do I have that this person is who they claim to be?”

Because in an AI-enabled threat environment, appearances are getting better.

Evidence still has to hold up.