Your email provider’s setup page asks one question, “Which domain do you want to send from?”, and one wrong answer can break SPF for the mailbox your whole team uses, or send password resets to spam. You cannot tell whether example.com or send.example.com is the safe choice for your app’s transactional email.

Use a subdomain such as send.example.com and put the From address on it too. It can pass DMARC (the check receivers use to decide whether mail really comes from your domain), leaves your company mailbox records alone, and you can remove it by deleting the records you added.

Root domain vs subdomain: what actually changes?

Your root domain is example.com, the one on your website and your company mailboxes. A subdomain is a name in front of it, like send.example.com or mail.example.com. You create one for free by adding DNS records under it. Nothing is bought and nothing existing is replaced.

Two things follow from the choice:

  • What customers see. The From address is hello@example.com or hello@send.example.com. The longer one looks unusual to some customers. Keeping the root address in From also works, with a catch explained below.
  • Where the records go. Your provider hands you a few DNS records (DKIM is a signature that proves the email came from your provider; SPF is a list of servers allowed to send for you). They are published under whichever domain you chose. Pick the subdomain and the records sit under send.example.com.

Your company mailbox at the root domain already has an SPF record. Adding a second SPF record at the root can break mail that works today. A domain may only have one SPF record.

Does a subdomain pass DMARC alignment?

DMARC passes only when the domain that proved itself (through DKIM or SPF) matches the domain in the From address. That match is called alignment, and by default it is forgiving: under relaxed alignment, send.example.com and example.com count as a match because they share the same main domain. Our alignment explainer walks through it.

So a subdomain can pass, as long as the provider’s DKIM or SPF check also passes. The catch: if your DMARC record contains adkim=s or aspf=s (you would have added it on purpose), the From address on the subdomain must match exactly. That is another reason to put the From address on the subdomain.

Why use a subdomain for app email?

A name of its own. Some receivers weigh a sending domain’s history, and a subdomain gives app mail its own name and so its own sender reputation. This is common practice, not a rule of the standard.

DMARC already covers it. When a subdomain has no DMARC record of its own, receivers use the one found by looking at the parent domain, normally the one on example.com. So send.example.com is protected by your existing record the moment you create it. Subdomain-specific settings are covered in our subdomain policy guide.

The cost is one more set of records to keep for each sending tool.

Which should you pick? A subdomain, in 5 steps

  1. In the provider’s setup, choose to send from a subdomain and enter send.example.com.
  2. Log in to the company where you manage your domain’s DNS (often your domain registrar). Add each record the provider lists, with the name it gives you. Do not edit or delete any existing record on example.com.
  3. Back at the provider, click verify. DNS can take a while to show up. If it stays on pending, see DKIM still pending? Check it with dig.
  4. Send a test email to yourself and look for dkim=pass and dmarc=pass in the original message (in Gmail, the three-dot menu, then Show original). The pre-launch DKIM check shows where.
  5. Set Reply-To to a real mailbox, then switch your app’s From address to the new subdomain. Without it, a reply to an address on the subdomain would go nowhere.

What is safe to undo: every record you added lives under send.example.com. Delete them and you are back where you started. Your website, company mailbox and existing records are untouched.

Next month you will add a newsletter app or a support desk, and each one sends as your domain. DMARC Guardian reads the summary reports receivers send about your domain, and on trial and paid plans its Senders tab lists every sending source with an alignment status, and by default shows only the senders that need attention.

See which services are sending as example.com, including ones you forgot