The plain-English guide to mail routing. What MX records are, the ports that matter, SMTP versus ESMTP, hosted versus self-hosted servers, transport security, and a ready-to-paste Claude prompt that builds your server config for you.
Quick answer, in case that is all you came for:
An MX record is a DNS entry that names the mail server responsible for accepting email for your domain, along with a priority number. When someone emails you@yourcompany.com, the sending server looks up the MX records for yourcompany.com and connects to the host with the lowest priority number first. A typical record looks like 10 mx.yourprovider.com. Lower priority wins. No MX record usually means mail bounces. An MX record proves the domain can receive mail, but it does not prove a specific mailbox exists.
MX is about inbound mail. SPF, DKIM and DMARC are about outbound mail. Those are four different records doing four different jobs, and mixing them up is why people spend afternoons fixing the wrong thing.
The bounce that makes no sense
A customer tells you they emailed and got no reply. You check. Nothing arrived.
They forward you the bounce. It says something like Recipient address rejected: Domain not found, or it just sat in a queue for four days and gave up.
You check your website. It loads fine. Your domain clearly exists. So what happened?
Your domain has an A record pointing at your website and no MX record pointing at your mail. To a browser, everything is perfect. To a mail server, your domain has nowhere to put a letter.
This happens constantly during DNS migrations, after a hosting change, and on any domain where somebody set up the website and assumed email came along for free. It does not.
What is an MX record, in plain English?
MX stands for Mail Exchanger. It is defined in RFC 1035, with its role in mail routing spelled out in RFC 5321.
Think about a physical mailroom.
Your domain name is the company name on the front of the building. The MX record is the sign in the lobby that says "all deliveries to the loading dock around the back, and if that dock is closed, use the side entrance."
When a courier arrives with a package addressed to your company, they read that sign and go where it tells them. Without the sign, they stand in the lobby, then eventually take the package back to the depot.
That is an MX record. It is the delivery instruction for everything addressed to the part after the @.
Why the priority number exists
Every MX record has a number in front of the hostname:
10 mx1.provider.com
20 mx2.provider.com
Lower is preferred. The sender tries mx1 first because 10 is lower than 20. If mx1 does not answer, it falls back to mx2.
The numbers themselves are meaningless in isolation. 10 and 20 are conventional, but 1 and 2 work identically, as do 0 and 5. All that matters is the ordering.
Hosts sharing the same number are load balanced, used in random order. That is why Google Workspace tenants historically published five hosts at various priorities: redundancy plus spread.
How email actually gets delivered, step by step
This is the whole journey, from your keyboard to someone else's inbox.
Step 1. You hit send. Your mail client (the MUA, more on that terminology below) connects to your outgoing mail server, usually on port 587, and hands over the message with your username and password.
Step 2. Your server takes ownership. It queues the message and reads the recipient address, say sarah@example.com.
Step 3. It looks up the MX records for example.com. One DNS query. It gets back a list of hostnames with priority numbers.
Step 4. It resolves the lowest priority host to an IP address. Another DNS query, this time for the A or AAAA record of that hostname.
Step 5. It opens an SMTP connection on port 25. Server to server delivery always uses port 25. There is no alternative.
Step 6. The two servers negotiate. They greet each other, agree on extensions, and almost always upgrade the connection to encryption using STARTTLS.
Step 7. The message transfers. Sender address, recipient address, then the message itself.
Step 8. The receiving server runs its checks. SPF, DKIM, DMARC, reputation, content filtering, all of it.
Step 9. It accepts or rejects. If it accepts, the message is handed to a delivery agent that files it in Sarah's mailbox. If it rejects, your server generates a bounce back to you.
Step 10. Sarah reads it. Her mail client connects over IMAP and pulls it down.
Every one of those steps has a name, a port, and a protocol. Here they are.
Every term you need, decoded
This is the reference section. Nothing here is complicated once somebody writes it in plain English.
The three agents
| Term | Stands for | What it actually is |
|---|---|---|
| MUA | Mail User Agent | The thing you look at. Outlook, Gmail's web interface, Apple Mail, Thunderbird. |
| MTA | Mail Transfer Agent | The server software that moves mail between servers. Postfix, Exim, Exchange, Sendmail. This is the piece MX records point at. |
| MDA | Mail Delivery Agent | Takes the message from the MTA and files it in the right mailbox. Dovecot, Courier, procmail. |
A single machine often runs all three. In modern setups they are frequently separate services or separate providers entirely.
The protocols
| Term | What it does | Direction |
|---|---|---|
| SMTP | Simple Mail Transfer Protocol. The language servers speak to hand mail to each other. | Sending |
| ESMTP | Extended SMTP. The modern version, which added extensions like STARTTLS, authentication, size limits and 8-bit characters. When a server greets you with EHLO instead of HELO, you are speaking ESMTP. Almost everything today is ESMTP. | Sending |
| IMAP | Internet Message Access Protocol. Your client reads mail that stays on the server, synced across devices. | Receiving |
| POP3 | Post Office Protocol v3. Your client downloads mail and typically deletes it from the server. Largely obsolete. | Receiving |
| Submission | The specific act of a mail client handing a message to its own server, as opposed to server-to-server transfer. Uses port 587 with authentication. | Sending |
The distinction that trips people up: SMTP moves mail, IMAP and POP3 read mail. They are not alternatives to each other. You use SMTP to send and IMAP to receive, both, always.
The security layers
| Term | Spec | What it does |
|---|---|---|
| TLS | Transport Layer Security | Encrypts the connection. Replaced SSL, though people still say SSL out of habit. |
| STARTTLS | Part of ESMTP | Starts a connection unencrypted, then upgrades it to TLS. This is how nearly all server-to-server mail is encrypted. Its weakness is that an attacker in the middle can strip the upgrade offer. |
| Implicit TLS | Port 465 | The connection is encrypted from the first byte. No upgrade step to strip. |
| MTA-STS | RFC 8461 | Lets your domain declare that senders must use validated TLS and must never fall back to plaintext. Closes the STARTTLS stripping hole. |
| TLS-RPT | RFC 8460 | Asks sending providers to send you daily reports on TLS delivery failures. Pure reporting. Cannot break anything. |
| DANE / TLSA | RFC 6698, RFC 7672 | Pins your mail server's certificate in DNS. Requires DNSSEC. Common in the Netherlands, Germany and public sector, rare elsewhere. |
| DNSSEC | RFC 4033 to 4035 | Cryptographically signs DNS answers so tampering is detectable. Without it, an attacker who can forge DNS can redirect your MX lookup entirely. |
The reputation signals
| Term | What it means |
|---|---|
| PTR / reverse DNS | Maps an IP address back to a hostname, published by whoever owns the IP block. |
| FCrDNS | Forward-Confirmed reverse DNS. The PTR name resolves back to the same IP it came from. Receivers strongly prefer this. Missing or generic reverse DNS is one of the oldest spam signals there is, and a frequent reason self-hosted mail gets rejected. |
| Greylisting | The receiver temporarily rejects a first delivery attempt from an unknown sender. Real servers retry. Most spam software does not. |
| Smarthost / relay | An external SMTP server your machine hands all outbound mail to, instead of delivering it itself. How you send mail when port 25 is blocked. |
| Catch-all | A domain that accepts mail for every possible address. Makes mailbox verification impossible. |
| Null MX | RFC 7505. A record of 0 . (priority zero, a single dot) declaring the domain accepts no mail at all, so senders fail instantly instead of retrying for days. |
| Implicit MX | RFC 5321 behaviour where a sender finding no MX record may fall back to the domain's A record. Unreliable. Many senders do not try. |
Email ports: which one, and when
This table answers more support tickets than any other single thing in this article.
| Port | Protocol | Encryption | What it is for | Use it? |
|---|---|---|---|---|
| 25 | SMTP | STARTTLS | Server to server delivery. The only port MX delivery uses. | Yes, for MTAs. Never for mail clients. |
| 587 | SMTP submission | STARTTLS | Mail client to your own server, with authentication. | Yes. This is the default for sending from an app or client. |
| 465 | SMTPS | Implicit TLS | Client submission, encrypted from the first byte. Deprecated in 1998, then formally reinstated in 2018. | Yes, fine. Slightly safer than 587 in hostile networks. |
| 2525 | SMTP | STARTTLS | Not a standard. An unofficial alternative many providers offer when 587 is blocked. | Only as a fallback. |
| 143 | IMAP | STARTTLS | Reading mail. | Prefer 993. |
| 993 | IMAPS | Implicit TLS | Reading mail, encrypted. | Yes. Default for IMAP. |
| 110 | POP3 | STARTTLS | Downloading mail. | Only if you have a reason. |
| 995 | POP3S | Implicit TLS | Downloading mail, encrypted. | Only if you have a reason. |
The rule to remember: port 25 is for servers talking to servers. Port 587 is for you talking to your server. If a setup guide tells you to configure your email app on port 25, that guide is at least fifteen years out of date.
Port 25 and your cloud provider: the thing nobody warns you about
If you plan to run your own mail server, read this before you pick a host.
Almost every cloud provider blocks outbound port 25 by default. They do it because freshly created VPS instances are a favourite spam vector: a spammer spins one up, blasts a million messages, and abandons it. Blocking the port at the network layer kills that business model.
The consequence for you is that your mail server can receive mail perfectly and cannot send a single message. Your logs fill with connection timeouts and nothing explains why.
Here is roughly where the major providers sit:
| Provider | Outbound port 25 | Getting it opened |
|---|---|---|
| OVHcloud | Blocked by default at the network level | Unblock available through the Manager or a support request. Widely reported as granted on first request for accounts in good standing. |
| Hetzner | Blocked on new accounts | Opened on request, generally straightforward |
| DigitalOcean, Vultr | Blocked | Support ticket, usually granted with a stated use case |
| AWS EC2, Google Cloud | Blocked | Effectively a dead end. AWS largely stopped granting these years ago |
A note on OVH specifically, since it comes up constantly in self-hosting discussions. OVH is one of the more permissive mainstream hosts here, and its unblock path is documented rather than discretionary. But "permissive" is not the same as "open by default." OVHcloud's own documentation states that outgoing port 25 is blocked by default across dedicated servers, VPS and Public Cloud instances to prevent abuse, and directs you to use port 587 or request an unblock.
Two things worth knowing before you rely on it:
- The unblock is revocable. OVH runs anti-spam monitoring on its network. If mail from your IP gets flagged, port 25 is re-blocked, and repeated incidents extend the cooldown or make it permanent.
- Behaviour can vary by data centre and account age. Test it the moment you provision, not the day before launch.
And the honest advice, whatever your host: just because you can deliver directly on port 25 does not mean you should. A brand new IP address has no sending reputation, and building one takes months of consistent, low-complaint volume. For most people the right architecture is to run your own server for receiving and for control, and relay outbound mail through an established provider as a smarthost. You keep ownership of your data and skip the reputation problem entirely.
Who actually runs the world's email
There is a useful distinction here between who hosts the mailboxes and what software runs the server. Both matter, for different reasons.
The hosted providers
As of August 2026, the picture is dominated by exactly who you would guess. Google Workspace sits at 17.4% of surveyed sites and Microsoft 365 at 13.5%. Together that is roughly 31% of domains. The concentration is far higher among large organisations.
The middle of that list is the interesting part. Hostinger, IONOS, GoDaddy, Namecheap, Zoho and OVH together represent an enormous number of small business domains where nobody has ever looked at the authentication setup.
Reading the provider from the MX hostname
This is a genuinely useful skill. MX hostnames are a fingerprint.
| Provider | MX hostname pattern |
|---|---|
| Google Workspace |
smtp.google.com, or the older aspmx.l.google.com set |
| Microsoft 365 | <tenant>.mail.protection.outlook.com |
| Zoho Mail |
mx.zoho.com, mx2.zoho.com, plus regional variants |
| Proton Mail |
mail.protonmail.ch, mailsec.protonmail.ch
|
| Fastmail | in1-smtp.messagingengine.com |
| Amazon WorkMail / SES | inbound-smtp.<region>.amazonaws.com |
| Mimecast | hostnames ending mimecast.com
|
| Proofpoint | hostnames ending pphosted.com
|
| Barracuda | hostnames ending barracudanetworks.com
|
| Registrar or shared hosting |
mx1.registrar-servers.com, ...secureserver.net
|
The last three security vendors are worth calling out. Mimecast, Proofpoint and Barracuda are gateways. They sit in front of the real mailbox provider and filter everything. If you see one in an MX record, the actual mailbox host is hidden behind it, and the organisation is almost certainly an enterprise with a security budget.
The open source mail servers
If you self-host, this is the software that does the work.
The established MTAs:
- Postfix. Written by Wietse Venema in 1997 as a secure alternative to Sendmail. Modular, well documented, sane defaults. The default choice for most new deployments.
- Exim. Written at the University of Cambridge in 1995. Enormously flexible with a configuration language that can do almost anything. The default MTA on Debian and the standard in the cPanel shared-hosting world.
- Sendmail. The original, dating to 1983. Still running in places. Its configuration format is legendary in the way that a difficult mountain is legendary.
- qmail. Dan Bernstein's 1997 security-focused MTA. Development stalled for years. notqmail is the community continuation.
- OpenSMTPD. From the OpenBSD project. Deliberately minimal configuration, security-first design.
The modern generation:
- Stalwart. Combines MTA, delivery agent and IMAP access in one binary. Written in Rust.
- Mox. All-in-one server with automatic TLS via Let's Encrypt, built-in DMARC analysis and webmail.
- Chasquid. Lightweight, simple, with enforced TLS as a design principle.
- KumoMTA. Built for high-volume outbound sending rather than general mailbox hosting.
- Haraka. Node.js based, plugin-driven, popular where you need custom logic in the mail path.
The all-in-one stacks:
Mailcow, iRedMail, Mailu, Mail-in-a-Box, Modoboa, docker-mailserver, Poste.io.
Hosted versus self-hosted, honestly
I am going to be blunt, because a lot of writing on this topic is not.
The software is free. The operation is not. You are signing up for TLS certificate renewal, spam filtering that keeps working, blocklist monitoring, backups you have actually tested, security patching on an internet-facing service, and reputation management on an IP address that starts with none. The realistic cost is not the server, it is engineering hours forever.
Self-host when: you have a specific data residency or sovereignty requirement, you want to actually understand the stack, you are running a lab, or you have compliance rules that make third-party hosting difficult.
Use a provider when: email needs to work reliably and nobody on your team wants to be paged about it. Which is most people, most of the time. There is no shame in this.
The middle path is underrated: self-host for receiving and mailbox control, relay outbound through a reputable smarthost. You get the control without inheriting the deliverability problem.
MX versus SPF versus DKIM versus DMARC
These four get confused constantly, and fixing the wrong record is the usual outcome.
| Record | Direction | Answers | Published at | Spec |
|---|---|---|---|---|
| MX | Inbound | Which server accepts mail for this domain, and in what order | example.com, type MX | RFC 1035, RFC 5321 |
| SPF | Outbound | Which servers may send mail using this domain | example.com, TXT starting v=spf1
|
RFC 7208 |
| DKIM | Outbound | Was this message signed by a key the domain published, and unaltered since | selector._domainkey.example.com |
RFC 6376 |
| DMARC | Outbound | What receivers should do when SPF or DKIM alignment fails, and where to report |
_dmarc.example.com, TXT |
RFC 7489 |
A domain can receive mail perfectly and still fail every outbound authentication check. These are separate systems. Getting your MX right does nothing for your deliverability when sending, and vice versa.
Full tutorial: publishing MX records
Step 1: Decide where mail should land
Pick your provider first. Changing MX records later is easy, but migrating mailboxes is not.
Step 2: Get the values
Google Workspace, newer tenants:
1 smtp.google.com
Older tenants using the five ASPMX hosts do not need to migrate. Both are supported. Do not mix the two sets.
Microsoft 365:
0 yourdomain-com.mail.protection.outlook.com
One host per tenant. The label is your tenant's onmicrosoft.com prefix with dots replaced by hyphens. Microsoft publishes the exact value in the admin centre. Never guess it.
Zoho Mail:
10 mx.zoho.com
20 mx2.zoho.com
50 mx3.zoho.com
Regional suffixes such as .eu and .in exist. Use the ones your Zoho console shows.
Your own server:
10 mail.yourdomain.com
Then create an A record for mail.yourdomain.com pointing at your server's IP, and set the PTR record for that IP to mail.yourdomain.com in your host's control panel. All three must agree. This is forward-confirmed reverse DNS, and skipping it is the most common reason self-hosted mail gets rejected.
A domain that sends and receives nothing:
MX 0 .
TXT v=spf1 -all
TXT _dmarc v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; fo=1
That 0 . is a null MX. It tells senders to fail immediately and cleanly rather than retrying for four days. Combined with an empty SPF and a reject policy, it closes a domain attackers would otherwise like precisely because nobody is watching it.
Publish this on every parked domain, defensive registration and web-only hostname you own.
Step 3: Add them in DNS
| Field | What to enter |
|---|---|
| Type | MX |
| Name / Host |
@ or blank, meaning the root domain |
| Priority | The number, entered in its own field on most panels |
| Value / Points to | The mail server hostname, usually with a trailing dot |
| TTL | 3600 normally. Lower it to 300 before a planned migration. |
Three things that break setups:
- Never point an MX record at an IP address. It must be a hostname. Point the hostname at the IP with a separate A record.
- Never point an MX at a CNAME. It is explicitly not allowed and some senders will refuse it.
- Remove the old records when you migrate. Leaving the previous provider's MX in place at a higher priority means some mail keeps landing in a mailbox nobody reads.
Step 4: Add transport security, in this order
Do these one at a time. The order matters because the first one cannot break anything and the last one can.
Step 4a: TLS-RPT. Reporting only. Completely safe.
TXT _smtp._tls v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com
You now get daily reports on TLS delivery to your domain, including expired certificates and stripped connections. This is how you find out about problems before your users do.
Step 4b: MTA-STS in testing mode.
Two parts. The DNS record:
TXT _mta-sts v=STSv1; id=20260817T000000
And a policy file served over HTTPS with a valid certificate at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: smtp.google.com
max_age: 604800
In testing mode, failures are reported through TLS-RPT rather than enforced. Nothing breaks.
Step 4c: Enforce. Change one word and update the id:
mode: enforce
Two things that catch people out. Every MX host you accept mail on must be listed in the policy file, or mail to the missing one fails. And you must change the id value whenever you edit the file, otherwise senders keep serving the cached policy until max_age expires.
Step 4d: DANE, only if your zone is DNSSEC-signed. Publish a TLSA record at _25._tcp.<your MX host>. DANE is meaningful only with DNSSEC, because the certificate pin is only trustworthy if the DNS answer itself is signed. It is widely deployed in the Netherlands, Germany and parts of the public sector, and rare elsewhere. MTA-STS is the more common route. Either beats neither.
Step 5: Test everything at once
Use the free MX Record Checker from EmailVerifyerAPI. It runs nine records in one query and explains each result in plain English.
One lookup returns:
- MX hosts with priorities and TTLs
- The mail provider, matched from the hostname patterns
- SPF and DMARC, so you see the outbound half in the same view
- MTA-STS, TLS-RPT and DANE, the transport security layer almost no free checker shows
- Reverse DNS, resolving the primary MX to its IP and reporting the PTR
- DNSSEC, reported through the authenticated-data flag on the MX answer
- A verdict: configured, fallback only, or nothing at all
No account, nothing stored, and only the domain is sent to a public resolver.
What a real result looks like. Run github.com through it and you get one MX record at priority 0 pointing at github-com.mail.protection.outlook.com, immediately identifying Microsoft 365. SPF is published with a long list of includes covering Outlook, Google netblocks, Zendesk, Salesforce, Mailchimp, Marketo and SendGrid. DMARC is at p=quarantine with sp=reject and reporting enabled. MTA-STS, TLS-RPT and DANE are all absent. Reverse DNS resolves correctly. DNSSEC is unsigned.
That is a well-run domain that has done the authentication work and not yet done the transport work, which describes the large majority of the internet. Absence of MTA-STS and DANE is graded as amber rather than red for exactly that reason: it is an available hardening step, not a fault.
One documented limitation: MTA-STS has a DNS half and an HTTPS half. A browser-based tool can report the DNS half but cannot fetch the policy file from another origin. A domain with the TXT record but no reachable policy file is not actually enforcing anything, so verify the file loads yourself.
Pair it with the dedicated SPF, DKIM and DMARC checkers when you need to go deep on one record.
Step 6: Send a real test
Send a message to an address on the domain. Then send one from it. Both directions, because they exercise completely different records.
Why MX matters for your email list
There is a commercial angle here that is easy to miss.
Roughly 22% of marketing email addresses go invalid every year as people change jobs and companies fold, according to HubSpot's research. A domain-level MX lookup catches an entire category of those failures in a single query: dead domains, parked domains, and domains never configured for mail at all.
It is the cheapest possible bounce check. It costs one DNS query and it runs in milliseconds.
What it cannot tell you is whether a specific mailbox exists. Only an SMTP handshake can attempt that, and catch-all domains accept every address anyway, so even then the answer can be inconclusive. MX proves the door exists. It says nothing about who lives there.
The seven mistakes I see most often
- No MX record on a domain that receives mail. The A record fallback is unreliable and many senders never try it.
- MX pointing at an IP address. Not allowed. Use a hostname with its own A record.
- MX pointing at a CNAME. Also not allowed, and some senders will hard fail.
- Old provider's MX left in place after a migration. Mail quietly splits between two mailboxes.
- No PTR record on a self-hosted sender. One of the oldest spam signals in existence.
- Nothing on parked domains. Publish the null MX.
- Confusing MX with SPF. Adding your sending platform to your MX records does absolutely nothing. MX is inbound only.
A ready-to-paste Claude prompt for building your mail server
If you are going to self-host, this is where an LLM genuinely earns its keep. Mail server configuration is a large amount of interlocking, well-documented, unforgiving detail, which is exactly the shape of problem Claude is good at.
Copy the prompt below, fill in the bracketed values, and paste it into Claude. Ask follow-up questions as you work through it rather than trying to execute the whole thing blind.
You are an experienced mail server administrator. I want to deploy a
production-grade mail server and I need a complete, ordered configuration
plan I can follow step by step.
MY SETUP
- Domain: [yourdomain.com]
- Hosting provider: [OVHcloud / Hetzner / DigitalOcean / other]
- Server type and specs: [VPS, 4 vCPU, 8 GB RAM, Ubuntu 24.04]
- Static IPv4: [x.x.x.x] IPv6: [yes / no]
- Expected volume: [e.g. 200 messages/day outbound, 20 mailboxes]
- Outbound port 25 status: [open / blocked / unblock requested]
- Preferred stack: [Postfix + Dovecot / Mailcow / Stalwart / recommend one]
- Outbound delivery: [direct on port 25 / relay through a smarthost]
- My Linux comfort level: [beginner / intermediate / advanced]
WHAT I NEED FROM YOU
STACK RECOMMENDATION
Given my volume, comfort level and provider, recommend a stack and
explain the tradeoff in two or three sentences. If self-hosting is a
bad idea for my situation, say so plainly and tell me why.PRE-FLIGHT CHECKS
Exact commands to verify before I install anything: is outbound port 25
actually open, is my IP on any major blocklist, can I set a PTR record
with this provider, is my IP range already burned.DNS RECORDS
Give me every record as a table I can work through: MX with priority,
the A record for the mail hostname, PTR, SPF, DKIM, DMARC starting at
p=none, TLS-RPT, and MTA-STS in testing mode. Show the literal values
with my domain substituted in. Flag which ones I must get from the
software after installation rather than write in advance.INSTALLATION
Ordered commands for my exact OS version. After each block, tell me
what to check to confirm it worked before moving on.TLS
Certificate issuance and automatic renewal. Which ports listen with
implicit TLS and which use STARTTLS, and why.SECURITY BASELINE
Firewall rules with the specific ports. SASL authentication so I am
not an open relay, and the exact command to verify I am not. Rate
limiting. fail2ban. Disable anything I do not need.ANTI-SPAM
Inbound filtering (rspamd or SpamAssassin), and the outbound hygiene
that keeps my IP clean.DELIVERABILITY WARM-UP
A realistic schedule for a brand new IP with no sending history, and
the specific signals that tell me it is going badly.VERIFICATION CHECKLIST
Every test to run before I trust this with real mail: authentication
headers on a delivered message, open relay test, TLS check, blocklist
check, MX and reverse DNS confirmation.OPERATIONS
What to monitor, what to back up, what breaks silently, and what to
check monthly. Include the specific log lines that indicate trouble.
RULES
- Ask me clarifying questions before generating the plan if any of my answers above are ambiguous or contradictory.
- Explain the reasoning behind each significant choice in one line. I want to understand the system, not just paste commands.
- Flag every step that is destructive or hard to reverse.
- Where a hosted service would be the better engineering decision, say so.
- Assume I will get something wrong, and tell me how I will know.
Two caveats worth stating. Verify every command against the official documentation for your distribution and your software version before running it on a production box, because syntax drifts between releases. And check the output against your provider's own docs on port 25 and PTR records, since those policies change and are provider-specific.
Used well, this turns a multi-day research project into an afternoon. Used carelessly, it turns into an open relay. The difference is whether you read what you are pasting.
Frequently asked questions
What is an MX record?
A DNS record naming the mail server responsible for accepting email for a domain, along with a priority number. Sending servers look up the MX records for the part after the @ and connect to the host with the lowest priority value first.
What does the MX priority number mean?
It sets the order senders try the listed hosts. Lower numbers are tried first, so priority 10 is preferred over 20. Hosts sharing the same value are used in random order to spread load. Higher-numbered hosts act as backups.
What happens if a domain has no MX record?
RFC 5321 allows a sender to fall back to the domain's A or AAAA record, known as the implicit MX rule. In practice this is unreliable, since many providers do not attempt it, so mail is likely delayed or rejected. A domain with neither MX nor A records cannot receive mail at all.
Does a valid MX record mean the email address exists?
No. It only proves the domain has somewhere to deliver. Confirming a specific mailbox requires an SMTP handshake, and catch-all domains accept every address, so even that can be inconclusive.
What is the difference between port 25 and port 587?
Port 25 is for server-to-server delivery between mail transfer agents. Port 587 is for a mail client submitting a message to its own server, with authentication. Configure your apps and clients on 587. Never on 25.
What is the difference between SMTP and ESMTP?
ESMTP is the extended, modern version of SMTP. It added STARTTLS encryption, authentication, message size limits and 8-bit character support. A server greeting with EHLO rather than HELO is speaking ESMTP, which today is essentially all of them.
What is the difference between IMAP and POP3?
IMAP leaves mail on the server and syncs it across devices. POP3 downloads mail to one device and typically deletes the server copy. Use IMAP unless you have a specific reason not to.
Why is my cloud provider blocking port 25?
To prevent spam from compromised or disposable instances, which are a major source of abuse. Most providers will unblock it on request with a stated legitimate use case. AWS and Google Cloud are the notable exceptions where it is effectively permanent.
Can I use OVH for a mail server?
Yes, and it is one of the friendlier mainstream hosts for it. Outbound port 25 is blocked by default at the network level, but OVH provides a documented unblock path through the Manager or a support request, generally granted for accounts in good standing. Be aware the unblock is revocable if the IP is later flagged for spam.
What is MTA-STS and do I need it?
MTA-STS lets your domain declare that senders must use validated TLS and must never fall back to plaintext, closing the hole where an attacker strips the STARTTLS offer. It is not required, but it is a meaningful hardening step. Deploy TLS-RPT first, then MTA-STS in testing mode, then enforce.
What is a null MX record?
A record of 0 . declaring that a domain accepts no mail. Senders fail immediately and cleanly instead of retrying for days. Publish it on every parked and brand-defensive domain you own, alongside v=spf1 -all and a DMARC reject policy.
Can an MX record point to an IP address or a CNAME?
No to both. An MX record must name a hostname, and that hostname must resolve through an A or AAAA record, not a CNAME. Pointing an MX at a CNAME is explicitly disallowed and some senders will reject it.
Which open source mail server should I use?
Postfix paired with Dovecot is the conventional answer and the best documented. Mailcow or iRedMail if you want a full stack with a control panel rather than assembling one. Stalwart or Mox if you want a modern single-binary approach. Exim if you are already in the cPanel world.
Why do my MX changes not show up yet?
DNS answers are cached for the length of each record's TTL. Until it elapses, resolvers may keep serving the old answer. Lower the TTL before a planned migration and raise it afterwards.
Your action plan
Right now, 5 minutes:
- Run your domain through the free MX checker.
- Confirm you have MX records, that they point at hostnames rather than IPs, and that no old provider is still listed.
- Note whether SPF and DMARC came back found.
This week, 30 minutes:
- Publish the null MX set on every parked domain you own.
- Add TLS-RPT. It is one record and it cannot break anything.
- If you self-host, confirm your PTR record resolves forward and back.
This month:
- Deploy MTA-STS in testing mode, read the TLS-RPT reports, then enforce.
- Finish the outbound side: SPF, then DKIM, then DMARC to enforcement.
- Set a quarterly reminder to re-run all four checkers.
MX is the record that decides whether mail reaches you at all. Everything else in email authentication decides whether your mail reaches other people. You need both, and they are entirely separate jobs.
If you only do one thing today, run your domain through a checker and see what nine records say about a setup you probably have not looked at in years.
Top comments (0)