Incoming email shows FROM address as fake FROM [email protected]

Usually spam emails are easy to spot, the FROM address would look like this:

FROM: [email protected]
TO: [email protected]

But I’ve received an email that looks legit because the email shows:

FROM: [email protected]
TO: [email protected]

I’m pasting the header info below:

Return-path: [email protected]
Envelope-to: [email protected]
Delivery-date: Thu, 17 Apr 2025 19:22:35 -0600
Received: from ca-expressive.site ([188.127.251.164])
by myhosting.server.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.96)
(envelope-from [email protected])
id 1u5aR7-003YrF-2k
for [email protected];
Thu, 17 Apr 2025 19:22:35 -0600
Received: from [173.249.196.117] (localhost [127.0.0.1])
by ca-expressive.site (Postfix) with ESMTPS id 9444D40DEB
for [email protected]; Fri, 18 Apr 2025 04:15:13 +0300 (MSK)
From: [email protected]
To: [email protected]
Subject: myrealdomain.com: Password will expire!!!
Date: 18 Apr 2025 03:15:11 +0200
Message-ID: [email protected]
MIME-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

Does anyone know how this is getting past all of the built in security in HestiaCP?

Thanks!

Kidding aside, have you configured spoofing protection for your domain?

Are you publishing DMARC, DKIM, and SPF? Are you checking DMARC on your HestiaCP server?

2 Likes

Thanks for the reply!

I don’t know what spoofing protection is, so probably no.

I always add all of the default DNS records when I configure a domain, those include the DMARC, DKIM and SPF records, then I always test that they are working by sending emails to mail-tester.com.

Everything else is default hestiaCP out of the box.

Do I need to do something extra to perform checking DMARC and/or configure spoofing protection?

Thanks!

1 Like

If you have an enforcing DMARC policy of either quarantine or reject, checking DMARC is the cornerstone of spoofing protection. I expect it is configured in spamassassin, but I don’t use HestiaCP for email, so please wait for one of the other forum members to let you know how to enable that setting.

1 Like

You can use the dnschecker tools to setup your records: DKIM Checker | DKIM Record Lookup
I was not aware of how to do it myself, tbvh. But you can test it there and see if it is all good.

For all my domains, these are the DKIM/DMARC/SPF:

_dmarc v=DMARC1; p=quarantine; pct=100
mail._domainkey v=DKIM1; k=rsa; p=Your base64 encoded public key
_domainkey t=y; o=~;
domain.tld v=spf1 a mx ip4:IPHERE -all

1 Like

That is a good test to see if you are publishing DKIM records, but to prevent spoofed email from being received, inbound mail needs to be evaluated before it is delivered to the inbox.

A DNS test can’t determine if you are sending valid signatures. If you dont use a DMARC reporting service, you can always send an email to one of the many testing sites.

1 Like

So basically the DS records, you mean, am I right? Or also something like openpgp?

Apologies, I am in the same page as the OP, as I too have not been able to determine how to set the anti-spoofing for my email.

Is it possible for you to show or give some dummy data to determine how one can go about?

1 Like

Not DS records, those are used by DNSSEC, and not openpgp which can be used to send encrypted email.

This is a good site for learning how DMARC works.

2 Likes

Okay, that was a nice one. :slightly_smiling_face:

Thanks for that. Interactive and did not hurt the eye. :stuck_out_tongue:

1 Like

Thanks for that link! very cool site, easy and fun to follow how an email works!

I did send it a test from my domain and my email passed all the stuff, DMARC, DKIM, SPF.

But I’m still struggling to wrap my head around the one that I received.

So, that website specifically points out 2 things:

  1. RFC5321.MailFrom (also known as Return-Path, Bounce Address, or Envelope From)
  2. RFC5322.From (this is the Header From: address)

So, using the header info of the bad email that I received:

RFC5321.MailFrom = [email protected]
RFC5322.From = [email protected]

Shouldn’t this incoming email have failed validation?

Does this simply mean that my hestiaCP email server is NOT doing the DMARC, DKIM, SPF validation on incoming emails the same way that other email servers do it? For example the way that www.learndmarc.com processed the email I SENT to it?

Thanks!

1 Like

SPF tests against the RFC5322.MailFrom and in order for a valid SPF to be used to pass DMARC, the RFC5322.MailFrom and the RFC5322.From need to be in the same domain, or if the policy is relaxed, a subdomain is allowed.

In your example, the SPF would not be able to pass DMARC, even if it was valid. Without access to the secret key that corresponds to the public key in your DKIM record, that email couldn’t pass DKIM either. So neither way of testing DMARC would have passed that spoofed message.

I agree with your conclusion that you are not verifying DMARC on your server. Regrettably, this puts back to where we were earlier with me not knowing the HestiaCP way of enabling DMARC inspection since I use other email solutions. The upside is that once you identify that, you should be able to send such forgeries to quarantine, or, if you increase your policy to reject, you could refuse to accept such messages altogether.

I wish someone from hestiaCP would pipe in here to tell me if incoming emails are checked for DMARC!

I don’t know how to check if incoming emails are being checked for DMARC?

You could check your Spamassassin config.

https://spamassassin.apache.org/full/4.0.x/doc/Mail_SpamAssassin_Plugin_DMARC.html

1 Like

No, they aren’t.

As @linkp said, you can use it in SpamAssassin. By default, SpamAssassin is configured to check DKIM, SPF, and DMARC… if the required Perl modules are installed. However, Hestia only installs the module for DKIM (at least for Debian, for Ubuntu I don’t know if all mail modules are installed by default).

You can check whether they are installed:

for i in DKIM SPF DMARC; do perl -MMail::$i -e1 &>/dev/null && echo "$i is installed" || echo "$i is NOT installed"; done

If DMARC or SPF modules aren’t installed, you just need to install them, restart SpamAssassin and you’re good to go.

Well, you can tweak the score assigned to each case, but that’s another question :wink:

apt install libmail-dmarc-perl libmail-spf-perl
systemctl restart spamd
1 Like