Does Proton Mail or Fastmail win for a custom domain one person actually sends invoices from?

Fastmail. For one person sending invoices from their own domain, Fastmail is the mailbox that gets the PDF into a client’s inbox and the reply back to you without a bridge, a plugin, or a privacy model your accounting tool does not speak. Proton Mail wins if the requirement is that the provider cannot read the mailbox. That is a real requirement. It is not the requirement in the question. The question is invoices that arrive.

I have watched a solo operator move a domain to Proton because the marketing matched how they wanted to feel about email, then spend a month explaining to clients that the invoice was “in spam” or that the desktop client needed a bridge. The domain was fine. The job was not the job Proton is for.

What does sending an invoice actually require?

A From address on your domain. SPF, DKIM, and DMARC that a Microsoft 365 tenant will accept. A normal way to attach a PDF. A reply that lands in the same mailbox you check. An alias such as invoices@ or billing@ that is still you. None of that needs end-to-end encryption against your client. The client has to read the invoice. Encryption that only works Proton-to-Proton does not help a client on Google Workspace, and the copy you send them is readable by their provider anyway.

Fastmail is built around that list. You add the domain, it tells you the DNS records, you send from Apple Mail or the web with an app password, and aliases are a normal part of the product. Proton can add a custom domain on a paid plan and can publish the same kind of DNS. The sending path is where a single person gets hurt: Proton Bridge if you want a traditional mail client, a web app that is fine until a workflow wants SMTP, and a reputation story you have to test against the actual clients who pay you, not against Proton’s own inbox.

Where does Proton make this job harder?

Bridge. A lot of invoice habits live in Apple Mail, Outlook, or a small tool that sends mail over SMTP. Proton’s bridge translates that into Proton’s world. It works, and it is another process that has to be running on the machine that sends the invoice. When it is not, the send fails on a Friday and you blame the PDF. Fastmail is just an account. The client you already have logs in.

Filters on the other side. Some corporate gateways are jumpy about newer or privacy-branded sending domains, and about mail that does not look like ordinary authenticated mail from a long-lived sender. Fastmail’s shared reputation is the thing you are buying. Proton’s reputation is also real and often fine. “Often fine” is not what you want the first time you invoice a university or a bank. Send a real invoice, to a real client domain you depend on, before you move the domain. Do it from both if you are undecided. The one that lands in the inbox without a “this message looks unusual” banner is the one that wins, even if you prefer the other logo.

Search and bookkeeping. You will look for “invoice 1044” in a year. Fastmail search is ordinary mail search. Proton search has improved and is still constrained by the fact that the interesting parts of the message may be encrypted in ways that make the provider’s search a different product. For a mailbox whose purpose is a paper trail, ordinary search is a feature, not a failure of principle.

When Proton is the right answer anyway

Choose Proton if you already keep the rest of your life there, your clients are few, you have sent them mail from the custom domain and watched it arrive, and you do not need a third-party tool to send. The web app plus a domain is enough for some freelancers. The privacy property is then a bonus you are not paying for with bounced invoices.

Choose Proton if the invoice itself is sensitive in a way a normal client relationship is not, and you have a path to encrypt to that client that they will actually use. Most clients will not open a password-protected Proton message to pay you. They will ask you to resend it as a normal PDF. You will resend it. You will have done extra work to arrive at the Fastmail-shaped email.

Do not choose either one and also run your own mail server because it feels more serious. Deliverability becomes the product the month a client does not get the invoice. One person sending invoices does not want that month. Pay a company whose job is the domain’s reputation.

What about the DNS, the alias, and the reply-to?

Whichever you pick, the domain work is the same shape. MX to the provider. SPF that includes only them. DKIM on. DMARC at least at none while you watch, then quarantine when you see that nothing legitimate broke. A second tool still sending as the domain, a website form, an old Google Workspace you forgot, will fail SPF the day you tighten DMARC. List every sender before you get strict. An invoice provider that sends “on behalf of” you is a sender. Add it or stop using it.

Use a dedicated From address, billing@ or invoices@, that delivers to you. Fastmail aliases do this without a second mailbox fee in the way people hope. Proton addresses on a custom domain can too, on the plan that includes them. The point is that personal mail and invoices do not share one address that you are afraid to put on a PDF. Replies to the invoice address should still reach the phone you actually check. Test that. A pretty From line that replies into a mailbox you open monthly is how a client thinks you ignored them.

Put your legal name and the domain in the signature. Do not put a Proton or Fastmail marketing line. The client does not care which company holds the spool. They care that reply works.

What fails the month after you migrate?

The first failure is an old send path you forgot. A bookkeeping app, a Stripe receipt From address you customized, a contact form on the site, all still emitting mail for the domain after MX moved. Fastmail will receive the replies. The other tool will fail SPF and the client’s “your invoice bounced” mail will be the way you learn. Inventory every sender the week you move, not the week a client complains.

The second failure is a catch-all. It feels safe for a solo domain. It also collects spam to every guessable address, and it hides the fact that you typo’d the invoice alias. Prefer a real alias you named. Turn catch-all off once the real addresses work. Proton and Fastmail both offer the temptation. Decline it unless you have a reason you can say out loud.

The third failure is you, sending the invoice from the phone’s default Gmail because the custom-domain account was not the default on iOS. The PDF goes out from the wrong From, the client replies to Gmail, and the domain you pay for never sees the thread. Set the invoice alias as the From on the device you actually use to hit send. Send one to yourself from that phone before you send one to a client.

A test that takes one afternoon

1. Add the domain to the service you think you want. Publish SPF, DKIM, and a relaxed DMARC.
2. Send a one-line message with a tiny PDF to a Gmail address you control and to a Microsoft address you control, from the invoice alias.
3. Look at the headers, or at the “via” and spam placement. If it is in junk, you are not ready to invoice.
4. Reply from those accounts and confirm the reply hits the alias on your phone.
5. If you need Apple Mail or a desktop tool, try the send from there. If Proton requires the bridge and the bridge is the only way your real workflow sends, count that as a cost. If Fastmail logs in directly, that is the win.

Price will not rescue a bad fit. Both are paid once a custom domain is involved, and the cheaper plan is not cheaper if the first invoice sits in junk and you spend an afternoon on DNS you already published. Pay for the path your mail client already speaks. A domain on the wrong host is a logo, not a working billing system. If that path is a bridge you resent, you have already picked Fastmail and you are negotiating with yourself.

Fastmail wins for a custom domain one person actually sends invoices from, because the job is delivery and a normal client, not a provider that cannot read you. Proton wins when you have already proven delivery to the clients who pay you and you want the mailbox private. Test the invoice. Do not test the homepage.