In this article
For everyday business correspondence, choose a mailbox; for delivering incoming messages to an existing inbox, choose forwarding; for processing email in an application, choose an email API. These models can share a domain, but they solve different problems.
This is a documentation-based decision guide. We have not tested every provider or compared current subscription prices.
Start with the reply you want to send#
Suppose a customer writes to hello@example.com. What should happen next?
- A person reads and replies from that address: evaluate a business mailbox.
- The message reaches an existing personal inbox: evaluate forwarding and a separate supported sending setup.
- Software creates a ticket or processes an attachment: evaluate application email receiving.
The address alone does not tell you which system is behind it. Write down your receiving and replying requirements before changing DNS.
A mailbox is the human correspondence option#
Check support for composing, replying, search, attachments, calendars, mobile access and multiple users as needed. Determine whether support@ should be an alias, an individual inbox or a shared team workflow.
Also check storage, recovery, account administration and what happens when an employee leaves. A cheap service can be unsuitable if its access model does not fit the team.
Compare current plans in your region. Avoid selecting on a “free email” headline without checking which functions the free offer includes.
Forwarding delivers mail somewhere else#
Forwarding can make a domain address convenient without adding another inbox. However, receiving a forwarded message does not automatically configure your existing inbox to send authenticated mail from the custom address.
Cloudflare's Email Service documentation distinguishes routing and sending capabilities. Check the actual service you configure rather than treating every Cloudflare email feature as a conventional mailbox.
Test the reply path explicitly: does the recipient see the intended business address or your personal address? Is delivery authenticated according to your sender's documented setup?
An email API fits application workflows#
Resend supports custom-domain receiving and displays messages in its Receiving dashboard. Applications can also consume email through its supported integrations.
That can suit automated intake, but a dashboard showing received messages is not proof that it provides all the team-mailbox features you need. Evaluate composing and reply workflows separately.
For example, a product that extracts invoice attachments needs a different workflow from a founder answering ten customer messages a day.
Give incoming mail one intentional route#
MX records determine where incoming email is delivered for a domain or subdomain. Resend's MX conflict guide explains that adding competing receiving records can redirect mail or produce unpredictable delivery; equal priorities do not make both services receive a copy.
Before replacing a record, identify the existing mail service. Sending-related records under a return-path subdomain serve a different role from the root domain's receiving route.
For application email alongside an established mailbox, a dedicated subdomain may provide a clearer separation. Use the exact records supplied by each provider.
Run a complete delivery test#
- Send from an external account to the new address.
- Confirm receipt in the intended location.
- Reply and inspect the visible sender address.
- Test an attachment and a second external provider.
- Check account access and recovery.
Document the result instead of declaring success when a DNS record becomes verified. Verification and a working correspondence workflow are different checkpoints.
Protect the accounts administering your email domain with suitable authentication; see passkeys and recovery. For measuring the website attached to the domain, read Cloudflare Web Analytics versus GA4.