Deliverability (SPF, DKIM, DMARC)

Whether your mail reaches the inbox is decided by domain authentication — SPF, DKIM, and DMARC — plus the sending reputation of the IPs it goes out on. Under BYOK, both of those belong to your provider account, on your DNS — not to Mailway.

Mailway relays your message byte-for-byte through the provider you own, on your reputation. It does not sign, rewrite, or re-envelope your mail to pass it off as its own. So the records below go on your domain and are issued by your provider — Mailway never sits in the authentication path.

Mailway doesn't own your sender domain

There are no Mailway DNS records to add to send mail — no MX pointed at us, no include:mailway.net in your SPF. You authenticate your domain with your provider (Amazon SES, SendGrid, Mailgun…), exactly as you would if you sent through them directly. Mailway is the router in front, not the sender of record.

The three records

Each one answers a different question a receiving mail server asks. Set all three — DMARC only means anything once SPF and DKIM are in place.

SPF — “is this server allowed to send for this domain?”

A TXT record listing the infrastructure authorized to send for your domain. With BYOK you authorize your provider’s sending servers, not Mailway’s. Your provider gives you the exact value; for Amazon SES it’s typically a custom MAIL FROM subdomain carrying:

v=spf1 include:amazonses.com ~all

SPF authenticates the envelope sender (the MAIL FROM), which your provider sets — so SPF passes on the provider’s domain unless you configure a custom MAIL FROM to align it with yours. That alignment is what DMARC cares about (below).

DKIM — “was this message signed by the domain, and untampered in flight?”

A cryptographic signature over the message, verified against a public key in your DNS. This is the record that matters most, and it’s where byte-fidelity earns its keep:

• Your provider signs on the way out. Once your domain is verified, most providers add their own DKIM signature — Amazon SES Easy DKIM publishes three CNAME records (<token>._domainkey.yourdomain.com) and signs every message aligned to your domain.
• If you sign before handing off, Mailway passes your signature on untouched. It never injects tracking pixels, rewrites links, or appends footers, the changes that silently break a DKIM body hash. The archive keeps the signature as received, and Mailway checks it shortly after receiving the mail and keeps the result, because a signature can only be checked while its key is still published. What reaches the inbox is up to the provider. Tested with signed messages in 2026 Q3: SMTP2GO, over SMTP, delivered the message unchanged and your signature passed. Amazon SES replaces Message-ID and Date. Mailtrap adds an open-tracking pixel to HTML and re-wraps quoted-printable bodies. Postmark, Resend, Mailjet, MailerSend, and Nuntly remove the signature. Brevo, Mailjet, and MailerSend add tracking to HTML (a pixel and rewritten links), Brevo turns text-only mail into HTML, and MailerSend appends a footer (details). Rely on the provider’s own signature (above) for inbox authentication; yours keeps its value in Mailway’s archive.

The five things that can change the bytes

Mailway changes a relayed message in exactly five situations. Each one leaves a DKIM signature made the usual way intact, or is opt-in:

• a message without a Message-ID or Date gets one when Mailway receives it, and a Bcc or Resent-Bcc field is removed. Nothing else in the header block changes and the body isn’t touched by this, so a signature made the usual way survives; one that signed a Bcc field, or signed a Date or Message-ID that wasn’t there, doesn’t;
• a bare line feed (one without a carriage return before it) or a bare carriage return (one without a line feed after it) is sent to the provider as a carriage return and a line feed (CRLF), the line ending SMTP requires. A signature made the standard way is computed over CRLF, so this doesn’t break it (one computed over the bare characters themselves doesn’t survive);
• a send above the provider’s recipient cap is fanned out BCC-style (header-only surgery: the body and its DKIM body hash are untouched, and the provider re-signs the headers);
• provider instruction headers (X-SES-CONFIGURATION-SET, X-PM-Metadata-mw, X-MJ-CustomID) are added at the top, replacing a same-named header of yours; the provider removes them before delivery;
• re-encoding through a structured-only API provider, which is off by default and an admin must enable per project.

All five are detailed on the SMTP relay page. Otherwise the handoff is byte-for-byte, so a signature that passed before Mailway still passes on the copy your provider receives.

DMARC — “what should I do if SPF and DKIM don’t line up?”

A TXT record at _dmarc.yourdomain.com that ties SPF/DKIM to your From: domain (alignment) and tells receivers what to do on failure. Start in monitor mode and tighten once you’ve confirmed pass rates:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Move p=none → p=quarantine → p=reject only after your rua reports show SPF or DKIM aligning on your domain for real traffic.

Who provides each value

Record	Type	Value comes from	What it proves
SPF	TXT	Your provider (e.g. include:amazonses.com)	The sending server is authorized
DKIM	CNAME / TXT	Your provider’s verification wizard	The message is signed by the domain and untampered
DMARC	TXT (_dmarc.)	You author it	The policy when SPF/DKIM don’t align

The exact SPF/DKIM strings are always your provider’s to hand you — see the Amazon SES guide for the concrete walk-through, and your provider’s domain-authentication wizard for the rest.

Verify it worked

1. Confirm the domain in your provider. It should read Verified with DKIM enabled (SES: the three CNAMEs resolved; the console shows “Successful”). This is the provider’s check, not Mailway’s.

2. Send yourself a test and read the receipts. Send a real message to a Gmail address, open Show original, and confirm SPF: PASS, DKIM: PASS, and DMARC: PASS — all aligned to your domain. Or paste into Mail Tester for a scored report.

3. Watch it settle in the console. The mail should reach accepted (your provider took it) and, if the provider emits delivery events, delivered (the recipient’s server confirmed receipt). Every supported provider except Gmail and generic SMTP reports delivery once its events are wired up; those two stop at accepted, which is not a failure — see troubleshooting.

Accepted is not delivered

A provider accepting the handoff and the recipient’s server receiving the mail are two different facts. Mailway keeps the two separate and never relabels one as the other. “Accept rate” on the console’s Dashboard is exactly that — provider acceptance — and a real delivered figure appears only for providers that report delivery events back.

One delivery history, every provider

Delivery events don’t just power a status column — they pool. Every provider that reports back (every supported provider except Gmail and generic SMTP) reports into the same gateway, and Mailway normalizes what comes back into one delivery history with one vocabulary: a hard bounce is a hard bounce whether Amazon SES, Mailgun, or Postmark reported it, and the console, the webhook events, and the suppression list all read from that same record.

This vantage point is structural — it’s what sitting in front of your providers buys, and it’s something no single provider can offer, because each one only ever sees its own traffic:

• Outcomes are comparable. The same kind of message through two providers shows two real outcomes, side by side, in one search — not two dashboards with two vocabularies.
• Knowledge transfers between providers. A hard bounce reported by SES lands the address on the project’s suppression list — and that list gates every send path and every provider in that project. The same address won’t go out through the project’s SendGrid account tomorrow either (suppression is per project; other projects keep their own lists). On its own, each provider only knows its own bounces.
• Failovers come with receipts. When one provider fails and another rescues the send, both attempts sit in the mail’s timeline: which provider failed, with what error, and which one accepted it instead.

The limit: the history is built from what providers report back. Providers wired for delivery events (every supported provider except Gmail and generic SMTP) contribute delivered / bounced / complained; the rest stop at accepted — which the console says plainly, per the aside above.

Delivery forensics in the console

That history has its own page: Forensics (Pro and up) reads your whole window and answers what no single provider dashboard can:

• the outcome mix with explicit denominators — accepted and delivered are never conflated,
• the same outcome taxonomy per provider, side by side — two providers, one vocabulary, directly comparable,
• outcomes split by mailbox provider (Gmail / Outlook / Yahoo / …),
• recurring failure signatures, grouped and counted, so a pattern reads as a pattern instead of scattered rows.

The same page carries a sender-domain readiness report for the Gmail/Yahoo bulk-sender rules: DKIM evidence taken from your real relayed traffic (not a DNS lint), SPF and DMARC presence, a one-click-unsubscribe sample — informational, since transactional mail is exempt and the report says so — and whether your volume even reaches the roughly-5,000-a-day threshold where those rules apply to you. No aggregate score anywhere: scores flatter, numbers inform.

DKIM validation in the console

DKIM isn’t only something you set up and forget — Mailway re-verifies the sender’s DKIM signature on the message it relayed and shows you the verdict, so you can see at a glance whether your signing actually holds.

• In the mail list, a shield sits beside each message: green when the signature verified, grey when there’s no sender signature, amber when it couldn’t be verified.
• On the mail’s detail page, an Authentication row shows the signing domain (d=), whether it aligns with your From:, and the exact verdict.

What it checks, and what it can’t:

• It verifies the signature on the message Mailway received and stored, against the signer’s published DNS key, shortly after receiving the mail. A pass means the sender’s own domain vouched for those exact bytes at that time. It’s the same check behind a proof-of-delivery certificate.
• It is not your provider’s downstream DKIM. Under BYOK your provider signs after Mailway hands the message off, on bytes Mailway never sees — so “no sender signature” on an API send is normal, and it says nothing about what the recipient’s server ultimately verified.

Available on Pro and up.

BIMI — your logo next to your mail

BIMI (Brand Indicators for Message Identification) is the optional fourth record: a TXT at default._bimi.yourdomain.com pointing at a square SVG logo you host on your own domain. Mailbox providers that honor BIMI can show that logo beside your messages — and the Mailway console shows it next to your mail (the list, the detail page, and the sender-domain readiness report on Forensics), so your senders stop being anonymous monogram tiles.

default._bimi.yourdomain.com.  TXT  "v=BIMI1; l=https://yourdomain.com/logo-bimi.svg;"

Before you set it up:

• BIMI is brand display, not deliverability. Publishing it moves no spam filter. It’s the reward for authentication done right, not a way to get there.
• It requires DMARC at enforcement — p=quarantine or p=reject on your domain. With p=none, receivers ignore the record entirely.
• Gmail wants more than the record: a Verified Mark Certificate (VMC — a paid certificate tied to a registered trademark, the a= tag) before it displays your logo. Yahoo displays without one, and the Mailway console needs only the bare record — no VMC, no trademark.

To publish: draw a square SVG (the SVG Tiny P/S profile — no scripts, no external references, ideally under 32 KB), serve it over HTTPS from your domain, add the TXT record above, and check it resolves:

dig +short TXT default._bimi.yourdomain.com

Mailway re-checks each sender domain’s record on its own (new domains within a day; a domain without a valid record weekly, one with a logo monthly), so a newly published record shows up within about a week — and if the SVG is rejected, the console tooltip tells you exactly why.

Newsletters and other bulk mail

Mailway carries any mail your own system builds, newsletters included. It has no contact lists, segments, or campaign editor: your system decides who gets what, and Mailway keeps a copy of each mail and sends it through your provider accounts. The terms don’t allow spam or mail to people who haven’t agreed to receive it.

Give bulk mail its own project, apart from your app’s transactional mail. Free includes 1 project, so a second one needs Pro and up.

• Suppression lists stay apart. Each project has its own suppression list, so a recipient who marks a newsletter as spam still gets their password resets.
• Failover stays on the right accounts. In its own project, bulk mail fails over only to provider accounts you’ve set up for it. Some provider accounts are for transactional mail only. Postmark, for example, wants bulk mail in a Broadcast message stream (Postmark’s guide). Over SMTP, your system names the stream in Postmark’s X-PM-Message-Stream header. Through the HTTP API, Mailway can’t choose a Postmark stream yet. Add Mailway’s webhook to that stream as well, because Postmark sets webhooks per stream.
• Failover doesn’t fix a list problem. If a provider pauses your account over spam complaints, failover sends the same mail through your next provider account, and the complaints follow. Fix the list first.

Gmail and Yahoo expect bulk senders to offer one-click unsubscribe: the List-Unsubscribe and List-Unsubscribe-Post headers. Over SMTP, your system adds them, because Mailway relays the message byte-for-byte and rules can’t change relayed mail. Over the HTTP API, set them in headers, or let a rule add them with inject_unsubscribe (rules: Team and up). Some providers change these headers on the way out (What providers change).

When it still goes to spam

Authentication passing is necessary, not sufficient — reputation and content matter too. The usual culprits, in order:

• DMARC not aligned. The classic BYOK failure: SPF/DKIM pass on the provider’s domain but not yours, so DMARC fails and mail is filtered or rejected. Fix alignment (custom MAIL FROM for SPF; provider DKIM on your domain) before anything else.
• Cold IP / domain reputation. New sending identities warm up slowly — this is your provider’s territory under BYOK.
• Missing or weak records — no DMARC, ~all where the receiver wanted more, no reverse DNS on a dedicated IP.
• Content and list hygiene — spammy HTML, no unsubscribe on bulk, sending to addresses on your suppression list.

If mail is landing in spam despite passing authentication, see the troubleshooting guide next.