How Inbound Email Works in Buzzmark: MX Records, Forwarding, and Webhooks

Most people think of an email platform as something that sends. But receiving is just as useful, and Buzzmark handles it for you. Once you point your domain at us, we accept mail on your behalf and route it wherever you need: to a normal inbox, to your application over a webhook, or to both at the same time.

Here is how it works.

The one setup step: point your MX record at Buzzmark#

Email routing is controlled by a DNS record called the MX record. MX stands for "mail exchange," and it tells the rest of the internet which server is responsible for receiving mail for your domain. When someone sends a message to an address at your domain, their mail server looks up your MX record to find out where to deliver it.

To receive mail with Buzzmark, you set your domain's MX record to point at our inbound servers. That single change is what puts us in the path of your incoming mail. From that moment on, messages addressed to your domain arrive at Buzzmark first, and we take care of what happens next.

Because this affects all mail for the domain or subdomain you configure, most people use a dedicated subdomain for inbound (for example, mail.yourapp.com or inbound.yourapp.com) so it stays separate from their primary mailboxes.

Where your mail can go#

Once we are receiving your mail, you decide where it should end up. There are three patterns, and you can pick whichever fits.

1. Forward to a preferred inbox#

The simplest option is to have Buzzmark forward incoming mail straight to an email address you already use. Someone writes to support@yourapp.com, and the message lands in whatever inbox you nominate, a shared team mailbox, a personal address, a helpdesk intake address, or anything else. This is a clean way to give your product a professional inbound address without running a mail server yourself.

2. Forward to a webhook#

The more powerful option is to have Buzzmark deliver each incoming message to your application over a webhook. Instead of a human reading the mail, your code receives it. We parse the raw message and hand your endpoint the useful pieces: the sender, the subject, the text and HTML bodies, attachments, and headers, all as structured data you can act on.

This is what powers reply-by-email, automated ticket creation, email-to-action workflows, and any feature where an incoming message should trigger something in your software rather than just sit in an inbox. Your code never has to touch the raw email format.

3. A combination of both#

You do not have to choose. Buzzmark can forward a message to a human inbox and deliver it to your webhook at the same time. That combination is genuinely useful: your support team sees the email in their normal mailbox while your application simultaneously logs it, creates a ticket, or updates a record. One incoming message, two destinations, no extra work.

Inbound addresses live on your hives#

Every hive in Buzzmark comes with its own inbound address and its own inbound webhook setting. Because inbound is configured per hive, you can run separate receiving streams for separate purposes. One hive might forward support mail to your team's shared inbox, while another delivers reply-by-email traffic straight to your application. Keeping these streams distinct makes routing predictable and keeps your message history easy to follow.

A few practical notes#

Incoming email is messy in ways you do not control. People send large attachments, quote entire threads back to you, and use every mail client imaginable. If you are sending inbound mail to a webhook, plan for that: decide how you will strip quoted history from replies, set sensible limits on attachment sizes, and treat every incoming message as untrusted input that you validate before acting on it.

If you are forwarding to an inbox instead, the main thing to get right is the MX record and the subdomain you use, so inbound mail stays cleanly separated from the rest of your setup.

Getting started#

Setting up inbound comes down to two decisions. First, point your MX record at Buzzmark for the domain or subdomain you want to receive on. Second, choose a destination on the relevant hive: an inbox to forward to, a webhook to deliver to, or both. From there, mail sent to your domain flows exactly where you want it, whether that is a person, your product, or both at once.