A magic link is a one-time, signed URL emailed to a customer that signs them straight into their support ticket or portal with no password. It removes the account-creation step that blocks people the moment they most need help, and when the token is short-lived, single-use, and scoped to one customer's tickets, it is no weaker than the password-reset flow every login already depends on. Below is how it works, where the security boundaries actually sit, and what to build into the link.
Why passwordless wins for support
Forcing a customer to create an account just to check a ticket adds friction at the worst moment. Someone is already annoyed enough to contact support; making them invent a password, verify an email, and remember credentials they will use twice a year guarantees drop-off. A magic link signs them straight into their ticket instead.
- No abandoned tickets. The customer clicks one link and is in. There is no signup wall between them and the answer they came for.
- Fewer "I can't log in" tickets. Password portals generate their own support load — reset requests, locked accounts, wrong-email confusion. Passwordless removes that whole category.
- No credentials to leak. You are not storing passwords for people who barely use the portal, so there is nothing to breach or rotate.
- It matches how email support already works. The customer found you by email; authenticating by email is the same trust model they already accepted.
This is also why a passwordless portal pairs naturally with a shared inbox — the ticket exists whether or not the customer ever opens the portal, and the link just gives them a richer view of the same conversation.
How the link works
The link carries a signed, expiring token. Clicking it authenticates the customer for their ticket or portal only. Mechanically the flow is short:
- The customer emails support, or an agent replies, and the system generates a token tied to that contact and ticket.
- The token is signed (so it cannot be forged) and given an expiry timestamp.
- It is embedded in a URL in the email — for example a "View this ticket" button under the reply.
- Clicking it sends the token back; the server verifies the signature and expiry, then issues a normal session cookie scoped to that customer.
- The customer lands directly on their ticket. No login screen appears.
The token itself is the secret. It is not a username-and-password pair, so there is nothing for the customer to remember and nothing for you to store in a reversible form.
Is it secure? The honest answer
Magic links are as secure as your weakest link in the email chain — which is the same boundary password resets live behind. Four properties carry the security, and you need all four:
| Property | Why it matters |
|---|---|
| Signed token | Prevents forgery; a tampered or guessed token fails verification. |
| Single-use | A link captured from a forwarded email is worthless after first use. |
| Short-lived expiry | Limits the window in which a leaked email is dangerous. |
| Scoped to one contact | A valid link only ever exposes that customer's own tickets, never the queue. |
The honest caveat: anyone who can read the customer's inbox can use the link. That is true of every password-reset email ever sent, so it is rarely a reason to avoid magic links — but it is why you scope tokens tightly and keep expiries short. For higher-assurance accounts, layer the magic link with single sign-on or an existing product session so the portal recognizes already-authenticated users without a second hop. See how we think about this on the security page.
What a magic link should carry
Keep the token opaque and put the meaning on the server side. A good token references, but does not expose, the following:
- The contact it authenticates, so access is scoped to that person's tickets only.
- An expiry short enough to limit risk (minutes to a small number of hours, not weeks).
- A single-use flag so the token is burned on first successful exchange.
- An optional return path so the customer lands on the exact ticket, not a generic dashboard.
Resist the temptation to encode customer data or permissions into the link itself. The URL ends up in browser history, server logs, and sometimes email-scanner previews; treat it as a bearer credential, not a data envelope.
Into a branded portal
The link should land in a white-label help center on your own domain, so the whole experience feels native rather than like a detour through a vendor's UI. A good portal lets the customer read the full thread, reply inline, see status, and browse the help center articles next to their open tickets. Self-service there also drives deflection — people who can find the answer and check status themselves open fewer follow-up tickets. For the deliverability side of getting that link into the inbox in the first place, the email has to be signed as your own domain; that is what BYODKIM handles. You can see the portal in context on the customer portal section.
Edge cases worth handling
A few situations come up often enough to design for up front:
- Expired links. Show a friendly "request a new link" button rather than a dead end; email a fresh token to the same address on file.
- Forwarded emails. Single-use plus short expiry means a forwarded link usually fails by the time anyone else clicks it.
- Shared mailboxes. For team or company accounts, scope by contact and optionally by account membership so colleagues see shared tickets while still authenticating individually.
- Multiple open tickets. Let the portal show all of a contact's tickets once they are in, not just the one the link pointed at.
Handle these and the passwordless flow stops being a clever trick and becomes the default people barely notice — which is the goal. For the broader access model behind who sees what, see role-based access for support teams and the RBAC definition.
Frequently asked questions
Are magic links secure enough for a support portal?
Yes, when implemented correctly. The token is signed so it cannot be forged, single-use so a captured link is worthless after first use, short-lived so a stolen email loses value quickly, and scoped to one customer's tickets only. The real risk is the same as password reset emails: anyone with access to the inbox can use the link. For most consumer and B2B support that is an acceptable trade-off, and it is no weaker than the password-reset flow every account already relies on.
What happens when a magic link expires?
The customer sees a short message and a button to request a fresh link, which is emailed to the same address on file. Nothing is lost. Because the address must match a contact on the ticket, an expired link cannot be used to fish for access to someone else's conversation.
Can customers still get a password login if they want one?
Magic links and passwords are not mutually exclusive. You can offer a passwordless default and let customers who prefer a saved password set one, or support single sign-on for logged-in product users so the portal recognizes them without any extra step. The point is to remove the forced account creation that blocks first contact, not to ban passwords entirely.
Does a magic-link portal work for B2B accounts with multiple users?
Yes. Scope the link to the contact and, where you model company-level accounts, let an account see tickets opened by its members based on shared domain or an explicit account membership. Each person still authenticates with their own emailed link, so you keep an audit trail of who viewed what without making everyone share a password.
Cherryrise portals use magic links. See the customer portal.