Today on DELIVTERMS, the series here on Spam Resource where we help you decode deliverability and email terminology, we're looking at one of the core components of how email actually finds its way to your inbox. A foundational DNS record that helps direct the traffic behind the scenes. The term: MX Record. It might seem basic and obvious to some, but not everybody knows every concept of how email works, so let's take a moment to share what we know.
MX stands for Mail Exchange. An MX record is a type of DNS (Domain Name System) record that tells the world where to send email for a specific domain. If someone wants to send a message to user@example.com, their mail server looks up the MX record for example.com to find out which server should receive that message.
If you're a Yahoo user, sending email to a Gmail user, Yahoo needs to look up the MX record for Gmail, to know what Google server to hand that mail of to; it's a necessary pointer to allow mail to flow between services, defining the routing of messages externally through the email ecosystem.
That record doesn't contain an IP address. Instead, it points to a hostname (or FQDN, fully qualified domain name), like mail.example.com, and from there, the sending server can look up the IP address associated with that hostname, and attempt to make a connection, to be able to deliver that email message.
You can have one MX record, or you can have multiple. Each MX record comes with a priority value, a number that indicates which mail server should be tried first. Lower numbers mean higher priority. So if a domain has two MX records, one with priority 10 and one with priority 20, the one with priority 10 gets tried first. If that one's down, only then does the sending server try the next one.
Here's what that might look like: example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
Mail will be handed off to mail1.example.com unless it's unavailable, in which case mail2.example.com is the backup.
No MX record at all? RFC 5321 says the sender can fall back to trying the A or AAAA record for the domain directly. Still, that's not considered best practice. You lose some ability to set ranking for priority and purpose of failover, and going this route can tie you into annoying operational complexities (oh I have to run a webserver on my MTA?) that go beyond what I'm going to get into here. TL;DR? If you're going to receive mail, publish an MX record.
MX records are one piece of the DNS puzzle that enables the proper path for the successful flow of email messages from sender to recipient. Without them, messages can't get in. And if they're pointing to the wrong place, or nowhere at all, your mail ends up GNDN (going nowhere, doing nothing). So while it might seem like a simple setting, getting it right is always mandatory.
What about an MX record's impact on deliverability? MX records themselves don't really have a reputation. You sending server could be hosted in a "bad network neighborhood," but that's generally not going to affect the receipt of inbound mail. Fumble your MX record so that mail get rejected or deferred, and that will bring a negative impact. But is that a long term reputation stain? Generally, no. Fix your MX record in DNS, and mail will start reaching you again as soon as various sending services expire and update cached entries relating to DNS for your domain.
Want to see more email and deliverability terminology defined? Click on through to view the whole DELIVTERMS series here on Spam Resource.
Today on DELIVTERMS, the series here on Spam Resource where we help you decode deliverability and email terminology, we're looking at one of the core components of how email actually finds its way to your inbox. A foundational DNS record that helps direct the traffic behind the scenes. The term: MX Record. It might seem basic and obvious to some, but not everybody knows every concept of how email works, so let's take a moment to share what we know.
MX stands for Mail Exchange. An MX record is a type of DNS (Domain Name System) record that tells the world where to send email for a specific domain. If someone wants to send a message to user@example.com, their mail server looks up the MX record for example.com to find out which server should receive that message.
That record doesn't contain an IP address. Instead, it points to a hostname (or FQDN, fully qualified domain name), like mail.example.com, and from there, the sending server can look up the IP address associated with that hostname, and attempt to make a connection, to be able to deliver that email message.
You can have one MX record, or you can have multiple. Each MX record comes with a priority value, a number that indicates which mail server should be tried first. Lower numbers mean higher priority. So if a domain has two MX records, one with priority 10 and one with priority 20, the one with priority 10 gets tried first. If that one's down, only then does the sending server try the next one.
Here's what that might look like:
example.com. 3600 IN MX 10 mail1.example.com.
Mail will be handed off to mail1.example.com unless it's unavailable, in which case mail2.example.com is the backup.
No MX record at all? RFC 5321 says the sender can fall back to trying the A or AAAA record for the domain directly. Still, that's not considered best practice. You lose some ability to set ranking for priority and purpose of failover, and going this route can tie you into annoying operational complexities (oh I have to run a webserver on my MTA?) that go beyond what I'm going to get into here. TL;DR? If you're going to receive mail, publish an MX record.
MX records are one piece of the DNS puzzle that enables the proper path for the successful flow of email messages from sender to recipient. Without them, messages can't get in. And if they're pointing to the wrong place, or nowhere at all, your mail ends up GNDN (going nowhere, doing nothing). So while it might seem like a simple setting, getting it right is always mandatory.
Want to see more email and deliverability terminology defined? Click on through to view the whole DELIVTERMS series here on Spam Resource.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.