Are hyphens or dashes allowed in email From names and subdomains?
Updated on 25 Oct 2026: We clarified hyphen placement, Unicode dash support and authentication checks for email addresses and subdomains.
Yes, hyphens are allowed in email From names, local parts, and subdomains. The ASCII hyphen-minus - works in each of those places when placed correctly. An en dash or em dash can appear in a From display name with proper header encoding, but it is a different character from the ASCII hyphen used in ordinary email addresses and domain labels. A name like Brand - Updates and a subdomain like email-news.example.com can work.
The bigger question is whether the hyphen helps recipients and your own operations. Treat hyphens as acceptable syntax, not as a deliverability shortcut. They do not damage deliverability by themselves, but poor naming choices can look less trustworthy, cause typing errors, or make a sending domain resemble a lookalike domain.
- The ASCII hyphen is valid in From names, local parts, and subdomain labels when used correctly.
- A domain or subdomain label used in an email address cannot start or end with a hyphen. This restriction does not apply to the local part before @.
- A mailbox provider can restrict hyphens when creating a local part even though standard syntax permits them.
- Use a subdomain under the brand domain instead of a cousin domain created only for sending.
- Validate SPF, DKIM and DMARC after adding the subdomain, then send a real message through Suped's email tester.
Where hyphens are allowed in email
Email has several names in play, and hyphen rules depend on which part you mean. The visible From name is a display label in the message header. The From address has a local part before the at sign and a domain part after it. The subdomain belongs to DNS, not to the display name.
A hyphen in Brand - Billing has different rules from a hyphen in billing-alerts.example.com. Both are allowed, but display names and domain labels use different syntax.
|
|
|
|
|---|---|---|---|
From name | Yes | Brand - News | Recognition |
Local part | Yes | news-team | Provider rules |
Subdomain | Yes | email-news.example.com | Placement |
Cousin domain | Yes | example-mail.com | Brand confusion |
Where hyphens are allowed and what to watch.
A hyphen does not need quoting in a simple From display name or an ordinary local part. Keep the resulting name recognizable and configure authentication for the domain used in the From address.
From names can use hyphens
The display name in the From header is meant for human recognition. A hyphen or dash is normal in sender names when it separates a brand, department, region, or product line. Examples include Acme - Receipts, Acme - Product updates, and Acme Support - AU. Keep campaign claims, deadlines, and recipient names out of the display name. It should identify the sender.
A plain hyphen is the most predictable choice because it is an ASCII character. En dashes and em dashes can also appear through MIME encoded-words or internationalized headers, but they create more room for rendering differences across mail clients and are easier to mistype when a team edits templates by hand. For operational email, use a simple hyphen with spaces around it.
Works well
- The brand appears first, then the team or message type follows.
- Recipients see the same From name across a message stream.
- Spaces around the hyphen make the display name easier to scan.
Avoid
- The department name appears first and the brand is missing.
- A new From name for every campaign can reduce recognition.
- Multiple separators make the sender name look messy.
Email From header showing the display name, local part, subdomain, and parent domain.
The display name is not used for DMARC alignment. DMARC compares the visible From address domain with the authenticated SPF or DKIM domain. Still, a display name can affect trust because users read it first. For more detail on that side of the decision, see the page on whether the sender name matters.
Hyphens in the local part before @
A hyphen in a local part, such as customer-care@example.com, is valid in standard email address syntax. It can also appear at the start or end of an unquoted local part, and consecutive ASCII hyphens are allowed. These rules differ from domain-label rules. See RFC 5322 for the local-part grammar.
Valid local-part syntax, subject to mailbox provider rulestext
customer-care@example.com -customer@example.com customer-@example.com customer--care@example.com
A period cannot start or end an unquoted local part, and consecutive periods are invalid there. An underscore is permitted in a local part, but not in a hostname label used after @. RFC 5321 defines the SMTP address rules.
Syntax does not prove that a mailbox exists. Check the provider's account-naming rules, create the mailbox or alias, and test sending and receiving. For a hyphenated surname, keep a consistent address format and add an explicitly configured alias if another spelling is needed. Do not silently remove hyphens: sam-lee@example.com and samlee@example.com are different addresses unless the receiving system maps them together.
Hyphens and dashes are different characters
People often call every horizontal mark a dash, but email syntax does not treat them as interchangeable. The keyboard hyphen is U+002D HYPHEN-MINUS and belongs to ASCII. An en dash, em dash, or mathematical minus sign (U+2212) is a different Unicode character. Use the keyboard hyphen in ordinary ASCII addresses and domain labels.
|
|
|
|
|---|---|---|---|
Hyphen-minus (-), U+002D | Yes | Yes, subject to provider rules | Yes, inside a label |
En dash, U+2013 | Yes, with valid encoding | Only with SMTPUTF8 and provider support | No, not valid under IDNA2008 |
Em dash, U+2014 | Yes, with valid encoding | Only with SMTPUTF8 and provider support | No, not valid under IDNA2008 |
Minus sign, U+2212 | Yes, with valid encoding | Only with SMTPUTF8 and provider support | No, not valid under IDNA2008 |
Hyphen-minus, typographic dashes, and the mathematical minus sign are different characters.
Internationalized email addresses are an exception to ASCII-only local parts. RFC 6531 permits non-ASCII local-part characters through SMTPUTF8 when the provider accepts them and the mail path supports the extension. MIME encoded-words can encode a display name; they cannot make a non-ASCII local part work over ordinary SMTP. Domain labels still have to satisfy IDNA character rules.
Watch for automatic typography when copying names between documents and email templates. A text editor can replace a hyphen with a longer dash. A properly encoded display name supports that change, but an ordinary ASCII address or mail domain does not. Check the exact character before provisioning a mailbox or publishing DNS.
Subdomains can use hyphens
A hyphen is valid inside a hostname label. That means email-news.example.com and customer-mail.example.com are valid hostnames. In an ordinary ASCII mail domain, each label between dots must start and end with a letter or digit and contain only ASCII letters, digits, or hyphens. Each ASCII label is limited to 63 characters, including hyphens, under DNS label rules.
Valid and invalid subdomain labelstext
Valid: email-news.example.com customer-mail.example.com news-2026.example.com Invalid: -email.example.com email-.example.com email..example.com email_news.example.com Valid but usually avoid: mail--news.example.com
Under IDNA rules, labels with hyphens in both the third and fourth positions are reserved. Use the xn-- prefix only for a valid Punycode-encoded internationalized domain label. Doubled hyphens elsewhere can be valid, but they add needless confusion to an ordinary sending subdomain.
A hyphenated subdomain can be useful when it describes the mail stream without creating a long or ambiguous label. Examples include transactional naming such as order-mail.example.com or regional naming such as email-au.example.com. Shorter options such as mail.example.com or e.example.com are often cleaner when the function is obvious internally and externally.
Prefer a subdomain under an established brand domain when separating mail streams. A cousin domain is a separate domain that looks close to the brand domain, such as example-mail.com instead of mail.example.com. It can confuse recipients even when the owner has good intent. An established brand domain that already contains a hyphen is not inherently suspicious.
The underscore in authentication record names such as _dmarc.email-news.example.com or selector1._domainkey.email-news.example.com is valid for those DNS records. It does not make an underscore valid in the domain part of an email address.
Why subdomains are usually clearer than cousin domains
When several sending platforms need separate DNS records, use subdomains under the brand domain. Delegate DNS management only when the platform requires it. This lets each platform have its own authentication and bounce handling without registering a similar-looking domain. A separate domain can authenticate successfully too; the advantage of a subdomain is its clearer relationship to the brand.
Subdomain under the brand domain
Use a subdomain below the real brand domain, such as email.example.com or email-news.example.com.
- Relaxed DMARC alignment can use a shared organizational domain when policy discovery identifies one.
- The visible domain has a clear relationship to the brand.
Separate cousin domain
A separate lookalike domain, such as example-mail.com or example-news.com, needs its own sending identity.
- It can pass DMARC for its own From domain, but a similar spelling does not connect it to the original domain for alignment.
- Recipients can mistake the separate domain for an unrelated sender.
A subdomain separates mail streams for operations, but it does not guarantee independent sender reputation. Receivers use their own domain and IP reputation signals and can associate related subdomains with the parent domain. Keep each sending identity stable and monitor results. More detail is covered in the guide to subdomain reputation.
Naming choices and recipient recognition
Qualitative naming guidance, not a deliverability score or a provider filtering rule.
Clear brand relationship
email-news.example.com
A short hyphenated subdomain under the brand domain.
More to read
email-product-news.example.com
A longer subdomain that needs a clear operational purpose.
Separate brand identity
example-news.com
A separate domain that needs recognition and its own authentication.
How authentication handles a hyphenated subdomain
SPF, DKIM and DMARC do not reject a domain because it contains a hyphen. The records need to exist at the correct DNS names. DMARC passes when at least one of SPF or DKIM passes with an authenticated domain that satisfies alignment with the visible From address domain.
Under RFC 9989, a valid DMARC record at the exact From domain takes priority. If it is absent, policy discovery uses a DNS tree walk to find an applicable policy. Check the effective subdomain policy before sending; adding a subdomain does not bypass a parent's enforcement policy.
Illustrative DNS records for a hyphenated sending subdomaindns
email-news.example.com TXT "v=spf1 include:send.example.net -all" selector1._domainkey.email-news.example.com TXT "v=DKIM1; k=rsa; p=..." _dmarc.email-news.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
These records are placeholders. Replace the SPF include and DKIM public key with the values supplied by the sending platform, and use a working aggregate-report destination. Publish SPF at the envelope sender domain actually used by the platform; SPF is not inherited from a parent domain. The example p=none requests monitoring rather than enforcement.
For news@email-news.example.com, a passing DKIM signature with d=email-news.example.com satisfies both strict and relaxed alignment. A different signing domain must share the same discovered organizational domain for relaxed alignment. Strict alignment requires an exact domain match. SPF alignment uses the envelope sender domain, not the display name. These are the alignment rules in RFC 9989.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health checker checks published SPF, DKIM and DMARC configuration, including policy syntax and SPF lookup issues. A DNS check cannot establish whether a real message was signed or passed DMARC alignment. Send a message through the production platform and inspect its authentication results too.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
For ongoing monitoring, Suped's DMARC reporting shows which sources send as each domain or subdomain and their authentication results. Use those source-level results to identify unauthorized traffic and fix legitimate senders' configuration errors before moving to a stricter DMARC policy.
Recommended naming pattern
Stable sender names and subdomains are easier for recipients to recognize and easier for support teams to audit. Use a brand-first From name paired with a subdomain under the main brand domain.
- Decide whether the subdomain is for marketing, product, receipts, alerts, or support.
- Use one or two words, such as mail, news, or email-news.
- Place the subdomain under the brand domain instead of registering a similar-looking cousin domain.
- Configure SPF, DKIM and DMARC before sending production traffic.
- Review DMARC aggregate reports and source-level failures during rollout.
|
|
|
|
|---|---|---|---|
News | Brand - News | news | Clean |
Receipts | Brand - Receipts | receipts | Clear |
Regional | Brand - AU | email-au | Useful |
Support | Brand Support | support | Simple |
Example naming choices for common mail streams.
If you need several sending platforms, avoid creating many similar domains. Create a small set of sending subdomains instead, then assign each platform to the right subdomain or selector. The page on subdomain naming covers that planning choice in more depth.
Common mistakes to avoid
Most problems blamed on hyphens are really naming or authentication problems. A valid hostname can still be a bad sender identity if it makes the mail look disconnected from the brand or creates a hard-to-debug DNS setup.
- Do not use a separate hyphenated domain just because a sending setup feels easier.
- Make the From or Reply-To mailbox real, monitored, or safely routed.
- Do not rotate From names and subdomains without a clear operational reason.
- Do not send before authentication, bounce handling, and tracking are configured.
How to test before sending
Before sending real volume from a hyphenated From name or subdomain, test the exact message. Do not test only the DNS records. Send the same template through the same sending platform, using the From name and From address that production mail will use.
A six-step flowchart for testing a hyphenated email sending identity.
- Check how the From name renders across the mail clients your recipients use, including mobile clients.
- Reply to the message and confirm the intended From or Reply-To mailbox receives it. Test important contact forms with the exact hyphenated address too.
- Inspect SPF and DKIM results and verify that at least one passing result satisfies DMARC alignment with the From domain.
- Watch engagement and complaints alongside bounces and blocklist (blacklist) signals.
- Move DMARC enforcement to quarantine or reject after reports confirm that legitimate senders pass.
Suped's DMARC reporting supports this workflow by showing which platforms use the new subdomain and which sources fail authentication or alignment. Review those reports alongside message tests and DNS checks during rollout.
For teams or MSPs managing many domains, Suped's multi-tenancy dashboard keeps client domains separate while surfacing source-level failures and recommended fixes. This reduces the manual work of comparing raw XML reports across a subdomain rollout.
If the subdomain starts appearing on a blocklist or blacklist after launch, investigate it as a reputation event. The listing alone does not establish that the hyphen caused the problem. Check sending volume, list quality, complaint rates, compromised sources, and authentication failures before changing the name.
Blocklist checker
Check your domain or IP against 144 blocklists.
Views from the trenches
Best practices
Keep the brand first in the From name so recipients can identify the sender quickly.
Use subdomains under the real brand domain instead of separate lookalike sending domains.
Confirm that reply handling works before using a new From name or hyphenated subdomain.
Common pitfalls
Creating cousin domains for convenience makes legitimate mail look unrelated to the brand.
Using long hyphenated names can confuse users and create unnecessary support questions.
Skipping DMARC review hides whether the new subdomain is passing alignment checks.
Expert tips
Treat hyphens as a naming choice, then validate the full authentication path with real mail.
Delegate a short sending subdomain when multiple platforms need separate DNS records.
Watch early reports after launch because syntax validity does not prove sender trust.
Marketer view
Marketer from Email Geeks says hyphens in From names are common enough when the name remains recognizable and the mailbox can receive replies.
2019-02-18 - Email Geeks
Marketer view
Marketer from Email Geeks says a hyphenated From or Reply-To address is acceptable when it matches branding and works as a real mailbox.
2019-02-18 - Email Geeks
