Sendmail SMTP settings (quick reference)
- SMTP host:
mail.yourdomain.com(hostname of your Sendmail server) - Ports: 25 (server‑to‑server), 587 for submission if configured, 465 for legacy SMTPS in some setups
- Encryption: STARTTLS on 25/587 when enabled; implicit TLS on 465 if exposed
- Username: Mailbox or app user in your auth backend (system accounts, virtual users, etc.)
- Password: Credential tied to that user
- Auth: Authentication required on submission ports; never expose a public open relay
What Is Sendmail?
Sendmail is one of the oldest and most influential MTAs, originally created in the early days of the internet to route email between Unix systems. For decades, it was the de facto standard MTA on many Unix and early Linux distributions.
Today, Sendmail is best understood as legacy but still present: it powers older infrastructures, in‑place upgrades, and niche use cases where compatibility or “don’t touch a working box” culture dominates. For new deployments, however, virtually all modern guidance recommends Postfix or Exim instead, with Sendmail reserved for maintaining or carefully unwinding existing systems.
Where Sendmail Still Makes Sense (and Where It Doesn’t)
When Sendmail is a rational choice
| Scenario | Why Sendmail is still acceptable |
|---|---|
| Legacy Unix / commercial software | Vendor stack hard‑coded or certified only against Sendmail. |
| Minimal‑change environments | High‑risk systems where “if it works, don’t touch it” truly applies. |
| Deep in‑house Sendmail expertise | Team has years of operational experience and stable, known configs. |
| Short‑horizon systems | Server will be retired/migrated soon; not worth a full MTA swap now. |
If you fit one of these and the system is stable, hardened, and tightly controlled, keeping Sendmail live for now can be a pragmatic decision.
When you should not pick Sendmail
- Any new MTA deployment (greenfield or major re‑architecture).
- Environments where you need rapid onboarding of new engineers; Sendmail’s config is a tax.
- High‑volume, multi‑tenant infrastructure where flexibility and maintainability matter more than “old default”.
In other words: maintain Sendmail where you must, but don’t choose it for new builds.
Sendmail Architecture and Configuration: Why People Still Fear It
High‑level architecture
Sendmail, like other MTAs, receives messages, routes them, queues them, and delivers them. The core differences are in its architecture and config model:
- A central
sendmaildaemon handles SMTP reception and queue management. - Monolithic binary with many command invocations (
sendmail,newaliases, etc.) acting as different modes. - Historically, a very complex configuration file (
sendmail.cf) written in a macro language.
sendmail.cf vs .mc and modern tooling
The horror stories are mostly about sendmail.cf: a dense, macro‑expanded file that is painful to edit directly. Modern practice is:
- Write high‑level macros in a
.mcfile. - Use
m4to generatesendmail.cffrom that.mc. - Use macros for common patterns: enabling auth, TLS, smart‑host routing, access controls, etc.
Even with macros, the learning curve is steep compared to Postfix/Exim, and this is a core reason many teams standardize on other MTAs.
How Sendmail Compares to Postfix and Exim
Strategic positioning
| Dimension | Sendmail | Postfix | Exim |
|---|---|---|---|
| Age / design era | Oldest of the three | Modern, security‑oriented architecture | Modern, “framework‑like” configuration |
| Config complexity | High; macro language + sendmail.cf | Moderate; parameter‑based, modular | High; powerful, scripting‑style language |
| Best suited for | Legacy, compatibility, “don’t touch” systems | New general‑purpose mail servers | Complex routing, multi‑domain hosting |
| Performance & scaling | Solid but less efficient in many benchmarks | Excellent performance and queue handling | High, depends on routing complexity |
| Learning curve | Steep | Reasonable | Steep (different kind of complexity) |
If your goal is authority and modern best practices, your Sendmail content shouldn’t pretend it’s “one of three equal choices”. It should explicitly state:
- If you’re starting fresh, go with Postfix or Exim.
- If you’re on Sendmail today, here’s how to evaluate whether to migrate, and how to do it safely.
Modern Sendmail Use Cases (Realistic, Not Idealized)
Legacy Unix / vendor stack
Some commercial apps (especially older ERP/Unix‑stack software) assume sendmail exists and call it directly via CLI. Replacing it might mean touching vendor‑unsupported scripts and binaries. In this case:
- You keep Sendmail, but harden, monitor, and restrict it.
- You may front it with a newer relay for outbound traffic while preserving local call semantics.
Transition environment (Sendmail front, modern back)
A common pattern during migration:
- Sendmail remains on the legacy host to keep local processes happy.
- Outbound routing is changed so Sendmail relays to a modern MTA (Postfix/Exim/PowerMTA) as a smart host.
- Inbound MX can be shifted away from Sendmail entirely.
Short‑life or isolated systems
For systems that will be decommissioned soon, or where email volume and risk are minimal, deeply re‑architecting the MTA might not be worth it. The key is to lock Sendmail down so it can’t be abused as an open relay or compromised entry point.
SMTP Behavior and Typical Sendmail Config Patterns
Typical SMTP submission and relay
- In legacy setups, users or apps often use port 25 with weak or no auth (bad by modern standards).
- A hardened deployment should:
- Use submission ports (587) with AUTH and TLS for users and apps.
- Restrict port 25 primarily to server‑to‑server traffic and controlled sources.
Common configuration patterns you still see
- Local daemons calling
/usr/sbin/sendmailto inject messages into the queue. /etc/mail/accesscontrolling who can relay, often using outdated or incomplete rules.- Smart‑host configurations where Sendmail forwards all outbound mail to another MTA.
Security and Deliverability Risks with Sendmail
Security risks
- Open relay risk: many of the worst open‑relay incidents historically involved misconfigured Sendmail.
- Outdated defaults: older distributions ship with defaults that are not aligned with 2026 best practices.
- Attack surface: long history and codebase mean careful patch management is mandatory.
Deliverability and reputation risks
- Inconsistent use of TLS, SPF, DKIM, and DMARC in legacy setups.
- HELO/EHLO names and reverse DNS often misaligned on old boxes that were never revisited.
- Bulk or quasi‑bulk traffic sometimes pushed through Sendmail from scripts with zero warm‑up or throttling.
If Sendmail is sending anything meaningful to Gmail/Microsoft/Yahoo in 2026, you must treat it like any other MTA-warm‑up, IP hygiene, authentication, monitoring-regardless of how old the software is.
Migration: From Sendmail to Postfix/Exim (The Real Playbook)
Step 1, Inventory and risk assessment
- Identify all ways mail is injected:
- Local
/usr/sbin/sendmailcalls (cron, apps, system daemons). - SMTP clients pointing to the server (hosts, apps, printers, scanners).
- Local
- Map roles: inbound MX, outbound relay, local delivery to system mailboxes, aliases, mailing lists.
- Measure volume: daily/peak messages, per domain, per application.
Step 2, Decide migration strategy
- Big bang: replace Sendmail completely with Postfix or Exim on the same host (common in small installs).
- Side‑by‑side: stand up a new host with Postfix/Exim and drain traffic from Sendmail (safer at scale).
- Front/back split: modern MTA as inbound MX and primary outbound; Sendmail remains only for legacy local delivery until apps are updated.
Step 3, Stand up the new MTA
- Build and harden Postfix or Exim on a new host or in parallel on the same machine.
- Recreate key behaviors: local delivery patterns, aliases, domain routing, smart‑host logic.
- Test with test domains and non‑critical paths before moving real production traffic.
Step 4, Gradual traffic cutover
- Move inbound MX DNS to the new MTA first (if possible), letting Sendmail only serve remaining local processes.
- Update app and device SMTP settings to point to the new MTA.
- For local
sendmailcalls, either:- Replace the
sendmailbinary with a wrapper to Postfix/Exim equivalents, or - Keep Sendmail but route all outbound mail to the new MTA as a smarthost, then slowly phase it out.
- Replace the
Step 5, Queue draining and retirement
- Allow Sendmail to drain its queues fully (days, not minutes).
- Keep the old host in a “receive only / flush only” mode for a while in case delayed messages show up.
- Once you’re confident all flows are moved and stable, disable Sendmail services and decommission.
Sendmail for Modern Deliverability: If You Must Keep It
Hardening checklist
- Enforce authentication on submission ports (587), with TLS required.
- Tighten
/etc/mail/accessto strictly limit relaying to known networks and authenticated users. - Ensure HELO/EHLO, reverse DNS, SPF, DKIM, and DMARC all align for sending domains.
- Disable obsolete/weak ciphers and protocols where possible.
Operational and monitoring checklist
- Monitor queue size, bounce patterns, and error codes like you would with Postfix/Exim.
- Alert on spikes of outbound volume (potential compromise) and on repeated 4xx/5xx from major providers.
- Log and review authentication failures and rejected relays.
A hybrid pattern-Sendmail as a local injector forwarding to a modern outbound MTA-can give you better deliverability while keeping local compatibility.
Pros, Cons and Honest Recommendation
Pros
- Ubiquitous in older Unix environments; lots of legacy scripts and tools expect
/usr/sbin/sendmail. - Very powerful and configurable if you already know the macro language.
- Can still be secured and operated reliably with discipline and experience.
Cons
- Steep learning curve and configuration complexity compared to Postfix/Exim.
- Defaults and ecosystem are tuned for a previous era of email, not modern SaaS/ESP workloads.
- Makes hiring and handover harder; fewer engineers are comfortable with Sendmail today.
Practical recommendation
- New build? Use Postfix or Exim (or a commercial MTA), not Sendmail.
- Existing Sendmail system that works? Harden it, monitor it, and put a migration plan on your roadmap.
- Complex or high‑volume use cases? Strongly consider moving to a more modern MTA as part of an infrastructure refresh.
Sendmail FAQ
Is Sendmail still “good enough”?
It can be, but it’s no longer the default choice. It’s “good enough” for stable, legacy systems with low change and strong expertise; for new builds, most experts reach for Postfix/Exim or commercial MTAs.
Why do some distributions still ship Sendmail?
Primarily for compatibility and continuity: it remains an option for admins who depend on it, but most modern install guides recommend switching to alternatives during setup.
Should I migrate from Sendmail to Postfix or Exim?
If you’re actively touching your mail infrastructure and plan to keep it for years, yes. Migrations give you better security defaults, easier config, and a larger pool of engineers who can maintain it.
Can I run Sendmail just as a wrapper while using another MTA?
Yes. A common pattern is to keep a sendmail‑compatible binary on legacy hosts that simply hands mail to Postfix/Exim/another MTA, letting you maintain compatibility while moving real delivery to a modern engine.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
