Can a business email address contain curly braces?

For a public-facing small business, prefer a simple role or person address that avoids curly braces—such as quotes@<short-name>.au or bookings@<short-name>.au—then test the exact setup before printing or publishing it.

Why curly braces do not work in practice

RFC 5321 section 4.1.2 defines the normal SMTP mailbox local part using characters that do not include { or }. RFC 5322 section 3.4.1 lists the allowed characters in the local part of an email address, and curly braces are not among them. Curly braces are not supported in the local part of a standard email address, and even in a quoted-string local part they are not accepted by most mail providers for public addresses.

Mail providers rarely create addresses containing { or }. Website forms, booking tools, CRMs, accounting packages and imported contact lists often reject curly braces outright, strip them, or interpret them as syntax errors. Many validation libraries treat curly braces as invalid characters in email addresses because they are not part of the standard unquoted local-part character set defined in the RFC specifications.

When speaking the address, the curly braces are described as "open curly brace", "close curly brace", "left curly brace", "right curly brace", "open brace", "close brace", or simply "curly bracket". Regional and technical conventions differ. Customers typically omit them, confuse them with square brackets, round brackets, or angle brackets, type the word "brace" or "bracket", or assume they indicate optional text, template syntax, or placeholder variables rather than part of the address. The same workflow concerns that make giving an email address over the phone challenging are amplified when { } cannot be reproduced reliably from speech.

What customers hear and type

Picture a business telling a customer on a noisy call: info{main}@example. The customer hears "info open curly brace main close curly brace at example dot ..." or "info open brace main close brace at example dot ..." or "info curly bracket main curly bracket at example dot ...". Do they type info, infomain, info-main, info{main}, info[main], info(main), or assume the curly braces indicate a template variable or placeholder text that should be replaced with something else?

Now imagine the same address on a printed invoice, quote PDF or van sign. The { } are visible, but to most readers they look like template syntax, placeholder variables from programming, merge fields from mail merge documents, or mustache/handlebars template delimiters. When a customer retypes the address from a mobile screen or physical paper, they may drop the curly braces entirely, replace them with square brackets or parentheses, type the words "open brace" and "close brace", or assume the text inside the braces is meant to be replaced with actual content.

This variability does not mean every customer will mistype the address. It means there are several ways to interpret { } where none would exist if the address were info@<short-name>.au or bookings@<short-name>.au instead. Compare this to the narrower concern around hyphens, underscores and spaces in business email addresses, where the character can be seen but may still be confused, missed or rejected.

Form validation and CRM import rejection

Most email validation libraries and form validation tools reject curly braces in email addresses because they are not part of the standard unquoted local-part character set defined in RFC 5321 section 4.1.2. Even lenient validation that permits some special characters in quoted local parts typically excludes curly braces because they have no defined role in RFC 5322 address syntax and are widely recognized as template placeholder syntax in programming and document systems.

Website contact forms, CRM imports, booking systems, accounting packages and quote generators often validate or normalise email addresses before storing them. Curly braces may be rejected outright with an error message like "Invalid email address", stripped silently (turning info{main}@example into infomain@example or info@example), replaced with hyphens or underscores, or URL-encoded as %7B and %7D, depending on how the form processes the input.

The business may not see the alteration until a reply to a stored address bounces or goes missing. A customer who enters info{main}@example into a website form may receive a confirmation message sent to info-main@example, infomain@example, info_main@example or info%7Bmain%7D@example, depending on how the form processed the input.

CSV imports into CRMs, accounting tools and mailing list platforms often reject rows containing addresses with curly braces, or silently drop the braces during import. This means contact lists exported from one system and imported into another may lose or alter addresses containing { } without any visible error. Some systems may even interpret curly braces as merge field syntax and attempt to replace them with database values during import.

Phone and spoken ambiguity

When spoken aloud, { can be called "open curly brace", "left curly brace", "open brace", "opening brace", "open curly bracket", or "left curly bracket". The } can be called "close curly brace", "right curly brace", "close brace", "closing brace", "close curly bracket", or "right curly bracket". Regional and technical conventions differ. In Australia, "bracket" typically refers to square brackets or round brackets (parentheses), so "curly brace" or "curly bracket" may be clearer, but both terms are longer and less familiar to non-technical customers.

A customer hearing "info open curly brace main close curly brace" may type info, info-main, infomain, info{main}, info[main], info(main), or assume "main" is a template variable name that should be replaced with actual content rather than being part of the literal address. A customer hearing "info open brace main close brace" may not know whether "brace" refers to curly braces { }, square brackets [ ], or parentheses ( ).

A customer hearing "info curly bracket main curly bracket" may type info{main}, info[main], or assume the business is reading from technical documentation or template syntax rather than giving out a real public email address. This ambiguity between bracket types is shared with square brackets and parentheses and creates multiple points of confusion when speaking or transcribing the address.

This spoken ambiguity does not exist for a simple address like info@<short-name>.au or bookings@<short-name>.au. For the wider phone workflow, see this guide to giving an email address over the phone without spelling.

Print and signage: looks like template or placeholder syntax

When printed on a business card, invoice, quote PDF, van sign, or website footer, curly braces in the email address create visual confusion. To most readers, { } signals template syntax, placeholder variables, merge fields, mustache/handlebars template delimiters, or programming language syntax—not literal characters that must be included in the address.

Customers seeing info{main}@<short-name>.au on printed material may assume the address is incomplete or that {main} is a placeholder variable that should be replaced with actual text before use. Readers familiar with programming, mail merge, or content management systems will recognize curly braces as template syntax and may assume the business printed a template by mistake rather than intending the braces to be part of the public address.

Compare this to a simple address like info@<short-name>.au or bookings@<short-name>.au, which reads clearly and unambiguously on any printed surface. The goal is not to prove that an address can be technically created or quoted, but to choose an address customers can use without hesitation or guesswork.

Confusion with square brackets and parentheses

In spoken and written contexts, "brace" or "bracket" without clear qualification can refer to curly braces { }, square brackets [ ], or round brackets ( ) (parentheses). When a customer hears "info brace main brace" or sees handwritten notes mentioning braces, they may not know which type is intended.

Curly braces { } are used for template placeholders, merge fields, mustache/handlebars syntax, JSON objects, code blocks in programming, and set notation in mathematics. Square brackets [ ] are used for IPv6 addresses, array indexing in programming, optional parameters in documentation, and editorial clarifications. Round brackets ( ) are used for optional text, alternatives, clarifications and grouping in general writing. None of these are practical in a public business email address, but the ambiguity between them adds another layer of confusion when speaking or transcribing an address containing any bracket or brace character.

A customer who hears an address with "braces" or "brackets" may type the wrong bracket type, omit them entirely, replace them with hyphens or underscores, or assume the business meant to include template syntax or placeholder instructions rather than giving out a final public address. For the same concerns around other bracket types, see can a business email address contain square brackets and can a business email address contain parentheses.

Trading name and email address are different

A business that trades under a name containing curly braces—such as "Design {Studio}" or "Tech {Group}"—does not need to reproduce the curly braces in the email address. The trading name remains on the letterhead, website, business card, invoice PDF, quote footer and email display name. The email address is only the technical routing identifier.

Use a simpler role address—such as studio@<short-name>.au or bookings@<short-name>.au—or a person address—such as chris@<short-name>.au—that drops the curly braces. The email display name can still show the full trading name with curly braces: Design {Studio} <info@<short-name>.au> or Chris Lee — Tech {Group} <chris@<short-name>.au>.

This separation keeps the public contact workflow simple without removing the business identity. For the wider naming choice, see this guide to professional email address formats for small business. For display name guidance, see what your business email display name should be.

Prefer a simple role or name address

For a public customer-facing business, use a simple role address (such as quotes@<short-name>.au or bookings@<short-name>.au) or a person address (such as chris@<short-name>.au) without curly braces, square brackets, parentheses, spaces, quote marks or other special characters.

A role address does not create a shared mailbox or give several people access by itself. The routing rule, destination mailbox, staff login, shared access and storage policy are separate parts of the setup. The public address is only the visible entry point.

When choosing the format, prioritise what customers can hear, say and type consistently. Read the separate guide to common mistakes customers make when entering email addresses for the wider picture.

Run a harmless test before publishing

Before printing, publishing or giving out a public business address:

1. Confirm that the provider can create or route the exact address without curly braces, square brackets, parentheses, quote marks or other special syntax.
2. Send harmless fictional content from an unrelated inbox and confirm that it reaches the intended destination.
3. Enter the address into the real website, quote, booking, CRM and accounting workflows the business uses.
4. Copy it from a PDF and a mobile screen. Check that the format remains visible and unchanged.
5. Have someone who is not already familiar with the address hear it over a call and write down what they heard. Compare their version to the original.
6. Test the address in any form validation, CRM import, contact list and quote generation workflows the business relies on. Pay special attention to how curly braces are handled by validation libraries and CSV imports.
7. Record who owns the public address, routing rule and mailbox access. Set a retest trigger for any provider or configuration change.

This test proves only the exact route, provider and configuration tested at that time. It does not guarantee delivery or inbox placement.

The public address is only 1 layer. A curly-braces-free address does not create a routing rule, mailbox, login, shared access, storage policy or permission to send from that address. Confirm mailbox access, storage, display name and reply-from behaviour separately.

Where Short Mail may fit

If your current public address is awkward to say, print or type—or if your trading name includes curly braces and you want a clearer public email identifier—a Short Mail account manager can check whether a shorter matched .au address may fit and forward to the inbox you already use. Fit, availability, .au eligibility, setup requirements and provider compatibility are confirmed manually before anything changes.

The public address, routing, mailbox, access and storage remain separate parts of the setup. Sending permission and the From and Reply-To details customers see also require separate checks for your business.