Can a business email address contain a semicolon?

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

Why a semicolon does not work in practice

RFC 5321 section 4.1.2 defines the normal SMTP mailbox local part using the atext character set, which does not include the semicolon character. While RFC 5322 section 3.4.1 primarily reserves the comma as the standard separator in address lists, the semicolon has historically been used as an alternative address separator in some email clients and mailing list contexts. A semicolon is not an allowed character in the local part of a standard unquoted email address.

Even in a quoted-string local part (such as "sales;info"@example), mail providers rarely create or accept addresses containing semicolons for public use because of the fundamental conflict with address-list syntax and the semicolon's role as a statement terminator in databases, spreadsheets, and programming languages. Website forms, booking tools, CRMs, accounting packages and imported contact lists almost universally reject or split addresses at semicolons, treating the semicolon as a field separator, statement terminator, or list delimiter rather than part of the literal address.

When customers see an address containing a semicolon—such as sales;info@example—they typically interpret it as two separate addresses: sales and info@example, as the end of one statement and the beginning of another, or as a typing error. The semicolon's role as a separator in programming, database queries, CSV files with semicolon delimiters (common in Europe), and email address lists is so entrenched that using it inside an address identifier creates ambiguity at every point in the workflow. The same workflow concerns that make giving an email address over the phone challenging are amplified when a semicolon is part of the address.

What customers see and type

Picture a business telling a customer: sales;info@<short-name>.au. The customer hears "sales semicolon info at ..." and writes down two addresses: sales (incomplete) and info@<short-name>.au, or assumes the semicolon is a separator and types salesinfo@<short-name>.au without the semicolon, or wonders whether the business meant to say "sales or info" or "sales then info" rather than giving a single literal address containing a semicolon character.

Now imagine the same address on a printed invoice, quote PDF, business card or van sign. The semicolon is visible, but it looks like it separates two email addresses, marks the end of a statement, or terminates one instruction before another. When a customer retypes the address from a mobile screen or physical paper, they may type only the part after the semicolon (assuming the part before the semicolon is a separate address or a label), drop the semicolon entirely, replace it with a comma, colon, hyphen or period, type the word "semicolon", or enter both parts as separate addresses in their contact list.

This variability does not mean every customer will mistype the address. It means the semicolon introduces an interpretation choice where none would exist if the address were sales@<short-name>.au, info@<short-name>.au, or bookings@<short-name>.au instead. Compare this to the narrower concern around periods, hyphens and underscores in business email addresses, where the character is permitted and can be seen, but may still be confused or missed.

Form validation and CRM import rejection

Most email validation libraries and form validation tools reject semicolons in email addresses outright because semicolons are not part of the standard unquoted local-part character set defined in RFC 5321 section 4.1.2 and have been used as address separators in various email contexts. Even validation that permits special characters in quoted local parts typically excludes semicolons because of their role as statement terminators in SQL, JavaScript, CSS, and many other languages, as well as their use as field separators in semicolon-delimited CSV files (common in European regions).

Website contact forms, CRM imports, booking systems, accounting packages and quote generators often treat a semicolon as a statement terminator or list delimiter. An address like sales;info@example entered into a form may be rejected with an error message like "Invalid email address", split into two separate addresses (sales and info@example), truncated at the semicolon (keeping only sales), stripped of the semicolon (turning it into salesinfo@example), or interpreted as the end of one database statement and the beginning of another.

The business may not see the alteration until a reply to a stored address bounces or goes missing. A customer who enters sales;info@example into a website form may receive no confirmation (because sales without a domain is invalid), a confirmation sent only to info@example (if the form interpreted the semicolon as a separator and dropped the first part), or an error requiring them to re-enter the address in a different format.

Semicolon-delimited CSV files are the standard in many European countries and in Microsoft Excel when the system locale uses a comma as the decimal separator. When importing contacts from semicolon-delimited CSV files, CRMs, accounting tools and mailing list platforms will interpret semicolons as field delimiters, not as literal characters within a field value. This means an address containing a semicolon will be split across multiple columns during import, even if the address was intended to remain intact. Contact lists exported from one system and imported into another will often lose, split or reject addresses containing semicolons, and the business may not discover the problem until customer communications fail.

Confusion with statement terminators and multiple addresses

The primary source of confusion with a semicolon in a business email address is that semicolons serve as statement terminators in SQL, JavaScript, C, C++, Java, C#, PHP, and many other programming languages, as well as separators in certain email address list contexts. When someone sees sales;info@<short-name>.au, they may read it as two separate statements or addresses: sales (incomplete) and info@<short-name>.au, or as a typing error where the domain was accidentally omitted from the first address.

While commas are the standard separator in RFC 5322 email headers, semicolons have been used as alternative address separators in some email clients (particularly older Microsoft Outlook address books and certain mailing list systems) and in Windows contact lists. This inconsistent history means that customers familiar with email, databases, or programming may interpret a semicolon in an address as a separator rather than a literal character, and will either type only one part or split it into separate contact entries.

Even when a customer carefully types the semicolon as shown, mail clients, web forms and CRMs may interpret the input as a multi-recipient list or a statement boundary. An outbound message addressed to sales;info@example may be parsed by the sending system as two recipients: an incomplete address sales (which will be rejected or autocorrected) and a valid address info@example. The sender may not see the parsing error until the message bounces or only one recipient receives it.

Phone and handwriting ambiguity

When spoken aloud, a semicolon is called "semicolon" in English, but the customer hearing the address must decide whether the semicolon is part of the literal address or a separator or terminator in the spoken sentence. A business saying "our email is sales semicolon info at <short-name> dot au" could be interpreted as giving one address (sales;info@<short-name>.au), two addresses (sales@<short-name>.au and info@<short-name>.au), or a description where "semicolon" marks the end of one statement or instruction rather than a character to be typed.

A customer writing down the address by hand may write sales; info@<short-name>.au (with a space after the semicolon, treating it as punctuation), sales info@<short-name>.au (dropping the semicolon and assuming it was just a separator), or two separate entries in their address book: sales and info@<short-name>.au. When later transcribing the handwritten note into a computer or mobile device, they may split the address at the semicolon, type the word "semicolon", confuse it with a colon, or omit it entirely.

Handwritten semicolons can also be misread as colons, commas with floating dots, or stray marks, especially when combined with cursive or hurried writing. A customer seeing a handwritten sales;info@<short-name>.au may type sales:info@<short-name>.au, sales,info@<short-name>.au, salesinfo@<short-name>.au, or assume the semicolon is a smudge or punctuation mark that is not part of the address. For the wider phone workflow, see this guide to giving an email address over the phone without spelling.

Print and signage: looks like a separator or terminator

When printed on a business card, invoice, quote PDF, van sign, or website footer, a semicolon in the email address creates immediate visual confusion. To most readers, the semicolon signals a separator between two items, the end of one statement before another begins, or a punctuation mark—not a literal character that must be included in the address.

Customers seeing sales;info@<short-name>.au on printed material will typically assume they are looking at two separate addresses (with the first one missing its domain), a statement terminator followed by a new instruction, a typing error, or abbreviated instructions like "contact sales or info at <short-name> dot au" rather than a single technical identifier containing a semicolon character. Readers familiar with programming, databases, or semicolon-delimited CSV files will recognise that semicolons terminate statements or separate fields, reinforcing the interpretation that the semicolon is not part of the address itself.

Compare this to a simple address like sales@<short-name>.au, 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 colons: similar appearance

The visual similarity between a semicolon (;) and a colon (:) creates an additional layer of confusion. When typed in certain fonts, handwritten, or seen at a distance, the two characters can be difficult to distinguish. A customer may type sales:info@example when the business intended sales;info@example, or vice versa.

Colons also have their own set of problems in email addresses, being reserved in URL syntax and used as key-value separators in many contexts. Neither character is practical for a public business email address, but the visual similarity means that even when a customer recognises that the address contains one of these punctuation marks, they may type the wrong one.

Trading name and email address are different

A business that trades under a name that might conceptually use a semicolon for separation does not need to reproduce any separator punctuation 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 partners@<short-name>.au or bookings@<short-name>.au—or a person address—such as chris@<short-name>.au—that drops semicolons, commas, and other separator punctuation. The email display name can still show the full trading name or role description: Sales & Info <info@<short-name>.au> or Chris Lee — Sales <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.

Semicolon-delimited CSV files: regional concern

In many European countries and in systems where the comma is used as a decimal separator (such as 1.234,56 for one thousand two hundred thirty-four point five six), semicolons are the standard field delimiter in CSV (Character-Separated Values) files instead of commas. Microsoft Excel and other spreadsheet applications automatically use semicolon delimiters when the system locale specifies a comma as the decimal separator.

This means that an address containing a semicolon—such as sales;info@example—will be split across multiple columns when imported from a semicolon-delimited CSV file into a CRM, accounting tool, or mailing list platform. Even if the business carefully encloses the address in quotes in the CSV file, many import tools will reject the address during validation or strip the semicolon, turning it into salesinfo@example or splitting it into separate fields.

Contact lists exported from Australian or US systems (which typically use comma-delimited CSV) and imported into European systems (which typically use semicolon-delimited CSV), or vice versa, will often lose or alter addresses containing semicolons. This cross-region incompatibility is a practical problem for businesses that work with international customers, suppliers, or partners.

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 semicolons, commas, spaces, quote marks or other special characters that serve as separators, terminators, or delimiters in email, CSV, database, or programming syntax.

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 without wondering whether they are looking at one address or two, or whether the punctuation is part of the address or a statement terminator. 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 semicolons, commas, spaces, quote marks or other special characters that serve as separators, terminators, or delimiters in email headers, CSV files, database queries, or programming languages.
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. Pay special attention to how forms, semicolon-delimited CSV imports, and contact list tools handle the address.
4. Copy it from a PDF and a mobile screen. Check that the format remains visible and unchanged, and that no automatic parsing splits the address at punctuation or interprets it as a statement terminator.
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 and check whether they interpreted the semicolon as a separator, terminator, or literal character.
6. Test the address in any email client To/Cc/Bcc fields to confirm that it is not parsed as multiple recipients or a statement boundary. Test it in any form validation, CRM import (both comma-delimited and semicolon-delimited CSV), contact list and quote generation workflows the business relies on.
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 semicolon-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 you want a clearer public email identifier without semicolons, commas, or other separator punctuation—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.