The country of Australia, officially known as the Commonwealth of Australia, consists of six states and two territories. There are over 13 million known deliverable addresses in Australia. This article breaks down the standard format used for Australian addresses, and what to check for in each field of these addresses.

Postal Services

Mail in Australia is handled by Australia Post, formally known as the Australian Postal Corporation. Australia Post is a government-owned corporation that was founded in 1809.

International Country Code

First, let’s look at how Australia defines its country codes, as well as its states and territories. The International Organization for Standardization (ISO) published the ISO 3166 standard, officially known as Codes for the representation of names of countries and their subdivisions.

The ISO 3166 standard consists of three parts:

Part	ISO	Description
1	ISO 3166-1	Country Codes – defines codes for the names of countries, dependent territories, and special areas of geographical interest.
2	ISO 3166-2	Country subdivision code – defines codes for the names of primary subdivisions of a country, such as a state or a province.
3	ISO 3166-3	Code for formerly used names of countries – defines codes for country names that have been removed from ISO 3166-1.

ISO 3166-1, which defines country codes, contains three sets of country codes:

ISO Country Codes	Description
ISO 3166-1 alpha-2:	Defines a country as a two-letter country code, commonly referred to as the ISO, ISO2, or ISO-2.
ISO 3166-1 alpha-3:	Defines a country as a three-letter country code, commonly referred to as ISO3, or ISO-3.
ISO 3166-1 numeric	Defines a country as a three-digit country code.

ISO 3166-1 Country Codes – Australia

Country Code Type	Country Code
ISO 3166-1 alpha-2 code	AU
ISO 3166-1 alpha-3 code	AUS
ISO 3166-1 numeric code	36

ISO 3166-2 Codes

The ISO currently lists codes for Australia’s six states and two of its territories.

ISO 3166-2 code	Subdivision Name	Subdivision category
AU-NSW	New South Wales	State
AU-QLD	Queensland	State
AU-SA	South Australia	State
AU-TAS	Tasmania	State
AU-VIC	Victoria	State
AU-WA	Western Australia	State
AU-ACT	Australian Capital Territory	Territory
AU-NT	Northern Territory	Territory

Address Format

Now, let’s look at how delivery addresses are constructed. The address format for deliverable mail in Australia is defined by Australia Post, where an address is made up of several components.

Position	Address Component	Description	Format	Requirement	Example
First line	Recipient	The name of the person, company or organization.	Use common abbreviations in titles and distinctions. Also,avoid unnecessary punctuation.	Required	Issac Nichols
Second line and third line if necessary	Reference Details	When necessary, the name of the person’s job/position and/orthe name of the company, organization or department.		Optional	Postmaster Australia Post
Second to last line	Thoroughfare	The street address, Box number or Locked Bag number. If athoroughfare is not available, then include thebuilding/complex name in its place. Include building subunitand floor/level when necessary.	Use common abbreviations where applicable. Also, no punctuationallowed.	Required	111 Bourke St
Last line, first component	Locality or Delivery office	The full name of the city, suburb, placename or Post Office-Delivery Centre (DC) or a Business Centre (BC). Note that thedelivery locality may not necessarily be the same as thegeographic locality.	Must be in UPPER CASE. Also, no punctuation allowed.	Required	MELBOURNE
Last line, second component	State or Territory	The abbreviated format of the state or territory.	The abbreviation of the state or territory and not the fullname. Also, no punctuation allowed.	Required	VIC
Last line, third component	Postcode	A four-digit numeric code used to identify the postal deliveryarea.	Do not omit leading zeros. Also, no punctuation allowed.	Required	300

States

Name	Abbreviation	Postcode Ranges
New South Wales	NSW	1000—1999 * 2000—2599 2619—2899 2921—2999
Queensland	QLD	4000—4999 9000—9999 *
South Australia	SA	5000—5799 5800—5999 *
Tasmania	TAS	7000—7799 7800—7999 *
Victoria	VIC	3000—3999 8000—8999 *
Western Australia	WA	6000—6797 6800—6999 *

* Reserved for PO Boxes and Large Volume Receivers (LVR)

Territories

Name	Abbreviation	Postcode Ranges
Australian Capital Territory	ACT	0200—0299* 2600—2618 2900—2920
Northern Territory	NT	0800—0899 0900—0999*

* Reserved for PO Boxes and Large Volume Receivers (LVR)

External Territories

Australia has three inhabited external territories. They do not use their own name and abbreviation in Australia Post’s postcode system and are instead assigned the name of another state.

Name	Abbreviation	Postcode
Norfolk Island	NSW	2899
Christmas Island	WA	6798
Cocos (keeling) Island	WA	6799

Postcodes

Australian postcodes are four-digit codes that are used to help sort and route mail. The first two digits often represent which state or territory the postcode belongs too, with the exception of the Australian Capital Territory (ACT) which is embedded in New South Wales (NSW).

The postcode is the third and final address component in the last address line, following the Locality and State/Territory components. However, if the envelope being used includes four postcode squares in the bottom right corner then Australia Post prefers that you fill those boxes in with the postcode instead.

Postcode vs Geography

Some postcodes may cover two or more states or territories. For example, the postcode 0872 is currently used to cover 87 localities located in West Australia (WA), South Australia (SA) and Northern Territory (NT). Australia Post sometimes finds it easier to send mail through a post office located in one state/territory for an address geographically located in another state/territory. So, it is not uncommon to find an address with a mailing address that does not match its physical address or geographic location.

Postcodes do not always correspond to a geographic location. Many postcodes are reserved for post office (PO) boxes and some are reserved for large organizations. Some large companies, government agencies, and organizations are classified as Large Volume Receivers (LVR) and will have their own unique postcode. For example, the postcode 0200 corresponds to the Australian National University

Address Validation International: Overcoming Cultural Idiosyncrasies and Postal Format Variables

The above content provides a general overview of Australia and the address format specified by Australia Post. Overall, there are more than 18 different address components, elements and fragments to consider when working with Australian addresses. There are also monthly data updates published by Australia Post to stay on top of.

As with most countries, Service Objects’ Address Validation International (AVI) is capable of processing and validating deliverable addresses in Australia. By understanding this country’s very structured address format, including specific idiosyncrasies such as required upper-case municipality addresses, state and territory abbreviations, and four-digit postal codes, you can automate much of the process of ensuring your contact data quality for this important international market.

In a previous blog, we discussed the benefits of using DOTS Address Detective – International to detect a contact’s country. This blog will discuss some of the challenges surrounding country detection in more detail, as well as provide an overview on how we determine the best country from your data.

Contact Components

When trying to append a country to a contact, we have four main components to examine.

1. Address
2. Phone
3. IP Address
4. Email

Each component must be carefully evaluated on its own merit before it can be used to help identify a country for the contact.

Address Component

The Address component may represent a contact’s physical location or mailable address. It is the most diverse and complex of all the components. International addresses do not follow a singular format, language or standard. Each country has its own set of rules and standards, which can also make the storage of international addresses problematic for US-centric CRMs.

This also means that is common for a contact’s address to be incorrect and/or incomplete. Additionally, some businesses are not always interested in capturing a mailable address and only wish to store a contact’s region. Depending on who is entering the contact address and how it is being stored, it would not be unreasonable to expect this data to be flawed in more ways than one.

Knowing the country is critical to processing most addresses. It determines the address format, which is needed to identify individual address elements, which in turn are needed to identify a locality, postal code or region. With that said, our sophisticated data-driven algorithms are not dependent on completeness and allow for a wide variety of formats and languages.

If you think you can identify a country’s address, take our fun, short Country Quiz.

Similar to the DOTS Address Validation International service, the address component consists of Address Lines 1-8, Locality, Admin Area and Postal Code. The address can be entered entirely in lines 1-8 or in combination with the Locality, Admin Area and Postal Code fields. Address line order does not matter, and common mistakes like putting an address value into the wrong address field are detected and handled.

Not all countries follow the US city-state pairing format or the equivalent locality admin area pairing. Many international addresses do not include an admin area, which can make country detection difficult since many localities from around the world can often share names. Take Venice, for example, which can be found in separate locations of three different countries.

Locality	Admin Area	Country
Venice	Venice	Italy
Venice	Alberta	Canada
Venice	California	USA
Venice	Florida	USA

If no other address information besides the name Venice was made available, one would be left having to choose between these three countries. However, by making use of other contact data such as a phone number, IP address and/or email, the service can cross reference various datasets to better determine which country is the best match. Then again, if the locality was entered as Venezia, the Italian endonym for Venice, there would be less ambiguity and the country Italy would be the clear choice.

Phone Component

The phone component consists of a contact’s phone number(s). The format of a phone number is dictated by its country’s numbering plan. Some countries have their own numbering plan, while others share one. The USA and Canada, for example, share the North American Numbering Plan (NANP), whereas the UK and its crown dependencies share the UK National Telephone Numbering Plan. Most countries conform to the E.164 International Telecommunication Numbering Plan, which is published by the International Telecommunication Union (ITU).

The E.164 Numbering Plan
The E.164 currently provides five number structures (numbering plans) for international phone numbers:

1. International ITU-T E.164-number for geographic areas.
2. International ITU-T E.164-number for global services.
3. International ITU-T E.164-number for Networks.
4. International ITU-T E.164-number for groups of countries.
5. International ITU-T E.164-number for trials.

Each structure has its own set of rules and requirements, but telephone numbers that conform to E.164, in general, will adhere to the following:

• The recommended maximum length for a telephone number is 15 digits.
• Telephone numbers will begin with a Country Code (CC).
• Telephone numbers will not include Prefixes and Suffixes

Country Codes
Country calling codes are published by the Telecommunication Standardization Bureau (TSB). Depending on which E.164 structure is being used the country code (CC) may vary between 1 to 3 digits or may be fixed to 3 digits. Country codes are followed by the destination number in accordance with the E.164 numbering plan. When storing a country code or an international (E.164) number, the number is commonly prefixed with a plus symbol (+) to indicate that when dialing the number, one must first dial the appropriate international call prefix to complete the call.

Prefixes
International call prefixes (also known as call out codes, dial out codes, exit codes or international access codes) are used to make a call from one country to another. The Prefix is dialed before the country code (CC) and the destination telephone number. Prefixes are not a part of the E.164 numbering plan and it is recommended to not include them as they can interfere with country code identification.

Making the Call
Suppose you have a contact in the UK with the following number saved in your CRM, ‘+44 123 456 7890 Ext. 123’, and you wanted to call this person from within the USA. To call them, you would dial 011441234567890, and then after you have been successfully connected you would next dial your contact’s extension of 123.

The table below shows how the prefix and suffix are not a part of an international number.

Prefix	International Number		Suffix
	Country Code	Destination Number
011	44	1234567890	Ext. 123

Now suppose that you wanted to call this contact again, but this time you are in Sweden and not in the USA. Instead of dialing the 011 prefix, which is shared by all countries in the North American Numbering Plan (NANP), you would dial 00 which is the prefix used by many countries in Europe.

At Service Objects, we understand that not all phone numbers will conform to an E.164 numbering plan and that many numbers will have missing country codes, which why our services make use of a wide variety of datasets and are flexible enough to intelligently identify a country.

IP Address Component

Not all companies capture a contact’s IP address, but when they do they are most likely capturing it via the web form the contact used to submit their information. The captured IP address and the location for that IP is often for the registered owner of the IP, so if the contact filled out a web form from their home computer then it is likely that the IP is for their Internet Service Provider (ISP). If they filled it out from their office computer, then the IP address may belong to the business or to the business’s ISP. IP based geolocation systems will commonly return a general location for the owner of the IP, which in most cases is the end user’s ISP.

There is often a misconception that IP based geolocation services will always return an end user’s exact location. For example, that the IP address assigned to a mobile smartphone can alone be used to pinpoint and track the phone’s exact location. This is simply not true. In most cases, IP based geolocation services will return the city and/or the metropolitan area for where the IP address is commonly served. Subscribers will generally be located within the serviceable area of their ISP, and so the IP based location can be used in confidence to identify the region of the end user.

Identifying Anonymous Users
If a contact used a Virtual Private Network (VPN) or Proxy connection, such as a Tor network, when filling out a form then that means that the end user’s true IP address was masked and it was not captured. Some users will make use of methods such as these to try and remain anonymous and prevent others from capturing their true IP address. These methods are not only used to mask a user’s true location, but they can also be used to make a user appear to be from somewhere they are not. This is commonly done to circumvent region locked sites and services, however not all VPN and proxy connections are used for this purpose. Many businesses make use of VPN and proxy connections to connect their employees, sites and services from various regions, including remote employees.

A service like DOTS IP Address Validation is capable of identifying proxy related IP addresses as well as IP addresses associated with malicious activity. By leveraging this data, the country detection algorithm can determine if the IP is trustworthy and if the IP based location is genuine.

Email Component

The email address component uses the contact email address to identify where in the world the mail servers are located. The location of the mail server should not be confused with the location of the mail sender; after all, one of the benefits of email is that you can send and receive it from just about anywhere an internet connection is available. This means that a contact may not necessarily be anywhere near where the mail server is located and could potentially reside in an entirely different country. It’s also worth noting that the domain name, including the Top Level Domain (TLD), can be misleading.

For example, let’s suppose we have an email with a domain that consists of Spanish words and the TLD country code for Spain (ES), like: ejemplo@una_palabra_espanola.es

While the above example email address may appear to be for a contact for Spain, the company could instead be hosted or even located in another country, such as the USA. Another possibility is that the company is located in one country and has their email handled by a provider in another. It is quite common for businesses to outsource email duties to specialized email providers.

Some domains have mail servers located in multiple countries and regions and are not tied to a single location. So, email addresses alone cannot be used to accurately and confidently identify a contact’s country, as doing so would be too far-reaching. However, the country or countries for the email component can be used in some cases to help identify a single country when used in combination with other contact data.

Which Country is Best

As you can see, each contact component is carefully analyzed to the point where a country may be singled out for each one, but the next step is to now determine which country best represents the overall contact. By taking the countries that are related for each component and carefully weighing their relevance as well as cross-examining them we can in many cases successfully identify the single best country that best exemplifies the contact.

As previously mentioned, contact components like the Address and Email can result in more than one country. The country detection algorithm takes all possible countries into account, so even though a single component may not have a clear country winner, a best match can be found between all the components. Some components have a stronger influence than others. For example, the IP address and email address components do not have as much influence as the address and phone components since they are not always directly related to where a contact resides.

In general, the more complete the contact information is, the more the country detection algorithm will have to work with, choosing a best overall country. However, even when a few contact components are available, the service will still be able to make do with the information it receives.

Is a mailing address the same as a physical address?

No, not always.

In general, a mailing address can often be the same as a street address, but this is not always the case. To understand why, we must first acknowledge that the two types of addresses are often defined and regulated by two separate authoritative entities that generally serve different purposes.

Different Purposes

A mailing address, or postal address, is often regulated by postal authorities that are commonly associated with services related to the sending and receiving of mail. For example, in the US this would be USPS. In the United Kingdom, Royal Mail. Deutsche Post DHL Group for Germany and JP Post or Japan Post (日本郵政 Nippon Yūsei) for Japan. These postal authorities can be public government agencies, like the USPS, or privatized companies like Royal Mail, Deutsche Post and JP Post- which were sold off by their governments.

A physical address, sometimes referred to as a street address, is used to describe where a place is geographically located. It often pertains to a geographic location under the jurisdiction of an administrative area or region that has some government function. The physical address should have a set geographic boundary that is recognized and governed by an administrative area. If an address resides in an incorporated area then its municipality is generally responsible for providing some public services, such as law enforcement, public schools, sanitation, water works etc. If an address resides in a rural and/or unincorporated area, then sometimes these services are provided by the governing state, territory, province, county etc. Sometimes certain services are not available at all.

Location, Location, Location

Where a physical address is geographically located will often determine what public and private services it has access to. For example, a rural address may not have access to readily available public transportation or high-speed internet, whereas an address in a metropolitan area likely would.

In the US, it is the job of the US Census Bureau (USCB) to collect and produce data about the people. Both public and private agencies rely on the various datasets produced by the USCB, such as geographic and demographic data, to help make informed decisions. The USCB produces various Topologically Integrated Geographic Encoding and Referencing (TIGER) datasets that are designed for use with Geographic Information Systems (GIS) and various mapping projects. TIGER products are spatial datasets used to describe geographic features such as boundaries, roads, address information, water features, as well as legal and statistical geographic areas.

TIGER products are widely used in many US related geolocation solutions, including our own DOTS Address Geocode US service, and are considered a standard when it comes to working with geographic locations and features in the US and its territories. TIGER data, along with other topological geographic mapping datasets, can be used to help geocode a physical address to varying degrees of accuracy.

Choosing the Right Route

Mailing address datasets are generally used to help facilitate and ensure the delivery of mail, and they are not necessarily one-to-one comparable with geographic datasets like TIGER. The main reason being that these datasets are intended to serve different purposes. Let’s take USPS ZIP Codes for example. USPS ZIP Codes are not geographic areas. They are a collection of mail delivery routes and they help identify individual post offices and delivery stations that are associated with mailing addresses.

ZIP Codes help the USPS determine the best route for delivering mail. It is not uncommon for a physical address, that is geographically located in one locality, to be assigned to a different locality in its mailing address. This is common for areas where a single post office or delivery station may serve multiple localities.

Not All Mailing Addresses Are Physical Addresses

Here’s an interesting example of an address that is physically or geographically located in one state of the US, but the mailing address has it listed as being in another.

Physical Address:
25777 Co Rd 103
Jelm, CO 82063

USPS Mailing Address:
25777 Co Rd 103
Jelm, WY 82063-9203

Using Google Maps to inspect the address and the surrounding area, we see that the location is near a state line, but the address is clearly in Colorado and not in Wyoming.

According to Google the physical address is approximately six miles from the Wyoming and Colorado state line. When we investigated other addresses in the area we found that they too had a mailing address that said they were in Wyoming.

When we reached out to USPS to inquire about the addresses they acknowledged that they were indeed geographically located in Colorado; however, their ZIP code is associated with a USPS Post Office located in Jelm, Wyoming and that is the reason why the mailing addresses are for Jelm, Wyoming and not Jelm, Colorado. It may be confusing to base an address’ location on where it’s post office is located, but logistically it makes sense for the postal authority, USPS.

It’s also not uncommon for some rural areas to use general delivery, where mail is not delivered to a recipient’s physical address and it is instead kept at a post office that the recipient will go to and pick it up. If the post office is located in a different locality, then the recipient’s mailing address would be different from their physical address.

Other examples of mailing addresses that are not physical addresses include:

• Post Office Box (PO Box) and Private Mailbox (PMB) – Many individuals and businesses use PO Boxes and Private Mailboxes as an alternative to their physical address. Postal Agencies like UPS offer PMBs as Personal Mailboxes, and while they do advertise that their PMBs include a street address it still is not the recipient’s physical address.
• Centralized Mailboxes – Also known as cluster mailboxes or community mailboxes, are basically a large communal mail box made up of multiple individual boxes clustered together. The mailing address for a centralized mailing box does not have to reflect the recipient’s physical address as each box in the cluster will have its own unique identifier.
• Unique ZIP Codes – These are ZIP codes that are assigned to some single high-volume addresses such as universities, government agencies and some large businesses. Postal carriers will deliver mail to the organization’s mail department, and it then delivers the mail to the final destination which may be in an entirely different geographic location.
• Military Addresses – Are used to route mail for military mail services, such as the US Military Postal Service (MPS), the British Forces Post Office (BFPO) and the German Armed Forces (Feldpost). Civilian postal carriers deliver mail to military post offices which then perform the final delivery.

Which Address to use

For some people, their physical address is the same as their mailing address and when asked for their address they don’t have to worry about which address to give because they are both the same. For others who don’t have matching mailing and physical addresses, some consideration is needed. If the purpose of the address is to send mail to it, then the mailing address should be given. If the address is needed to locate where a place is geographically located, then the physical address is needed.

The answer should be clear but sometimes there are misconceptions and confusion and on the behalf of the party requesting the address. The party asking for the address may simply be unaware that not all mailing addresses are physical addresses and that not all physical address have mailing addresses. If the intent on how an address is to be used is not made clear, then the person giving their address could potentially give the wrong one if the two are not the same. Sometimes the person giving the address will be sure to specifically ask if they want the mailing address or the street address, but the party asking may be unaware of the difference and inadvertently ask for the wrong one.

Shipping Address and Physical Address

There can also be some confusing cases when it comes to the terms billing address and shipping address. Likely, the billing address will be a mailing address, but what about the shipping address? Let us suppose that a customer wants to have a package delivered to their doorstep. They want to enter their physical address, but they know that USPS does not deliver mail to their physical address. However, they do know that UPS does deliver to their door, but they are not sure about FedEx. If the site they are purchasing from gives them the option to choose the shipping carrier then that helps, but if it doesn’t then which address do they choose to give? Worse yet, what if the customer is unaware that their physical address is undeliverable?

Helpful Tools

When businesses and organizations work with addresses it is important to know where they are located and if they are valid and deliverable. Otherwise, they risk making uninformed decisions that can end up wasting valuable resources like time and money and damaging customer relationships. That is why Service Objects provides various address related products to help prevent mistakes and reduce waste. Our services can quickly correct and standardize address to help determine where they are located and if they are valid and deliverable.

Feel free to test drive any of our Address products and see how we handle these scenarios.

Our DOTS Phone Exchange can validate both domestic and international phone numbers. In this article, we will focus on validating international phone numbers using the operation, GetInternationalExchangeInfo. This operation parses a given international phone number to determine the validity of its telephone exchange. The resulting outputs also include geographic location and carrier information when available. Use of this operation helps determine the overall validity of a phone number and returns a standardized format along with other information about the line-type. Many countries have distinct numbering plans, formats, and rules. This operation verifies that each number conforms to those rules and confirms regional validity. 

To get started, the following GetInternationalExchangeInfo inputs are recommended:

Name	Type	Required?	Description
PhoneNumber	String	Yes	The phone number to be parsed, validated and formatted. The phone number may include extension as well. If no country is provided, the country code should be provided in the phone number.
Country	String	No	The Country format to be validated using the provided phone number. Acceptable Country formats include ISO2 (preferred), ISO3, full country name, variant of full country name, and IP of the phone number’s collection region.
LicenseKey	String	Yes	Your license key to use the service. Sign up for a free license key.

Although Country input is not required, we highly recommended it. The Country input helps the service validate the phone number according to the rules and format of the given country. Making it easier to parse the number and make possible corrections. Without the Country input, the service does its best to find a country that matches the given number; however, some countries share numbering plans and formats, which can lead to ambiguities.

Outputs from Phone Exchange

The operation output consists of a response container and three complex child objects:

Response Objects Container:

• InternationalExchangeInfoResponse

Child Objects:

• InternationalExchangeInfo – contains useful information about the number, such as line type, validity, and geographic location details. The developer guide includes a full list of output fields and descriptions. NOTE: If an Error object is returned, then expect this object to be null.
• Error – returned if a problem occurs. Specific error types and descriptions are returned and handled accordingly.
• Debug – primarily used for internal use by Service Objects, but in some special cases, a client request may enable it to help troubleshoot client-specific issues.

Below is an example of the response XML body:

Example of the response JSON body:

 

Handling the Response Output from Phone Exchange

When calling the service, first check for errors and handle them appropriately. There are four different error types, which are listed below.

Error Type	TypeCode
Authorization	1
User Input	2
Service Objects Fatal	3
Domain Specific	4

Please refer to the developer guide for a complete list of errors and their descriptions.

Error type 1: Authorization

Authorization errors indicate a problem with the given license key. License key expiration and exceeding maximum transaction threshold triggers Authorization errors. Authorization errors indicate a license key is no longer authorized to process transactions. These types of errors cannot be resolved on their own and require the license key owner to contact Service Objects to reauthorize their license key or increase their maximum transaction threshold. The most common Authorization errors occur when first integrating the service or when a user tries using the wrong license key.

Error type 2: User Input

User Input errors occur because of a wrong input, like a missing PhoneNumber or LicenseKey input value.

Error type 3: Service Objects Fatal

These errors occur when the service encounters an unexpected error that causes the application to fail. If you encounter a fatal error, please report it to Service Objects support team, along with any pertinent details, such as the request date and time, the operation name and the input values. Fatal errors should be infrequent, so please report them so that the support team can investigate and fix any potential issues.

Error type 4: Domain Specific

These errors show that despite successful processing of the request, a problem occurred. For example, a phone number entered with a missing a country code, or a value that does not appear to be a valid phone number. Most domain-specific errors for the GetInternationalExchangeInfo indicate a problem with the phone number and notifies the user that it is likely invalid. Refer to the developer guide for a list of domain-specific errors and be sure to handle each one appropriately.

InternationalExchangeInfo Object

If no errors are returned, then you may start using the InternationalExchangeInfo object to get details about the phone number, like country, locality and line type. We recommend first checking the following two output values before any others in the InternationalExchangeInfo object:

Name	Type	Description
IsValid	Boolean	A boolean response type determining whether the phone number is a valid phone number.
IsValidForRegion	Boolean	A boolean response type determining whether the phone number is a valid phone number for the provided Country.

If the phone number is found to be invalid, you can save yourself time by immediately rejecting it. If the number is valid, then start making use of the other output values as they pertain to your needs. The complete list of outputs can be seen below:

Name	Type	Description
PhoneNumberIn	String	The phone number that was provided as input.
CountryCode	String	The country code of the provided phone number.
FormatNational	String	The provided phone number in a national format.
Extension	String	The parsed extension from the provided phone number.
Locality	String	The locality from where the phone number belongs. The locality format is generally Locale/Region, Region or Country.
LocalityMatchLevel	String	The match level that was determined from the locality that was found. Possible values include (Locale/Region, Region, Country) match.
TimeZone	String	The Time Zone of the validated phone number.
Latitude	String	The latitude of the locality determined from the phone number.
Longitude	String	The longitude of the locality determined from the phone number.
Country	String	The country to which the validated phone number belongs.
CountryISO2	String	The ISO 2 character country designation for a validated phone number.
CountryISO3	String	The ISO 3 character country designation for a validated phone number.
FormatInternational	String	The provided phone number in international format.
FormatE164	String	The provided phone number in E.164 format.
LineType	String	The linetype determined for the phone number. See InternationalExchangeInfo LineType table.
SMSAddress	String	The SMS gateway address for the provided mobile number.
MMSAddress	String	The MMS gateway address for the provided mobile number.
IsValid	Boolean	A boolean response type determining whether the phone number is a valid phone number.
IsValidForRegion	Boolean	A boolean response type determining whether the phone number is a valid phone number for the provided Country.
NoteCodes	String	The corresponding codes which match NoteDescriptions. These values vary from 1 to 6 based on test results. See NoteCode table below.
NoteDescriptions	String	The corresponding descriptions which match NoteCodes. These values vary based on NoteCodes. See NoteCode table below.

Geographic information about a number is useful, as is knowing if the line type is mobile, fixed (landline) line or Voice Over IP (VOIP) line. As always, please refer to the developer guide for the complete list of outputs and descriptions.

When in doubt – reach out!

Hopefully, this overview provides a strong understanding of how you can use the operation, GetInternationalExchangeInfo, to validate and standardize international phone numbers. If you are looking to validate and standardize US and Canadian phone numbers, we recommend the GetExchangeInfo operation.

As always, our experienced staff is ready to help, so please do not hesitate to reach out. We would be happy to answer any questions and offer best practices for using our service.

For companies who deal with users in the United Kingdom, this reference guide can help you better understand how UK addresses are formatted and what makes an address valid.

The United Kingdom: Three Nations, One Province, 29 Million Addresses

The United Kingdom of Great Britain and Northern Ireland – commonly referred to as Britain, the United Kingdom, or simply the UK – is made up of three nations and one province: England, Scotland, Wales, and Northern Ireland. There are approximately 29 million known deliverable addresses in the UK, with over five thousand addresses being added and removed monthly.

International Country Code

The International Organization for Standardization (ISO) published the ISO 3166 standard, officially known as Codes for the representation of names of countries and their subdivisions.

The ISO 3166 standard consists of three parts:

Part 1: ISO 3166-1	Country Codes – defines codes for the names of countries, dependent territories, and special areas of geographical interest.
Part 2: ISO 3166-2	Country subdivision code – defines codes for the names of primary subdivisions of a country, such as a state or a province.
Part 3: ISO 3166-3	Code for formerly used names of countries – defines codes for country names that have been removed from ISO 3166-1.

 

ISO 3166-1, which defines country codes, contains three sets of country codes:

ISO 3166-1 alpha-2:	Defines a country as a two-letter country code, commonly referred to as the ISO, ISO2, or ISO-2.
ISO 3166-1 alpha-3:	Defines a country as a three-letter country code, commonly referred to as numeric-3, ISO3, or ISO-3.

 

ISO 3166-1 Country Codes – United Kingdom

ISO 3166-1 alpha-2 code	ISO 3166-1 alpha-3 code	ISO 3166-1 numeric code
GB	GBR	826

Note that the alpha-2 code is GB and not UK.

 

ISO 3166-2 Country Codes

In the ISO, England, Scotland, Wales, and Northern Ireland are not included in the ISO 3166-1 country list and are instead listed as subdivisions of GB in ISO 3166-2. However, their subdivision description is that of “country,” except for Northern Ireland, which is described as a “province.”

ISO 3166-2 code	Subdivision Name	Subdivision category
GB-ENG	England	Country
GB-SCT	Scotland	Country
GB-WLS	Wales	Country
GB-NIR	Northern Ireland	Province

 

UK vs. GB Country Code – FIPS vs. ISO 3166-1

The United States Federal Government developed the Federal Information Processing Standards (FIPS) for use in computer systems by non-military government agencies and government contractors. Country codes are defined in the FIPS 10-4 standard, where the United Kingdom is listed as UK and not GB. However, where the FIPS 10-4 codes where defined for use in computer systems, the standard has been dropped by many institutes and agencies in preference to ISO 3166-1, making ISO 3166-1 alpha-2 the global standard.

Postal Services

Mail in the United Kingdom is primarily handled by Royal Mail. Royal Mail was established in 1516 by King Henry the VIII, and it was government owned for 499 years. There are other mail delivery services available in the market, but many of them use Royal Mail for the last mile delivery.

Address Format

The address format for mail delivery in the United Kingdom is defined by Royal Mail, where an address is made up of four elements. The elements should appear in the following order:

Address Element:	Address Example:	Element Names:
Premise	Royal Mail Flat 9, Wheatstone House	[Organization] [Sub-Building], [Building Name] [Building Number]*
Thoroughfare	47* Gorse View School Road	[Dependent Thoroughfare] [Thoroughfare]
Locality	Southampton Knodishall Saxmundham	[Double Dependent Locality] [Dependent Locality] [Post Town]
Postcode	SWA1AA	[Postcode]

*NOTE: Although the building number appears with the thoroughfare, it is part of the Premise element.

Premise Elements

A mailing address premise is made up of the following elements:

Order	Premise Element Name	Description	Example
1	Organization	The name of the organization, and when necessary the name of the department within the organization, which is registered to the delivery address.	Royal Mail
2	Sub-Building	This is also known as a sub-premise, such as an apartment, flat, or suite.	Flat 9
3	Building Name	The name of the building of the business or residence.	Wheatstone House
4	Building Number	Also known as the premise number or address number, this number identifies the premise on the thoroughfare or dependent thoroughfare.	47

 

Not all elements are required, but enough must be given to identify a single unambiguous delivery point. Also, note that while the building number is a part of the premise element, it must be applied on the same line as its corresponding thoroughfare.

Thoroughfare Elements

A thoroughfare premise is made up of the following elements:

Order	Thoroughfare Element Name	Description	Example
1	Dependent Thoroughfare	Distinguishes a premise when a thoroughfare appears more than once in a post town.	Gorse View
2	Thoroughfare	This is also known as the street or road.	School Road

 

Royal Mail defines three thoroughfare address possibilities:

1. Thoroughfare without a dependent thoroughfare – When an address does not include a dependent thoroughfare, the element is to be omitted.
2. Thoroughfare with a dependent thoroughfare – When an address contains both elements, Royal Mail instructs that the dependent thoroughfare is required and the thoroughfare is optional.
3. No Thoroughfare – Not all addresses contain a thoroughfare, in which case the thoroughfare element is simply omitted.

Example:

Her Majesty the Queen
Buckingham Palace
London
SW1A 1AA

Locality Elements

The mail address Locality is made up of the following elements:

Order	Locality Element Name	Description	Example
1	Double Dependent Locality	Distinguishes a premise when an address thoroughfare appears more than once in the same post town and dependent Locality.	Southampton
2	Dependent Locality	Distinguishes a premise when an address thoroughfare appears more than once in the same post town.	Knodishall
3	Post Town	Also known as the Locality; however, the post town represents the postal delivery Locality and not necessarily the geographic Locality.	Saxmundham

 

Other aspects of Locality elements you should be aware of:

1. The Post Town is required.
2. The initial letter of the Post Town must always be capitalized.
3. The Post Town may be written in all capital letters (uppercase). It is the only Locality element where this is allowed.

Postcode

The postcode is made up of the following elements:

Order	Element Name	Description	Example
1	Postcode	Also known as a postal code, this is an alpha-numeric code that is associated with one or more addresses along one or more thoroughfares.	SW1A 1AA

 

The postcode must be written in all capital letters (uppercase) and must be the last address element. Royal Mail recommends that the postcode be listed as a singular element on the last line of the address; however, it may be preceded by either the county or post town on the same address line when separated by a space or on the preceding line.

Regarding County

Though the geographic county of an address is not required, according to the Royal Mail website regarding the inclusion of county, “you are welcome to do so.” However, the issue of listing geographic counties and postal counties has been the cause of some confusion over the years. Counties were removed from the address elements in the early 2000s, and they are no longer officially supported. This was due, in some part, to the boundaries of postal counties and geographic counties not matching up, so an address in one geographic county would be listed in a postal county of a different name.

Postcode Overview

The postcode is an alphanumeric code of varying length that is composed of two codes called the outward code and inward code. It ranges from six to eight characters in length with a single space to separate the two codes. A postcode may represent a group of addresses on a street or on a part of a street, a group of premises, or a single premise. On rare occasions, it may also represent a group of addresses on more than one street.

Postcode Format

Outward code

1. Postcode area
2. Postcode district

Inward Code

1. Postcode sector
2. Postcode unit

For example, in the postcode “SW1A 1AA” we have the following:

Name	Example
Postcode	SW1A 1AA
Outward code	SW1A
Postcode area	SW
Postcode district	SW1A
Inward code	1AA
Postcode sector	SW1A 1
Postcode unit	AA

Outward Code

The outward code represents the first half of the postcode that precedes the single space separator. It is made up of the postcode area and postcode district. The length of the outward code is between two and four characters.

Postcode Area 

The postcode area is an alpha code that is one or two characters in length. The code commonly represents a geographical area. For example, “SW” represents London, “AB” is commonly Aberdeenshire, “BS” is often Avon, and so on.

Postcode District 

The postcode district is the postcode area plus an alphanumeric code, essentially making it the outward code.

Inward Code

The inward code represents the second half of the postcode, immediately following the single space separator in the middle. It is three characters in length. The inward code is used to assist in the delivery of mail within a district.

Postcode Sector 

The postcode sector is between four and six characters in length. It begins with the outward code, followed by the single space separator, and ends with the first digit of the inward code.

Postcode Unit 

The postcode unit is an alpha code that is two characters in length. In addition to representing a group of addresses, the postcode unit may also represent a unique premise, an individual organization, or even a subsection/department of an organization. Postcode unit level designation cannot be purchased; it is determined by the amount of mail received by the premises or organization.

Special Postcodes

Royal Mail will assign postcodes to some high-profile organizations such as banks and telecoms, as well as non-geographic postcodes for assignment to PO Boxes and direct marketing. It will also assign postcodes to crown dependencies, overseas territories, and HM British Forces.

Crown dependencies

The crown dependencies are three self-governing island territories off the coast of Britain for which the United Kingdom is responsible. However, they are not a part of the United Kingdom or its territories. These islands have adopted the UK postcode format.

Name	Postcode area
Guernsey	GY
Jersey	JE
Isle of Man	IM

Overseas Territories

There are 14 overseas territories in the United Kingdom. They may be commonly referred to as British Overseas Territories or the United Kingdom Overseas Territories. These territories are mostly self-governed, and some have developed their own postal codes, such as Bermuda, the Cayman Islands, the British Virgin Islands, and Montserrat.

British Forces Post Office

The British Forces Post Office (BFPO) and Royal Mail use the non-geographic postcode area “BF” to represent a BFPO address.

Address Validation International: Overcoming Cultural Idiosyncrasies and Postal Format Variables

The above content provides a general overview of addresses in the United Kingdom. Understanding all the ins-and-outs of UK addresses can be a monumental task on its own. In addition, the ever-changing list of addresses, postcodes, and regulatory boundaries involved can make for a very dizzying array of challenges. Fortunately, the DOTS Address Validation International real-time service is capable and robust enough to handle various address formats and cultural idiosyncrasies. As always, our experienced staff is here to help, so please do not hesitate to reach out to us! We would be happy to answer any follow-up questions you may have and make recommendations on how to interpret and use the results from the service.

 

 

 

You say tomato, I say tomahto.
You say Rome, I say Roma.
You say Munich, I say München.
Let’s Not call the whole thing off.

Have you ever wondered why the country code and abbreviation for Germany is DE, or similarly why it is ES for Spain? Unlike FR and CA, which are France and Canada respectively, DE and ES seem out of place for Germany and Spain. A simple explanation is that DE is short for Deutschland and ES is short for España – which are the names used locally for these countries.

Local names such as Deutschland and España are known as endonyms, and Germany and Spain are English language exonyms. You may be wondering, what are endonyms and exonyms? To put it simply, endonyms are the names of places used by the locals and exonyms are the names used by foreigners. So an endonym is what a country calls itself, and an exonym is the name used by other countries.

(As another example, United States is an endonym for, well, the United States. Meanwhile, exonyms for the United States will depend on the country involved: the French call us the États Unis and the Russians call us Соединенные Штаты.)

The DOTS Address Validation International (AVI) service currently offers three output language options to let the end user choose their preferred language setting and behavior: ENGLISH, BOTH (English and local addresses), and LOCAL_ROMAN. Let’s examine each of these in detail:

ENGLISH – Instructs the service to return the address in English, without any localized text or accents.

BOTH – Instructs the service to return a standardized address in both English and in its localized text (e.g., Cyrillic, Chinese, etc.) and format when applicable.

Here’s an example of a Chinese address in both English and in its local Chinese text.

Address input in English

No. 1514 Changyang Lu
Yangpu Qu, Shanghai Shi

Address output in Simplified Chinese

上海市杨浦区长阳路1514号

 

Here’s an example of a Russian address in both English and Cyrillic.

Address input in English

Kommunarov Ul, 290, 9
Krasnodar
Krasnodarskiii Kraii
350020

Address output in Cyrillic

Коммунаров ул, д. 290, OFFICE 9
КРАСНОДАР
КРАСНОДАРСКИЙ КРАЙ
350020

 

One last example, this time in Greece.

Address input in English

Alkamenous 76
104 40 Athens

Address output in Greek

104 40 Αθηνα
Αλκαμενους 76

 

LOCAL_ROMAN – Instructs the service to return the address in its local spelling using Roman text.

For example, the city of Rome will be returned as Roma, Naples as Napoli, Dublin as Baile Átha Cliath, Naestved as Næstved, and Cologne as Köln. Let’s take a look at some address examples.

Here’s an example of an address in Italy.

Address input in English

Via Villafranca 20
00185 Rome RM

Address output in Italian

Via Villafranca 20
00185 Roma RM

 

Example of an address in Denmark

Address input in English

Kobmagergade 20
4700 Naestved

Address output in Danish

Købmagergade 20
4700 Næstved

 

Example of an address in Germany.

Address input in English

Weisshausstr. 20-30
50939 Cologne

Address output in German

Weißhausstr. 20-30
50939 Köln

 

The service also has the ability with some countries to accept an address in its localized spelling and text and return the address in English. Try entering any of the address examples above into the AVI service using the local language, spelling, and format with the output language set English to see the address validated and standardized into English. When submitting an address in a non-English language, be careful to ensure that the text is properly encoded.

The AVI service cannot correct corrupted characters, so it is important to ensure that anything that will hold the address in memory and stores the data can support the character set. Otherwise, you will end up with data corruption, which is not always easy to detect or fix.

For example, in some cases, a character may simply come back as a question mark ‘?’ or a square ‘■’. Take the following address.

Weißhausstr. 20-30
50939 Köln

The fourth character of the first line and the eighth character of the second line will come back corrupted, as follows:

Wei■hausstr. 20-30
50939 K?ln

 

In other cases, the corruption can be quite severe, and you may end up with something like ‘تخت اره ÙŠÚ©’. Not only is it important to ensure that you do not send any corrupted data to the AVI service, but you also want to make sure that you properly handle and store the service response. Otherwise you may end up corrupting an address after it has been validated. (How this happens would make a good topic for another blog, but for now, just make sure to use the Unicode Transformation Format (UTF) on everything that handles the data.)

Each of these options gives you the flexibility to have a consistent addressing format for your international addresses, depending on your location, your customers, and your mailing conventions. All of them provide an automated, consistent approach to address validation. Whether it is addressing mail to customers in the format of their home countries, translating addresses, or ensuring readability for the sender, DOTS Address Validation International truly speaks your language.

We love data here at Service Objects. We are constantly working to expand and improve on our datasets to further innovate our product lineup. A big part of what makes our Email Validation (EV) service so good is the data that helps drive it. When communicating with a mail server in real-time to verify an email address it helps to know what kind of mail server it is dealing with and if it is trustworthy. Just because an email address is deliverable does not always mean that it is good.  For example, an email may be disposable, vulgar or worse yet, a spamtrap.

Our Email Validation service already keeps track of mail server behavior patterns for millions of domains, which allows us to identify and flag mail servers with malicious activity or servers that have a high association with malicious activity.  In addition to monitoring behavior patterns, we are now focusing on determining the geographic location of the email servers.

What benefits does identifying mail server location offer?

Email addresses can be sent and received from anywhere in the world. They are not anchored to one physical location, and at a glance, one cannot easily discern its geographic origin. Even email addresses with a country code for a Top Level Domain (TLD) can have a global presence and may have servers located in multiple countries.  Fortunately, mail server location data can be derived and aggregated from some of our other datasets. This allows our Email Validation service to better identify potentially malicious mail servers and flag servers from known geographic hot spots.

In addition to helping identify problematic email servers, mail server location data can provide additional insights and benefits. From a marketing and administration perspective, the mail server location data can be used to help identify and organize email addresses for a particular region. The location information can also be used to gain business insights about a company and its location(s). At Service Objects, we are using the additional information to further enhance some of our other services, such as Lead Validation.

Challenges to identifying mail server location information

There are a number of challenges to accurately identifying mail server location information. First, we are identifying the mail server locations of a domain, not attempting to identify where an email message was sent from. This would require more than just a simple email address. However, the location data can be used to help cross-check and verify the legitimacy of an email message. For example, an email message is received, and the headers say that the message was sent from Gmail.com. However, the server IP address in the header does not match any of the known Gmail mail server locations, so chances are the message was spoofed and that it is spam or part of a phishing scam.

Second, trying to identify all of the mail servers for a particular domain is not something that can be done quickly enough for a real-time service where end-users expect sub-second response times. Real-time communication with a mail server can often take several seconds, but trying to identify all the mail servers for a domain from around the world can sometimes take several minutes. For this reason, our DOTS Email Validation service does not include mail server location identification in its suite of real-time checks. Instead, the service relies on background systems that have already collected and identified mail server locations from around the world. This ensures that the service is not bogged down by slow processes and continues to respond normally. While mail server location identification may be too slow for a real-time check, it is a daily process that we perform to ensure our list of locations is up to date. The process is also quick enough that our background processes can routinely check for any new domains that we have not come across before and process them hourly.

Third, if a business has multiple locations, then a typical DNS lookup for a domain will just tell you which mail server(s) to connect to that are closest to your area, and not necessarily tell you about their other mail servers. DNS does this to help ensure that communication is quick and efficient, that way an end-user isn’t trying to communicate with a server on the other side of the country or potentially in a different nation entirely if it doesn’t have to. Part of what makes the location identification process “slow” is that we are looking for mail servers in every major region of the world, and not just in our own local areas.

What’s going on behind the scenes

While our email validation service will currently only display the location(s) of the mail server(s) in the notes of the output when it has been identified, it is doing a lot more with that data behind the scenes. Knowing the IP Addresses and locations of the mail servers means that we can perform cross-checks against more data points in other areas. Service Objects is extremely interested in fraud prevention, so we use this data to check for associations with known proxies, VPNs, bot services and other data points that have ties to malicious activity. The data allows us to check various data driven blacklists and white hat resources against more than a simple email address and domain.  Instead, we can pull back the curtain, so to speak, and dig deeper into the mail server(s) that run behind the scenes. All, while continuing and expanding our server behavior monitorization.

With the addition of this new data, we have added additional NoteCodes to the output from our DOTS Email Validation 3 service. Below is a list of the new notes codes and that have been added:

Code	Description	Example
11	Countries: The ISO2 country code for the country where the mail server(s) is located. If mail servers are found in more than one country, then all country ISO2 codes will be represented in a pipe-delimited list.	JP
12	Region: The region in the country where the mail server(s) is located. The region is commonly returned as a two-character abbreviation. If mail servers are found in more than one region then the value will be a pipe-delimited list of the regions.	OS|TY
13	Localities: The name of the locality where the mail sever(s) is located in. If mail servers are found in more than one locality then the value will be a pipe-delimited list of all the localities.	Osaka|Tokyo
14	PostCodes: The post code of where the mail server(s) is located. If multiple post codes are found, then the value will be a pipe-delimited list.	543-0062|102-0082

 

For more information about terms for international addresses and locations please check out this previous blog post.

Unlike other NotesCodes where the corresponding NotesDescriptions value will be a human readable flag to describe the note code, the value will instead contain the list of locations found.

Get started testing DOTS Email Validation by downloading a real-time API trial key or sending is a sample list to run for you.

The DOTS Email Validation 3 (EV3) service has been designed to be robust enough to accommodate the particular needs of a detailed oriented programmer and simple enough to be used by a marketing assistant who needs to run an email campaign. The service can meet various needs that can essentially be narrowed down to two use cases, form validation and post-processing jobs such as batches and database hygiene. Before we discuss those two cases we will first go over the recommended service operation and review some of the important result fields.

Which Operation Should I Use?

The recommended service operation for EV3 is the ValidateEmailAddress method. This operation performs real-time server-to-server email verification. It lets the user specify a timeout value, in milliseconds, for how long it can take to perform real-time server checks. A minimum value of 200 milliseconds is required; however, results are dependent on the network speed of an email’s host, which may require several seconds to verify. Average mail server response times are approximately between 2-3 seconds, but some slower mail servers may take 15 seconds or more to verify.

Please note that the above information is also available in the service developer guide.

Understanding the Results

The service returns many results that can be used to meet a programmer’s particular email validation needs, but the easiest way to determine if an email should be accepted or rejected is by looking at either the IsDeliverable value or the Score value.

Score:

For most cases it is recommended to use the Score along with other output values to cater to your particular needs. Here are the possible score values.

Score	Description	Notes
0	Email is Good	Indicates with high confidence that the email address is deliverable and good. The email address was verified with the host mail server and no malicious warnings were found.
1	Email is Probably Good	Indicates that the email is deliverable but one or more lesser warnings were found. For example the email may be a potential alias or a role, which are sometimes used as disposable addresses.
2	Unknown	Indicates that not enough information was available to determine deliverability and integrity. Unknowns most commonly occur for slow mail servers that do not respond to the web service in time. They also occur for catch-all mail servers and greylists.
3	Email is Probably Bad	Indicates that one or more warnings were found, such as a potential vulgarity or a string of garbage-like characters.
4	Email is Bad	Indicates with high confidence that the email address is bad and/or undeliverable. Occurs for email addresses that fail critical checks such as syntax validation and DNS verification. Most commonly occurs for email addresses where the actual host mail server verified that the email does not exist. Also occurs for deliverable email addresses that are known spam traps or bots.

IsDeliverable:

The simplest way to use the service is to look at the IsDeliverable field. This field will return true, false or unknown. If your primary concern is to be able to send out email with the lowest possible chance of a hard bounceback then this field alone will suffice. However, this field does not take spamtraps, vulgarities, bots or other factors into consideration. It simply indicates if the service was able to verify the deliverability of an email address with the host mail server. It does not measure the overall integrity of the email address.

If you choose to only look at one result value then it is our recommendation that you use the Score value instead of the IsDeliverable value. The Score evaluates the overall integrity of the email address and not just its deliverability. Either one of these fields can be used in conjunction with other result values to more intelligently evaluate an email address if the need arises. For example, if an email comes back as unknown in either the Score or in IsDeliverable, then we can refer to the following outputs to help us decide if we should accept, reject or retry the email address.

IsSMTPServerGood:

Returns true, false or unknown to indicate if the email’s host mail server was responsive at the time of the check. This is a one of the service’s critical checks. If this value comes back false then it will be reflected in the IsDeliverable value and in the score. Refer to this value if the email is unknown. If the value for this field is also unknown then the service most likely did not have enough time to finish verifying the email address with its host mail server. In these cases the service will continue to try and verify the email in a background process even though the request has finished. Chances are high that if you wait one or more hours and check the email again that the service will have been able to finish verifying the email addresses with the host mail server.

IsCatchAllDomain:

Returns true, false or unknown to indicate if the email’s host mail server is a catch-all. A catch-all mail server will say that an email address is deliverable even if it is not.  This is because catch-all mail servers do not reject email addresses during the initial SMTP session. This means that a catch-all mail server cannot be trusted to verify the deliverability of an email address because it may or may not reject the email address until after an email message is sent. If an email address is unknown and this value is false then chances are good that if the email is checked again at a later time then the service will have verified its deliverability. If catchall is true and there are no warnings, then we know that the mail server is good and that the email does not appear to be bad. In general this scenario leads to a 55% chance that the email is deliverable and won’t result in a hard bounce.
IsSMTPMailBoxGood:

Returns true, false or unknown to indicate if the service was able to verify the email address with its host mail server. This value can be treated similarly to the IsDeliverable value. A true value indicates that the email address is deliverable. If the value comes back false then the mail server verified that the email is undeliverable. A false will be accompanied by the warning flag, ‘Email is Bad – Subsequent checks halted.‘ Some common reasons why this value will return unknown; the mail server is a catch-all, the service ran out of time when communicating with the host mail server or the host mail server used a defensive tactic such as a greylist.

A complete list of the output fields and values are available in the service developer guide.

The result fields given above are useful when it comes to sorting, grouping and filtering all of your validated email addresses. This is useful when working on a post-processing email job, which we will discuss later. Next, we will look at some of the descriptive flags that the service will return. These flags can be used programmatically or at a glance to determine the status of an email address.

Warning Codes & Descriptions:

There are many warning flags that the service may return but we will look at some of the more common and critical ones.

DisposableEmail, SpamTrap, KnownSpammer and Bot

An email address may be deliverable but if one or more of these warning flags is returned then it is highly recommended to reject it.

Alias, Bogus and Vulgar

If one of these warning flags is returned then you may want to either reject the email or set it aside for later review, depending on how strict you want to be.

InvalidSyntax, InvalidDomainSpecificSyntax and InvalidDNS

These are warnings for critical checks that failed. If one of these flags appears then it will be immediately followed by the warning flag ‘Email is Bad – Subsequent checks halted.‘

Email is Bad – Subsequent checks halted

This warning indicates that the email failed a critical check and is undeliverable. If the flag is not preceded by one of the critical warning flags then it simply means that the email’s host mail server verified that the email address is undeliverable.

A complete list of warning codes and their descriptors are available in the dev guide.

Note Codes & Descriptions:

The note flags will return descriptive information about the email, not all of which will affect the score, but we will focus on the ones that will explain why some email addresses came back as unknown.

GreyListed

The service is good at detecting greylist behavior from mail servers and has procedures in place to avoid them, but not all greylists are avoidable. If the service encounters a greylist then it is temporarily unable to verify the email address with its host mail server. If you encounter a greylist then chances are good that if you try to validate the email again a couple of hours later that you will get a better response.

MailServerTemporarilyUnavailable

This flag indicates that the service was able to connect to the email’s host mail server, but that the server was temporarily busy or unavailable and it was unable to verify the email for us. If you encounter this flag then try and validate the email again a few of hours later to see if the server becomes more responsive then.

ServerConnectTimeout

This flag indicates that the service was unable to establish a connection with a host mail server. A possible reasons for the connection failure could be that the mail server is completely offline or it is responding too slow and unable to respond in time. Some mail servers are configured to commonly respond slowly, taking as long as 60 seconds to respond to a connection. This behavior is rare but it is not entirely uncommon. If an email returns this flag then try and enter a longer timeout time to allow the service the time it needs to verify the email.

MailBoxTimeout

This flag indicates that the service was unable to finish verifying the email address with the host mail server in the time allowed. The mail server could be responding very slowly or the timeout time given to the service was too short. If an email returns this flag then try and enter a longer timeout time to allow the service the time it needs to verify the email.

A complete list of note codes and their descriptors are available in the developer guide.

Use Case 1 – Using Validate Email Address for Form Validation

The ValidateEmailAddress method has four input fields that are all required.

Input Field Name	Description	Notes
EmailAddress	The email address you wish to validate.
AlowCorrections	Accepts true or false. The service will attempt to correct an email address if set to true. Otherwise the email address will be left unaltered if set to false.	The majority of the email corrections are being performed on the domain. The local part of the email address, the portion before the @ symbol, is generally left untouched.
Timeout	Accepts an integer as a string. Timeout time is in milliseconds. Do not include any commas or non-numeric values. This value specifies how long the service is allowed to wait for all real-time network level checks to finish. Real-time checks consist primarily of DNS and SMTP level verification. A minimum value of 200ms is required.	When it comes to form validation it is recommended to use a timeout time that is short enough to not keep your user impatiently waiting, but long enough to allow the server-to-server communication time to finish. A relatively short timeout time between 2 to 4 seconds is generally recommended.
LicenseKey	Your license key to use the service.

Accept, Reject or Review & Retry

ACCEPT

Emails with a score of 0, 1 or 2. In general it is recommended to not be too strict when accepting emails in a form because you do not want to potentially lose an end user.  Also, when performing form validation an end user may become agitated if they have to wait more than 5 seconds for the validation process to complete, but some slow mail servers may not be able to respond in that short amount of time.

REJECT

Emails with a score of 3 or 4. If you do not want to be too strict then you can accept 3 for review, but you should always reject an email that receives a score of 4.

REVIEW & RETRY

Depending on how strict/cautious you want to be you can choose to not initially accept emails with a score of 2 and instead put them aside to have them reviewed. If the IsCatchAllDomain field is not true then you can try and validate the email again later. Email addresses that return a score of 3 can also be set aside for review if you do not want to initially reject all of them. An email will commonly be given a score of 3 if a potential vulgarity or string of garbage characters is found.

In form validation the programmer is sometimes allowed some luxuries while others are taken away. For example, a programmer can be given the opportunity to communicate a result back to the end user but is usually restricted to a shorter timeout time so that the end user is not kept waiting too long. If you have the ability to communicate back the end user then ask the user to check for a typo and try again or try a different email address. If you don’t want to accept a role or alias type email address because they are commonly not accepted by mass email marketers then you can catch for that and tell the user to try again with a different email address.

Use Case 2 – Using ValidateEmailAdress for Batches, Email Campaigns and Data Hygiene

The ValidateEmailAddress method has four input fields that are all required.

Input Field Name	Description	Notes
EmailAddress	The email address you wish to validate.
AlowCorrections	Accepts true or false. The service will attempt to correct an email address if set to true. Otherwise the email address will be left unaltered if set to false.	The majority of the email corrections are being performed on the domain. The local part of the email address, the portion before the @ symbol, is generally left untouched. Since you are unable to ask a user to re-enter and try again if they make a mistake you can set this value to true and allow the service to make corrections.
Timeout	Accepts an integer as a string. Timeout time is in milliseconds. Do not include any commas or non-numeric values. This value specifies how long the service is allowed to wait for all real-time network level checks to finish. Real-time checks consist primarily of DNS and SMTP level verification. A minimum value of 200ms is required.	For non-form validation it is recommended to give the service plenty of time to verify an email address with its host mail server. Most mail servers will only take about 2 seconds on average to verify an email address, but for the occasional slow mail server that requires more time it is recommended to set the timeout time to 65 seconds. The number of mail servers that require this much time is generally minimal, so the long timeout should not make a big impact on the overall batch job.
LicenseKey	Your license key to use the service.

Accept, Reject or Review & Retry

ACCEPT

Emails with a score of 0 or 1.

REJECT

Emails with a score of 3 or 4. If you do not want to be too strict then you can accept 3 for review, but you should always reject an email that receives a score of 4.

REVIEW & RETRY

Emails with a score of 2, unless the IsCatchAllDomain field value is true. An email that gets an unknown score  due to a greylist, timeout or temporarily busy server should be checked again a couple of hours later.

If you would like to discuss your particular use case for recommendations and best practices contact us!

For most organizations, one of the most critical assets of their marketing operations is their email contact database. Email is still the lingua franca of business: according to the Radicati Group, over a quarter of a trillion email messages are sent every business day, and the number of email users is expected to top 4 billion by 2021 – roughly half of the world’s population. This article will explore current best practices for protecting the ROI and integrity of this asset, by validating its data quality.

The title of this article is not just a cute play on words – and it has nothing to do with Santa. Rather, it describes an important principle for your game plan for email data quality. By implementing a strong two-step email validation process, as we describe here, you will dramatically reduce deliverability problems, fraud and blacklisting from your email marketing and communications efforts.

The main reason we recommend checking emails in two stages revolves around the time these checks take: many checks can be performed live using a real-time API, particularly as email addresses are entered by users, but server validation in particular may require a longer processing time and interfere with user experience. Here are 3 of the most important checks that are part of the email validation process:

• Syntax (FAST): This check determines if an email address has the correct syntax and physical properties of an email address.

• DNS (FAST): We can quickly check the DNS record to ensure the validity of the email domain (MX record) for the email address. (There are some exceptions to this – for example, where the DNS record is with a shoddy or poor registry and the results take longer to come back.)

• Email Server (VARIABLE, and not within the email validation tool’s control): Although this check can take from milliseconds to minutes, it is one of the most important checks you can make – it ensures that you have a deliverable address. This response time is dependent on the email server provider (ESP) and can vary widely: large ESPs like Gmail or MSN normally respond quickly, while corporate or other domains may take longer.

There are many more checks in Service Objects’ Email Validation tool, including areas such as malicious activity, data integrity, and much more – over 50 verification tests in all! We auto-correct addresses for common spelling and syntax errors, flag bogus or vulgar address entries, and calculate an overall quality score you can use to accept or reject the email address. (For a deeper dive, take a look at this article to see many of the features of an advanced EV tool.)

Here are the two stages we recommend for your email validation process:

Stage 1: At point of entry. Here, you validate emails in real-time, as they are captured. This provides the opportunity for the user to correct mistakes in the moment such as typos or data entry errors. Here you can use our EV software to check for issues like syntax, DNS and the email server – however we recommend setting the API configuration settings to no more than a wait of a couple of seconds, for the sake of customer experience. At this stage either the user or validation software has a chance to update bad addresses.

Stage 2 – Before sending a campaign. Validate the emails in your database – using the API – after the email has been captured and the user is no longer available in real-time to make corrections. In this stage, you have more flexibility to wait for responses from the ESPs, providing more confidence in your list.

It is estimated that 10-15% of emails entered are not usable, for reasons ranging from data entry errors to fraud, and 30% of email addresses change each year. Together these two steps ensure that you are using clean and up-to-date email data every time – and the benefit to you will be fewer rejected addresses, a better sender reputation, and a greater overall ROI from your email contact data.