Use Smailor with Proton Mail

Run a shared, customer-facing address in Smailor while your team keeps using
Proton Mail for everything else.

This guide replaces an earlier version that described forwarding
[email protected] from Proton into Smailor while Proton kept the domain's MX
records. That flow is not supported. The section
Why forwarding into Smailor does not work
explains what happens if you try it, so you can recognise the symptoms if you
already set it up.

What is supported is a split by hostname: Smailor receives mail for one name it
owns end to end, Proton keeps the rest.

Choose which name Smailor receives

Smailor needs to be the MX for the exact domain or subdomain the shared address
lives on. Pick one:

Option Address customers see Proton keeps
Subdomain [email protected] all of example.com, unchanged
Second domain [email protected] all of example.com, unchanged
Whole domain [email protected] nothing on this domain

The subdomain is the usual choice. It changes the address customers write to,
which is the trade-off: nothing else about Proton moves, and no DNS record that
Proton relies on is touched.

Choose the whole domain only if you intend to leave Proton for this domain. It
moves every mailbox on it, including personal ones.

Understand the mail flow

With a subdomain:

Customer writes to [email protected]
          |
          v
MX for help.example.com -> Smailor
          |
          v
Smailor shared inbox (ticket)
          |
          v
Team replies -> customer sees [email protected]

Mail to [email protected] never enters this path. Proton receives it exactly as
before, because example.com's own MX records are unchanged.

Before you start

You need:

  • a Smailor account with access to Settings → Domains and Addresses;
  • the ability to create DNS records for the name you chose (TXT, MX, and two more
    TXT records for SPF and DKIM);
  • your Proton plan only if you are keeping Proton — this guide adds nothing to it.

You do not need a Proton plan that supports forwarding. No forwarding rule is
involved.

Step 1: Add the name in Smailor

  1. Sign in to Smailor.
  2. Open Settings → Domains and select Add domain.
  3. Enter the exact name you chose — help.example.com, not example.com, if you
    picked the subdomain option.
  4. Smailor shows four records: an ownership TXT, an MX, an SPF TXT, and a DKIM
    TXT.

Step 2: Publish the DNS records

Create all four records on the name you added.

  1. TXT (ownership) — the value Smailor displays, on the name itself.
  2. MX — pointing at the relay host Smailor displays.
  3. TXT (SPF) — v=spf1 include:<relay host> ~all.
  4. TXT (DKIM) — at smailor._domainkey.<your name>, the value Smailor
    displays. See Publish your DKIM record.

If you picked the subdomain option, none of these replace a record Proton uses.
example.com's MX, SPF, and DKIM records stay as they are, and a subdomain's SPF
record is independent of the parent's.

Step 3: Verify

  1. Return to Settings → Domains → your name.
  2. Select Verify DNS.
  3. The domain becomes usable once the ownership TXT and the MX record
    resolve. SPF and DKIM do not block activation, but publish them before you
    send anything real: without them your mail is unauthenticated and will be
    filtered.

A DKIM row that reads verified means the public key is published and matches the
key Smailor holds. It is a statement about DNS, not a report on the last message
you sent.

Step 4: Create the address

  1. Open Settings → Addresses and select Add address.
  2. Enter support and choose the name you verified.
  3. Assign it to the group that should handle the conversations.
  4. Open the address's own settings — the gear icon on its row — to set the
    sender name recipients see on replies.

Step 5: Publish DMARC

Add a _dmarc TXT record for the name, starting at monitoring:

v=DMARC1; p=none; rua=mailto:[email protected]

Tighten the policy only after you have confirmed that SPF and DKIM pass on real
mail. See Email authentication.

Step 6: Test the loop

From an external mailbox — Gmail, Outlook, anything you control:

  1. Send a message to the new address.
  2. Confirm it appears in Smailor as one ticket, once.
  3. Reply from Smailor.
  4. In the received reply, open the original headers and confirm:
    • spf=pass;
    • dkim=pass with header.d= equal to your sending domain;
    • dmarc=pass.
  5. Reply again from the external mailbox and confirm Smailor adds it to the same
    ticket instead of opening a new one.

Step 4 is the one worth doing carefully. A missing dkim= line means the message
carried no signature at all, which is not the same as a signature that failed —
report it rather than adjusting your DNS.

Why forwarding into Smailor does not work

The natural-looking alternative is to leave Proton (or Cloudflare Email Routing,
or Google) as the MX for example.com and forward only [email protected]
into Smailor. Two things stop it, and the second one has no workaround:

  1. There is no inbound forwarding destination to forward to. Smailor does not
    issue a per-account catch-all address for foreign forwarders. An earlier
    version of this guide told you to copy one from the dashboard; no such value
    exists, which is why you could not find it.

  2. A domain whose MX is elsewhere cannot send through Smailor. Verification
    requires the ownership TXT record and an MX record pointing at Smailor's
    relay. Until a domain is verified, Smailor refuses to send with a From
    address on it. So even if the mail reached a ticket, the reply could not go out
    as [email protected] — which is the whole point of handling it in a shared
    inbox.

Forwarding into an address on a Smailor-hosted domain does create tickets, but
replies then leave as that Smailor address, not as your own. If that is
acceptable, it works; if it is not, use a subdomain as described above.

If keeping your existing MX while replying as your own address is what you need,
tell support. It is a known gap, not a plan limitation — no Smailor plan enables
it today.

What stays in Proton and what moves through Smailor

Assuming the subdomain option:

Activity Service responsible
Receiving mail for example.com Proton Mail
Receiving mail for help.example.com Smailor
Shared ticket assignment and routing Smailor
Replying from a Smailor ticket Smailor sending infrastructure
Personal and internal team addresses Proton Mail
Proton Calendar, Drive, and VPN Proton; unaffected

Troubleshooting

Verification will not complete

Check that you created the records on the full name you added. A DNS provider
that appends the zone automatically turns help.example.com into
help.example.com.example.com when you paste the whole name into the host field.
Query the record yourself before re-verifying:

dig +short MX help.example.com
dig +short TXT smailor._domainkey.help.example.com

Mail arrives but replies fail

  • Confirm the address is active in Settings → Addresses.
  • Confirm the domain still reads verified — a removed MX record un-verifies it.
  • Check delivery statistics and the send error
    shown on the ticket.

Replies from Smailor land in spam

Publish SPF and DKIM if you have not, then check a received message's
authentication results. A reply with no dkim= line is a fault to report, not a
DNS problem on your side.

The same message appears twice

Look for a forwarding rule that also routes the address into Smailor. Keep one
deliberate inbound path per message.

Replies create new tickets

Confirm that nothing between the sender and Smailor rewrites the Subject,
Message-ID, References, or In-Reply-To headers.

Go-live checklist

  • The name Smailor receives is decided and nobody expects Proton to receive it.
  • Ownership TXT and MX published on that name; the domain reads verified.
  • SPF and DKIM published on that name; both rows read verified.
  • DMARC published at p=none for that name.
  • The address is active and its sender name is set.
  • A test message produced one ticket, and the reply passed SPF, DKIM, and DMARC.
  • example.com's own MX, SPF, and DKIM records are untouched.
Back to docs

Found an issue on this page?