FAQ

No. SPF and DKIM are for outbound/sender verification. We're receiving mail, not sending it. Your existing SPF/DKIM setup is unaffected.

You can! But then you deal with: IP reputation, spam filtering, TLS certs, parsing MIME, retry queues, monitoring, scaling...SMTP is basic ancient devil magic. We handle all of that so you can focus on what to do with the emails, not how to receive them.

Also, we plan to open source our service, called MxBox internally, soon. You will be able to fully host MyMX! ...if you are into that sort of thing.

SES drops emails into S3 as raw .eml files. You still need to parse MIME, extract attachments, build a webhook system, handle retries, etc. We give you parsed JSON with automatic webhook delivery and retries built in.

We automatically retry up to 6 times over approximately 10 hours:

1. Immediate (first attempt)
2. +60 seconds (inline retry)
3. +5 minutes
4. +30 minutes
5. +2 hours
6. +8 hours

The first two attempts happen immediately. Attempts 3-6 are scheduled and may vary by up to 5 minutes.

Your email is stored until delivery succeeds. After all retries are exhausted, the email shows as "failing" and you can manually replay it anytime. We don't lose mail.

Yes. From the Logs page, click on any email to see its delivery history, then hit "Replay" on any delivery. This sends the exact same payload with the same event ID. This is useful for debugging or recovering from handler bugs.

If the replay succeeds, any pending automatic retries are cancelled. You don't need to worry about duplicate deliveries after a successful manual replay.

Because replays use the same event ID, your webhook handler should be idempotent: track processed event IDs and skip duplicates. This is standard webhook practice (Stripe does the same thing).

Yes. You might receive the same webhook twice due to network issues, retries, or manual replays. Track the id field from each webhook and skip events you've already processed.

If you receive a duplicate, return a 2xx response to acknowledge it. Don't error out. This stops retry loops and keeps your logs clean.

An email shows as "failing" when it was accepted but all webhook delivery attempts have failed so far. This means your endpoint returned an error or was unreachable for every attempt.

Check your endpoint URL and server logs, then use the manual replay feature to redeliver. Once a delivery succeeds, the status changes to "accepted" or "completed".

Senders get a temporary failure (451 SMTP status) and their mail server retries automatically. That's how SMTP works, actually. Resilience is built into the protocol. Once we're back, queued mail flows through.

Only if you want us to. By default we store until delivery succeeds. If you enable auto-discard and confirm processing (via the X-MyMX-Confirmed header), we wipe the content immediately after your webhook responds. Metadata stays for your logs.

5MB in beta, but we will expand to 25MB, the standard SMTP limit.

We score every email and include the spam score in the webhook payload. You decide the threshold for what to accept or reject. We never silently drop mail. You always see what came in.

No. We only count accepted emails that successfully trigger a webhook to your endpoint.

Technically no. Practically, yes. Without it, anyone who discovers your webhook URL can POST fake emails to your endpoint. The signature proves the request actually came from MyMX. Use it.

24 hours. Long enough for retries and async processing, short enough that you can't bookmark them forever.