What is a sending domain?

A sending domain is the domain your email is sent from and authenticated against. It is the part after the @ that mailbox providers check when they decide whether to trust your mail. If you send a receipt from receipts@yourcompany.com, then yourcompany.com is the sending domain that has to prove it authorised the message.

Getting this right is the single biggest factor in whether your transactional email reaches the inbox. Here is what a sending domain actually is, and what "verified" means.

Two domains, not one

Every email carries two sender addresses, and they are often different.

• The visible From domain is what your recipient sees in their mail client, for example receipts@yourcompany.com.
• The envelope sender, also called the return-path or bounce address, is the hidden address the mail servers themselves use to route the message and send bounces back. It is set during the SMTP conversation and is usually on a domain controlled by your sending provider.

When people say "sending domain" they usually mean the domain they want recipients to see and trust, the From domain. The return-path matters too, because SPF validates the return-path rather than the From address, and the two need to line up for authentication to hold together.

Why providers require a verified sending domain

Anyone can type any address into a From field. Nothing in the email format stops a spammer from writing support@yourbank.com. Mailbox providers like Gmail, Outlook and Apple Mail therefore ignore the claim and check the DNS of the sending domain instead. They want cryptographic proof that the domain owner authorised the message.

A verified, authenticated sending domain gives them that proof. Without it your mail is unsigned, cannot be tied back to a domain you control, and gets treated with suspicion: throttled, filed under spam, or rejected. Since 2024, Gmail and Yahoo require authentication for bulk senders outright, and the direction of travel is towards requiring it from everyone.

The DNS records involved

Verifying a sending domain means publishing a small set of DNS records that let receivers authenticate your mail. At a high level:

• SPF is a TXT record listing which servers may send for your domain. It is checked against the return-path.
• DKIM publishes a public key in your DNS so receivers can verify a cryptographic signature on each message. This is what proves the message came from your domain and was not tampered with.
• The return-path, often set up as a CNAME pointing to your provider, puts the bounce address on a subdomain of your own domain so that SPF aligns with your visible From domain.

A DMARC record ties these together and tells receivers what to do when authentication fails. For the full detail on each record and how they interact, see SPF, DKIM and DMARC explained.

A subdomain or the root domain?

You can send from your root domain, for example yourcompany.com, or from a subdomain such as mail.yourcompany.com or send.yourcompany.com. For transactional and bulk sending, a subdomain is usually the better choice.

• It keeps your sending reputation separate from your root domain, so a bad patch of email volume does not drag down the domain you use for your own staff correspondence.
• It lets you keep different streams apart, for example mail.yourcompany.com for transactional messages and news.yourcompany.com for broadcasts, each building its own reputation.
• It keeps the DNS for sending self-contained, which is tidier to manage.

Your recipients still see your brand, because the subdomain carries your root domain in it. The one case for sending from the root is a very small sender who wants a single address and no extra DNS, but most senders are better served by a subdomain.

What "verified" actually means

A sending domain is verified when the required DNS records are in place and the provider has checked that they resolve correctly. In practice that means your DKIM public key is published and readable, your SPF record authorises the right servers, and your return-path resolves to the provider. Once those checks pass, your provider can sign outgoing mail with DKIM and receivers can authenticate it.

Verification is a one-time setup per domain, though the records need to stay in place. Remove or edit one by mistake and authentication quietly breaks, which is why it is worth letting your provider generate and monitor them.

How Mailhuset handles it

With Mailhuset you add your domain and we generate the exact records you need: the DKIM key, the SPF entry and the return-path, ready to paste into your DNS. We then verify that they resolve and keep an eye on them afterwards, so you are not debugging a stray character months later. Mailhuset sends from the EU by default, and the same verified domain works across transactional email, inbound and broadcasts.

See how we handle deliverability to set up and verify your sending domain.