DreamHost Email Settings: 587, and Nothing Above It

Reading time: 11 min · Last verified: August 2026 · SMTPedia editorial team

Nearly every provider we have documented publishes two outgoing ports and calls one of them the secure one. DreamHost publishes two as well, and calls both of them something else. In its own client configuration table, port 587 sits on a row labelled Insecure Transport, and port 25 sits on a row labelled Outdated and not recommended. There is no third row. Port 465, the implicit-TLS submission port that Rackspace treats as its only outgoing option and that HostGator puts alone in its encrypted block, does not appear anywhere in DreamHost’s email documentation. Not as an alternative, not as a legacy note, not at all.

That is unusual enough to be the whole story of this page. It is also the part every AI summary of these settings gets backwards: ask Google for DreamHost email settings today and the generated answer prints 587 under the heading Secure via STARTTLS, citing the very DreamHost page whose table says the opposite word.

The Settings DreamHost Actually Publishes

These are transcribed from DreamHost’s Email client configuration overview, which is the article its own support pages point back to, and cross-checked against its per-client guides for Outlook, mobile Outlook, Mac Mail and iPhone. Where those guides disagree with each other, that is called out further down rather than smoothed over.

The word choice in that second table is not sloppiness. Under the naming convention that the submission RFCs settled on, a session that opens in cleartext and negotiates its way up is opportunistic TLS, and a session that is encrypted from the first byte is implicit TLS. DreamHost is describing the transport, not the outcome: 587 begins unencrypted and is upgraded. Most providers gloss that distinction and print the word “secure” next to 587 anyway. The mechanics behind the two models, and why the distinction stopped being academic once downgrade attacks were demonstrated, are laid out in our reference on SMTP, IMAP and POP3 ports and their TLS requirements.

What matters operationally is smaller and blunter: if your client offers you an SSL/TLS choice on the outgoing server, choose STARTTLS on 587, not SSL on 465. Selecting 465 against smtp.dreamhost.com is configuring for a service DreamHost has never documented. If your client refuses to hold the setting, the failure surfaces as a hang rather than an error, which is the same misdiagnosis trap described in our guide to setting up SSL and TLS for email.

What the AI Answer Gets Wrong About 587

We measured the AI Overview served on the query dreamhost email settings in the United States. It prints a clean three-block answer, and its hostnames and incoming ports are correct. Its outgoing block reads:

The hostname is right, the port is right, the authentication requirement is right. The parenthetical is a word that DreamHost’s table does not use and, on that row, actively contradicts. Four sources are cited under that block, three of them DreamHost’s own pages, and none of them puts 587 in a secure column.

This is the same class of defect we have now measured on four consecutive provider pages, and it is worth naming precisely, because it is not hallucination. Each individual value is real. The summary layer flattens two tables into one and carries a label across a boundary the source never crossed. On Bluehost the same mechanism merged two separate email products into a single table, and on IONOS it resolved a genuine provider self-contradiction between 465 and 587 by picking one silently. Here it simply relabels a row.

One Set of Hostnames, One Address Behind Them

DreamHost is the opposite of a cPanel host in the one respect that causes the most configuration failures elsewhere. On HostGator your incoming and outgoing host is a numbered machine name such as gator1234.hostgator.com, and copying a neighbour’s settings gets you a real server that has never heard of your mailbox. DreamHost gives everyone the same three names, and its Outlook guide is explicit that you should not substitute anything of your own:

Make sure you only enter your DreamHost mail servername. Do not use a subdomain such as mail.example.com.

We resolved the names before publishing, with negative controls, because a settings page that prints a hostname is making a claim about DNS.

Two things follow. First, the three documented names currently answer at a single address, so IMAP, POP and SMTP are fronted by the same endpoint; that is a snapshot, not a promise, and you should still enter the name DreamHost publishes for each protocol rather than reusing one. Second, and more useful in practice: because there is no wildcard, a typo in the hostname fails as a lookup error rather than as an authentication prompt. If your client is asking for the password again and again, the hostname is almost certainly right and something else is wrong. That distinction between a name that does not resolve and a name that resolves to the wrong thing is the first branch in our IMAP configuration reference and in the matching POP3 configuration guide.

Ports were not probed. Outbound 25, 110, 143, 465, 587, 993 and 995 are all blocked from our test environment, so nothing on this page asserts a successful handshake. Every port above is transcribed from DreamHost’s documentation, not measured.

Port 25 Is Blocked Outbound, by DreamHost, on DreamHost

DreamHost blocks port 25 for outgoing SMTP calls on its own shared hosting servers. The restriction does not apply on Managed VPS or Dedicated plans. Its guidance when you hit it is a single line: configure your email client to use 587 with STARTTLS.

This matters for a specific and frequently misread scenario. Code running on a DreamHost shared server that tries to reach an external mail host on 25 will fail, and the failure often surfaces inside an application as a generic timeout rather than as a connection refusal. It is not a firewall on the far end and it is not a reputation problem: it is the outbound rule on the machine your script is sitting on. The rejection shapes that do come from the far end look different, and the difference is worth knowing before you start changing DNS. A relay refusal reads as 454 4.7.1 relay access denied or 550 5.7.1 relaying denied, and a TLS policy refusal reads as 550 must issue STARTTLS. A blocked outbound port produces no SMTP reply at all, because no session ever opens.

The mirror image of this rule is the one consumer ISPs apply to their own subscribers, which is why Comcast and Xfinity customers are pushed onto 587 and why HostGator lists 25, then 26, then 587 as a descending fallback chain. DreamHost skips the middle step entirely: it has no port 26, and no equivalent.

The Sending Limit Counts Recipients, Not Messages

Most hosts publish an hourly cap and leave you to assume it counts messages. DreamHost states the opposite in plain language: the limits are based on the number of recipients, not the number of messages, and they apply per individual email address rather than per domain. One message to eighty people spends eighty units of your hourly budget, not one.

Two rows there deserve to be read twice. The shared-server script allowance of 200 an hour is per server, not per customer, which means it is a budget shared with every other site on that machine and is not something you can plan a send around. And the per-message recipient cap drops from 100 to 40 the moment the send comes from a script rather than from a client, so a newsletter loop that batches fifty addresses per envelope will fail on a shared plan while the same list succeeds from Thunderbird.

Message size is capped separately: 40 MB encoded from an email client, a web form or a server script, and 30 MB from Webmail. Encoded is the operative word, since base64 inflates an attachment by roughly a third before it crosses the wire; the arithmetic, and why a 30 MB file is not a 30 MB message, is worked through in our page on attachment size limits in Gmail, Outlook and on the wire.

The Block Clears After an Hour of Silence, Not After an Hour

This is the single most consequential sentence in DreamHost’s email documentation, and it is the one almost nobody reads carefully. When you exceed the quota, the sending address is blocked and DreamHost returns a Policy Rejection- Quota Exceeded error. Then:

The block remains in place until at least one hour has passed, during which time there have been no further attempts to send mail from the email address.

There is a harder consequence behind it. DreamHost states that email addresses blocked repeatedly for attempting to exceed the sending limit are blocked permanently by the system. An outbox on automatic retry is, from the platform’s point of view, exactly the pattern of repeated attempts that earns a permanent block. The lesson generalises past this host: an automatic retry against a rate limit is not a neutral act, and the same reasoning is why deferrals like 421 4.2.1 please try again later and 421 4.7.0 messages temporarily deferred due to unexpected volume ask you to back off rather than to insist. Where a client opens too many simultaneous connections rather than sending too much, the reply is instead 421 4.7.0 too many connections.

Note also what the quota is not. It is not a bounce and it is not a delivery failure at the recipient’s end. A full mailbox on the far side produces 452 4.2.2 out of storage space, which is somebody else’s problem to fix. A quota rejection is generated before the message ever leaves DreamHost. If you are trying to identify which of the two you are looking at, the full reference is our directory of SMTP error codes.

If your actual requirement is bulk or automated sending, none of the above is a limit to work around; it is a signal that mailbox hosting is the wrong tool. The distinction between a mailbox and a sending service, and where each one stops, is covered in our explainer on what a transactional email actually is and in the plan-by-plan comparison of what business email hosting lets you do.

DreamHost Email Has No Multifactor Authentication, So App Passwords Do Not Exist

DreamHost offers multifactor authentication on its web panel. On mailboxes, it states the position without qualification: DreamHost email service does not support Multifactor Authentication. There is consequently no app-specific password, no application password screen, and nothing to generate.

We flag this because incorrect advice on the point is currently ranking. A Microsoft support thread sitting in the top ten for this query, and cited as a source by the AI Overview itself, tells a user who cannot connect an IMAP account to generate an app password if two-factor authentication is enabled in DreamHost. Followed literally, that instruction sends someone hunting through a panel for a screen that is not there, on the assumption that their real problem is authentication, when the mailbox uses nothing but the password created alongside it.

The absence is worth weighing rather than glossing. Providers built around mailbox security have moved the other way: Google Workspace gates legacy client access behind OAuth and app passwords, and Microsoft 365 has been retiring basic authentication for years. A DreamHost mailbox is protected by one password over an authenticated, encrypted session, and that is the entire security model. It is simple to configure. It also means the password is the only thing standing in front of the mailbox, which is an argument for a long and unique one rather than for a shrug.

The Same Three Names, Client by Client

DreamHost publishes separate walkthroughs per client, and they agree on the values. What differs is the label each client puts on the encryption field, which is where people go wrong.

The mobile Outlook row is the one to read closely, because it contains the trap in miniature: SSL/TLS on the incoming server and STARTTLS on the outgoing server, in the same account, on purpose. A person who assumes both dropdowns should match will set outgoing to SSL/TLS, which on 587 produces a connection that stalls rather than a message that errors. Field-by-field walkthroughs for the individual clients are in our email clients directory, and the installers themselves are catalogued for Microsoft Outlook and Apple Mail. The general procedure for getting authentication, ports and TLS agreeing in any client is in our SMTP setup guide.

What DreamHost Does Not Publish

Listed rather than filled in from a comparison table, because an invented number is worse than an absent one.

• Port 465. Absent from the configuration overview, the mobile Outlook guide, the Office 365 guide, the Mac Mail guide and the port 25 article. We are not asserting it is closed, only that DreamHost does not document it
• A per-machine mail server hostname. Unlike cPanel hosts, DreamHost publishes one set of names for all customers
• A fixed mailbox storage quota stated as a number in the client configuration material
• App passwords or MFA on mailboxes. Explicitly unsupported, not merely undocumented
• A daily sending total. The published figures are hourly and per recipient; multiplying by 24 produces a number DreamHost never states

Symptom to Cause

The last row is the one that changes what you should be reading. Settings govern whether your client can hand a message to DreamHost; authentication records govern whether anyone accepts it afterwards. If mail leaves cleanly and disappears, the next checks are your domain’s MX configuration and your published sender policy, which you can draft with our SPF record generator and sign with the DKIM record generator. Redirected mail deserves its own look, since forwarding is the classic way a correctly configured domain starts failing authentication downstream: that case is covered in our guide to email forwarding and its DMARC pitfalls.

How DreamHost Compares to the Hosts Next to It

Read down that last column and DreamHost is the outlier, which is precisely why generic settings tables mislead here. The market convention is 465 and DreamHost has not adopted it. If you are choosing rather than configuring, the trade is between an operator that documents one clear path and operators that give you two, and our comparison of business email hosting plans sets out what else moves with that choice. Consumer providers make the same choice on different grounds, as the six-port sprawl on Optimum and the independent-provider pattern on Webmail.co.za both show.

Frequently Asked Questions

What is the SMTP server for DreamHost email?

It is smtp.dreamhost.com for every DreamHost mailbox. DreamHost’s Outlook documentation states that the outgoing server is always that name and warns against entering a subdomain of your own domain such as mail.example.com. Use port 587 with STARTTLS and authentication switched on, with your mailbox address and its password.

Is DreamHost POP3 or IMAP?

Both. DreamHost publishes imap.dreamhost.com on port 993 with SSL and pop.dreamhost.com on port 995 with SSL, and you choose when you add the account. IMAP keeps mail on the server and synchronises across devices; POP downloads it. Unencrypted 143 and 110 are documented too, and there is no reason to use them. The trade between the two protocols is set out in our IMAP configuration reference.

What port does DreamHost SMTP use?

587, with STARTTLS. DreamHost also documents port 25, which it describes as outdated and not recommended and which it blocks outbound on its own shared hosting servers. Its configuration table labels the 587 row Insecure Transport (Upgraded to a secure connection using STARTTLS), which describes how the session starts rather than how it ends. 587 remains the correct and recommended choice.

Does DreamHost support port 465?

DreamHost does not publish port 465 in any of its email configuration articles. Its outgoing table lists 587 and 25 and nothing else, and 465 is absent from its client guides for Outlook, mobile Outlook, Mac Mail and iPhone as well as from its port 25 article. If a settings table you found elsewhere shows 465 for DreamHost, it was not copied from DreamHost. Configure 587 with STARTTLS.

Why did my DreamHost email stop sending?

Most often the hourly quota. DreamHost allows 100 recipients an hour per address from a mail client, webmail or a web form, counting recipients rather than messages, and returns Policy Rejection- Quota Exceeded when you pass it. The block lifts only after a full hour during which nothing has attempted to send from that address, so a client retrying an outbox keeps resetting the clock. Close the client and wait.

Do I need an app password for DreamHost email?

No. DreamHost states that its email service does not support multifactor authentication, and there is no app-specific password to generate. Your client wants the password created for that mailbox, which is not your DreamHost account password. Advice circulating online telling DreamHost users to generate an app password is describing a feature that does not exist on this platform.

How big an attachment can a DreamHost mailbox send?

DreamHost publishes 40 MB encoded from an email client, a web form or a server script, and 30 MB from Webmail. Encoded matters: base64 adds roughly a third, so a file comfortably under the cap on disk can exceed it on the wire. The arithmetic is worked through in our page on attachment size limits.

The Short Version