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 sending 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, that signature survives. Mailway never injects tracking pixels, rewrites links, or appends footers — the mutations that silently break a DKIM body hash. Your signature is relayed intact.

The two things that can change the bytes

Mailway rewrites a relayed message in exactly two situations, both DKIM-safe or opt-in: 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, the provider re-signs the headers), and re-encoding through a structured-only API provider, which is off by default and an admin must enable per project. Both are detailed on the SMTP relay page. Everything else is byte-for-byte, so a signature that passed before Mailway passes after.

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). Amazon SES and Mailtrap report delivery today; other providers stop at accepted, which is not a failure — see troubleshooting.

Accepted is not delivered

Most email APIs only ever tell you a provider accepted the handoff, and call that “delivered.” Mailway keeps the two separate and never relabels one as the other. “Accept rate” on your 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. Because every provider you use reports back into the same gateway, Mailway normalizes what comes back into one delivery history with one vocabulary: a hard bounce is a hard bounce whether Amazon SES or Mailtrap 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. The same address won’t go out through SendGrid tomorrow either. 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 delivered instead.

The honest boundary: the history is built from what providers report back. Providers wired for delivery events (Amazon SES and Mailtrap today) contribute delivered / bounced / complained; the rest stop at accepted — which the dashboard 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 honest 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 — stated honestly:

• It verifies the signature on the message Mailway received and stored, against the signer’s published DNS key. A pass is a real integrity proof — the sender’s own domain vouched for those exact bytes, independent of Mailway. 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 plans and up.

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 green auth, work the troubleshooting guide next.