Troubleshooting

Find what you're seeing, then work down its list. The most common cause comes first. Each one links to where the fix is explained in full.

If none of them fits, ask on the community forum with what you see and what you've tried. Support says what else there is.

Mail sent to us doesn't arrive

1. The MX record isn't published, or points somewhere else. dig MX example.com should name your mail server. The records to publish are under Copy the DNS records.
2. Port 25 is closed on the way in. Check the machine's firewall and your provider's. The sending server's bounce usually says it couldn't connect.
3. It arrived, in Junk Mail. Why a message is in Junk Mail shows the reasons.
4. The server refused it. Management › Emails › History › Inbound Delivery records each attempt and the reply the sender got: Following a message.

Our mail is refused, or lands in spam

Open the message at the receiving end, Gmail's Show original for example, and look at three lines: SPF, DKIM and DMARC. Each should say pass.

1. SPF, DKIM or DMARC isn't published, or is out of date. Copy the DNS records and check the DKIM keys. Letting the server publish them itself keeps them right.
2. Reverse DNS doesn't name the server. The machine's address should look up to mail.example.com. It's set with your hosting provider, not your DNS host.
3. The address has a poor reputation. New and cheap cloud addresses often do. Sending through a relay service such as Amazon SES or Mailgun hands that problem to someone who manages it.
4. The other side says why. A refused message waits in Management › Emails › Queued with the other server's last reply, and Delivery tests shows each step to one address: Following a message.

We can't send at all

1. Port 25 is blocked on the way out. Many hosts and most home connections do this. The sending guide's Check tells you. Then send through a relay service, or receive and send through inbuxa Relay.
2. The relay refuses the sign-in, or hasn't verified your sender domain yet. The queued message's last error says which.

No certificate, or mail apps warn about it

1. The name doesn't point at the server yet. Certificates can't be issued until it does. sudo inbuxa certs shows what the mail ports present and where the name resolves: The mail server's certificate.
2. An earlier order failed, and the server doesn't retry a failed order by itself. Ordered automatically, on the console's Certificates page, shows why, and Order again starts a new one: Why an order failed. From a terminal, sudo inbuxa certs --key - does the same.
3. A CAA record allows another certificate authority only. CAA records.
4. Behind Cloudflare, the mail server's name must be DNS only, not proxied.

The console says Failed to fetch

The browser couldn't reach the server, or the server didn't recognize the console. The causes, in order, are under If the console says Failed to fetch. The usual one is a server certificate the browser doesn't trust yet.

Before first boot, the server answers on port 8080 only: Reach the server during first boot.

Sign-in bounces straight back

The server only signs people in to the console and the webmail at the exact addresses it was given.

• Console: INBUXA_ADMIN_URL in the server's environment must be the console's address exactly: scheme, host and port, no trailing slash. Tell the server where the console is.
• Webmail: INBUXA_WEBMAIL_URL on the server must equal the webmail's PUBLIC_URL plus any BASE_PATH, and both sides need the same secret. Tell the server where the webmail is.

A container keeps the environment it was created with. After changing it, recreate the container rather than restarting it.

Everyone is locked out at once

1. The server banned your proxy, or the machine the webmail runs on. All sign-ins come from that one address, so one person's wrong passwords can get it banned. Add it under Settings › Security › Allowed IPs. If you can't reach the console to do that, use recovery mode.
2. A settings change cut the console off, such as a bad listener or certificate. Getting back in starts the server in recovery mode with an administrator of its own.

One person can't sign in

1. In a mail app: it may need an app password rather than the main one, or the protocol it uses may be switched off.
2. Their password lives in a directory: reset it there, not in inbuxa. Directories and SCIM.
3. Their account is locked: Locked accounts.
4. Otherwise, reset their password.

Something else you might see

• Administration is grayed out or missing in the webmail: If Administration is grayed out or missing.
• Someone can't find a person to share with: by default people can only find accounts they already have a connection to. Who you can share with.
• Something was deleted by mistake: Bringing something back.
• The server won't start after an update: inbuxa upgrade puts a component back as it was if it fails its check, and archives the server's data before it starts. Updating with the installer, and Upgrading for what each version asks.