The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
In an MX record, the hostname field identifies the domain whose incoming mail you are configuring, while the target/value field contains your email provider’s mail-server hostname. For the root domain, enter @ or leave the name blank if your DNS panel uses that convention. For a subdomain such as support.example.com, enter only support.
Open DNS management at the provider authoritative for your domain, create an MX record, paste the provider’s exact target hostname, enter its specified priority, save, and verify the public MX response. Never replace the target hostname with an IP address or an invented server name.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What an MX hostname does
Mail-exchange (MX) records tell sending mail servers where to deliver messages for a domain. When someone sends mail to user@example.com, the sending system performs a DNS MX lookup for example.com, reads the published mail-exchange hostnames and their preference values, and then connects to an appropriate host over SMTP. RFC 1034 defines MX data as a preference value followed by a host name willing to act as a mail exchange; SMTP delivery behavior is specified in RFC 5321.
An MX record therefore has two different “hostname” concepts that are easy to confuse:
#1 Best Overall
| DNS field | What it identifies | Typical value |
|---|---|---|
| Name, Host, Alias, or Domain | The domain or mail subdomain receiving mail | @, blank, or a label such as support |
| Value, Target, Answer, or Mail server | The provider’s server that accepts incoming mail | An exact provider-supplied fully qualified hostname |
| Priority or Preference | Which MX host should be tried first | The number specified by your provider; lower numbers are preferred |
The name field is relative to the DNS zone in most control panels. The target is a separate DNS name and must be copied exactly from the service that handles your mail.
Find the DNS system that is authoritative
You must edit records at the DNS provider whose nameservers are delegated for your domain. That might be your registrar, a separate managed DNS service, a hosting company, or an organization’s internal DNS platform. An account at the email provider does not necessarily give you access to the authoritative DNS zone.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors- Look up the domain’s nameservers using your registrar’s domain details or a DNS lookup utility.
- Identify the organization operating those nameservers.
- Sign in there and open the zone or DNS-record editor for the exact domain.
If you add an MX record in a panel that is not authoritative, it will not appear in public DNS and cannot affect mail delivery. AWS notes that the exact procedure for adding an MX record depends on your DNS or hosting provider, so labels and validation rules vary between interfaces.
Collect the provider’s exact values first
Before changing DNS, open the incoming-mail or domain-setup instructions for your email service. Record every value it specifies:
- The MX target hostname or hostnames.
- The priority for each target.
- Any required TTL or an instruction to use the registrar’s default.
- Whether the record applies to the root domain or a particular mail subdomain.
- Whether existing MX records must be removed during activation.
Do not infer a target from a web address, an SMTP login screen, or an IP address shown elsewhere in the provider’s documentation. If the provider gives several records, create the complete set and preserve each target’s associated priority.
Set the hostname field correctly
Root or apex domain
For mail addressed to user@example.com, the owner name is the apex domain, example.com. DNS interfaces commonly represent that owner name as @ or as an empty Name/Host field. Some panels accept the complete domain instead. Use the convention documented by that panel; do not enter www unless you are intentionally configuring mail for that subdomain.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Mail subdomain
For an address such as agent@support.example.com, enter support in a zone editor for example.com. The resulting record applies to support.example.com. If the interface requires an absolute name, it may ask for support.example.com.; follow its displayed format and avoid accidentally creating support.example.com.example.com.
Separate zones and delegated subdomains
If support.example.com is delegated as its own DNS zone, edit that zone and use its own apex representation, usually @ or blank. The correct field depends on which zone you are editing, not merely on the visible address.
Step-by-step: add the MX record
- Open authoritative DNS. Sign in to the provider operating the domain’s delegated nameservers and select the correct DNS zone.
- Choose Add record. Select record type MX, not A, AAAA, CNAME, or TXT.
- Enter the owner name. Use
@or blank for the root domain, or enter the relevant subdomain label such assupport. - Paste the target. In Value, Target, Answer, or Mail server, paste the email provider’s exact hostname. Preserve a required trailing dot if the provider or panel uses one.
- Set priority. Enter the provider’s preference number for that target. DNS mail-delivery rules prefer the lower numeric value when choosing among MX records.
- Set TTL. Use the provider’s requested TTL. If it permits the registrar default, leaving the default is acceptable. Microsoft’s documented example uses a 3,600-second TTL; Google Workspace’s current instructions permit the registrar default.
- Save and publish. Confirm that the record is listed as MX and that the target was not automatically changed to an unrelated domain or wrapped in quotation marks.
- Verify publicly. Query the domain’s MX records from outside the management panel, compare the answer with the provider’s documented hostname, and send an inbound test message.
Provider examples (illustrative values)
These examples show how provider instructions map to DNS fields. They are not interchangeable defaults; use the values currently supplied for your own account and domain.
Google Workspace
Google’s current Workspace setup instructions tell you to open the registrar’s DNS settings, remove other MX records, and add an MX record for the domain. For a root domain, Name/Host can be blank or @, depending on the registrar. For a subdomain, enter that subdomain label. The current single target is smtp.google.com with priority 1; Google allows the registrar’s default TTL. After saving, complete verification in the Workspace administration workflow and test delivery.
Microsoft 365 and Exchange Online
Microsoft documents an MX record with host or alias @, a target hostname supplied for your tenant, priority typically 0, and a TTL of 3600 seconds. Exchange Online supports TTL values below six hours. The target is tenant-specific, so do not substitute a generic Microsoft hostname. Copy the exact value shown in your Microsoft 365 domain-setup page.
Amazon SES receiving
AWS’s generic SES procedure is to sign in to the DNS provider, create an MX record, and use the domain as the Name; its example is example.com.. The field may be called Host, Domain, or Mail Domain. Enter the SES-provided receiving endpoint as the target and use the priority specified for your configuration.
Moving mail from one provider to another
Changing MX records before the destination service is ready can strand incoming mail. Treat a migration as a sequence rather than a single edit.
- Provision destination mailboxes first. Create users, aliases, routing rules, and any required catch-all or shared-mail settings at the new service.
- Confirm the destination domain. Complete any ownership-verification step requested by the provider, usually with a separate TXT record.
- Record the existing MX set. Save the current targets and priorities so you can restore them if needed.
- Publish the new MX values. Follow the destination provider’s exact priorities. If it supplies one record, do not leave an old record with equal or unintended priority.
- Remove or demote stale records. Microsoft’s migration guidance cautions against leaving old MX records active at an unintended priority. Remove the old record, or assign it the lower delivery preference only if the provider explicitly supports a staged arrangement.
- Test multiple addresses. Send messages to newly provisioned users, aliases, and any important subdomains.
Resolvers may cache the previous answer until its TTL expires, so some senders can continue using the old destination temporarily. Keep the old service available during the transition when your migration plan requires it, but do not assume that retaining both records produces a controlled split.
Rank #3
- Used Book in Good Condition
Verify the published result
Query with a command-line resolver
From a system with DNS utilities installed, query the exact owner name:
dig MX example.comFor a subdomain, query that name instead:
dig MX support.example.comOn systems with nslookup, the equivalent is:
nslookup -type=MX example.comLook for the target hostname and numeric preference you configured. A successful result from your management panel alone is not proof that the public zone changed; the authoritative nameservers must return the record.
Use an independent lookup
A third-party MX lookup can show what public resolvers see and is useful when your local resolver has cached an older answer. Cloudflare recommends third-party MX lookups when troubleshooting. Compare the returned owner name, target, and priority with the provider’s instructions.
Send an inbound test
Send a message from an unrelated mailbox to a real address at the configured domain. Confirm arrival, inspect the received headers for the destination service, and test at least one alias or subdomain if those are part of your setup. An outbound test from the new mailbox does not prove that inbound MX routing is correct.
Why an MX record is not working
The record was added at the wrong provider
Symptom: The panel shows the record, but public lookups do not.
Fix: Recheck the domain’s delegated nameservers and edit the matching authoritative DNS provider. If nameservers were recently changed, verify which provider is currently authoritative rather than relying on an old bookmark or hosting account.
An IP address was entered as the target
Symptom: The panel rejects the value, or mail servers cannot obtain a valid exchange host.
Rank #4
Fix: Replace the IP address with the exact hostname supplied by the email provider. RFC 1034 defines MX data as a preference followed by a host name, not an address literal. The target hostname should resolve through its own DNS address records.
The owner name is wrong
Symptom: The root domain has no visible MX answer, while a similarly named record appears elsewhere.
Fix: For the apex, use the panel’s @ or blank convention. For support.example.com, use support in the example.com zone. Check that the interface did not append the zone twice.
Old MX records remain during a migration
Symptom: Some messages arrive at the old service or delivery behavior is inconsistent.
Fix: List every public MX record and compare its priority. Remove obsolete records or follow the destination provider’s documented staged-migration method. Equal or unintended priorities can leave senders choosing a server you no longer intend to use.
Recommended Free Tools
The target is a CNAME-style alias or is proxied
Symptom: The DNS provider reports an invalid target, or lookups show a proxy address instead of the mail host.
Fix: Use the provider’s actual mail hostname. MX records must remain DNS-only, and the target must resolve to a DNS-only address; do not place a web proxy in front of an SMTP endpoint.
You expected immediate global visibility
Symptom: One resolver shows the new value while another still returns the old value.
Fix: Check after the configured TTL and account for resolver caching. Query the authoritative nameservers and several independent resolvers before deciding that the change failed. Avoid repeatedly deleting and recreating the record, which can make diagnosis harder.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How priorities and TTL affect delivery
Priority, also called preference, is a number attached to each MX target. A lower number is preferred under DNS mail-delivery rules. When a provider gives multiple records, preserve the exact pairing of each hostname and priority; do not assign every target the same number unless the provider explicitly instructs you to.
TTL is the period for which a resolver may cache an answer. A shorter TTL can make a planned change visible sooner after caches expire, while a longer TTL reduces repeated DNS queries. The useful value is the one specified by your email provider or supported by your DNS host. A TTL change does not erase answers already cached under the previous TTL.
MX records are only one part of email DNS
MX controls where other servers deliver incoming mail. It does not authenticate messages sent from your domain, identify permitted sending systems, or define anti-spoofing policy. After inbound routing works, follow your provider’s separate guidance for:
- SPF: a TXT policy listing authorized senders.
- DKIM: a signing key published in DNS, usually under a selector subdomain.
- DMARC: a policy that tells receiving systems how to handle messages that fail alignment and where to send reports.
Do not put SPF, DKIM, or DMARC data in an MX record. They use different record types and names, and changing one does not automatically configure the others.
Pre-publish checklist
- You have access to the DNS provider that is authoritative for the domain.
- You know whether the record is for the root domain or a mail subdomain.
- The Name/Host field uses
@, blank, or the correct subdomain label for that DNS panel. - The Value/Target is the provider’s exact hostname, not an IP address or web URL.
- Every supplied priority and required TTL is entered with the correct target.
- Old MX records have been removed or intentionally prioritized for a migration.
- Destination mailboxes exist before you switch delivery.
- A public lookup returns the expected MX set.
- An inbound test message reaches the intended mailbox.
Once those checks pass, the hostname is set up correctly: the owner name identifies the domain that receives mail, and the target hostname identifies the server that accepts it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
