# 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](/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.