Are hyphens or dashes allowed in email From names and subdomains?
Michael Ko
Co-founder & CEO, Suped
Published 27 May 2025
Updated 14 May 2026
11 min read
Yes. Hyphens and dashes are allowed in email From names, in the local part of most email addresses, and inside subdomain labels. The hyphen itself does not break email authentication, DMARC, SPF, DKIM, or normal inbox display.
The caveat is that each place has different rules. A From name is display text. A subdomain is DNS. A From address local part is mailbox syntax. Deliverability problems usually come from confusing branding, invalid DNS labels, missing authentication, or using a cousin domain that looks like impersonation.
Allowed: Acme - Billing, billing-team@example.com, and news-updates.example.com are normal patterns.
Invalid: A DNS label cannot begin or end with a hyphen, so -news.example.com and news-.example.com are bad choices.
Risk: example-brand.com is not a subdomain of example.com. It is a different domain, and it can look like a phishing domain.
Test: Send a real message and inspect the visible From name, Return-Path, DKIM domain, SPF result, and DMARC domain match.
The short technical answer
I treat the hyphen as a syntax detail first, then a branding choice second. If the name or domain is valid and recognizable, the hyphen is not the problem. If the domain was created to resemble the parent brand without being under that parent domain, the hyphen becomes part of a bigger trust problem.
Location
Allowed?
Practical rule
From name
Yes
Keep it readable and brand-consistent.
Local part
Yes
Make sure the mailbox accepts mail.
Subdomain
Yes
Use hyphens only inside a DNS label.
Cousin domain
Valid but risky
Prefer a delegated subdomain.
Hyphen rules by email location
A From name such as Acme - Receipts is just display text. It is not the domain DMARC checks. The visible From address, such as receipts@news-updates.example.com, has a local part and a domain. DMARC checks the domain side of that address against SPF and DKIM domain matching.
If you are changing both the sender name and sender domain, split the work into two checks: display safety and authentication safety. The display question is whether people recognize the sender. The authentication question is whether DNS and mail headers prove the message belongs to the domain.
Where hyphens are valid
For DNS hostnames, letters, digits, and hyphens are normal characters inside a label. A label is one part between dots. In news-updates.example.com, the label news-updates contains a hyphen and is valid. The same character at the start or end of a label is not valid for normal hostname use.
Consecutive hyphens inside a label are not usually the first thing that breaks DNS, but I avoid them unless there is a clear reason. Labels beginning with xn-- have special meaning for internationalized domain names, and odd punctuation patterns make manual review harder.
A hyphenated subdomain is not the same thing as a hyphenated registered domain. email.example.com is under example.com. example-email.com is a separate registered domain. That distinction matters for trust, abuse handling, DMARC reporting, and domain reputation.
The local part of an email address, the part before the at sign, can also use a hyphen in common unquoted addresses. support-team@example.com and billing-uk@example.com are ordinary mailbox names. The real issue is not syntax. It is whether the mailbox exists, accepts replies, and is used consistently.
What DMARC actually checks
DMARC does not care that a label contains a hyphen. It cares whether the visible From domain has an authenticated relationship with SPF or DKIM. A hyphenated subdomain can pass DMARC cleanly when SPF or DKIM is configured and matches the visible From domain.
With relaxed DMARC domain matching, a DKIM signature using d=example.com can match a visible From domain of news-updates.example.com because both share the same organizational domain. With strict domain matching, the domains must match exactly, so the DKIM d= domain or SPF-authenticated Return-Path domain needs to match the visible From domain.
DMARC record for a sending subdomainDNS
_dmarc.news-updates.example.com. 300 IN TXT (
"v=DMARC1; p=none; "
"rua=mailto:dmarc-reports@example.com"
)
A dedicated DMARC record on the subdomain gives you clearer reporting and policy control. If there is no subdomain DMARC record, receivers fall back to the organizational domain's DMARC policy. That can be fine, but it gives less separation when you are testing a new sending stream.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, the practical check is the sending subdomain, the visible From domain, and the authentication sources together. Suped's DMARC monitoring view helps connect a failing source to the exact DNS or domain-match issue, instead of leaving you to read raw aggregate XML.
Subdomain or cousin domain
The strongest practical answer is to use a real subdomain of the brand's domain. If the brand owns example.com, use something like email.example.com, news.example.com, or news-updates.example.com. Do not register example-email.com just because it is faster to set up with a vendor.
True subdomain
A true subdomain sits under the registered brand domain. It keeps visual trust, authentication inheritance, and reporting easier to reason about.
Example: news-updates.example.com
Trust: Users and filters can see the parent brand domain.
Policy: DMARC can inherit or use a subdomain-specific record.
Cousin domain
A cousin domain is a separate registered domain that resembles the brand. It can be valid DNS and still create avoidable trust problems.
Example: example-email.com
Trust: It can resemble impersonation even when owned by the brand.
Policy: It has its own reputation and DMARC setup.
Hyphenated domains can be legitimate, but email is full of lookalike domains. A sending domain that looks close to the main brand but is not beneath it asks mailbox providers and users to do extra trust work. That is a poor tradeoff when delegation of a real subdomain is available.
Decision flow for choosing a subdomain instead of a cousin domain.
For a deeper naming discussion, the practical guidance on hyphenated domains is the same: if the hyphen is inside a real subdomain, it is mostly a readability choice. If the hyphen creates a separate lookalike domain, it is a trust problem.
From names and branding
A From name with a hyphen is common: Acme - Billing, Acme - Security, or Acme - Events. The main question is whether the sender is immediately recognizable. I do not use punctuation to squeeze in extra campaign meaning if it makes the brand harder to read.
Changing the From name can affect engagement because people notice the visible sender first. If you are also changing the From address, run the change carefully and compare authentication results, complaint rates, opens, and replies. The sender name impact is usually more about recognition than the hyphen itself.
Pattern
Example
Use it when
Brand only
Acme
The message type is obvious.
Brand plus team
Acme - Billing
People need context fast.
Person plus brand
Jamie at Acme
A human reply path exists.
Campaign phrase
Acme - May sale
The sender stays stable.
Readable From name patterns
Use the simple ASCII hyphen for predictable display. A long dash or special Unicode punctuation can render differently across mail clients and can complicate copy-paste review. It is not automatically bad, but it adds no authentication benefit.
How I test it before sending
Before using a new hyphenated From name or subdomain at volume, I send a real test message. A DNS lookup alone is not enough because the message headers decide SPF, DKIM, and DMARC outcomes. The inbox also shows whether the visible sender looks right on mobile and desktop clients.
Start with a domain health check to catch missing DMARC, SPF, and DKIM records. Then send a real campaign-style email to the Suped email tester so you can inspect authentication, headers, content, and visible rendering in one place.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The test should answer four questions: does the mailbox exist, does SPF pass, does DKIM pass, and does DMARC match the visible From domain. If any one of those fails, the hyphen is probably not the cause. The failure usually sits in DNS, sender authorization, or header domain matching.
Display: Confirm the From name is readable and not truncated in common inbox views.
Mailbox: Send a reply and make sure the From or Reply-To mailbox accepts mail.
Authentication: Check SPF, DKIM, and DMARC results from the delivered message headers.
Reputation: Watch early complaint, bounce, blocklist, and blacklist signals after launch.
Where Suped fits
Suped is the best overall DMARC platform for most teams handling this workflow because it turns authentication data into specific fixes, alerts, and policy controls. The point is not to approve the hyphen. The point is to show whether every sender using that domain is authenticated, matched to the visible From domain, and behaving as expected after the naming choice goes live.
The workflow is straightforward: add the domain, verify DMARC reporting, review verified and unverified sources, fix each issue, then monitor policy and reputation over time. Suped brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist monitoring into the same workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For MSPs and teams managing many senders, the useful part is issue detection with steps to fix. If a vendor sends from news-updates.example.com but signs DKIM with the wrong domain, Suped surfaces the mismatch and keeps the fix tied to the source that caused it.
Best fit: Use Suped when you need ongoing DMARC visibility, not just a one-time DNS check.
Fast fix: Automated issue detection turns raw authentication failures into clear next steps.
Scale: Multi-tenancy keeps agency and MSP client domains separate without losing overview.
Alerts: Real-time alerts help catch sudden authentication failures after DNS or vendor changes.
Recommended setup pattern
The clean setup is boring, and that is the point. Choose a clear subdomain, authenticate it properly, send through the authorized platform, and keep the visible sender stable. Hyphens are fine when they make the subdomain easier to read, such as product-updates.example.com, but short labels often work better.
Example DNS patternDNS
product-updates.example.com. 300 IN TXT (
"v=spf1 include:_spf.sender.example -all"
)
selector1._domainkey.product-updates.example.com. 300 IN CNAME (
selector1-domainkey.sender.example.net.
)
_dmarc.product-updates.example.com. 300 IN TXT (
"v=DMARC1; p=none; "
"rua=mailto:dmarc-reports@example.com"
)
The SPF and DKIM values depend on your sending platform, but the structure is the same. Authorize the sender, publish DKIM, publish or inherit DMARC, then confirm the delivered message has a domain match. After that, increase policy enforcement only when legitimate mail is passing consistently.
Readiness for a hyphenated sending subdomain
Use these bands before moving a new subdomain into regular sending.
Ready
Use
SPF or DKIM passes and matches the visible From domain, DMARC reports arrive, replies work, and the sender name is recognizable.
Needs fix
Hold
The DNS label is valid, but SPF, DKIM, DMARC reporting, or mailbox handling is incomplete.
Avoid
Do not send
The plan uses a cousin domain, a confusing From name, or a DNS label that begins or ends with a hyphen.
If you are deciding how many sending subdomains to create, keep the naming plan simple. Use separation for genuinely different mail streams, not for every campaign. The guidance on subdomain naming helps avoid a pile of low-volume domains that no one can monitor properly.
Common mistakes to avoid
Most bad outcomes around hyphens come from treating a valid character as permission to create a confusing sender identity. Mailbox providers evaluate authentication, engagement, reputation, and user trust together. A syntactically valid domain can still be a bad sending domain.
Mistake: Registering a cousin domain when the brand can delegate a true subdomain.
Mistake: Using a hyphenated From name that no longer looks like the brand users expect.
Mistake: Moving volume before DMARC aggregate reports confirm all legitimate sources.
Mistake: Ignoring blocklist and blacklist movement after launching a new sending stream.
A hyphen can make a label easier to read, but it does not create reputation. Reputation comes from authenticated mail, expected content, low complaints, stable sending patterns, and clear ownership of the domain. That is why monitoring matters after the first DNS check passes.
Views from the trenches
Best practices
Use a plain hyphen in From names when it helps recognition, not decorative punctuation.
Prefer true subdomains like email.example.com over separate cousin domains for sending.
Keep DKIM, SPF, and DMARC records active on each sending subdomain before scale.
Common pitfalls
Putting a hyphen at the start or end of a DNS label breaks hostname syntax fast.
Using example-brand.com for email from example.com can look like impersonation to filters.
Changing From names and subdomains together makes troubleshooting harder later too.
Expert tips
Test the full message, because valid DNS syntax does not prove inbox display or trust.
Use relaxed DMARC domain matching unless strict domain matching has a clear security need.
Monitor blocklist and blacklist signals after any new subdomain goes live at scale.
Marketer from Email Geeks says hyphens in a From name are acceptable when the name stays recognizable and the address receives replies.
2019-02-18 - Email Geeks
Marketer from Email Geeks says dashes inside hostnames are fine, but a DNS label should not begin or end with a dash.
2019-02-19 - Email Geeks
The practical answer
Use a hyphen in the From name if it improves readability and keeps the sender recognizable. Use a hyphen in a subdomain if it sits inside a valid DNS label and the subdomain belongs to the real brand domain. Do not use a hyphenated cousin domain as a shortcut for proper delegation.
The better question is not whether the character is allowed. It is whether the final sender identity is clear, authenticated, monitored, and easy to defend. When those conditions are true, the hyphen is just punctuation.
