If the sign-in or verification email never arrives, the message almost always left your app and stopped somewhere you are not looking. Open your mail provider's own dashboard first. If the message is not listed there at all, the failure is between your container and the provider. If it is listed and marked rejected or suppressed, the failure is your DNS records or an unverified sender address.
Nothing bounces. Nothing errors. The application log says the mail was sent, because from the application's point of view it was.
Why is this worse than ordinary broken email?
Because passwordless sign-in has no fallback. A tool that emails you a magic link or a verification link has no second route in: no password field to try, no recovery question, no admin console behind a different door. Broken mail does not degrade the site, it locks you out of it.
Fider's maintainer wrote the trap out in full when opening issue #1204 in September 2024:
You're stuck here. You can't resend, try again, change email, anything like that.
mattwoberts, getfider/fider issue 1204
That issue stayed open for over a year before pull request #1378, "Allow resending signup verification email for pending tenants", was merged in October 2025. Across the fence, Astuto's issue #330, titled simply "SMTP configuration", is the highest-comment issue in that repository at 24 comments, still open and now frozen because the repository was archived. Both read from the GitHub API on 23 August 2026.
This is not the same problem as any of these, and it is worth ruling them out before you start:
- The relay rejected your login, in which case you would see 535 5.7.8 username and password not accepted rather than silence.
- The connection never opened, because your host blocks the port. That gives you a timeout, and it is covered in your host blocks the SMTP port.
- The message arrived at the recipient's provider and was refused with a code, such as Gmail's 550 5.7.26. That is a bounce, and a bounce is good news by comparison, because it tells you what is wrong.
How do you find out where the message stopped?
Trace it forward, in this order, and stop at the first place it is missing.
- Look in your mail provider's dashboard, not your inbox. Every transactional provider logs each accepted message with a delivery status. This single step splits the problem in half. If your provider never saw it, skip to the container. If it saw it and dropped it, skip to the DNS records.
- Read the container logs while you trigger a send. Follow them live rather than reading them after:
docker compose logs -f --tail=200. Many self-hosted tools log a successful hand-off and nothing else, so a clean log here does not mean the mail arrived, only that the app thinks it sent it. - Test the relay from inside the container, because that is the network path the app actually uses. A test from your laptop proves nothing about the container's egress.
- Check the DNS records for the sending domain, especially the DKIM selector your provider gave you. A missing selector is invisible from the sending side and is the reason a message can be accepted by the relay and then quietly discarded.
For the relay test, swaks gives you the whole conversation:
swaks --to you@example.com \
--from board@yourdomain.com \
--server smtp.provider.com:587 \
--tls --auth LOGIN \
--auth-user 'apikey' --auth-password 'secret'For the DNS side, check all three records in one pass, substituting your own domain and the selector your provider issued:
dig +short TXT yourdomain.com | grep spf1
dig +short TXT selector._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.comAn empty result from the middle line is the answer more often than anything else on this page.
What actually stops the message?
Real reports on Fider's tracker cluster into four causes, and it is worth knowing which one you have before you change anything.
| Where it stops | What you see | How to confirm |
|---|---|---|
| Never leaves the container | Provider dashboard shows nothing at all | Relay test from inside the container succeeds or fails |
| Blocked outbound port | The send hangs, then times out | nc -zv host 587 from inside the container |
| Accepted by the relay, then dropped | Provider dashboard shows the message, marked rejected or suppressed | The provider's own reason column |
| Delivered, filtered on arrival | Provider shows delivered, recipient sees nothing | Search the recipient's spam folder and check the message headers |
The third row is the cruel one, because the sending side looks perfect. In the discussion on issue #1129, whose title is "[BUG] Email not sent from Docker image regardless of using Mailgun or SMTP" and which ran to thirteen comments, one reporter chased the problem across two providers and a port unblock request to their host before finding it:
The DKIM on my domain was not set for Mailjet properly. It's weird that Mailjet doesn't mention this email as rejected or note the problem anywhere.
Cristy94, getfider/fider issue 1129
One payment, no subscription, unlimited products.
How do you get back in when you are already locked out?
If the install is brand new and stuck at a pending verification screen, your options depend on what version you are running.
- Check for a resend control first. Fider gained one in the pull request merged in October 2025, so an install newer than that has a supported route out. Upgrading before you touch anything destructive is the cheapest thing to try.
- Point the tool at a relay you can read, then trigger the email again. Setting up a fresh transactional account takes minutes and gives you a dashboard showing exactly what happened to the next attempt, which is worth more than another blind retry.
- Capture the mail locally instead, using a catch-all SMTP debugger on the same network as the app. You get the verification link out of the captured message and can finish setup, then fix real delivery afterwards with no clock running.
- Only then consider the database. Before the resend feature existed, the maintainer's own note said the only way round was to clear the database and start again. Take a dump first, whatever you do, so a wrong guess is recoverable.
Once you are back in, send a real test message to an address at each provider your users are actually on, and open the headers to confirm SPF, DKIM and DMARC all passed. SMTP for self-hosted tools covers what each record does.
What a support centre that sends nothing cannot do
A closing note on scope, since it changes the size of the problem rather than solving it. This whole failure mode needs two things: a tool that sends mail, and sign-in that depends on it. Docket's free edition has neither. It runs as static files plus two endpoints, with no SMTP client in the runtime, so there is no verification email to lose and no pending-activation screen to be stuck behind. The paid tiers add email notifications, and from that point the DNS records and the relay dashboard matter to a Docket site exactly as much as to anything else. What does not come back is the lockout, because the notifications are not the way in.
Frequently asked questions
The application log says the email was sent, so why did nothing arrive?
Because most tools log the hand-off to the mail server, not the delivery. The relay can accept a message and then reject or suppress it a second later for a reason the sending application never hears about, such as an unverified sender address or a missing DKIM record. Treat the application log as proof that the app tried, and the provider's dashboard as proof of what happened next.
How do I tell a blocked port apart from wrong credentials?
By what the failure looks like. A blocked port hangs and then times out, with no reply from the server at all. Wrong credentials produce an immediate numbered reply, usually 535 5.7.8. Running nc -zv yourhost 587 from inside the container settles it in one line: if the connection is refused or hangs, no password would have helped.
Can I just disable email verification during setup?
Some tools allow it through an environment variable and some do not, and it is worth checking your own documentation before assuming either way. It is a reasonable temporary measure to get through first-run setup on an install nobody else can reach yet. It is not something to leave on for a public site, because verification is what stops someone claiming an address that is not theirs.
Should I run my own mail server to avoid depending on a provider?
Almost never for this. A new sending IP has no reputation with any mailbox provider and cloud address ranges often arrive already distrusted, so a self-run server makes silent non-delivery more likely rather than less. The dashboard a transactional provider gives you is also the single most useful debugging tool in this entire failure mode.
Why does the same configuration work on one server and not another?
Usually outbound network policy or DNS, not the configuration. One report on Fider's tracker had identical SMTP settings working on one host and failing on another, and hosts differ on which outbound mail ports they permit. Test the port from inside the failing container before comparing config files line by line.