Send Client Emails From Your Own Domain

Your client gets an email asking for last year's bank statements. The sender is an address they've never seen, at a company they've never heard of. Some clients ignore it, and some forward it to their IT person as a possible phishing attempt. Others never see it, because it went to spam.

Custom SMTP fixes this. Your file requests and automatic reminders go out from your own domain, such as [email protected], through a mail account you control. This guide gives you the SMTP settings for Microsoft 365, Outlook and Gmail. It also covers the DNS records that keep those emails out of spam, and a test to run before any client sees one.

What custom SMTP means

SMTP (Simple Mail Transfer Protocol) is how email gets sent. When an app sends an email, it hands the message to an SMTP server, and that server delivers it to your recipient's mail server.

Most apps that email your clients use their own SMTP server and their own sending address. Custom SMTP means you give the app the details of your mail account instead: a host name, a port, an encryption setting, a username and a password. The app then sends through your account, from your address.

For your client, the email now comes from someone they know. The From line shows your firm's name and domain instead of your software vendor's. If they reply to ask "which year do you need?", the reply goes to an address they recognize, in a mailbox you already read.

Spam filters also get something they can check. Receiving servers look at whether the sending server is allowed to send for your From domain. With SPF, DKIM and DMARC in place (covered below), your mail can pass those checks under your name.

The link your client clicks stays the same. Putting the upload page itself on your own domain is a separate step, done with a DNS record.

What you need before you start

• A sending address on your domain. A dedicated address such as documents@ or requests@ keeps client mail out of one person's inbox. On Microsoft 365, the account that signs in needs a licensed mailbox.
• The SMTP details from your email provider. The Microsoft 365 and Gmail settings are below.
• An admin, if you aren't one. Microsoft 365 and Google Workspace both let admins block SMTP sign-ins.
• Access to your domain's DNS, to check or add SPF, DKIM and DMARC records.

Microsoft 365 and Outlook SMTP settings

If you use Outlook with a work or school address, your email runs on Microsoft 365. Personal Outlook.com and Hotmail accounts use a different server, smtp-mail.outlook.com. Microsoft says they require modern authentication (OAuth2), so check that your tool supports it.

For Microsoft 365, the method you want is client SMTP submission, which Microsoft also calls SMTP AUTH. These are the Office 365 SMTP settings from Microsoft's setup guide:

Use port 587. Microsoft says an app that defaults to port 465 doesn't support the TLS versions this method requires.

Two limits to know:

• Each mailbox can send to 10,000 recipients a day, at 30 messages a minute. That's plenty for requests and reminders.
• If the From address is different from the mailbox that signs in, that mailbox needs Send As permission on the other address. Without it, your emails bounce with error 5.7.60.

Turn on SMTP AUTH for the sending mailbox

Microsoft turns SMTP AUTH off for organizations created after January 2020. An admin can switch it on for one mailbox without opening it up for everyone:

1. Open the Microsoft 365 admin center and go to Users > Active users.
2. Select the user, then select Mail.
3. Under Email apps, select Manage email apps.
4. Check Authenticated SMTP.
5. Select Save changes.

Two settings can still block it:

• Security defaults. If your organization uses them, SMTP AUTH is already off, and Microsoft says you'd have to turn security defaults off to use it. That weakens protection for every account, so leave that call to your admin.
• Authentication policies. A policy that blocks Basic authentication for SMTP overrides the mailbox setting.

Basic auth for SMTP AUTH: what's changing

When an app signs in to Microsoft 365 with a username and password, Microsoft calls that Basic authentication. Microsoft is retiring Basic auth for SMTP AUTH, and the dates have moved before. This is the current timeline, from the Exchange team's update of January 27, 2026:

• Until December 2026: no change.
• End of December 2026: Basic auth for SMTP AUTH is turned off by default for existing tenants. Admins can still turn it back on.
• New tenants created after December 2026: Basic auth for SMTP AUTH is unavailable by default, and OAuth is the supported sign-in method.
• Second half of 2027: Microsoft will announce the final removal date.

In practice, a password-based SMTP setup on Microsoft 365 works today. From the end of December 2026, Basic auth for SMTP AUTH is off by default, so an admin has to turn it back on, and a final removal date is coming. If your admin won't allow it, a transactional provider (below) is the simpler route. Microsoft itself points app senders to Azure Communication Services Email.

Office 365 SMTP relay and direct send

Microsoft's guide lists two other methods. Neither works for a cloud app that emails your clients:

• SMTP relay uses a connector that trusts your static IP address or a certificate, on port 25. Microsoft says you can't use it to send from a third-party hosted service. It's built for printers, scanners and servers in your own office.
• Direct send skips sign-in, but it only delivers to mailboxes inside your own Microsoft 365 organization. Mail to a client's Gmail address is rejected.

Gmail and Google Workspace SMTP settings

If your email runs on Google Workspace, these are the Gmail SMTP settings Google lists for apps and devices:

Google limits Workspace accounts to 2,000 messages a day on this server.

Create a Gmail app password for SMTP

An app password is a 16-digit code that lets one app sign in to your Google Account. To create one:

1. Turn on 2-Step Verification for the account. App passwords only work on accounts that have it.
2. Go to myaccount.google.com/apppasswords and sign in.
3. Create a new app password for the tool and copy it.
4. Paste it into the tool's SMTP password field.

Before you rely on it:

• If you can't find the option, Google gives three usual reasons: 2-Step Verification uses only security keys, the account has Advanced Protection, or it's a work, school or other organization account. In that last case, ask your Workspace admin.
• Changing your Google password revokes your app passwords. The SMTP connection stops until you create a new one.
• Google recommends "Sign in with Google" over app passwords wherever an app offers it.

Google Workspace SMTP relay

Workspace admins can also set up the SMTP relay service (smtp-relay.gmail.com) in the Admin console. It accepts mail from IP addresses you list, or with SMTP authentication over TLS on port 587. Google built it for your organization's own mail servers and devices, so for one cloud tool, an app password on smtp.gmail.com is less work.

Another option: a transactional email provider

A transactional email service sends app emails such as password resets, receipts and notifications. Amazon SES, Mailgun, Postmark and SendGrid are common examples. Each gives you SMTP credentials that work in any tool with a custom SMTP form.

This route makes sense when:

• your Microsoft 365 admin won't enable SMTP AUTH, or you'd rather not depend on Basic auth;
• you don't want client emails tied to one person's mailbox and password;
• you want a log that shows whether each email was delivered or bounced.

Setup follows the same pattern everywhere. You add your domain, publish the DNS records the provider gives you, wait for the domain to verify, then create SMTP credentials. Use the host and port your provider lists. The cost is one more account to manage, and often one more bill.

SPF, DKIM and DMARC: keep your emails out of spam

These three DNS records prove to receiving mail servers that a message using your domain is genuine. Since February 2024, Google requires everyone who sends to Gmail accounts to set up SPF or DKIM. Senders of more than 5,000 messages a day to Gmail need SPF, DKIM and DMARC.

• SPF is a TXT record that lists the servers allowed to send for your domain. On Microsoft 365, it includes include:spf.protection.outlook.com. A domain can have only one SPF record, so add a new sending service to the existing record instead of creating a second one. Keep it to 10 DNS lookups or fewer, or the check fails.
• DKIM adds a signature to each message, which receivers check against a public key in your DNS. Microsoft 365 and Google Workspace each have their own DKIM setup for a custom domain. Transactional providers give you the records when you add your domain.
• DMARC is a TXT record at _dmarc.yourfirm.com. It tells receivers what to do with mail that fails the checks, and where to send reports. A starting record looks like v=DMARC1; p=none; rua=mailto:[email protected]. With p=none you only monitor. Move to quarantine or reject once the reports show your real senders pass.

For DMARC to pass, the domain in your From line has to match the domain that passed SPF or DKIM. That's why your sending address should sit on the domain you've set up, not on a free Gmail address.

Test your setup before clients see it

1. Send a real request email, not "test 123", to a Gmail address and an Outlook address you own. For the wording, start from these document request email templates.
2. Check the sender name and address, both in the inbox list and in the open message.
3. Check where it landed: inbox or spam.
4. In Gmail, open the message, click More next to Reply, then Show original. In the header, look for spf=pass, dkim=pass and dmarc=pass.
5. Reply to the test and confirm the reply reaches the right inbox.

Common errors and what they usually mean

• Sign-in fails on Microsoft 365: SMTP AUTH is off for that mailbox, security defaults are on, or a policy blocks Basic auth.
• Error 5.7.60, "Client doesn't have permissions to send as this sender": the From address isn't the mailbox that signs in. Give that mailbox Send As permission.
• "Password incorrect" on Gmail with 2-Step Verification: use an app password.
• Emails arrive but land in spam: check SPF, DKIM and DMARC for the From domain.
• Connection times out: check the port and encryption pair (587 with STARTTLS or TLS, 465 with SSL). Some networks and ISPs block port 25.

Set up custom SMTP in File Request Pro

In File Request Pro, custom SMTP comes with the custom domain on the Business ($149 a month) and Enterprise (from $249 a month) plans. Once it's set up, File Request Pro sends your collection emails, such as file requests and reminders, from your address through your mail server.

1. Open your account menu and choose SMTP Settings.
2. Enter the SMTP host, port, encryption setting and credentials from your provider (see the settings above).
3. Enter the sender name and email address. Use an address your account is allowed to send from.
4. Save, then send a test email to an address you control. A saved setup doesn't prove delivery, so check that it arrived and which sender your client will see.

Things to know:

• Ports 465 and 587 work. Port 25 isn't supported. For Microsoft 365, use 587.
• Microsoft 365 and Outlook: it works through SMTP AUTH with the mailbox's username and password. There's no Microsoft OAuth sign-in for email, so the mailbox needs Authenticated SMTP on and Basic auth allowed (see the December 2026 change above). Talk to your admin before anyone changes tenant security settings.
• Gmail and Google Workspace: use an app password, not your account password.

The custom SMTP docs cover the full setup and what to check when an email fails. Custom SMTP is one part of white-label upload pages, along with your own domain and removing File Request Pro branding. You can compare what each plan includes on the pricing page.