What providers change

Mailway’s fidelity promise covers what Mailway does. Mailway archives the message your app hands over, and hands the same message to your provider, byte-for-byte apart from the automatic exceptions. What the provider does to its own copy before delivery is outside Mailway’s control. So we tested it, and this page publishes what we found.

The short version

What changes depends on the provider. Some change only a couple of headers; some rewrite the HTML. Over SMTP, SMTP2GO only added headers of its own.
Tracking on by default. Mailtrap inserted an open-tracking pixel into HTML. Brevo, Mailjet, and MailerSend inserted one and also rewrote links to go through their click trackers. Where a provider lets you switch its tracking off, the section below says how.
Visible content. MailerSend appended a “Delivered by MailerSend” line to both the text and the HTML part.
Unsubscribe headers over SMTP. Nuntly delivered mail without its List-Unsubscribe and List-Unsubscribe-Post headers; MailerSend removed those and every other custom header; Resend rewrote a two-link List-Unsubscribe into one unusable link.
A sender’s own DKIM signature. If your app signs a message before handing it to Mailway, the standard way (over CRLF line endings; see the automatic exceptions), the signature arrives at your provider intact. SMTP2GO, over SMTP, kept it valid at the inbox; for each other provider, the table below shows how it breaks or removes it on the way.
Mailway’s archived copy keeps that signature intact. It holds the message as Mailway received it, with only the header fixes and line endings described in the automatic exceptions. Mailway checks the signature shortly after receiving the mail and keeps the result (see DKIM validation). That result is the lasting evidence: a signature can only be checked against a key that is still published, and you may rotate yours.
Inbox authentication comes from the provider’s own DKIM for your domain. It passed at every provider we tested. Set it up per provider; see Deliverability.

Results

Tested in 2026 Q3. The Mailway side of every test was the same: the archived copy was byte-identical to what we sent, and our DKIM signature passed on it.

Provider	Headers	Text + HTML message	Text-only message	Your DKIM at the inbox
Amazon SES	Replaces `Message-ID` and `Date`	Both parts unchanged	Unchanged	❌ fails (both headers are signed)
Mailtrap	Unchanged	Text unchanged; open-tracking pixel added to the HTML; links left alone	Unchanged (7-bit); quoted-printable line breaks re-wrapped	❌ fails (body hash)
Postmark	Removes your signature; new `Message-ID` and `Date`; headers re-ordered	Both parts’ content unchanged, rebuilt with a new MIME boundary	Re-encoded (7-bit → quoted-printable)	❌ removed
Brevo	Keeps `Message-ID` and `Date`; adds `List-Unsubscribe`	Text unchanged; HTML rewritten: open-tracking pixel added, links rewritten through Brevo’s click tracker, entities converted	Converted to HTML (the text part is gone) with a tracking pixel	❌ fails (body hash)
Resend	Removes your signature; new `Message-ID` and `Date` (Resend delivers through Amazon SES); over SMTP, corrupts a two-link `List-Unsubscribe` and turns `X-Priority` into `Priority`	Both parts’ content unchanged, rebuilt with a new MIME boundary; no tracking	Unchanged	❌ removed
Mailjet	Removes your signature; new `Message-ID` (keeps `Date`); adds `List-Unsubscribe`	Text unchanged; HTML rewritten (with tracking on, the default): open-tracking pixel added, links rewritten through Mailjet’s click tracker, hidden tracking links added	Unchanged	❌ removed
MailerSend	Removes your signature; new `Message-ID` and `Date`; over SMTP, removes every custom header, `List-Unsubscribe` included	“Delivered by MailerSend” appended to both parts; HTML rewritten (with tracking on, the default): open-tracking pixel added, links rewritten through MailerSend’s click tracker, entities converted; new MIME boundary	“Delivered by MailerSend” appended	❌ removed
Nuntly	Removes your signature; new `Message-ID` and `Date` (Nuntly delivers through Amazon SES); over SMTP, removes `List-Unsubscribe` and `List-Unsubscribe-Post` and turns `X-Priority` into `Priority`	Both parts’ content unchanged, rebuilt with a new MIME boundary; no tracking; over SMTP, inline images moved into the HTML as `data:` URIs and attached as regular files	Unchanged	❌ removed
SMTP2GO	Over SMTP, unchanged: keeps `Message-ID`, `Date`, and every header you set; adds only its own headers. Over the API, new `Message-ID` and `Date`	Over SMTP, unchanged, down to the MIME boundary; no tracking (off by default). Over the API, rebuilt with a new MIME structure, content unchanged	Unchanged	✅ passes over SMTP

Every provider’s own DKIM signature passed.

Not tested: SendGrid, Mailgun, Mandrill, Gmail / Google Workspace, and generic SMTP. This page lists only what was tested.

Provider by provider

Amazon SES

SES left both parts of a multipart message, and a text-only message, exactly as sent, down to the MIME boundary. It does give every message its own Message-ID (…@<region>.amazonses.com) and a new Date. Standard DKIM signing covers both headers, so a signature your app applied fails at the inbox. One untested possibility: a signature that doesn’t cover Message-ID or Date might survive SES.

Everything else arrived as sent, over SMTP and the API: links (including mailto: and tel:) were left alone, with no tracking, and every header we set arrived, including List-Unsubscribe, List-Unsubscribe-Post, X-Priority, Reply-To, custom X- headers and a non-ASCII value. Over SMTP, an inline cid: image arrived exactly as sent. SES adds Feedback-ID and X-SES-Outgoing, and signs with your domain’s DKIM and with Amazon SES’s own.

Mailtrap

Mailtrap keeps your headers and your text part. A plain 7-bit text message arrived with its body untouched, apart from the trace and signature headers Mailtrap adds. But in the HTML part it inserted a 1×1 open-tracking image before </body>, and it re-wrapped the soft line breaks of a quoted-printable body. Either one breaks the DKIM body hash. Links were not rewritten in our test. If you don’t want opens tracked, check the tracking settings for your sender domain in Mailtrap.

Over SMTP, Mailtrap kept Message-ID and Date, all five kinds of link (including mailto: and tel:), an inline cid: image with its Content-ID and bytes, and every header we set: List-Unsubscribe, List-Unsubscribe-Post, X-Priority, Reply-To, custom X- headers and a non-ASCII value. It adds no List-Unsubscribe of its own. It adds its own X-MT-Data, CFBL-Address and Feedback-ID headers, and signs with its DKIM for your domain.

Postmark

Postmark builds its own message from yours, over its API and over SMTP alike. It removes an existing DKIM signature, assigns a new Message-ID and Date, re-encodes 7-bit bodies as quoted-printable, rebuilds the MIME structure with its own boundary, and re-orders the headers. The content of both parts came through unchanged, and no tracking was added in our test. The delivered bytes are Postmark’s, not yours.

Over SMTP, links (including mailto: and tel:) were left alone, an inline cid: image arrived with its Content-ID and bytes intact, and every header we set arrived, including List-Unsubscribe, List-Unsubscribe-Post, X-Priority, Reply-To and custom X- headers. Postmark adds its own X-PM-* headers and signs with its DKIM for your domain and its own.

Brevo

Brevo changes the content, not just the envelope around it:

A text + HTML message keeps its text part, but the HTML is rewritten. Brevo inserts its own open-tracking image, routes every link through its click tracker (r.brevo.<your domain>/tr/cl/…), and re-serializes the markup (HTML entities become characters, a <head> is added).
A text-only message is delivered as HTML: the text part is replaced, line breaks become <br/>, and the tracking image is added.
Brevo adds a one-click List-Unsubscribe header, pointing at its own unsubscribe page, to mail that has none. A List-Unsubscribe you set arrived unchanged.

It does the same over SMTP and over the API. The click tracker rewrites web links only: mailto: and tel: links arrived as sent. X-Priority, Reply-To, custom X- headers and a non-ASCII value arrived intact on both transports. Over SMTP, an inline cid: image kept its Content-ID and bytes; over the API it arrives as a plain attachment, because Brevo’s API has no field for an image’s Content-ID. Brevo’s own advice is to host images and link to them; to embed one, send over SMTP. Brevo’s help center says opens and clicks are tracked by default on transactional mail. It offers anonymized tracking and per-contact tracking consent. We haven’t found a documented way to switch the rewriting off. Your DKIM signature is still in the delivered message, but the body no longer matches it.

Resend

Resend sends through Amazon SES, and it shows: every message gets an SES Message-ID (…@eu-west-1.amazonses.com in our test) and a new Date, leaves from an SES address (X-SES-Outgoing), and carries a second DKIM signature from amazonses.com. On top of that Resend removes an existing DKIM signature and rebuilds the MIME structure with its own boundary. The content of both parts came through unchanged, links included, and no tracking was added. Resend’s open and click tracking are settings on your domain in Resend; neither was on in our test. Resend signs with its own DKIM for your domain (selector resend) alongside SES’s.

Two headers changed over SMTP:

List-Unsubscribe was corrupted. We sent a mailto: link and an https: link, folded over two lines as the standard allows. Resend delivered <mailto:https://example.com/unsubscribe?u=test>: the email address is gone and the web link is wrapped as a mailto:, so neither works, while List-Unsubscribe-Post still announces one-click unsubscribe. If your mail relies on it, send List-Unsubscribe with a single link, or check how Resend delivers yours.
X-Priority: 3 arrived as Priority: normal.

Links, Reply-To, custom X- headers and a non-ASCII value arrived as sent. An inline cid: image kept its Content-ID and bytes, inside a reordered MIME structure, over SMTP and over the API alike.

That has a consequence beyond the message itself. Resend and Amazon SES are not independent paths. A chain of your own SES account with Resend as backup still fails over between different accounts, regions and IP addresses, which covers the common failures: a suspended account, an exhausted quota, a bad key. But an outage in SES itself can reach both. For backup that doesn’t share infrastructure, pair SES or Resend with a provider that runs its own sending network.

Mailjet

Mailjet keeps your text part and your Date, but gives every message its own Message-ID, removes an existing DKIM signature, and adds a one-click List-Unsubscribe header. With its tracking on, which is the default, it rewrites the HTML part: every link goes through its click tracker (<id>.mjt.lu/lnk/…), an open-tracking image is added, and so are a few hidden links. It does this over SMTP and over the API.

You can turn this off in Mailjet: Account → Tracking → Track openers and Track clicks (“transactional and campaigns”). The setting applies to the whole account, sub-accounts included. Mailjet signs with its own DKIM for your domain (selector mailjet).

The click tracker rewrites web links only: mailto: and tel: links arrived as sent. Mailjet adds its List-Unsubscribe only when your message has none; a List-Unsubscribe you set arrived unchanged, and so did X-Priority, Reply-To and custom X- headers. Over SMTP, a non-ASCII header value and an inline cid: image (Content-ID and bytes) arrived intact.

MailerSend

MailerSend gives every message its own Message-ID (…@mailersend.net) and Date, removes an existing DKIM signature, and rebuilds the MIME structure. It also changes what your recipient reads: in our test account it appended “Delivered by MailerSend” to the end of both the text and the HTML part. That’s a footer on the message itself, likely tied to the account’s plan; check yours before relying on it.

With its tracking on, which is the default, it also rewrites the HTML: every link goes through <id>.click.mailersend.net, and a hidden open-tracking image is added. The tracking settings live on your domain in MailerSend. It does all of this over SMTP and over the API, and signs with its own DKIM for your domain (selector ms1).

Over SMTP, MailerSend removes every custom header we set: List-Unsubscribe, List-Unsubscribe-Post, X-Priority, custom X- headers and a non-ASCII value, all gone from the delivered copy in our test account. Reply-To is kept, and when a message has none MailerSend adds one set to the From address. The mailto: and tel: links are left alone by its click tracker, and an inline cid: image arrived with its Content-ID and bytes intact.

Over the API, custom headers are a Professional-plan feature in MailerSend. Mailway sends them in MailerSend’s headers field; on a lower plan MailerSend refuses them (“This feature requires a Professional plan or higher”), and Mailway then sends the mail without them, so it’s still delivered, just without your headers. Our test account is below Professional, so we’ve seen the refusal and the fallback, not the headers arriving.

Nuntly

Nuntly delivers through Amazon SES, so every message gets a new Message-ID (…@eu-west-1.amazonses.com) and Date. It rebuilds the message, over SMTP too: the MIME structure is new and an existing DKIM signature is removed. The text and the HTML content arrived unchanged, with no tracking: every link was left alone and no image was added.

Three things changed beyond that:

Unsubscribe headers, over SMTP. Mail relayed over Nuntly’s SMTP arrived without its List-Unsubscribe and List-Unsubscribe-Post headers. The same headers sent through the HTTP API, which goes out over Nuntly’s API, arrived intact. Gmail and Yahoo expect one-click unsubscribe from bulk senders, so check this before relaying bulk mail through Nuntly’s SMTP.
Priority, over SMTP. X-Priority: 3 arrived as Priority: normal. Over the API, X-Priority arrived as sent.
Inline images, over SMTP. An image embedded with a cid: reference arrived written into the HTML as a data: URI, and the image itself was attached as a regular file. How that displays depends on the recipient’s mail client. Over the API, an inline image arrives as a plain attachment: Nuntly’s API has no field for an image’s Content-ID.

Every other header we set arrived unchanged, including Reply-To, custom X- headers and a non-ASCII value. Nuntly signs with its own DKIM for your domain, and Amazon SES adds its own signature as well.

SMTP2GO

Over SMTP, SMTP2GO delivered the message as sent. Message-ID, Date, the MIME structure, both parts, every link, an inline cid: image and every header we set (List-Unsubscribe, List-Unsubscribe-Post, X-Priority, Reply-To, custom X- headers, a non-ASCII value) arrived unchanged. It adds only headers of its own (Feedback-ID, X-Report-Abuse, X-SMTPCORP-Track) and its DKIM signature for your domain, and a DKIM signature your app applied still passed at the inbox. Open and click tracking and the unsubscribe footer are off by default; turning them on would change the message.

Over the API, SMTP2GO builds its own message from the fields it receives: a new Message-ID and Date and a new MIME structure, with the text and HTML content, the links, the inline image, and the custom headers intact.

How we tested

Sender domain with SPF, DMARC, and each provider’s DKIM set up, plus a test DKIM key of our own (relaxed/relaxed, signing From, To, Subject, Message-ID, MIME-Version and Date).
For each provider, over Mailway’s SMTP endpoint:
- a plain 7-bit text message;
- a text-only message signed with the test key, quoted-printable;
- a signed multipart/alternative message with a text and an HTML part, a link in each, and non-ASCII text.
Brevo, Resend, Mailjet, and MailerSend also got an HTTP API message.
Then, for every provider above, a set of seven over SMTP and the HTTP API: plain text; text + HTML; five kinds of link (plain, with a query string and fragment, mailto:, tel:, and link text that differs from its target); an inline and a remote image; custom headers (List-Unsubscribe, X-Priority, custom X- headers, a non-ASCII value, a long folded value, Reply-To); and two signed with the test key, plain and with all of the above. SendGrid, Mailgun, and Mandrill get the same set with their first test.
Every message went through Mailway to the provider and on to a Gmail inbox. We compared the delivered copy with Mailway’s archived copy, decoded part by part, checked the test signature with an independent DKIM verifier, and read Gmail’s own Authentication-Results.
Not covered yet: attachments, and messages over the provider’s recipient limit.

Providers change their behavior without notice. We’ll re-run these tests and date every update.

What Mailway sends the provider

The archived bytes, with one addition: a few providers take instructions through message headers, and Mailway adds those at the top of the message. The provider reads these headers and removes them before delivery (we checked each one), and they aren’t covered by your DKIM signature.

Provider	Header Mailway sets	What it’s for
Amazon SES	`X-SES-CONFIGURATION-SET`	the account’s configuration set, which turns on SES’s delivery events
Postmark	`X-PM-Metadata-mw`	the mail’s Mailway id, so Postmark’s events match the right mail
Mailjet	`X-MJ-CustomID`	the mail’s Mailway id, so Mailjet’s events match the right mail

If your message already carries one of these headers, Mailway’s value replaces yours. Your header is removed from the copy the provider gets, and Mailway’s is added. Your recipient never sees either, since the provider removes it, and Mailway’s archive keeps your original. But inside the provider your value is gone: with Mailjet, for example, the CustomID in its message history and its events is Mailway’s id, not the one your app set. If your app relies on its own value there, track it on Mailway’s side instead.

Mailway’s archive keeps the message as Mailway received it, after its own changes on receipt: a missing Message-ID or Date added, a Bcc field removed, and line endings sent as CRLF. Above a provider’s recipient limit, Mailway also rewrites the visible recipient headers in the copy the provider gets; the archive keeps them as they were. Details: SMTP relay.

What this means for the delivery certificate and the share viewer: both show the message Mailway received and handed over. That’s the evidence you control. The recipient’s copy is the provider’s version of it.