MX recored & Time to Live (TTL)
When you add or change an MX record, the TTL setting for the previously existing MX record determines how long it takes for every DNS server to start using the new MX record.
Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like Web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions.
When someone from another domain sends email to your domain, the domain name system (DNS) server for the sender’s domain contacts your domain’s DNS server for the prioritized list of MX records. The sender’s DNS server keeps a copy of the MX records so that it doesn’t need to contact your DNS server the next time it sends email to your domain. Each MX record includes a setting, called Time to Live (TTL), which tells the sender’s DNS server how long it can wait before contacting your domain’s DNS server to check for changes to the record.
When changing your MX records set a low TTL value so that you can quickly resolve any mistakes, or set a low TTL value for your existing records to facilitate the change.
The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.
Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are “per record” and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide.
MX priority
The relative priority of an MX server is strong-minded by the preference number present in the DNS MX record. When a remote client does an MX lookup for the domain name, it gets a list of servers and their first choice numbers. The MX record with the smallest first choice number has the highest precedence and is the first server to be tried. The remote client will go down the list of servers until it successfully delivers the message or gets permanently rejected due to an inaccessible server or if the mail account does not exist on that server. If there is more than one entry with the same preference number, all of those must be tried before moving on to lower-priority entries.
The cPanel WHM MX Editor interfaces
The cPanel and WHM MX Editor interfaces and subsystems received an update in cPanel™ 11.25.
This changed for cPanel™ 11.25. There are now the following options to configure how mail is to be handled by the local server:
• Automatically Detect MX Configuration
• Local Mail Exchanger
• Backup Mail Exchanger
• Remote Mail Exchanger
These options are presented in the Email Routing section of the MX Entry cPanel™ interface. A bried decription of each option appears in the cPanel™ interface. The description includes how the option will change the way the local system handles email for the domain being modified. This setting may be changed independently from the action of modifying a MX record.
Modifying the Email Routing for domain changes, or adds, an entry to the cPanel™ user file, normally in /var/cpanel/users.
MX Entry Maintenance
An MX (mail exchanger) entry tells a client which server receives mail sent to a domain name.
Assigning Priority to MX Entries :
Lower values denote higher priority, with 0 being the highest possible priority.
The primary mail server(s) (with the lowest-numbered priority) will receive mail sent to your domain.
Secondary mail servers (those with higher priority values) can be used for backup or other purposes.
If you assign multiple mail servers the same priority, then when that level of mail server is needed, mail will be distributed to those servers randomly.
Lowest numbered MX record points to local host
temporarily rejected RCPT : lowest numbered MX record points to local host
If you see the following in exim’s main_log: /var/log/exim_mainlog
This indicates that the domain doesn’t exist in /etc/localdomains. Edit the file with and ensure it’s listed there.
Please also ensure that it isn’t listed in /etc/remotedomains.
