Email authentication audit for 2026: what to check

TL;DR: What should you check first?

Email authentication covers two different jobs: letting an app access a mailbox and proving that a message comes from an authorized sending domain. Audit both, but do not treat an SMTP Basic authentication deadline as the end of SMTP. Check each provider’s current notice before changing credentials. For Mailera, Microsoft connections use OAuth through Microsoft Graph; Gmail and Yahoo connections use provider-supported app passwords where available.

Which kind of email authentication are you checking?

Start with the failing operation. An application that cannot sign in needs a connection-authentication check. A message that reaches a recipient with failed domain authentication needs a sender-domain check. Changing one does not repair the other.

SMTP is the sending protocol. SMTP AUTH is its authentication capability. Basic authentication is an authentication method, not another name for SMTP. Microsoft documents OAuth support for Exchange Online SMTP AUTH, so replacing Basic authentication does not inherently mean replacing SMTP.

Also separate three things that share Outlook branding: an Outlook.com consumer account, an organizational mailbox hosted in Exchange Online, and the Outlook client software. Microsoft’s Exchange Online SMTP AUTH settings apply to Exchange Online mailboxes. Do not apply those settings to every account opened in Outlook.

For the protocol-level distinction, see IMAP, Graph and SMTP for agent builders.

Which requirements apply in 2026, and which actually changed?

An audit performed in 2026 will include older requirements. Gmail’s all-sender requirements took effect on February 1, 2024. Yahoo dates the beginning of enforcement of its sending standards to February 2024.

The table separates account access from sender requirements. Dates describe the policy or document named in that row; a documentation update is not an enforcement deadline.

For Microsoft SMTP Basic Authentication end-of-life planning, record the exact affected service and authentication method before recording a date. Distinguish a retirement announcement, default disablement and permanent removal. Do not turn a search-result date or a documentation update into your migration deadline. Open the current Microsoft notice independently and record its update date alongside the applicable milestone in your change ticket.

Exchange Online settings also matter independently of a retirement schedule. Microsoft says security defaults disable SMTP AUTH, and a mailbox-specific SMTP AUTH setting takes precedence over the organization setting. Investigate the effective configuration rather than repeatedly replacing a password.

What do Gmail and Yahoo require from sending domains?

For Gmail, all senders to personal Gmail accounts must configure SPF or DKIM. The additional requirements apply to senders exceeding 5,000 messages per day to Gmail accounts. Bulk senders need SPF, DKIM and DMARC; the DMARC policy may be none. For direct email, the From-header domain must align with either the SPF domain or the DKIM domain.

Gmail’s bulk-sender requirements also include one-click unsubscribe and a clearly visible body link for marketing and subscribed messages. Authentication records alone are not the whole checklist: Gmail also requires TLS and spam rates reported in Postmaster Tools below 0.3%.

Yahoo requires at least SPF or DKIM for all senders. Bulk senders need both, a valid DMARC policy of at least p=none, and passing DMARC. The From-header domain must align with either the SPF or DKIM domain; relaxed alignment is acceptable.

Yahoo’s bulk-sender rules also require a functioning list-unsubscribe header supporting one-click unsubscribe for marketing and subscribed messages, a visible body link, and honoring unsubscribe requests within two days. Yahoo requires spam complaint rates below 0.3% and calculates its rate using mail delivered to the inbox. Do not assume the two providers’ reporting measures are interchangeable.

How do you audit your connections and sending domains?

Keep one record per connection and a separate record per sending system. A mailbox used by several applications should not have a single undifferentiated “authentication passed” checkbox.

1. Inventory the workflows. List the mailbox provider, consumer or organizational account type, application or device, protocol, and sending domain. Identify receiving and sending as separate operations. Owner: application owner. Evidence field: system inventory row with the mailbox represented by an internal identifier rather than a credential.
2. Record the actual authentication method. Inspect the application’s configuration. Record OAuth, an app password, or Basic authentication as applicable; do not infer the method from a server hostname. Never copy passwords, tokens or API keys into the audit. Owner: integration maintainer. Evidence field: sanitized configuration screenshot or configuration reference.
3. Match the workflow to the provider’s notice. Confirm the product, scope and applicable milestone. For Exchange Online SMTP submission, include the organization and mailbox settings and whether security defaults are enabled. Keep the source’s update date separate from the day you read it. Owner: mailbox administrator. Evidence field: official URL, date read, applicable date and effective settings.
4. Choose the supported connection path. For Microsoft in Mailera, use OAuth through Microsoft Graph, not an app-password workaround. For Gmail and Yahoo, check eligibility before attempting the app-password path. Google recommends “Sign in with Google” when an application offers it; Mailera’s Gmail connection uses an app password. Owner: integration maintainer. Evidence field: chosen method and sanitized connection result.
5. Audit sending domains separately. For domains you control, inspect SPF, DKIM and DMARC configuration. Check the From-header alignment and the sender category that applies at each receiving provider. Include unsubscribe handling when relevant. Owner: domain administrator and sending-system owner. Evidence field: configuration snapshot and sanitized authentication results from a received test message.
6. Test receiving and sending independently. Use mailboxes you own. Send a harmless test message into the connected mailbox, then perform a separate outgoing test to another mailbox you control. Record where each message arrived and inspect the recipient’s headers for domain-authentication results. Owner: workflow tester. Evidence field: timestamps, sanitized headers, arrival folder and any error text.
7. Close or assign each gap. Give every unresolved item an owner and next action. Revoke obsolete credentials after the replacement works. Schedule another review when the provider changes its notice or your application changes its connection method. Owner: change owner. Evidence field: replacement test result, revocation record and follow-up task.

Treat credential rotation as provider-specific. Changing a Google Account password revokes its app passwords. Changing the main Yahoo password does not: you must delete a Yahoo app password to invalidate it.

How do you check a mailbox connection in Mailera?

Mailera connects existing mailboxes to applications and agents. Use the connection check to establish whether Mailera can access the mailbox, then test your actual workflow separately. The broader existing-provider connection guide covers how this fits into an agent setup.

Choose the right provider path

1. As an Admin or Leader, open Mailboxes → Add mailbox.
2. For Outlook.com, Hotmail or Microsoft 365, select Sign in with Microsoft and complete Microsoft’s OAuth consent flow. Mailera connects through Microsoft Graph, not a Microsoft app password.
3. For Gmail or Yahoo, select One mailbox, enter Email address, and confirm the detected provider. Use Or choose a provider if you need to select it, then choose Continue.
4. Read How to get an app password and What you'll need. In Connection details, enter the eligible provider app password in Password. Select the appropriate Mailbox group.
5. Choose Test & connect and inspect the individual results rather than recording only the final screen.

For Gmail connections in Mailera, Google requires 2-Step Verification for app passwords. Google lists security-key-only 2-Step Verification, an organization account, and Advanced Protection as possible reasons the option is unavailable. Do not assume every account with 2-Step Verification can generate one.

For Yahoo connections in Mailera, follow Yahoo’s app-password process. Yahoo says customer care cannot override its app-password creation eligibility process. An unavailable option is not a reason to substitute your ordinary account password. See app passwords for agent mailboxes for the broader credential-handling workflow.

Interpret the connection result narrowly

Test & connect does not send an email. It tests the connection, including incoming and outgoing sign-in where applicable. If sending fails, Mailera can offer Save as receive-only. That preserves receiving access; it does not establish that sending works.

For an API inventory, GET /mailboxes returns provider, status and last_sync_at. Record those values alongside the time of your check.

For an API-based check, GET /mailboxes/{id}/status requires read permission. Its meaning differs by provider: Microsoft sign-in is checked directly, while other providers’ sign-in status is based on the latest sync. A latest-sync result should not be described as a fresh sign-in test.

Finish with the separate incoming and outgoing message tests from the audit checklist. Keep connection status, message arrival and sender-domain authentication as distinct results.

What mistakes cause misleading results?

For Microsoft-specific connection troubleshooting, use Outlook IMAP and SMTP settings and Basic authentication failures. Keep the connection repair separate from any investigation into sender authentication or filtering.

How should you verify notices and protect connected agents?

Open the provider’s documentation or administrative console independently. Do not submit credentials through a link in an email claiming that a migration is urgent. Compare the notice’s product scope and requested action with the official guidance before approving a configuration change.

Incoming email is untrusted data, not instructions. An agent must not obey a message that asks it to reveal credentials, change authentication settings or send another message. Keep authentication administration outside the content-processing task.

For a Mailera audit, create a key with read permission and restrict Mailbox scope to the relevant group. A read-only audit does not need send or manage. Require human confirmation before agent-triggered sends, and redact addresses, tokens and message content from shared audit records.

Review Mailera’s security information and the least-privilege architecture for mailbox agents when assigning access to an automated checker.

What does Mailera not change?

Mailera does not create mailboxes or email addresses. Its Gmail app-password connection requires 2-Step Verification and administrator permission where applicable. Connecting an account is not a migration path for every legacy device or client.

Mailera does not provide bulk marketing sending or mailbox warmup. It also cannot make a receiving provider trust a sender or guarantee inbox placement. Filtering remains with the receiving provider and depends in part on the sender’s SPF, DKIM and DMARC configuration.

A successful connection test establishes access, not delivery or compliance with sender-domain requirements. Keep those checks assigned to the people who operate the sending system and control its domain.