Skip to main content
Lettr has no routing rules to configure. Mail sent to any address at an inbound domain is posted to that domain’s one forwarding URL, and your handler decides what to do with each message. This page shows common routing patterns you can build in that handler.

What Lettr Routes for You

The only routing Lettr does is per domain: each inbound domain has its own forwarding URL. If you want different kinds of mail to reach different services, you can set up separate inbound domains with separate forwarding URLs: Everything below that level, such as support@ versus billing@ on the same domain, is handled in your code.

Fields Used for Routing

Your forwarding URL receives a JSON array of events. Each event has a msys.relay_message object (see Email Parsing for the full payload). These are the fields you usually route on: The examples on this page share these helpers:
The raw MIME message in content.email_rfc822 makes payloads with attachments large. Raise your body parser’s size limit (Express defaults to 100kb), as the examples below do.

Routing by Recipient

The most common pattern is to route on the address that received the message:

Variable Address Routing

Because every address at the domain is forwarded, you can encode data in the address itself (plus addressing) and parse it in your handler:

Common Variable Address Patterns

Anyone can write to any address at your inbound domain, so treat the encoded value as untrusted input. Look it up in your database rather than trusting it, or sign it so you can detect tampering.

Routing by Subject

Route on keywords or patterns in the subject line:

Routing by Sender Domain

Route on the sender’s domain, for example to send mail from known customers to their account manager:
msg_from is the envelope sender and can differ from the address in the From header (friendly_from), for example when mail comes through a mailing list or a bulk sender. Neither proves who sent the message. See Security before you grant anything based on the sender.

Content-Based Routing

Route on what the message says:

Multi-Criteria Routing

Combine criteria into an ordered rule list in your code, and run the first rule that matches:

Routing with Priority Queues

For high volumes, push messages onto queues by priority and respond right away:

Unknown Addresses

Every address at your inbound domain is forwarded, including ones you never planned for. Decide in your handler what happens to addresses you don’t recognize:
Lettr does not filter spam on inbound mail, and unknown addresses tend to attract it. Add your own checks before acting on these messages. See Spam Filtering.

Forwarding Emails

To pass a received message on to another mailbox, send it with the Lettr send API. Attachments are only in the raw MIME message (content.email_rfc822), so parse that first and re-attach the files as base64:
Forwarded HTML comes from an external sender. Sanitize it before you show it anywhere other than the recipient’s mail client.

Error Handling

Store the payload before you route it, and answer with a 2xx once it is saved. Handle routing failures from your own store instead of counting on the message being delivered to you again:
The same message can occasionally arrive more than once. Make your routing idempotent, for example by skipping messages whose Message-ID header you have already handled. See Best Practices.

Email Parsing

The full inbound payload

Reply Tracking

Match replies to the emails you sent

Spam Filtering

Handle spam in your own code

Best Practices

Inbound best practices