The question arrives as a ticket: a customer’s invoices show “via mailbaby.net” next to the sender name in Gmail, and they want to know whether the relay is impersonating them. It is not. The label is Gmail’s way of saying that the DKIM signature it validated belongs to a different domain from the one in the From: header. Understanding why that happens, and how to stop it, requires a clear picture of what MailBaby does and does not do to DKIM on its way through.
Table of Contents
Short answer: MailBaby leaves a valid DKIM signature from your server untouched, but when a message arrives unsigned it adds a transport signature on its own mailbaby.net domain, and Gmail shows “via mailbaby.net” because that signing domain differs from the From: domain. The label is cosmetic, but the transport signature is not DMARC-aligned, so any domain with p=quarantine or p=reject must sign its own mail before it reaches the relay. Enable DKIM in cPanel or DirectAdmin, keep the dkim_* options on the relay transport, and route applications that connect to MailBaby directly through the local MTA instead.
What the relay does with signatures
When a message arrives at MailBaby carrying a valid DKIM-Signature: header from your server, the relay leaves it alone. It does not re-sign, strip or reorder the signed headers, and because the relay does not modify the body or the signed headers, the signature still verifies at the destination. This is the intended arrangement: your domain signs, your domain’s DMARC aligns, and the recipient never sees MailBaby’s name.
When a message arrives with no signature at all, MailBaby adds one of its own, using a key on its transport domain. This is transport signing. It exists so that the message is not delivered wholly unauthenticated; a DKIM pass from any domain improves acceptance at large mailbox providers compared with no DKIM. The cost is the mismatch: the From: says example.com, the signature says a mailbaby.net domain, and Gmail renders the via label to make that visible.
If a message arrives with a signature that is already broken, for example because a plugin modified the body after signing, the relay cannot repair it. The broken signature stays, MailBaby adds its transport signature alongside, and the recipient sees one failed and one passing signature, plus the via label.
Why alignment matters more than the label
The via label is cosmetic. The real issue is DMARC. A DMARC policy on example.com asks receivers to check that either SPF or DKIM passes with a domain aligned to the From: header. A transport signature from mailbaby.net passes DKIM but is not aligned. SPF alignment depends on the envelope sender: if your envelope sender is on example.com and the domain’s SPF includes spf-c.mailbaby.net, SPF aligns and DMARC passes. If the envelope sender has been rewritten, for example by SRS on a forward, SPF alignment is lost too, and a p=reject policy now rejects the mail.
So the practical rule is: any domain with a DMARC policy stricter than p=none must sign its own outbound mail before it reaches the relay. Everything else benefits from doing so.
Sign at the source
On cPanel, DKIM is per domain and the smarthost transport applies it as long as the transport has the dkim_* options. Confirm keys exist and are enabled:
whmapi1 has_dkim domain=example.com
whmapi1 enable_dkim domain=example.comThe transport in our cPanel guide uses dkim_private_key = /var/cpanel/domain_keys/private/${dkim_domain} so that every domain with a key signs. On DirectAdmin, keys live under /etc/virtual/<domain>/dkim.private.key with selector x; enable DKIM for the domain in the panel and use the transport from the DirectAdmin guide. On Postfix, OpenDKIM as a milter does the same job before the message is queued for the relay.
Applications that talk to the relay directly, such as an SMTP plugin in WordPress or WHMCS in SMTP mode, bypass the panel’s signer entirely. Those messages will carry the transport signature. Route them through the local MTA instead, as described in the WordPress guide and the WHMCS guide.
Keep the signature intact
A signature applied at the source can still break before delivery. The common causes on hosting servers:
- A content filter or disclaimer plugin that appends text after signing. Sign last: DKIM must be the final step before the message leaves.
relaxed/simplecanonicalisation with a mail client that reflows long lines. Userelaxed/relaxed, which is whatdkim_canon = relaxedsets in Exim.- Signing headers that the relay legitimately touches. Do not include
Received:orReturn-Path:in the signed header list. Exim’s defaults are safe; customdkim_sign_headerslists sometimes are not. - A key rotation on the panel without a DNS update, so the selector in the signature points at a stale public key.
Verify
Send a message from the domain to a mailbox where you can read raw headers. In Authentication-Results: you want dkim=pass header.d=example.com and, if a DMARC record exists, dmarc=pass. In Gmail, the sender line should show the display name with no via label. Then send a second message from an application that connects to the relay directly and compare: if it shows header.d= with a mailbaby.net domain, that application is unsigned and needs routing through the MTA. The common pitfall is testing only from webmail, which always goes through Exim and always signs, and concluding that DKIM is fine when the customer’s contact form is bypassing it.
MailBaby DKIM at a glance
Official documentation: RFC 6376 (DKIM), RFC 5321 (SMTP), Linux man pages.
Related guides: Configuring DirectAdmin’s Exim to relay through MailBaby · Sending WHMCS notifications through MailBaby (SMTP settings and DKIM) · Newsletters and mailing lists through MailBaby: staying under the 6,000/hour limit and out of spam folders.
Frequently asked questions
Does MailBaby strip or replace my DKIM signature?
No. A valid DKIM-Signature: from your server passes through unchanged and still verifies at the destination, because the relay does not alter the body or the signed headers. MailBaby only adds its own transport signature when the message arrives with no signature at all.
Does “via mailbaby.net” hurt deliverability?
The label itself is cosmetic, but what causes it, an unaligned transport signature, matters for DMARC. Direct mail still passes DMARC through aligned SPF if the domain includes spf-c.mailbaby.net, but forwarded or SRS-rewritten mail fails, and a p=reject policy then rejects it. Signing at the source removes both the label and the risk.
Why does my WordPress or WHMCS mail show the via label when webmail does not?
Webmail always goes through Exim, which signs with the domain’s key. An SMTP plugin or WHMCS in SMTP mode talks to the relay directly and bypasses the panel’s signer, so those messages are unsigned when they arrive. Route them through the local MTA or sign them at the application.