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.
 
Back
Top