Some of your contact email addresses may contain an IP address, for example, john.smith@[123.123.123.123] rather than a domain name, such as john.smith@example.com. Can you use these email addresses for mailing purposes?
The short answer is technically yes, but really no.
The Simple Mail Transfer Protocol (SMTP) does allow an IP address to be used instead of a domain name under special circumstances when encapsulated in brackets, such as our previous example of john.smith@[123.123.123.123], However, here are some common reasons why doing so may end up with the email message being bounced back and/or not making it to the intended recipient.
- By default, it is not uncommon for many mail servers to not accept email addresses without a ‘fully qualified domain name’ (FQDN).
- For a mail server that hosts more than one domain, the FQDN in the email address is necessary to identify which domain group the email user belongs to.
- Email addresses with IP addresses often get flagged as spam.
When is an IP address allowed?
Email messages are transmitted using the Simple Mail Transfer Protocol (SMTP), which is defined by the Request for Comments (RFC) 5321, 5322 and various extensions. In the email address specification section of RFC 4532, we see where the specification mentions the use of a domain-literal form, i.e. a domain’s literal IP address.
RFC 5322 – 3.4.1
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a hostname or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain- literal form, the domain is interpreted as the literal Internet address of the particular host.
In other words, RFC 5322 says that either a domain name form or a domain literal form may be used to describe the domain portion of an email address. Where the domain name form is what we are typically used to seeing (ex: john.smith@example.com), and the domain literal form being an IP address (ex: john.smith@[123.123.123.132]). It goes on to say that, “In both cases, how addressing is used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321].” So, we must dig further to learn more about when an IP address may be acceptable to use.
In RFC 5321 we find the Host and Domain Names listed under sections 2.3.4 and 2.3.5 respectively. Here we see the RFC strongly recommending against the use of an address literal, also known as a domain literal or IP address.
RFC 5321 – 2.3.4
Hosts are known by names…they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.
And then we finally get a glimpse as to when an IP address would be allowed.
RFC 5321 – 2.3.5
Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP…There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4. o The reserved mailbox name “postmaster” may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used.
Two situations where IP is allowed
We find that a domain name may be replaced with an IP address if the host has no name, as described below in sections 4.1.3, or if the email address is for the host postmaster (for example: postmaster@[123.123.123.123]). Now we’re finally getting somewhere. So according to the RCF below (emphasis mine), an IP address is allowed in email address when a domain name is not available in DNS, otherwise it must be an email addressed to the host postmaster.
RFC 5321 – 4.1.3
Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized “tag” that identifies the address syntax, a colon, and the address itself, in a format specified as part of the relevant standards (i.e., RFC 4291 [8] for IPv6).
IP addresses often associated with spammers
The RFC states that an address literal (IP address) is allowed as an alternative to a domain name when the recipient host is not known in DNS, but why wouldn’t a domain name be available? There are plenty of reasons for why a mail server might not be listed in DNS, but a mail administrator who is in charge of keeping out spam is not likely willing to take the risk. Many mail servers require reverse pointer (PTR) DNS records from the submitter. A PTR record allows the receiving mail server to perform a reverse lookup on the IP address that is sending the email message. The PTR record should resolve to a FQDN. If a PTR record does not exist or if the FQDN it resolves to does not match the one in the email address, then it is likely a spoofed email message and the recipient mail server will reject it. This is just one common method used by mail severs to try and fight spam.
A mail server without a FQDN will not have a PTR record, so if it were to try and send out mail then it is likely its messages would be rejected by most recipient mail severs. If chances are that your mail server will not accept email from a mail server without a FQDN then you likely wouldn’t want to send email to one, as you wouldn’t be able to get a reply. More likely, when a FQDN is not available it means there is no mail server that accepts email and that the IP address is just being used as a burner to blast out spam. This is why so many address literal form email addresses appear in various blacklists and why they are associated with spammers.
Address literal form disabled by default
It is common for many mail servers to disable the acceptance of address literal form by default or not support them at all. After all, even though the RFC does allow the use of IPs under special conditions, it does strongly recommend against using them. That coupled with the high abuse of address literal form by spammers and malicious users it makes sense for most mail servers to not allow them. If the mail server does not have the acceptance of address literals enabled, then it will likely reply with a permanent reject (aka a hard bounce). In other cases, the recipient mail server may reply with a temporary reject (aka a soft bounce) and instructions for the sender to use a FQDN instead and try again.
Domain groups
Mail servers are designed to host multiple domains. If one of these is reached by its IP address via address literal form, then it would be unable to route the email message to the end recipient because it needs to FQDN to know which domain group the message belongs to. For example, say you have three different email addresses.
sales@exampleone.com
sales@exampletwo.com
sales@examplethree.com
In our example, these email addresses are for three different businesses where ExampleOne is a large global leader in its marketspace, ExampleTwo is a longtime rival of ExampleOne and ExampleThree is fledgling competitor. ExampleOne and ExampleTwo are too big to adequately manage all their email traffic on their own, so they outsource to an Email Service Provider (ESP). ExampleThree is too small and lacks the resources to host their own mail, so they too outsource to an ESP. As it turns out, the ESP is so popular (cough, Gmail… cough, Office365) that all three businesses end up using the same ESP and the ESP is using the IP address 123.123.123.123.
Now, let’s say that we wanted to write the email addresses in domain literal form and use their IP address instead of the domain. If we were to do this then all three email addresses would end up looking the same.
sales@[123.123.123.123]
If we were to try and send a message to sales@[123.123.123.123] then the ESP’s mail server(s) wouldn’t know who it belongs to and it would be unable to deliver the message. Even in an example where a company hosts their own mail server and has only one domain, chances are that the mail server will still require the domain. Likely because it is configured that way, or it is simply a part of the way it works.
IPs are accepted but discouraged
In conclusion, while an IP address is technically allowed, it is not widely accepted and is in fact highly discouraged. However, because it is technically required to be accepted for mail server, we find that many servers may behave differently when they encounter them. The DOTS Email Validation service will attempt to verify these types of email addresses.
If the IP address is bogus and does not resolve, then the Email Validation service will fail the email address. If the IP does resolve and communication can be established with the recipient mail servers then it may respond with a temporary reject code (soft bounce), a permanent reject code (hard bounce) or it might accept the email. If the mail server does accept the email, there is a possibility that it will be delivered to a catchall mailbox. Overall, regardless of how an EV service responds to an email address with an IP instead of a domain, you should give some thought on whether you want to keep these addresses in your mailing lists or not.
If you would like to see how a validation service works, please sign up for a free Email Validation API trial key and test up to 500 email addresses.
