The short answer: give your app a receiving subdomain
If your team already receives mail at you@example.com, use a dedicated address such as support@replies.example.com for your application. Configure receiving for replies.example.com and preserve the existing mail configuration for example.com.
This guide is for developers adding inbound email to an existing product, rather than migrating their company’s mail service. The goal is a separate route that you can test before customers depend on it.
Receiving email in an application is an established workflow. For background, MailerSend’s August 2021 inbound-email announcement describes parsing messages and routing them to an application. Here we focus on the DNS setup that lets an application receive mail alongside an existing team mailbox.
What an MX record actually does
An MX record tells sending mail servers where to deliver email for a domain. Its value is a mail-server hostname, and its priority helps choose between servers: lower numbers are preferred. See Cloudflare’s explanation of MX records.
The address after the @ matters. Mail to support@example.com and mail to support@replies.example.com have different recipient domains. Configure the one you intend to use.
MX records are not a rule that sends one username to one provider and another username to a second provider. Adding a second provider at the same domain does not create that split. For our example, keep the existing root-domain route and give the application its own subdomain.
DNS routing also does not create an inbox by itself. Your receiving service must have a destination for the address.
1. Write down what must keep working
Before editing anything, record the current authoritative nameservers and export or screenshot the existing MX records. Note which provider currently handles your team’s email. DNS settings live with the authoritative DNS provider, which may be different from the company that sold you the domain.
Prepare this small routing plan:
| Address | Purpose | Action |
|---|---|---|
| you@example.com | Existing team mailbox | Keep the current route |
| support@replies.example.com | Application conversations | Configure a receiving subdomain |
In the remaining steps, example.com is an illustration. Replace it with your domain. Do not edit your production root-domain MX records to reproduce this example.
2. Verify the exact domain in your workspace
In InboxIt, open Domains in the workspace that will own the receiving inbox and add replies.example.com. Publish the ownership and DKIM records returned for that domain, then run verification.
Use the actual values from the platform. A DKIM selector and verification token belong to your domain setup; copying another account’s values will not verify yours. Keep the provider instructions beside the DNS editor and check the final saved hostname for each record.
Sending verification and incoming routing are separate checks. A domain that is verified for sending can still lack an MX route for incoming mail. Follow the domain and DNS documentation for the current requirements.
3. Add the receiving MX record at the subdomain
For the current InboxIt receiving setup, the dedicated subdomain needs an MX record pointing to mail.inboxit.wtf, with priority 10. Check the live setup instructions before making changes.
| Type | Full DNS name | Value | Priority |
|---|---|---|---|
| MX | replies.example.com | mail.inboxit.wtf | 10 |
When editing the example.com zone in an editor that automatically appends the domain, the Host field is usually replies. If you are editing a separately delegated replies.example.com zone, its root may instead be represented by @. Use your DNS provider’s convention.
Namecheap’s host-record instructions specifically explain entering only the subdomain in its Host field. Pasting the full hostname into an editor that appends the zone can create a duplicated domain.
InboxIt currently requires the receiving domain’s MX targets to point exclusively to mail.inboxit.wtf. Use the dedicated subdomain for that route, not a domain whose existing mailbox provider must remain in use.
4. Connect the address, then test both routes
Create a permanent inbox in the same InboxIt workspace and configure the receiving address as support@replies.example.com. Wait for the address to become active. A saved DNS record or a copied value is not evidence that the mailbox is ready.
- Send a uniquely titled message from a mailbox you control to the new receiving address.
- Confirm that the message appears in the correct InboxIt inbox, including its body.
- If replies are part of your product, send a controlled outgoing message with the active receiving address as its reply-to destination, then reply to it.
- Check message IDs and conversation association in your application. See the threading guide.
- Send a separate message to your existing team address and confirm that the original mail service still receives it.
For API-based workflows, also check incoming-message retrieval and your signed email.received webhook. Deduplicate repeated events and enforce your own workspace access rules.
When receiving still does not work
Check the exact saved record before assuming that DNS needs more time. From PowerShell, inspect the public route:
Resolve-DnsName -Name replies.example.com -Type MX
Resolve-DnsName -Name example.com -Type MXCompare those answers with the routing plan. Resolver caches can differ, so check authoritative DNS if the results disagree.
| Symptom | Next check |
|---|---|
| New address is not active | Domain verification, exact MX targets and address provisioning |
| Expected DNS record is missing | Authoritative provider and final saved hostname |
| Old team mailbox stopped receiving | Whether the root MX records were changed |
| DNS resolves, but no message appears | Exact recipient address, delivery failure and receiving-service status |
Cloudflare’s email troubleshooting guide also covers missing mail records and DNS proxy issues. If you host your own mail server, ordinary HTTP proxy settings are not a substitute for SMTP connectivity.
MX versus SPF, DKIM and DMARC
MX answers where incoming mail goes. SPF authorizes sending sources, DKIM lets receivers verify message signatures, and DMARC uses authentication and domain alignment to inform handling and reporting. These records solve different problems; a successful DKIM check does not prove that incoming mail is routed to your inbox. Cloudflare explains these authentication mechanisms.
Use the authentication records generated by your sending provider. Do not replace an existing SPF policy with a guessed value while configuring receiving.
Common questions
Can I keep Google Workspace or Microsoft 365?
Yes, for this subdomain-based setup you keep the existing root-domain mail route. This does not make support@example.com arrive in InboxIt: the configured application address is support@replies.example.com.
Can two providers receive different usernames at the same domain?
MX alone does not express per-user routing. That requires a supported routing or forwarding arrangement between the providers. Use a dedicated receiving subdomain when you want a separate application route.
Does adding MX create a private business inbox?
No. DNS selects the receiving service. You still need an active inbox, an assigned receiving address and appropriate access permissions.
Can I try email testing without changing DNS?
Yes. The InboxIt email-testing tool supplies a temporary address. Use it to test message arrival before configuring your own domain.
Sources and next steps
Sources checked on 28 October 2026:
- MailerSend: inbound-email feature announcement — the research signal behind this topic.
- Cloudflare: MX records — routing and priorities.
- Namecheap: host records — DNS-editor host fields.
- Cloudflare: troubleshooting email issues — DNS and mail checks.
- Cloudflare: SPF, DKIM and DMARC — sending authentication.
Ready to connect the application side? Start with receiving email in InboxIt or follow the Node.js receiving tutorial.
