Suped

How do I set up Outlook SMTP authentication with 2FA and OAuth2 for GlockApps?

Published 27 Apr 2025
Updated 3 Oct 2026
11 min read
Summarize with
Outlook, OAuth2, and GlockApps SMTP setup shown as a clean technical article thumbnail.
Updated on 3 Oct 2026: We updated the GlockApps connection steps and added the Microsoft 365 consent checks needed when approval blocks sign-in.
The short answer is to use GlockApps' built-in Microsoft connection. In Inbox Insight, open Connected Mailboxes, click "Connect New Mailbox," choose Outlook, and click "Continue with Microsoft." GlockApps documents this flow as Microsoft OAuth 2.0 authorization with Microsoft Graph sending, so 2FA happens during Microsoft's browser sign-in. You do not enter an app password, SMTP host, or copied token for this path.
Custom SMTP is a separate, password-based GlockApps connection. A Microsoft 365 business mailbox uses smtp.office365.com, while a personal Outlook.com, Hotmail, or Live account uses smtp-mail.outlook.com. Both use port 587 with STARTTLS. Outlook.com requires OAuth2 or Modern Auth, so use GlockApps' built-in Microsoft connection instead of its Custom SMTP password form.
Microsoft revised the Exchange Online basic SMTP AUTH retirement schedule in January 2026. Behavior remains unchanged through December 2026. At the end of December 2026, basic SMTP AUTH will be disabled by default for existing tenants, although administrators will still be able to enable it temporarily. Microsoft plans to announce the final removal date in the second half of 2027, so app passwords remain a migration-only option rather than a dependable long-term setup.
  1. Choose Outlook in GlockApps and complete the "Continue with Microsoft" sign-in and consent flow.
  2. Use Custom SMTP with an app password only for a Microsoft 365 business mailbox where basic SMTP AUTH is still allowed.
  3. Do not copy OAuth2 tokens or credentials from another mail client. OAuth2 tokens belong to the app that requested them.
  4. After the Microsoft connection works, validate headers, inbox placement, DMARC alignment, and reputation signals.

Choose the GlockApps connection method

Start with GlockApps' built-in Outlook integration. It handles Microsoft authorization without asking you to configure an SMTP OAuth client. Use Custom SMTP only when a business mailbox is permitted to accept basic SMTP AUTH and the exception has an owner and migration plan.
Microsoft connection choicestext
Recommended GlockApps path: Provider: Outlook Action: Continue with Microsoft Authentication: Microsoft OAuth 2.0 Sending method: Microsoft Graph Manual Microsoft 365 fallback only: SMTP host: smtp.office365.com Port: 587 Encryption: STARTTLS Authentication: Basic SMTP AUTH where temporarily allowed Outlook.com documented SMTP host: smtp-mail.outlook.com Port: 587 Encryption: STARTTLS Authentication: OAuth2 / Modern Auth
App passwords are not OAuth2
An app password is still a password. It lets an older client sign in without an interactive 2FA prompt, but it does not turn a password-only SMTP connection into OAuth2. If Microsoft has disabled basic authentication for the tenant or mailbox, an app password will fail even when the password is correct.
  1. Use the built-in Outlook connection for Outlook.com and Microsoft 365 accounts that can complete Microsoft sign-in.
  2. Use an app password only when a business account exposes one and basic SMTP AUTH is allowed.
  3. Ask an administrator to review consent or mailbox restrictions when the Microsoft sign-in is blocked.

Account

Auth path

GlockApps result

Microsoft 365
Continue with Microsoft
Uses GlockApps' built-in OAuth2 and Microsoft Graph connection.
Outlook.com
Continue with Microsoft
Uses OAuth2; do not use the Custom SMTP password path.
Exchange Online fallback
Custom SMTP
Works temporarily only when basic SMTP AUTH and the credential are allowed.
Shared mailbox
Microsoft connection
Confirm GlockApps supports the delegated sender; Microsoft requires the relevant Graph and mailbox permissions.
How each Microsoft account type affects a GlockApps connection.

Why app passwords fail with Microsoft 365

The Gmail pattern is familiar: enable 2FA, generate an app password, paste it into the SMTP tool, and send. Microsoft accounts have had similar app-password behavior in limited cases, but Microsoft 365 security policies and Outlook.com's Modern Auth requirement make that pattern unreliable for GlockApps. The account can have the correct password and still fail because Microsoft has blocked the authentication method.
Password-based SMTP setup
  1. The SMTP client stores a password-like secret.
  2. An app password bypasses the interactive 2FA prompt for that client.
  3. The setup fails when Microsoft blocks basic SMTP AUTH.
GlockApps Microsoft OAuth2 setup
  1. GlockApps receives scoped access after Microsoft consent.
  2. Microsoft handles 2FA in the browser sign-in flow.
  3. The setup fails when consent or mailbox access is denied.
OAuth2 tokens belong to the application that requested them. A token granted to another mail client should not be reused in GlockApps. Microsoft issues tokens for a specific client, user, resource, and permission set. Microsoft OAuth2 guidance explains why each sending application needs its own supported OAuth2 flow. GlockApps already provides that flow through its Outlook connection.

Connect GlockApps through Microsoft OAuth2

GlockApps' built-in Outlook integration uses Microsoft's OAuth 2.0 flow and Microsoft Graph to send messages with the user's permission. It is not a manual XOAUTH2 connection to an SMTP server. The built-in path does not require an SMTP host, port, app password, client secret, or separately registered Entra application.
Decision flow for choosing OAuth2 or app password when connecting Outlook SMTP to GlockApps.
Decision flow for choosing OAuth2 or app password when connecting Outlook SMTP to GlockApps.
  1. In GlockApps, go to Inbox Insight, then Connected Mailboxes, and click "Connect New Mailbox."
  2. Name the connected mailbox, then select Outlook for Outlook.com, Hotmail, or Microsoft 365.
  3. Click "Continue with Microsoft" to start browser authorization.
  4. Select the sending account and complete sign-in, 2FA, or conditional access prompts.
  5. Review GlockApps' requested permissions and click "Accept" if permitted by your organization.
  6. Run one test to confirm the connected mailbox works before changing DNS or adding more senders.
GlockApps built-in Microsoft connectiontext
Connection: Outlook Authorization: Microsoft OAuth 2.0 Sending method: Microsoft Graph User action: Continue with Microsoft 2FA: Completed during Microsoft sign-in Consent: Access account and send mail on the user's behalf
Token ownership matters
A successful OAuth2 sign-in in another application does not authorize GlockApps. Complete the "Continue with Microsoft" flow inside GlockApps so Microsoft can issue the correct access for that application. If the tenant blocks user consent, a Microsoft 365 administrator needs to review the request.
If Microsoft displays "Approval required" during GlockApps sign-in, the tenant's consent policy is blocking the connection. The mailbox password and SMTP settings cannot resolve this error. Have the administrator review the exact application and permissions requested before access is granted.
  1. Submit the approval request in the Microsoft prompt if the tenant has an admin consent workflow. Otherwise, send the administrator the application name, account address, and error text.
  2. An authorized reviewer can open Microsoft Entra ID, then Enterprise apps, then Admin consent requests, and inspect the request in My Pending.
  3. After approval, return to GlockApps and repeat "Continue with Microsoft" using the mailbox that will send the test.
If the visible From address is a shared mailbox or another user's address, verify the required Send As or Send on Behalf mailbox permission. Microsoft Graph delegated sending also requires the appropriate shared-mail permission; confirm that GlockApps supports this sender arrangement before relying on it for a test.

Use an app password only for a temporary business exception

An app password remains a temporary fallback for a Microsoft 365 business account that still allows password-based SMTP after 2FA is enabled. It is not the documented Outlook.com OAuth2 path or the preferred GlockApps path. Use it only when the account exposes app passwords and an administrator confirms basic SMTP AUTH is allowed by security defaults, the authentication policy, and mailbox settings.
  1. Try GlockApps' Outlook option and "Continue with Microsoft" first.
  2. Limit this fallback to a Microsoft 365 business mailbox, not an Outlook.com personal account.
  3. Ask an administrator to check security defaults, the authentication policy, and the mailbox SMTP AUTH setting.
  4. In Custom SMTP, enter the full address as the username and the app password as the password.
  5. Move to the built-in Microsoft connection before basic SMTP AUTH becomes disabled by default at the end of December 2026.
When to stop trying app passwords
Stop rotating passwords if the error says basic authentication is disabled. More passwords will not change a tenant or mailbox policy. Return to GlockApps' built-in Microsoft connection, or ask the tenant administrator to review consent and mailbox access. For broader Microsoft policy context, use the Outlook sender requirements checklist.

Test the sender inside GlockApps

Once the Microsoft connection works, GlockApps can run the inbox placement test through the connected mailbox. Treat that as a live send, not a DNS-only check. The connection result proves whether GlockApps can send with the granted Microsoft access. The message result shows how mailbox providers handled the message. For a separate send-and-inspect workflow, Suped's email tester reports on headers, authentication, and content signals.
GlockApps SMTP sender setup screen with Outlook SMTP fields and test controls.
GlockApps SMTP sender setup screen with Outlook SMTP fields and test controls.
Run the first test with one sender and one change at a time. If the Microsoft connection fails, the message never reaches the deliverability stage. If the connection succeeds and the message lands in spam, then move to headers, domain authentication, content, sending volume, and reputation. A message resent through the connected mailbox gets fresh authentication results, so inspect the received test message rather than assuming its original headers carried over.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed
  1. Use the connected mailbox as the visible From address unless the account and application have the required delegated sending permissions.
  2. Check whether DMARC passes through aligned SPF or DKIM; investigate either mechanism that fails.
  3. Save the connection error, Authentication-Results header, and test timestamp for the administrator.
  4. Change one variable, then run the next test so the result is attributable.
Keep access problems separate from deliverability problems. A Microsoft consent error is not a spam-folder problem. A successful GlockApps connection with failing DMARC is not an OAuth2 problem. Separating those paths prevents unnecessary DNS changes.

Separate Microsoft access from domain authentication

After the GlockApps Microsoft connection works, check whether the message authenticates as your domain. Suped's domain health checker reviews SPF, DKIM, and DMARC records. Suped's DMARC monitoring then shows which sources send mail for the domain over time.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product supports the ongoing domain-authentication workflow after Microsoft access is solved. Its DMARC reports help identify unfamiliar senders and sources whose SPF or DKIM result does not align with the visible From domain.
Post-setup DMARC review priorities
Classify each sending result by authorization and domain matching after the GlockApps connection works.
Healthy
Authorized pass
An authorized source has a passing SPF or DKIM identity aligned with the visible From domain.
Investigate
Unknown source
The source is unfamiliar, or forwarding has changed the authentication result.
Fix now
Known-source fail
A known sender fails DMARC or uses the wrong visible From domain.
Where Suped fits
Suped does not authorize GlockApps in Microsoft. It handles domain-authentication monitoring after mail starts moving and helps identify which sending sources need investigation.
  1. Identify unfamiliar sources, broken domain alignment, and authentication drops.
  2. Review SPF lookup usage and sender changes before adjusting the record.
  3. Move DMARC toward enforcement after authorized sources are verified.
  4. Track authentication results across multiple Microsoft domains.

Troubleshoot Microsoft connection errors

Start by identifying which GlockApps connection failed. Built-in Outlook integration errors usually point to Microsoft sign-in, consent, conditional access, or mailbox permission. Custom SMTP errors point to the SMTP host, credential, basic-auth policy, or mailbox SMTP AUTH setting. DNS cannot repair either access path.

Error

Likely cause

Next action

Consent denied
Permission blocked
Ask the tenant administrator to review GlockApps access.
535
Custom SMTP auth failed
Use the built-in Outlook connection or verify the temporary basic-auth exception.
5.7.3
SMTP auth failed
Confirm the host, account type, and selected authentication method.
5.7.30
Basic auth unsupported
Stop using the password-based Custom SMTP path and connect through Microsoft OAuth2.
5.7.60
Send As denied
Grant the required sending permission or use the connected mailbox address.
5.7.139
SMTP auth request rejected
Check the complete error text and tenant policy; use the built-in connection if basic auth is blocked.
Common Microsoft connection failures and the next action to take.
For a Custom SMTP connection to a Microsoft 365 business mailbox, ask an administrator to verify the organization and mailbox SMTP AUTH settings before resetting the password. A blank mailbox value inherits the organization setting; false enables SMTP AUTH for that mailbox, and true disables it. These checks do not apply to GlockApps' built-in Microsoft Graph connection, where the administrator should review app consent and mailbox access instead.
Read-only PowerShell checks for Custom SMTPpowershell
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled Get-CASMailbox sender@yourdomain.com | Format-List SmtpClientAuthenticationDisabled
Do not bypass OAuth2
Do not borrow another application's token, disable tenant security broadly, or use an unapproved relay. Use GlockApps' built-in Microsoft connection. If a temporary Custom SMTP exception is required for a business mailbox, document its owner and migration deadline.

The practical way forward

For Outlook.com, Hotmail, and Microsoft 365, choose Outlook in GlockApps and use "Continue with Microsoft." That built-in OAuth2 connection handles 2FA during Microsoft sign-in and sends through Microsoft Graph. Do not start with an app password or manual SMTP token setup.
  1. Use the built-in connection without manual SMTP settings.
  2. Treat a Microsoft 365 Custom SMTP exception as temporary while its policies allow basic authentication.
  3. After sending works, use Suped's product to monitor DMARC results and identify unauthenticated sources.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard
What you'll get with Suped
Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing