Incorrect FROM Header in DirectAdmin messages

I get that if someone used a yahoo address or other in their header nothing will match, (I hope I've read what you've wrote correctly) and I wonder why anyone would use an email address that isn't linked to their server in some way as the built in mail services are free and they would have a domain for it anyways?
To a degree, you are correct to wonder this. BUT... a reseller setting their Contact E-Mail Address has a reasonable assumption that this is the email address that notices are going to go TO. Not necessarily the email address messages are sent FROM.

Any time you send an email message to an off-server email address, and especially one you don't control, you become at the mercy of however the administrators of that off-server email server is going to see and treat your email message. Even though these Your account for is now ready for use. email messages you know are legit, who's to say that the administrator or system controlling mail for yahoo.com is going to see it that way?

BUT... resellers (and admins) have a reasonable belief that Contact E-Mail Address is referring to where they want those messages to go. If a reseller only checks their Yahoo email address - would I really recommend setting their Contact E-Mail Address to this Yahoo address? Probably not. But... messages TO this Yahoo address should be allowed to go out because the rest of the server passes inspection.

I don't think resellers (or admin) have the belief that this Contact E-Mail Address is going to be used as the From header email address when their DirectAdmin account sends out emails. That's where the issue comes up. Most resellers are probably oblivious to this - either that the system is doing it or understanding why it is wrong. But that's where the issue comes up.

Sending emails to an off-server email address is fine.

Sending emails to an off-server email address while pretending that the message is being From header sent from an off-server email address, is wrong.
 
I tried out that script, out of curiosity, and i'm guessing it would work if the {hostname} variable actually provided the domain. Not sure if it's my setup but the hostname is appended to the new header without the domain, even though my hostname is set in the admin panel as a FQDN.

What I mean here is this, with that script as is, my hostname for the email is malformed and fails SPF, DKIM and DMARC so lands in the Spam:
I suppose one bit I left out, this assumes your server's hostname is a Fully Qualified Domain Name (FQDN).

To put this simply, if you go to your server's shell (SSH) and type:

echo ${HOSTNAME}

What is displayed?

If this just says:

server

Or just a single word, that's not a FQDN.

An FQDN will include all levels of a domain name, including a TLD (i.e. .com, .net, .org, etc)

A FQDN would be:

example.tld

or

server.example.tld

If your ${HOSTNAME} isn't a FQDN then it won't have a published SPF record and it won't have a published DKIM key.

The "on behalf of" text comes from the user of the Sender header. Explaining all of this gets a bit tricky, I'd probably just leave the Sender header off - but it's there. The Sender header is supposed to tell what organization sent the message. While the From header tells what individual (presumably from that organization) sent the message (or maybe it's vice-versa, I can't remember). Basically, if the Sender header is present and it differs from the From header, then some MUA's will display this as "on behalf of."

For my testing purposes, I was using mutt - which is a command-line ncurses email MUA and it doesn't interpret the Sender header, so I wasn't picking this up.
 
I suppose one bit I left out, this assumes your server's hostname is a Fully Qualified Domain Name (FQDN).

To put this simply, if you go to your server's shell (SSH) and type:

echo ${HOSTNAME}
Thank you,

I did mention it may be my setup, and here's where the confusion for me is, as the hostname is a FQDN in the admin panel:

1762875975457.png

But as I mentioned it may be my setup and you suggested checking in the shell, It differs.
 
1762876855256.png


Sorry having to post another post as the forum is playing up again.

Looks like I may have to amend the contents of /etc/hostname and try again 😁

Also, would this have had anything to do with the deliverability? I know there was a big change a while back and by default now, EXIM is setup to only allow mail properly if the domain is listed on the server. I know we're not trying to spoof with the foreign email, but wondered if the spoofing protection was disabled (maybe not the best idea) mail would get delivered based on the servers credentials?

 
Last edited:
You can use the hostnamectl utility on the command-line to set the server's hostname. No clue what DirectAdmin's setting of the server's hostname actually does.

To use hostnamectl, you would do:

hostnamectl set-hostname your.fully.qualified.domain.name.for.the.server.tld

or

sudo hostnamectl set-hostname your.fully.qualified.domain.name.for.the.server.tld

You're not facing this particular problem because the Contact E-Mail Address you are using is a domain that is setup and resolving to the same server. I'm not going to delve too much into this because I think it takes the discussion off-topic. But my guess would be that these DirectAdmin messages are being signed by the DKIM private key associated with the domain name you have with the Contact E-Mail Address on the server and thus when recipients receive your message they are able to validate the DKIM signature by using the public key store in the domain name for your Contact E-Mail Address's DNS record.

If a reseller comes about on your server and sets their Contact E-Mail Address to an off-server email address (such as a yahoo or gmail address) then you will see this issue.

I also don't want to get into DirectAdmin's Sender address spoofing protection feature, because I think that discussion will take this discussion off-topic. I will just say that I'm not a fan of this. While I can understand what DirectAdmin is trying to do, I just think think that DirectAdmin trying to police this is taking away from how SMTP is supposed to work. Technically you can make the same argument in regards to SPF, DKIM, and DMARC - it's forcing users to adhere to something that technically doesn't break SMTP. But SPF, DKIM, and DMARC are common authentication methods that we're seeing more and more of in the email environment (all of these have been around for a long time, it's just recently that the big cat email providers started enforcing it). And while SPF, DKIM, and DMARC can disrupt an SMTP transaction - that generally requires modification of how the MTA works and integrates another specification (SPF, DKIM, or DMARC) into the SMTP transaction. The Sender address spoofing protection isn't integrating another specification. It's just DirectAdmin saying "if you authenticate as this user, then you shouldn't be able to send out mail as this other user." and that's just opening up a can of worms that I'm not ready to deal with just yet. And I don't think the rest of the Internet is really interested in dealing with at this point.

But to DirectAdmin's credit - they do allow you to very simply disable this Sender address spoofing protection feature. And so while I'll probably preach that I think it's a bad idea. Everybody is entitled to their own opinion and if you want it disabled DirectAdmin allows you to do so.
 
HI, so I changed the server hostname in the name of science and enabled that hook again. Rebooted the server and sent another welcome email. Straight to spam again.

Heres the header data from Hotmail. Gmail the mail went to some black hole again I guess as it never arrived.

With the hostname as part of the sender address, everything failed.

Code:
Received: from VI6PPF29278906E.EURP250.PROD.OUTLOOK.COM (::1) by
 AM8P250MB0312.EURP250.PROD.OUTLOOK.COM with HTTPS; Tue, 11 Nov 2025 16:23:24
 +0000
Received: from SJ0PR03CA0117.namprd03.prod.outlook.com (2603:10b6:a03:333::32)
 by VI6PPF29278906E.EURP250.PROD.OUTLOOK.COM (2603:10a6:808:1::249) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9298.16; Tue, 11 Nov
 2025 16:23:18 +0000
Received: from SJ1PEPF0000231C.namprd03.prod.outlook.com
 (2603:10b6:a03:333:cafe::b9) by SJ0PR03CA0117.outlook.office365.com
 (2603:10b6:a03:333::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.9298.16 via Frontend Transport; Tue,
 11 Nov 2025 16:23:16 +0000
Authentication-Results: spf=none (sender IP is 5.9.XX.XX)
 smtp.mailfrom=v9.my-domain.co.uk; dkim=none (message not signed)
 header.d=none;dmarc=fail action=quarantine
 header.from=v9.my-domain.co.uk;compauth=fail reason=000
Received-SPF: None (protection.outlook.com: v9.my-domain.co.uk does not
 designate permitted sender hosts)
Received: from v9.my-domain.co.uk (5.9.XX.XX) by
 SJ1PEPF0000231C.mail.protection.outlook.com (10.167.242.233) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9320.13
 via Frontend Transport; Tue, 11 Nov 2025 16:23:15 +0000
X-IncomingTopHeaderMarker:
 OriginalChecksum:770C92A9ED6B344156BBEBA4402A65B67AD8A023F6B97EC96756CBD1963FBCBF;UpperCasedChecksum:FF6387EB85C551D9A9ADEAC7ECB77A7E906A14BE3BACE801947CB89EA8E20DBD;SizeAsReceived:593;Count:10
Received: from root by v9.my-domain.co.uk with local (Exim 4.98.2)
    (envelope-from <[email protected]>)
    id 1vIr9F-0000000020a-49wc
    for [email protected];
    Tue, 11 Nov 2025 17:23:13 +0100
To: [email protected]
From: <[email protected]>
Sender: v7admin53 <[email protected]>
Reply-To: v7admin53 <[email protected]>
MIME-Version: 1.0
X-DirectAdmin-Sender: v7admin53
Subject: Your account for newdomain.co.uk is now ready for use.
Message-Id: <[email protected]>
X-IncomingHeaderCount: 10
Return-Path: [email protected]
X-MS-Exchange-Organization-ExpirationStartTime: 11 Nov 2025 16:23:15.7768
 (UTC)

When I change everything back to how I set server up myself, everything passes again. I'll create a reseller in a bit and have a play as I'm always interested in the nuts and bolts of how this all functions.

I do think this is something that DA will have to look into @sparek though.

And the anti spoofing protection, I won't be doing that myself, but I was just looking at what someone might have to do for the moment until some sort of fix is available for this particular problem. I think you've tackled this head on and fair play to you. This isn't one of those 1 size fits all situations and it's not an easy problem to find a proper solution to, but i'm really interested in seeing this resolved. I've enjoyed having a play about with this today to explore so thank you!
 
Your SPF and DKIM are both failing:

Authentication-Results: spf=none (sender IP is 5.9.XX.XX)
smtp.mailfrom=v9.my-domain.co.uk; dkim=none (message not signed)
header.d=none;dmarc=fail action=quarantine
header.from=v9.my-domain.co.uk;compauth=fail reason=000


I would guess that there is no SPF TXT record for v9.my-domain.co.uk

dig v9.my-domain.co.uk TXT

You would need to create a TXT record for v9.my-domain.co.uk that includes an SPF record. Maybe DirectAdmin has a tool that does this? I don't know.

I don't know if you have a DNS zone record for v9.my-domain.co.uk or if you are just using v9 as a third level domain in the DNS zone record for my-domain.co.uk.

The record would need to look something like:

v9.my-domain.co.uk. IN TXT "v=spf1 a ip4:%the_servers_ip% ~all"

I would argue that -all should be used, but that again is going beyond the scope of this discussion.

You probably don't need the ip4 part if v9.my-domain.co.uk is resolving to %the_servers_ip% but I usually include it anyway.

As for making a DKIM key for the server's hostname... I don't know if DirectAdmin has a DirectAdmin way of doing this or not. I never looked, I just create my own.

Use at your own risk - although this shouldn't overwrite anything by default. If DirectAdmin has their own way to create a DKIM public/private key pair for the server's hostname I'd use that. I tend to do a lot of stuff on my own, so I don't always go digging through a control panel's documentation on how to do things or have the patience to wait for the developer of a control panel to add a feature I need, so I can't always speak for what's "proper" and what's not. I know DirectAdmin create DKIM keys for added domains (like end user domain names) and it's basically doing what I'm doing here - it's just done automagically instead of parsing through the whole nuts and bolts.

Bash:
mkdir -p /root/dkim
rm -f /root/dkim/rsa.private /root/dkim/rsa.public
openssl genrsa -out /root/dkim/rsa.private 2048
openssl rsa -in /root/dkim/rsa.private -out /root/dkim/rsa.public -pubout -outform PEM

# You have to split a 2048 bit key
HEADCOUNT=$((255-$(echo -n "v=DKIM1; k=rsa; p=" | wc -c)))
FULLCOUNT=$(cat /root/dkim/rsa.public | grep -v '^-----' | tr '\n' ' ' | sed s/" "//g | wc -c)

DNS1="$(cat /root/dkim/rsa.public | grep -v '^-----' | tr '\n' ' ' | sed s/" "//g | head -c ${HEADCOUNT})"
DNS2="$(cat /root/dkim/rsa.public | grep -v '^-----' | tr '\n' ' ' | sed s/" "//g | tail -c $((${FULLCOUNT}-${HEADCOUNT})))"

echo "Add this to the DNS zone file for ${HOSTNAME}"
echo "x._domainkey.${HOSTNAME}. IN TXT \"v=DKIM1; k=rsa; p=${DNS1}\" ${DNS2}\\;"

mkdir -p /etc/virtual/${HOSTNAME}
chown mail:mail /etc/virtual/${HOSTNAME}
chmod 711 /etc/virtual/${HOSTNAME}

if [ -f "/etc/virtual/${HOSTNAME}/dkim.private.key" ]
then
echo "/etc/virtual/${HOSTNAME}/dkim.private.key" already exists"
else
cp -f /root/dkim/rsa.private /etc/virtual/${HOSTNAME}/dkim.private.key
fi

if [ -f "/etc/virtual/${HOSTNAME}/dkim.public.key" ]
then
echo "/etc/virtual/${HOSTNAME}/dkim.public.key already exists
else
cp -f /root/dkim/rsa.public /etc/virtual/${HOSTNAME}/dkim.public.key
fi

chown mail:mail /etc/virtual/${HOSTNAME}/dkim.private.key /etc/virtual/${HOSTNAME}/dkim.public.key
chmod 600 /etc/virtual/${HOSTNAME}/dkim.private.key /etc/virtual/${HOSTNAME}/dkim.public.key

Basically... DirectAdmin's exim will check the envelope-sender of a message that is being sent out and take the domain part of that email address. If the file - /etc/virtual/%thatdomain%/dkim.public.key - exists, then Exim uses that file to sign the message with DKIM. By default, DirectAdmin exim uses "x" as the DKIM selector, maybe this is customizable? Not sure.

So when the recipient receives this message, it will see that it was signed with DKIM for the ${HOSTNAME} domain with the "x" selector, so it will query DNS:

x._domainkey.${HOSTNAME}

for a TXT record that will have a matching public key. If the signature of the signed message matches the signature of the message with that public key, then the message passes DKIM.

You would need either the SPF TXT record added for v9.my-domain.co.uk. or the DKIM key signing to pass in order for DMARC to pass and for Outlook to (presumably) accept your message as valid. Although, you're always at the mercy of however the recipient mail server (outlook.com in this case) decides to treat your message. Passing SPF, DKIM, and DMARC is not going to guarantee that your message will always go through. But a failing SPF, DKIM, and DMARC is probably going to mean that your message won't make it through (or will end up in the user's spam/junk box).
 
BUT... a reseller setting their Contact E-Mail Address has a reasonable assumption that this is the email address that notices are going to go TO. Not necessarily the email address messages are sent FROM.
Well I disagree a bit here. Because if a reseller, let's say me, creates a new user account, it would be nice if this user will get this mail from my contact e-mail adres and not from diradmin@hostname because that might be confusing to some users.
I wonder how CP is doing that, can't remember.
 
Well I disagree a bit here. Because if a reseller, let's say me, creates a new user account, it would be nice if this user will get this mail from my contact e-mail adres and not from diradmin@hostname because that might be confusing to some users.
I wonder how CP is doing that, can't remember.
Well... not try to sound condescending... but this ain't 2005 any more. Maybe in 2005 you could use your yahoo.com email address as the From address from any server and any message you sent. But it wasn't proper then. Now there are measures the dictate that it's not proper.

If you - the reseller - wants to do this and send a welcome letter from your yahoo.com (or gmail.com, or whatever) email address, then when you create the account you need to uncheck the box that says to send the welcome message. Then you need to log into your yahoo.com email account at yahoo.com and enter the user's email address as the recipient and type up the message you see fit.

That's the only way you can send an email from your yahoo.com email address and expect it to be delivered to the intended recipient.
 
I suppose if you have a reseller that is using a local-to-the-server email address as their Contact E-Mail Address (not a yahoo.com, gmail.com, outlook.com, etc email address), then that address can be used to send messages From. Presumably, the account would have SPF and DKIM set up to match what's on the server. This may be what @Richard G was referring.

You could modify the sendmail_pre.sh script to account for this. I don't really recommend this, because it's quite a bit more complicated and the more complicated something is, the more it is prone to unbeknownst errors.

But a sendmail_pre.sh script for such a case might look like:

Bash:
#!/bin/bash

## Set a default From Address - we'll set the envelope-sender and From header to this if the From address in the ${full_message} is not a local email address
USEFROM="diradmin@${HOSTNAME}"

## If it's determined that the From address in the original ${full_message} is a local email address, i.e. a reseller is using an email address
## hosted on this server as their Contact E-Mail Address, then we'll use that email address as the From address in these messages.
## Otherwise, The default From Address specified above will be used.

## Grab the From Address from ${full_message}
fromaddress="$(printf '%s\n' "$full_message"  | sed -nE 's/^From:[[:space:]]*(.*<)?([^>[:space:]]+@[[:alnum:].-]+\.[[:alpha:]]{2,}).*/\2/p')"

## Check to see if ${fromaddress} is syntatically correct for an email address
if [[ "${fromaddress}" =~ ^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$ ]]
then
    ## It is syntatically correct - so now we'll check to see if the From Email Address is a valid email address on this server
    ## The assumption is that an email address that is set up on this server will validate SPF and DKIM.

    ## Grab the local part of the From Email Address
    fromlocalpart="${fromaddress%@*}"
    ## Grab the domain part of the From Email Address
    fromdomain="${fromaddress#*@}"

    ## Set a flag stating that the From Email Address has not been found
    FOUNDFROMADDRESS=0

    ## Check to see if - /etc/virtual/${fromdomain}/passwd - exists, if it doesn't then it's probably not a real email account on this server
    if [ -f "/etc/virtual/${fromdomain}/passwd" ]
    then
        if [ $(grep -c "^${fromlocalpart}:" /etc/virtual/${fromdomain}/passwd) -eq "1" ]
        then
            ## This is a valid local email account - adjust the ${USEFROM} value accordingly
            USEFROM="${fromaddress}"
            ## Set the ${FOUNDFROMADDRES} variable to 1 so we don't check the next part
            FOUNDFROMADDRESS=1
        fi
    fi

    if [ "${FOUNDFROMADDRESS}" -eq "0" ]
    then
        ## If ${FOUNDFROMADDRESS} is still 0, then a valid local email account was not found, let's check for a forwarder
        if [ -f "/etc/virtual/${fromdomain}/aliases" ]
        then
            ## /etc/virtual/${fromdomain}/aliases has to exist for the ${fromaddress} to be a valid forwarder
            if [ $(grep -c "^${fromlocalpart}:" /etc/virtual/${fromdomain}/aliases) -ge "1" ]
            then
                ## A forwarder for ${fromaddress} was found in /etc/virtual/${fromdomain}/aliases - adjust ${USEFROM} accordingly
                USEFROM="${fromaddress}"
            fi
        fi
    fi
fi

## This sets the From Header to ${USEFROM} - whatever that may be.
full_message=$(echo "${full_message}" | sed -E "s/^[[:space:]]*[Ff][Rr][Oo][Mm][[:space:]]*:[[:space:]]*.*$/From: <${USEFROM}>/")

## This sets the envelope-sender to ${USEFROM} - whatever that may be.
echo "${full_message}" | /usr/sbin/sendmail -t -i -f ${USEFROM}

I would probably still just prefer to have all the messages sent from diradmin@${HOSTNAME} and let the chips fall where they may.

And while sendmail_pre.sh allows for a high level of customization here... I still think this should ultimately be fixed within the DirectAdmin mechanism that is sending out these messages.
 
That's the only way you can send an email from your yahoo.com email address and expect it to be delivered to the intended recipient.
I didn't mean an external account. But if my reseller account is on the server like [email protected] then I'm normally able to send messages to my customer from that mail address.
So in these kind of years, things change but also technologies change and it should be possible (just like with forums and other applications) that you can set the e-mail address you want to send system messages from. That's also 2025 modern times usability.

This may be what @Richard G was referring.
Indeed that is exactly what I'm referring to.
So yes for the time being then maybe it's best to send it from diradmin@hostname.

But we strongly agree that this should be fixed within the Directadmin system, so we can use a modern way to send out mails instead of this kind of sort of "in behalve of" mails.
 
Maybe to solve all of this, DA need to do something like (and this is only a suggestion, other solutions could be available) provide 2 options for Admin & Resellers on the panel.

1] Same as it is now, allowing mail to be sent from the server authenticated by the servers credentials, provided domain is listed on the server for services like SPF, DKIM, DMARC etc
2] A section where someone can use their Hotmail address or Yahoo or whatever, but with a section to add in the chosen SMTP port and details for this choice.

So where the admin/reseller email details are stored/amended on the panel, put the choices there.

I think this would be good for mail deliverability, gives choice, and also helps maintain the server's IP reputation as sending out mail that bounces, gets refused and lands in spam isn't good for the server and other server users long term I wouldn't expect.

Obviously a misconfigured server will always throw out errors, and it's a case of "Admin Aware" but if the correct tools are offered, documented and used correctly, things should flow. End of day it's down to the server owners to make sure they all run and get configured properly.
 
Last edited:
I think a lot of this thread is just over complicating things - I suppose a lot of that could be my doing, since I posted multiple solutions with sendmail_pre.sh scripts.

I would just go back to the very simple solution. Replace the From Header with diradmin@${HOSTNAME} and call it a day. That's what the envelope-sender is set to, so just make it match the From Header.

It's the server administrator's responsibility to insure that ${HOSTNAME} has a valid SPF record and DKIM keys. I posted solutions on how to do that in this thread, but that's really above and beyond the scope that this thread had initially. If DirectAdmin wants to deploy a tool that makes this easier to do, then so be it. But it's not really tied to this particular issue of always using the Contact E-Mail Address as the From header.

IF it is important for a server administrator to allow their resellers to use valid local-to-the-server email addresses as the From address, then the server administrator can use the sendmail_pre.sh script I posted in post #30 or adjust as however they see fit. I don't think it's DirectAdmin's responsibility to account for every single permutation of a solution to a problem. If you start giving too many options it over complicates things and users don't know what to do and you wind up with things being all over the place. Occam's razor.
 
I don't think it's DirectAdmin's responsibility to account for every single permutation of a solution to a problem.
Agreed but it should easy to provide the local to external mail for resellers. Which is probably the reason initially in the past the usage of the contact e-mail address was programmed in there. At the early days that didn't matter.

Now it does matter and resellers are used to have this working correctly, but either which choice, it has to be fixed anyways nowaday, without the need of a custom script (again thank you for that diradmin@hostname script).
 
As far as giving the message a better appearance of who it is coming from - it's important to note that the message sent out includes a Reply-To header. That Reply-To header is always going to be set to the reseller or admin's Contact E-Mail Address - that part does not change. So even if the From header is set to diradmin@${HOSTNAME}, if the individual replies back to that message, it's going to be sent to whatever the Contact E-Mail Address is for the creator of the account (the reseller or admin). That's the purpose of the Reply-To header.

Additionally, I might argue that if a reseller wants to make the message more personal, then they are free to the Edit User Message button and adjust the message accordingly, including modifying the subject - which some resellers may want to put their company name to better identify the message.
 
Yep I don't mind, but whatever the solution is, either more personal or more diradmin@hostname, it should be fixed decently. ;)
 
Back
Top