PHPJunkyard support forum

In a nutshell, the issue I was having was due to the SPF record not being looked up properly and thus forcing the endpoint system to label mail as spam.

Based on the docs and the research I have done for SPF resource records, The SMTP HELO should return the list of allowed senders to be resolved by the host (up to 10 max) *including* A records. Hence my domains A record mydomain.com. was pointing to the host the Hesk site resides on and should have been included in allowed senders. Why the name in the A record wasn't being resolved is beyond me. What I can state is that all the major players in the relationship of hosts including microsoft and google were culprits in this issue. To be clear, I do not know if these hosts were attempting to resolve the name or what but I do know what in checking multiple methods the A record was being provided and resolving that A record did point to my Hesk site. (this fact steered me away from further investigating that aspect which turned out to be misleading in the end)

After weeks of scratching my head and asking people who have little to do with my business for help, I started throwing caution to the wind and taking illogical chances. One of those chances was to put the actual IP of my Hesk site host in the SPF record. That was the solution that allow all the mail servers in the relationship to acknowledge the Hesk site IP was in fact an authorized sender and mails stopped being labeled as spam at the recipient.

Where the true issue lies here I don't know as my ability to take this further is pretty much nil since I don't own these hosts and the owners are not interested in pursuing any of this. Hopefully this will help save someone from the agony I faced...

Glad to hear you got it working, and thanks for sharing your findings.

There is a great free tool called mail-tester.com which I use regularly to check for email delivery problems. It will test your emails and let you know what needs to be fixed.

It's mentioned in the HESK emails are marked as SPAM article at the bottom.

I had used multiple tools which all claimed the setup I had was sane. I tried yours and got 6.5/10. Most expensive hit was that the email was from a PHP script which it obviously does and there is no way around that. That cost -2.5. the other -1 was because the message is authenticated but not fully being that it was not signed -which again it can't be unless I use SMTP auth using a real account which is what I had in the past and cause too much delay for the PHP environment. So all that said one could say that I got 100% of what is possible for the type of message being sent.


The famous spam filter SpamAssassin. Score: -2.5.
A score below -5 is considered spam.
-2.499 PHP_SCRIPT Sent by PHP script
0.001 SPF_HELO_PASS SPF: HELO matches SPF record
0.001 SPF_PASS SPF: sender matches SPF record
Great! Your SPF is valid

I found this one quite interesting...

Checks whether your message is well formatted or not.
There is no html version of your message.

I always thought plain txt vs HTML would be much cleaner and less likely to be scored and yet this implies I should include an html version. I find that odd.

In the end this also confirms I have a good SPF config. I don't feel like stripping the +ip4 for the A record to see if it does the same score

plc wrote: Tue May 23, 2023 7:37 pmMost expensive hit was that the email was from a PHP script which it obviously does and there is no way around that.

That's not something Hesk adds, but your server (most likely for spam protection, to find abused PHP scripts more easily). Not sure if you have a way of turning that off, but just wanted to point it out.

Okay good to know. I will enquire. Made sense it would be from heal just based on pure logic.

I just discovered something I hadn't noticed after solutioning this issue. Now email notifications don't have the configured From: and Name: values I put in Hesk config but rather the 'server.name.com on behalf of my business name'. So although this works on a technical standpoint people have no way of knowing who my web host is and whether that's legit or not so it ends up looking kind of phishy.

That's probably what the local SMTP server does (PHP mail() command in use).

Using an external SMTP server solves that issue.

Yes but we concluded we could not use an external SMTP due to the delays in connecting breaking async in the form.

What do you think about this response? I assume this would break the update process for that file or does Hesk have an exclusion system I don't know about? Another question is, why can't the local PHP mail command pull the values set in the Hesk config for From and Name?

"If you have a look at line 115 - 123 of your /public_html/help/vendor/phpmailer/phpmailer/src/PHPMailer.php

There is an area to add the return path header. Because the server has many accounts on it php mail can not be set as a global option and must be set in the script using it. If it is not set then it will default to the server name.

As for digitally encrypting email like you wanted to do in the past, you can buy an s-mime email certificate for the one address you choose and add it to the following section lines 705 - 732 of the same file."

PHPMailer is a third-party library, so not something I can guide on.

It's a hugely popular library with all kinds of features; can have a look at their docs to see if something there fits your needs:
https://phpmailer.github.io/PHPMailer/

Not sure what good it will do though; any headers you set for the email are in the end overwritten (if set so) by the server's email-sending software.

My point was that the phpmailer files may be third party but they are included in the hesk fileset. So if I modify that file the host suggests I assume it will get overridden everytime I update. Also, my second point is that the fields set in the config under Email for From and Name are only valid for authenticate SMTP then? Why doesn't the php mailer script pick those settings up?

ANY changes you make to the files may get overwritten during an update. If you make changes to your files, you are responsible for ensuring they are correctly updated. Tools like Git may help you track changes across versions.

Hesk does set the from name and address to the ones set in the settings (so does PHPMailer). However, the mail server (the program that actually sends emails from one mail server to another mail server) doesn't have to use those exact email headers and often SMTP servers will overwrite them using their own data. The most common reason for this is to combat spam. I am pretty sure all shared hosting companies do that (unless you have a self-managed server with root access).

Thanks for the clarification. That makes good sense.
I did the change to the file but as you implied in an earlier response the server overwrites it so the edit is pointless.