How to Use a Subdomain for Email (mail.yourdomain vs yourdomain)

"Should my email be on mail.mycompany.com?" mixes up two different things: the name of the server that handles mail, and the domain that appears after the @ in your address. This guide separates them, explains when sending from a subdomain is a smart move for a small business, and gives the records each option needs.

Quick summary

• The server hostname. Your MX records (the settings that tell the internet where to deliver email for your domain) points at a hostname such as mail.oqumail.com. That name belongs to the mail host, not to you, and it has nothing to do with your address. With OquMail, your MX simply points at mail.oqumail.com with priority 10; you do not create a mail.yourdomain.com record at all.
• The address domain. You can receive and send as you@yourdomain.com or as you@notify.yourdomain.com. A subdomain here is a separate email domain with its own MX, SPF, DKIM and DMARC records.
• Automated mail. Receipts, alerts and password resets from notify.yourdomain.com or mail.yourdomain.com keep their reputation separate from the people writing from yourdomain.com. A bad day for the app cannot drag down your personal inbox placement.
• Marketing. Newsletters from news.yourdomain.com isolate complaint rates from your transactional and human mail.
• Regional or product divisions where different teams control sending and you do not want one team's mistakes to affect another.

Two meanings of "subdomain for email"

• The server hostname. Your MX records (the settings that tell the internet where to deliver email for your domain) points at a hostname such as mail.oqumail.com. That name belongs to the mail host, not to you, and it has nothing to do with your address. With OquMail, your MX simply points at mail.oqumail.com with priority 10; you do not create a mail.yourdomain.com record at all.
• The address domain. You can receive and send as you@yourdomain.com or as you@notify.yourdomain.com. A subdomain here is a separate email domain with its own MX, SPF, DKIM and DMARC records.

When sending from a subdomain is wise

• Automated mail. Receipts, alerts and password resets from notify.yourdomain.com or mail.yourdomain.com keep their reputation separate from the people writing from yourdomain.com. A bad day for the app cannot drag down your personal inbox placement.
• Marketing. Newsletters from news.yourdomain.com isolate complaint rates from your transactional and human mail.
• Regional or product divisions where different teams control sending and you do not want one team's mistakes to affect another.
• Testing. A staging subdomain lets developers send real mail without touching the production domain's reputation.

When to stay on the root domain

• Every address a human sends from. jane@yourdomain.com is trusted more and remembered better than jane@mail.yourdomain.com.
• Role addresses you publish: support@, sales@, hello@. Customers expect the plain domain.
• Very small volumes. If your app sends fifty receipts a day, the reputation isolation benefit is small and the extra DNS is not worth it.

Records for a sending subdomain

1. Add the subdomain to your email host as if it were a domain. On OquMail's free plan it counts as one of the 3 domains.
2. MX at notify: mail.oqumail.com, priority 10. Even a send-only subdomain should accept bounces and replies.
3. SPF TXT at notify: v=spf1 MX (Mail Exchanger — where incoming email is delivered) a:mail.oqumail.com ~all.
4. DKIM TXT at selector._domainkey.notify, with the value from your dashboard.
5. DMARC TXT at _dmarc.notify, or rely on the root domain's DMARC policy, which applies to subdomains by default unless you set an sp= tag. Set sp=reject on the root if you want subdomains you have not configured to be unusable by forgers.
6. Send a test through your app to a Gmail address and check authentication (proof that email really comes from your company)-Results shows SPF (Sender Policy Framework — a list of servers allowed to send email as your domain)=pass and DKIM (a digital signature that proves your email was not tampered with)=pass with header.d=notify.yourdomain.com.

A simple layout for a small business

Most small companies end up with two sending domains: the root for people and published role addresses, and one subdomain such as notify.yourdomain.com for everything a system sends. Marketing can share the notify subdomain at low volume and move to its own subdomain later if complaint rates ever become a concern. That is two sets of DNS records, both verified in the same dashboard, and no confusion for customers about which address is the real company.

Using the subdomain with an API

POST https://api.oqumail.com/api/v1/emails
Authorization: Bearer oqm_live_xxxxxxxxxxxxxxxx
Content-Type: application/json

{
  "from": "receipts@notify.yourdomain.com",
  "to": "customer@example.com",
  "subject": "Your receipt #4471",
  "html": "<p>Thanks for your order.</p>"
}

Pitfalls

• Creating an A record for mail.yourdomain.com that points at your website server. It is unnecessary and confuses anyone reading the DNS later.
• Forgetting the subdomain's own SPF. SPF does not inherit; a subdomain without a record is "none" and mail from it fails alignment.
• Sending replies-to addresses on the subdomain that nobody reads. Set Reply-To to a monitored address on the root domain.
• Using the subdomain for people. Once a customer saves jane@mail.yourdomain.com, it is permanent.

Common questions

Does a subdomain need its own mailbox?

Not for sending through an API, but create at least one mailbox or alias on it so bounces and stray replies land somewhere a person can see.

Will mail from a subdomain look less trustworthy?

Receivers evaluate the sending domain's authentication and reputation; a properly authenticated subdomain is fine. Human readers rarely notice the difference for automated mail, and they never see the server hostname at all.

Can I move from root to subdomain sending later?

Yes, and it is common. Set up the subdomain records, switch the app's From address, and keep the root address as Reply-To. The root domain's reputation is unaffected because it simply stops sending that class of mail.