Outlook send from custom domain SMTP is a manual outgoing identity, not a new mailbox. Forwarded mail can already land in Outlook. Replies still leave as your Microsoft address until you attach paid MailerZ SMTP and pick an approved From. Copy the dashboard host, port, and encryption pair. Do not point Outlook at MX hosts. Labels differ across classic Outlook, new Outlook, and the web app.
Quick answer for outlook send from custom domain smtp
You need three facts before you touch Outlook. The domain is verified. Named aliases exist. Inbound MX is a single set with leftover Google or Microsoft MX deleted. Then you need a paid plan. Free has no send-as. Unauthorized From values get SMTP 550 / 550 5.7.1 because MailerZ is not an open relay.
SMTP is the submission path in IETF RFC 5321 — Simple Mail Transfer Protocol. Outlook is a client. It must AUTH, use the encryption pair you copy, and submit a From the server accepts. If you only add a display name, recipients still see the Microsoft account. Display names are not identities.
Product path: send and reply. Gmail’s parallel is Google Gmail Help — Send mail from a different address. Outlook does not use that Google screen. It uses account settings that Microsoft rearranges by version. This page stays on fields and proof, not a pixel tour that will rot next quarter.
If you already have a Microsoft 365 mailbox for that domain, you may not need MailerZ SMTP for that one identity. You might still want MailerZ inbound for other domains. Do not rip a working shared mailbox to “standardize” if Calendar and retention already live in 365.
Prove inbound first. Pay when Outlook must show the domain on send.
Start free — one domainThe real decision behind Outlook send-as
People search this after a client says “your email looks personal.” Outlook already shows the forwarded thread. The reply still says maya@outlook.com. Forwarding did its job. SMTP was never configured. Adding another inbound route will not fix From.
Decision one: do replies need the printed domain? If no, stop. If yes, pay and add SMTP. Decision two: which Outlook? Classic Windows, new Outlook, Mac, and Outlook on the web are different products that share a name. Decision three: is this identity a role (support@) or a person? Roles need an inbox the company keeps when Maya leaves.
A common failure is adding the domain as a second Exchange account. Outlook then tries to find a mailbox that does not exist. MailerZ is not IMAP and not Exchange. You want outgoing SMTP attached to the existing Outlook profile, not a phantom mailbox.
When this setup is the right tool
- The destination inbox is already Outlook or Microsoft 365 personal.
- You proved inbound aliases from another mailbox.
- You can staff a paid plan and stay inside hourly caps.
- You will pick the domain From on every send, not hope Outlook remembers.
When it is the wrong tool
- You need IMAP collection for a helpdesk. MailerZ has no IMAP.
- You need Calendar on that domain. Buy the suite.
- You are still on Free.
- Leftover MX is still published. Fix inbound first.
Agencies should configure SMTP on one operator machine, prove a received copy, then document the exact fields. “We set up Outlook” is not a handoff. The next person will use new Outlook and miss AUTH.
Write the handoff as a table: Outlook build (classic / new / Mac / web), SMTP host, port, encryption, username label, From string, date of received-copy proof, and who holds the vault item. If any cell is “unsure,” the identity is not production. Customers do not care that Microsoft renamed the settings pane. They care that Header From matched last Tuesday.
Time-box the Outlook fight. If you cannot store AUTH in two hours on the client they insisted on, switch the send client. Keep Outlook as the reading pane. The job is a domain From, not loyalty to a preview build. Teams that refuse to change clients and refuse classic Outlook will stay on a Microsoft From. Say that in the statement of work.
Do not combine this change with a domain registrar transfer. DNS and Outlook SMTP failing on the same day produces a war room that solves neither. Finish leftover MX. Wait a day. Then add SMTP. One moving part per window.
If finance requires a Microsoft shared mailbox for invoices@ already, leave it. MailerZ SMTP is for the domains that never got a seat. Parallel systems are fine when each printed name has one outbound path. Two outbound paths for the same From is how SPF and human owners both fork.
After go-live, watch the first week of sent items. Any message that left as a Microsoft address is a training miss, not a MailerZ outage. Forward that thread’s next reply from the domain identity and note it in the handoff. Three misses in a week means the From picker is too easy to skip. Pin a desktop note. Software will not save a habit.
If you must support both Gmail and Outlook operators on the same alias, use the same SMTP secret and the same approved From. Do not create two From spellings. Recipients thread on the address, not on the client. Prove both clients with separate received copies. One client succeeding is not a domain success.
Revisit the setup after every Outlook “new experience” toggle. Microsoft can hide the outgoing server again. The SMTP pair does not change. The menu does. If send starts reverting the week after an app update, open the identity and confirm AUTH is still present before you rotate passwords or blame MailerZ.
Security: the SMTP password is as powerful as sending as that identity. Do not paste it into a shared Slack channel. Rotate when a contractor who used that Outlook profile leaves. Dashboard seats do not revoke a password already stored in a client. Revoke and reissue.
Do not enable catch-all FORWARD hoping Outlook will send as unknown names. Catch-all is inbound policy. Outbound still requires an approved identity. Guessed From lines 550.
Technical mail flow
Inbound still goes sender → MX → alias → SRS envelope → Outlook. Outbound goes Outlook → SMTP AUTH → From check → SPF/DKIM as published → recipient MX. Outlook must not use the MX hostname as SMTP. Those hostnames accept inbound mail, not your password.
MailerZ inbound never rewrites Header From, Subject, Date, Message-ID, body, or MIME. Envelope MAIL FROM uses SRS. Your Outlook send is a new message. SPF, DKIM, and DMARC must authorize that new message. Specs: IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). Paste includes as the dashboard states. Leftover Google includes plus MailerZ can blow the ten-lookup SPF budget.
Caps: Solo 5/hour and 100/month. Starter 10/200. Business 15/400. Agency 25/800. Outlook will retry. Retries can burn the hourly cap faster. Space bursts. MailerZ is not a campaign sender.
DNS for the domain still needs one MX set. Outlook send-as can succeed while inbound is split across leftover Microsoft MX. Customers then say “you can email us but we cannot email you.” That is leftover MX, not an Outlook bug. Treat mixed MX as a hard stop. Troubleshooting covers public resolver checks.
Step-by-step setup
- Prove inbound. Unique titles from an unrelated mailbox to each alias you will send as. Confirm history. Self-send from Outlook to the same Outlook can lie.
- Upgrade off Free. Create or confirm the named alias. Copy SMTP host, port, username, password, encryption.
- Publish SPF, DKIM, and DMARC as instructed. One SPF record. Delete leftover includes from the old host.
- Open the Outlook that people actually use. Classic: more settings → outgoing server → my server requires authentication → same credentials, then advanced port and TLS. New Outlook: find the equivalent manual outgoing server. Web: if it cannot store SMTP, use desktop.
- Set From to the approved alias. Not a lookalike. Not a plus tag MailerZ never created.
- Send to a third mailbox. Read Header From and Authentication-Results. Then send a second message an hour later so you are not looking at a cached composer success.
- Train the click. Every compose, pick the domain identity. Outlook will happily send as the Microsoft account if that identity is selected.
Docs: docs. Features: features. Pricing: pricing. Gmail twin: Gmail send-as.
Classic Outlook field map
Incoming server stays whatever already receives mail (usually Microsoft). Do not change incoming to MailerZ. Outgoing server is the MailerZ SMTP host. AUTH on. Username and password from the dashboard. Port and encryption exactly as shown. If classic Outlook offers “SPA” or secure password authentication, leave it off unless the dashboard says otherwise. Wrong AUTH flavor looks like a bad password.
New Outlook field map
Microsoft moved settings behind “manage accounts.” You still need a manual outgoing server. If the UI only offers Microsoft 365 sign-in, you cannot complete MailerZ SMTP in that surface. Use classic Outlook or another client for send-as, or accept that this profile is inbound-only. Do not invent an Exchange autodiscover for MailerZ. There is none.
Outlook on the web
OWA is built around Microsoft mailboxes. Custom SMTP is often missing or incomplete. If the From reverts, that is expected. Desktop Outlook or Gmail Send mail as are the reliable clients for MailerZ SMTP. Do not promise a customer that outlook.com webmail will hold a third-party SMTP identity.
Worked examples
A bookkeeper uses Outlook for Microsoft 365 personal. Invoices forward to that inbox. She adds Solo, pastes SMTP into classic Outlook, sends a test to her Gmail. Header From is invoices@studio.test. She still has to click that From on every new message. One muscle-memory send as the Microsoft account undoes the brand for that vendor.
An agency sets new Outlook for a client and cannot find outgoing server. They add the domain as Exchange. Outlook spins, then errors. The fix is not a new MX. The fix is classic Outlook or Gmail for SMTP, plus a written note that new Outlook on that machine cannot store the identity.
A support pair shares one SMTP password in a 1Password vault and two classic Outlook profiles. When a contractor leaves, they rotate the password and update both profiles the same hour. History 550s until both are updated. That 550 is correct.
A shop bursts 12 shipping notices. Solo’s 5/hour 550s the rest. Outlook queues and retries, which can 550 again. They move notices to Starter or an ESP. SMTP send-as is for people, not a silent loop from a desktop rule.
If From looks right in Outlook but inbound is random, check leftover MX before you reset the password.
Open DNS troubleshootingFailure modes and proof
| Symptom | Likely cause | Proof |
|---|---|---|
| 550 / 5.7.1 | Free, unauthorized From, or unhosted domain. | History SMTP text. Plan. Alias table. |
| From reverts to Microsoft | Identity not bound. Web client. Wrong profile. | Received copy. Account list. |
| TLS or port error | STARTTLS mixed with implicit TLS. | Dashboard pair versus Outlook advanced tab. |
| Password failed | SPA on, old secret, or MX host used as SMTP. | Host name. AUTH flavor. |
| Composer shows domain, recipient sees Microsoft | Display name only. | Received Header From. |
| Hourly 550 | Cap plus Outlook retries. | Timestamps in history. |
| Inbound missing | Leftover MX. Different path. | Two public resolvers. |
| Autodiscover hunt | Domain added as Exchange. | Remove phantom account. Manual SMTP only. |
Proof is a received message plus history. Outlook’s “sent” folder is not proof of Header From. Check spam at the destination. Inbox placement is not an SLA.
The next article in this cluster covers From reverting in Gmail or Outlook in more depth. Here, the short version: if SMTP is missing, the client will always prefer the mailbox it actually owns.
Plus tags: MailerZ does not strip plus on custom domains. If you send as billing+acme@, that full string must be an approved alias. Otherwise 550.
MailerZ workflow and product boundary
Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Outlook is a client. MailerZ is inbound MX plus paid SMTP. Not Exchange. Not IMAP.
What MailerZ does
- Forward named aliases into Outlook with Header From preserved.
- Paid SMTP from approved identities.
- 550 for unauthorized From.
- Hourly and monthly outgoing caps.
- Hop history 14 days Free, 90 paid.
What MailerZ does not do
- Send-as on Free.
- Autodiscover or Exchange.
- IMAP, Calendar, or a hosted Outlook mailbox.
- Rewrite inbound Header From.
- Guaranteed labels inside Microsoft’s UI.
- SOC 2, ISO 27001, HIPAA, inbox SLAs, review counts. Controls: Security and Trust Center.
Plans: pricing. Free $0, 1 domain, 3 aliases, 1 seat, 14-day store, send-as disabled, SMTP and API disabled. Solo $40/year, 3 domains, 15 aliases, 90-day, 1,000 outgoing, 5/hour. Starter $8 or $80, 5/50/5, 2,000, 10/hour. Business $19 or $190, 25/200/25, 4,000, 15/hour. Agency $39 or $390, 100/500/50, 8,000, 25/hour. Unlimited is $99/month or $990/year. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.
Cost, alternatives, and trade-offs
| Approach | You get | You give up |
|---|---|---|
| MailerZ SMTP + existing Outlook | Approved From. Same inbox. | Manual identity. Caps. UI variance. |
| Microsoft 365 mailbox | Native From, Calendar, IMAP. | Per-user price. Google Workspace — product overview is the Google cousin; Microsoft bills its own suite. |
| Display name only | Composer looks branded. | Recipients still see the Microsoft address. |
| Forwarding only | Inbound in Outlook. | Replies look personal. |
Best practice for outlook send from custom domain smtp: inbound first, paid SMTP, copy the pair, classic or a client that stores AUTH, prove a third-party copy, train the From click. Do not add Exchange autodiscover for a forwarder.
If the team lives in new Outlook and refuses classic, Gmail Send mail as on a destination Gmail may be the more honest client. The destination can still be Outlook for reading if you forward there, but send-as from a client that cannot store SMTP will fail forever. Pick the client that can hold the secret.
Legal hold stays in the Microsoft mailbox if you have one. MailerZ history is not an archive. 14 or 90 days of hops. Copy what you must keep before you need it.
Mac Outlook and mobile
Outlook for Mac has its own account dialog. The same rule applies: outgoing SMTP from the dashboard, AUTH on, encryption pair copied, From must be approved. If Mac Outlook cannot store a third-party SMTP user next to a Microsoft mailbox, use another desktop client for send-as and keep Outlook for reading. Do not tell a customer that the Mac app “must” work because Windows classic did.
iOS and Android Outlook apps are worse. Many builds only speak Microsoft accounts. A phone that can read forwarded mail may be unable to send as the domain. That is acceptable if people send from the desktop. It is a failed project if the only operator lives on a phone. Discover that in week one, not after you printed invoices@.
Shared computers need a profile story. A front-desk PC signed into one Microsoft account cannot safely hold SMTP for billing@ if every intern uses that Windows login. Either they send from a personal machine with a vaulted password, or you accept that this role replies from a Microsoft address. SMTP in a shared unlocked Outlook profile is a sending incident waiting for a curious click.
Signature blocks should match the From you will actually use. A signature that says support@ while Outlook sends as a personal Microsoft address trains customers to ignore both. Update the signature the same hour you prove Header From. Remove personal mobile numbers from role signatures if the role will rotate.
Rules in Outlook that auto-forward outbound copies to a second mailbox can loop if that mailbox is also an alias destination. Keep auto-forward rules inside Microsoft, not back to the domain. Destination must be an external store that is not in the alias table.
If two people must send as support@ from two Outlook profiles, they share one approved identity and must both update the password on rotate. Staggered updates cause a week of 550s that look like “SMTP is flaky.” It is two clients and one revoked secret. Write the rotate runbook before the first vacation.
Proof you can hand a customer: screenshot of public MX from two resolvers (one set), Message-ID of inbound test, received outbound copy with Header From, history line without 550, and the plan name that includes send-as. That packet ends arguments about whether Outlook “is configured.”
FAQ
What is the safest way to handle outlook send from custom domain smtp?
Prove inbound aliases first. Use a paid plan. Copy host, port, username, password, and the STARTTLS or implicit TLS pair from the MailerZ dashboard. Add a manual SMTP identity in Outlook with an approved From. Send a test to an unrelated mailbox. Do not use inbound MX as the outgoing server.
Does this require a new mailbox?
No. Outlook stays the store. MailerZ is not IMAP. You add SMTP so Header From can be the domain. Buy Microsoft 365 only if you need a hosted mailbox and Calendar, not because you want hello@ on the From line.
Will it work with Gmail or Outlook?
This article is Outlook. The same paid SMTP pair works in Gmail Send mail as. Free has no send-as. New Outlook, classic Outlook, and Outlook on the web use different labels for the same fields. Prove a received copy, not the composer.
What DNS records are involved?
Inbound: verification TXT, one MX set, leftover MX removed. Outbound: SPF, DKIM, and DMARC as the dashboard states. Outlook SMTP does not replace MX. Mixed leftover MX still loses inbound while send can look fine.
What should I test before production?
Inbound from another mailbox to each alias. Then a paid Outlook send-as to a second unrelated mailbox. Confirm Header From is the domain. If Outlook reverts to the Microsoft account, the SMTP identity is not bound to that profile.
Key takeaways
- Outlook send-as is manual SMTP, not a new mailbox.
- Free has no send-as.
- Do not point outgoing SMTP at MX hosts.
- Copy host, port, and encryption from the dashboard.
- Classic, new, and web Outlook use different labels.
- Display names are not Header From.
- Leftover MX breaks inbound while send can look fine.
- Unauthorized From gets 550. Caps are hourly and monthly.
- Header From inbound stays original. Envelope SRS only.
- MailerZ is not Exchange, not IMAP, and not SOC 2.
Conclusion and next action
If you came here to configure Outlook to send from a custom domain address, attach paid SMTP to the Outlook you actually use, pick an approved From, and prove a received copy. Forwarding already filled the inbox. SMTP fills the From line. Mixing those jobs is how 550s and leftover MX get blamed on “Outlook being Outlook.”
MailerZ fits teams that kept Outlook as the store and need domain identities without another mailbox seat. It does not fit IMAP helpdesks or Calendar. Next action: prove inbound, upgrade, paste the dashboard pair into classic Outlook or another client that stores AUTH, and send one test to an unrelated mailbox.
Ready to send as the domain from Outlook
Start free to prove inbound. Pay for SMTP when From must match.
Free receives. Paid send-as uses the host, port, and encryption pair in the dashboard.
Review quarterly, or sooner if Outlook labels or SMTP caps change. Author: MailerZ editorial, Secuno LLC.