Recommended Free Tools
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.
A fully qualified domain name (FQDN) is the complete, DNS-resolvable name of a host, such as mail.example.com. Internet SMTP uses these names to identify mail servers, find recipient domains and evaluate authentication policies. A local nickname such as localhost is not an acceptable substitute in an SMTP transaction.
If your server sends mail with an unresolvable EHLO name, lacks coherent forward and reverse DNS, or publishes incomplete MX and authentication records, receiving systems may defer or reject messages. There is no single “missing FQDN” bounce code, so the practical fix is to validate the entire DNS and identity chain.
What an FQDN means
The complete name in the DNS hierarchy
“FQDN” means fully qualified domain name. It identifies a particular host by its complete path through the DNS hierarchy. In mail.example.com, mail is the host label, example is the domain, and com is the top-level domain. The name is useful to systems outside your network because DNS can resolve it to an address.
A bare label such as mail, an operating-system nickname such as localhost, or a private suffix used only inside your LAN is a local name or alias. RFC 5321 states that “Local aliases MUST NOT appear in any SMTP transaction.” It also says, “Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.”
#1 Best Overall
FQDN, hostname and domain are different
- Domain: the namespace used for addresses and DNS records, for example
example.com. - Hostname: a name assigned to a host, such as
mailor the completemail.example.com. - FQDN: the complete hostname that can be resolved in the relevant DNS namespace.
In practice, publish a public host name for the mail system, then use that same complete name wherever the SMTP server identifies itself. A name can be syntactically complete yet still fail the operational test if it has no public DNS answer.
Where the FQDN enters an SMTP delivery
Recipient-domain lookup and MX processing
When an SMTP client has identified the domain to which it will deliver mail, RFC 5321 requires a DNS lookup. Delivery first attempts to find an MX record for the recipient domain. If a CNAME is encountered, its target is processed, and the resulting name must resolve to an MX or an address record. A nonexistent recipient domain is an error rather than a deliverable destination.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, 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 minuteFor a message addressed to user@example.com, the receiving side therefore needs a usable DNS path for example.com. The MX record points to the host that accepts mail; that host, in turn, needs an address record. If the lookup returns no usable destination, the sending system cannot complete SMTP delivery.
The EHLO or HELO identity
At the start of an SMTP session, the client presents an EHLO (or, for older clients, HELO) argument. RFC 5321 requires that argument to be the client’s primary host name resolving to an address record, or an address literal when the host has no name. A setting such as localhost, an internal-only suffix, or a public name that has no A or AAAA record can fail a receiver’s interoperability or policy checks even though the mail application is running normally.
Rank #2
- Linux
- Linux DNS
Why DNS failure looks like a mail failure
SMTP depends on several independent DNS answers. A receiver may be able to resolve the recipient’s MX while rejecting the sender’s identity, or it may reject the destination before authentication is evaluated. Consequently, “missing FQDN” is not a universal SMTP response. The diagnostic text from the receiving server tells you which lookup or policy check failed.
Why messages bounce when identity is incomplete
Destination and MX problems
If the recipient domain does not exist, has no usable MX or address record, or points to an unreachable host, delivery cannot proceed. A malformed or private-only name in the destination path has the same practical effect as any other failed DNS resolution: the sender cannot establish a valid route.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Sender-name and reverse-DNS checks
Receivers commonly examine the name presented in EHLO together with the sending IP address. Your IP provider should publish a PTR (reverse-DNS) record that points back to the mail host name, while the host name should resolve forward to the expected address. This forward-and-reverse relationship does not by itself authorize mail, but an incoherent pair can trigger policy rejection or a delivery delay.
Authentication and policy checks
SPF, DKIM and DMARC add domain-level evidence after basic DNS resolution is available:
- SPF associates an envelope-From domain with the IP blocks or other mechanisms authorized to send for it. SPF can also validate the HELO/EHLO identity.
- DKIM uses a cryptographic signature that identifies a signing domain. The receiver retrieves the public key through DNS.
- DMARC evaluates alignment between authenticated identifiers and the visible From domain, then tells the receiver whether to deliver, quarantine or reject failures while producing reports.
RFC 9989 distinguishes SPF validation of the HELO/EHLO and MAIL identities from DMARC’s reliance on SPF validation of the MAIL FROM identity. These controls strengthen trust; they do not replace a resolvable host name, a working MX path or coherent reverse DNS.
DNS records your mail host needs
| Record or setting | Role in delivery | What to verify |
|---|---|---|
A and/or AAAA for mail.example.com |
Maps the public mail hostname to an IPv4 and/or IPv6 address. | The name resolves from outside your local network to the address the server actually uses. |
MX for example.com |
Names the host that accepts mail for the domain. | The MX target is a usable host with an address record; follow CNAME processing rules rather than assuming a nickname is sufficient. |
| PTR for the sending IP | Provides the reverse-DNS name associated with the outbound address. | The IP provider has set it to the intended mail hostname and the forward lookup returns the same address. |
| SPF TXT policy | Lists infrastructure authorized for the envelope-From domain. | Every legitimate sender is covered and the policy is published at the domain used in MAIL FROM. |
| DKIM selector TXT key | Lets receivers retrieve the public key for a message signature. | The selector record is present and the server signs with the corresponding domain. |
| DMARC TXT policy | Defines handling and reporting for authentication or alignment failures. | The policy is published for the visible From domain and its alignment expectations match your SPF and DKIM identities. |
Fix an SMTP hostname and reverse-DNS problem
Work through these steps in order. Each later check depends on the names and addresses established earlier.
- Control a real domain. Register or administer a domain such as
example.com. You need authority to edit its DNS records. - Choose the public mail FQDN. Give the server a name such as
mail.example.com. Do not uselocalhost, an unqualified label or a name that exists only on your private resolver. - Publish forward records. Create A and/or AAAA records for the mail host, using the public address from which SMTP connections originate.
- Publish the recipient MX. For domains that receive mail, set the MX record to the intended mail host and confirm that the target resolves to an address.
- Set the SMTP greeting. Configure the server’s EHLO/HELO value to the same resolvable host name. Restart or reload the mail service according to its administration procedure.
- Request reverse DNS. Ask the organization that controls the sending IP to set its PTR record to the mail FQDN. Recheck that forward and reverse lookups are coherent.
- Add authentication. Publish SPF for authorized senders, enable DKIM signing, and publish a DMARC policy after checking that the authenticated domains align with the address users see in From.
Test the configuration from outside your network
Testing only from the mail server can hide split-DNS or firewall mistakes. Run the following from an independent host or an external DNS-checking environment, replacing the example values with yours:
- Check the host’s address records with
dig +short A mail.example.comand, if IPv6 is enabled,dig +short AAAA mail.example.com. - Check recipient routing with
dig +short MX example.com. Resolve every MX target separately and confirm it has an address record. - Check reverse DNS with
dig -x 203.0.113.25 +short, substituting the actual sending IP. - Inspect SPF and DMARC TXT records with
dig +short TXT example.comanddig +short TXT _dmarc.example.com. Retrieve the DKIM selector record atselector._domainkey.example.com. - Observe the SMTP greeting and advertised capabilities with a controlled STARTTLS connection such as
openssl s_client -starttls smtp -connect mail.example.com:25, subject to your network’s outbound-port rules. - Send a test message to a domain you control. Save the complete bounce, including enhanced status text and the receiving server’s explanation; that text identifies whether the failure occurred during DNS, connection, authentication or policy evaluation.
How to interpret a bounce report
- Destination wording: references to an unknown domain, missing MX or an unresolvable host point to recipient-side DNS or an incorrect address.
- Greeting or hostname wording: complaints about HELO, EHLO, hostname or reverse lookup point to the server identity, A/AAAA records or PTR configuration.
- Authentication wording: SPF, DKIM, DMARC or alignment messages indicate that DNS is being queried but the declared sender is not authorized or authenticated as expected.
- Temporary wording: a deferral may indicate a transient connection or policy decision. Preserve the diagnostic and retry according to your mail system’s queue behavior rather than changing records blindly.
Do not infer the cause from a generic phrase such as “mail rejected.” The receiver’s diagnostic line, combined with independent DNS results, is more useful than the numeric code alone.
Self-hosting versus a managed SMTP service
The standards define naming and lookup requirements, but they do not set provider features, sending limits or prices. Use the following questions when deciding who should operate the mail-transfer infrastructure.
| Decision area | Operating your own server | Using a managed SMTP service |
|---|---|---|
| DNS and PTR control | You arrange the public hostname, records and the IP provider’s reverse-DNS change. | Confirm which records the service supplies and whether you can use a branded sending domain and aligned reverse identity. |
| SPF, DKIM and DMARC | You publish policies, protect signing keys and correct alignment errors. | Verify the service’s required SPF include or mechanisms, DKIM setup and DMARC compatibility. |
| Bounce diagnostics | You collect SMTP responses, queue logs and recipient feedback yourself. | Check whether the service exposes the original diagnostic text, event history and reporting needed to troubleshoot. |
| Geographic deliverability | You are responsible for the reputation and network path of your sending addresses. | Ask where mail is sent from and how the service handles regional routing and reputation. |
| Sending limits | Your host and upstream network determine practical limits and throttling. | Read the service’s limits, approval requirements and treatment of temporary deferrals. |
| Operational cost | Budget for the host, DNS administration, monitoring and maintenance. | Compare the recurring service charge with the administration you would otherwise perform. |
Common misconfigurations and their repairs
The server says “localhost”
Change the greeting and primary host setting to the public FQDN. Then publish its A/AAAA record and test the name externally. Editing only the greeting while leaving DNS empty changes the text but not the underlying failure.
The FQDN exists internally but not publicly
Split-horizon DNS can make a name appear healthy on the LAN while outside receivers see no answer. Query the authoritative or public DNS view from an unrelated network and publish the record in the zone used by Internet clients.
The MX points to an alias with no usable target
Follow the MX target through DNS. If a CNAME is involved, process its target and ensure the resulting name resolves to an MX or address record as required by SMTP. Correct the zone rather than adding arbitrary hostnames to the mail application.
Best Value
- Standard size: 6 pink server note pads, Each Book Comes with 50 bound order slips - that's 300 ticket sheets total! Check Pads Size 6.75 x 3.5 inch.
- Convenient Work: These guest check books for servers have a tear-free dotted line that is easy to rip off. You can give as a customer copy or keep for record keeping. We've provided extra rows on the back for additional note taking.Perfect For Restaurants, Lounges, Hotels, Cafes, And Waiters To Use.
- Record Important Information: These server note pads can record important information.Each ticket has a unique serial number printed at the top, dates, order details, number of guests, order amount, table numbers etc. They are lightweight, small and can fit most aprons. They can be used on-demand and can help decrease errors in orders, while improving work efficiency.
- High Quality: Sturdy, Not Drop Powder, It's Thick, You Can Write On The Back And Front Easily.Their whole page printing has clear handwriting and a reasonable layout. On the customer retention part of each guest check, "THANK YOU" on the back to make customers feel appreciated.
- Contact Us: We're confident that the quality of the server note pads will go beyond your expectation. If you experience an issue, feel free to contact us, we'll appreciate it to learn from your experience, and we'll make it better
PTR and forward DNS disagree
Ask the IP owner to change the PTR, then make sure the named host resolves forward to the same sending address. If you cannot control reverse DNS on a rented address, a managed relay may be operationally simpler.
Authentication was added before identity was fixed
SPF, DKIM and DMARC records cannot compensate for an EHLO name that does not resolve or an unavailable MX. Establish the FQDN, forward records and reverse relationship first, then verify authorization and alignment.
What to maintain after the repair
- Keep the EHLO name, A/AAAA record and PTR assignment synchronized when an address or hostname changes.
- Review MX targets and test them from outside the organization whenever DNS is reorganized.
- Monitor SPF, DKIM and DMARC reports for unauthorized senders and alignment failures.
- Retain complete SMTP diagnostics for rejected and deferred messages so recurring failures can be distinguished from one-off recipient problems.
An FQDN is therefore a prerequisite identity, not a cosmetic label. A mail server can run locally without one, but Internet SMTP requires resolvable names, valid DNS routing and a consistent identity across EHLO, forward DNS, reverse DNS and authentication policy.
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.
