Raw source and branding
When someone opens View Source / Show original, they see every hop and every cryptographic signature. Werkmail already brands the parts we control. A few lines are written by the outbound mail platform and cannot be rewritten, renamed, or hidden.
What Werkmail already brands
| Header / record | What recipients see |
|---|---|
| Message-ID | <uuid@your-from-host> — the host is the domain after @ on From. If that host is missing, it falls back to werkmail.eu. Simple send uses raw MIME so this header is not replaced by a platform-generated id. |
| Return-Path / MAIL FROM | bounce.<your-domain> after MAIL FROM DNS is live. Envelope sender is on your domain. |
| List-Unsubscribe | HTTPS on the product origin (/u/…, /u/oneclick/…). One-click POST is signed. |
| List-Unsubscribe-Post | List-Unsubscribe=One-Click when one-click is enabled. |
| From / Reply-To | Exactly what you send. |
| DNS you publish | DKIM CNAMEs, MAIL FROM MX, and SPF include: all point at product-branded hostnames (*.dkim.werkmail.eu, feedback.werkmail.eu, spf.werkmail.eu). Tenants never paste platform hostnames into their DNS panel. |
We do not add X-Mailer or a product name in custom headers. Those fail inbox quality tests and look like bulk software.
What the platform always adds
The outbound platform always signs mail with its own DKIM (d= on the platform domain, long random selector). Official reason: complaint feedback loops. That signature cannot be disabled, renamed, or replaced with a Werkmail d=.
If your domain identity is verified, the same message also carries a second DKIM signature: d=your-domain. Inbox alignment (DMARC) uses your domain signature. The platform signature stays alongside it. That is normal for this sending path.
A message that shows only the platform DKIM (d= on the platform domain, no d=your-domain) usually means the sending identity is not fully verified yet, or the From host is not the verified domain. Finish DNS and authentication, wait until DKIM is SUCCESS, and re-send. You should then see two DKIM-Signature headers.
A platform-generated Message-ID (host is not your From domain) means that particular send used the simple API fallback — raw MIME was unavailable. Domain DKIM is independent of that path: once the identity is verified, both paths still add d=your-domain.
What we will not do (and why)
| Idea | Why not |
|---|---|
Extra DKIM d= on werkmail.eu for mail whose From is the customer domain |
Unaligned. Some receivers pick one signature at random and fail DMARC. |
| Rewrite or strip the platform DKIM after send | Breaks the signature. Receivers treat it as tampering. |
| Claim the platform selector as ours | The d= domain is what receivers display. The selector name does not hide it. |
Hide Received hops or Feedback-ID |
Written by the platform after we hand the message off. Not under API control. |
When you need zero platform signatures
The only way to drop platform DKIM, Received, and Feedback-ID entirely is to send through an SMTP relay you control, so mail never enters that platform. Werkmail already supports an optional per-workspace SMTP relay (Settings → SMTP relay, off by default). That path has its own TLS, auth, and deliverability trade-offs — it is an escape hatch, not the default EU sending path. Open/click tracking does not apply over SMTP.
Mental model
You → Werkmail API
├─ brands Message-ID, From, List-Unsubscribe
├─ sets MAIL FROM to bounce.<your-domain>
└─ hands MIME to the outbound platform
├─ adds platform DKIM (always)
├─ adds your-domain DKIM (when identity is verified)
└─ adds Received / Feedback-ID
DNS aliases (*.dkim.werkmail.eu) are how tenants publish records. They do not change the d= string inside the DKIM header. The cryptographic domain in the signature is still the identity that was verified — your domain plus the platform’s own signer.