Diagnose SMTP Delivery Without Weakening Transport Security

When email fails, the most tempting fixes are often the worst ones: disable encryption, allow an old sign-in method, bypass a certificate warning, add a broad allowlist, or keep changing ports until something connects.

Those changes destroy evidence and can turn one delivery problem into a security problem.

A better diagnosis asks one question: what is the last stage at which this exact message was proven to work?

SMTP is a chain of handoffs. An application submits a message, a sending service queues it, DNS helps select a route, one or more servers relay it, a receiving system accepts or rejects it, and filtering or mailbox rules can act after acceptance. “Email is down” does not identify which handoff failed.

This guide gives you a safe order for finding that handoff. It does not provide one universal server name, port, or authentication method because those belong to the actual provider and sending model.

The short diagnostic path

For one affected message:

1. record the sender, recipient, exact time and time zone, subject or safe test marker, and Message-ID if available;
2. retain the complete non-delivery report or SMTP response, including the enhanced status code and reporting host;
3. confirm whether the sending platform received the message using its trace or logs;
4. identify the final successful event and the first failure or unexplained gap;
5. classify that point as submission, authentication, queueing, DNS/routing, remote acceptance, or post-delivery handling;
6. run one small authorised test through the same path and one meaningful comparison path;
7. make the smallest supported and reversible correction at the failed stage; and
8. repeat the trace and verify the final recipient state—not merely a successful Send button.

If you cannot name the failed stage, do not make a broad change yet.

Understand the message journey

A 250 reply is success for that SMTP command or handoff. It is not a universal guarantee that a human will see the message in an inbox. After the receiving system accepts the completed message, it may still route, filter, quarantine, forward, or generate a later delivery-status notification.

Likewise, a Send button returning normally proves very little. The application may have placed the message in a local outbox, handed it to another service, or failed without showing the complete server response.

Preserve a useful evidence packet

Collect evidence before retesting or changing configuration:

• exact date, time, and time zone;
• direction: inbound, outbound, internal, forwarded, or relayed;
• sender and recipient addresses, or safely redacted local parts when sharing externally;
• subject or a unique non-sensitive test marker;
• Message-ID, provider trace ID, queue ID, or correlation ID;
• the complete SMTP reply and enhanced status code;
• the host that issued the response;
• whether one recipient, one domain, or every destination is affected;
• whether the same path worked recently and what changed; and
• relevant application, mailbox, connector, gateway, or DNS change times.

Do not paste passwords, OAuth tokens, private keys, full customer headers, confidential subjects, internal hostnames, or unredacted addresses into a public forum. Message headers and NDRs can contain personal data, routing information, tenant identifiers, and security details. Keep an original secure copy and prepare a redacted working copy.

Treat an unexpected bounce carefully. A delivery report can be backscatter from forged mail that used your address, or a malicious message pretending to be an NDR. Confirm that the original Message-ID, time, recipient, and sending trace correspond to a message your system actually submitted before opening attachments or following links.

Read the whole SMTP response

SMTP commonly provides a three-digit reply, an enhanced status code, and provider-specific text. Use all three.

The first digit gives the broad result

• 2xx — the command or handoff succeeded.
• 4xx — a temporary condition prevented completion. A proper queued sending system will normally retry according to its policy.
• 5xx — a permanent failure for the message, address, or request in its present form. Something normally needs to change before retrying.

Do not train users to resend a 4xx message repeatedly. The server queue is designed to retry; manual duplicates can create several eventual deliveries or worsen throttling. Do not loop a 5xx message unchanged either.

Enhanced codes narrow the category

RFC 3463 defines the class.subject.detail structure, while the current IANA registry records the assigned codes and their references.

The middle number identifies the broad subject:

• X.1.X — addressing;
• X.2.X — mailbox status;
• X.3.X — destination mail-system status;
• X.4.X — network or routing;
• X.5.X — mail-delivery protocol;
• X.6.X — message content or media; and
• X.7.X — security or policy.

For example, 5.1.1 is much more specific than “550”: it points towards a bad destination mailbox address. A 4.4.X result points towards a temporary routing or network condition. A 5.7.X result belongs to the security or policy family, but the final digit and provider text are essential before deciding whether the issue is authentication, authorisation, reputation, content policy, sender requirements, or something else.

The familiar 550 reply is heavily overloaded. It can accompany a nonexistent address, a policy rejection, a spam decision, an unauthorised relay, or another permanent failure. Never prescribe a fix from 550 alone.

Google’s current SMTP error guide and Microsoft’s current Exchange Online NDR guidance both add provider-specific interpretation. Read the response issued for the actual message rather than copying a nearby code from a search result.

Find the last verified handoff

Work from the sender outwards for outbound mail, or from the recipient backwards for inbound mail.

If the sending platform has no record

The message probably did not reach that platform under the identity and time range you searched. Check the application outbox, account selection, submission host, network path, authentication flow, time zone, and whether another gateway was used.

Do not troubleshoot the recipient’s spam filter before proving the sender’s service received the message.

If the sender accepted and queued it

Follow the trace events. Look for deferral, DNS or connection failure, TLS negotiation, remote reply, connector selection, routing loop, policy action, or successful next-hop delivery.

In Exchange Online, current message trace can show whether the service received, rejected, deferred, delivered, or otherwise acted on a message. Microsoft notes a reporting delay can exist and exposes different detail through summary and downloadable reports. Search narrowly by sender, recipient, time, and full Message-ID where available.

In Google Workspace, Email Log Search can distinguish a message that reached Google’s network from one that did not, and can expose post-delivery state for mail in the organisation. A missing log result is evidence about the searched Google path, not proof that no system anywhere handled the message.

If the remote server returned 4xx

Confirm the sending queue retained the message and will retry. Read the enhanced code and text. Check provider incidents, DNS resolution, route, TLS policy, rate or reputation response, greylisting, and the retry history.

Escalate when the same remote response persists beyond a reasonable provider queue cycle, expiry approaches, or the error indicates a configuration you control. Do not convert a temporary rejection into repeated manual submissions.

If the remote server returned 5xx

Identify whether the rejection occurred at connection, sender, recipient, or end-of-data. That location changes the diagnosis:

• a recipient-stage rejection may concern address existence, relay permission, or recipient policy;
• a sender-stage rejection may concern authorisation, domain policy, or reputation;
• an end-of-data rejection may concern message size, content, malware, spam policy, or authentication results; and
• an authentication-stage rejection concerns the submission or relay identity before ordinary delivery begins.

Correct the specific cause, then send a new controlled message. Broad allowlisting or disabling an entire control is not a diagnosis.

If the recipient server accepted it

Move the investigation to the receiving organisation. Check its trace, gateway, quarantine, mailbox rules, forwarding, junk handling, distribution-group expansion, data-loss policy, and mailbox state.

“Delivered” in a provider trace must be read according to that provider’s event definition. It may mean delivered to a hosted mailbox, handed to a downstream connector, or accepted by another system. It does not always mean visible in the Inbox folder.

Separate submission from server relay

RFC 6409 separates message submission from server relay. A person, application, or device normally submits through a provider-defined authenticated service. Mail servers relay between domains using a different trust and routing model.

That distinction prevents several common mistakes:

• an MX record identifies where a domain receives mail; it is not automatically the correct submission server for a scanner or application;
• port 25 server-to-server relay is not a drop-in substitute for authenticated client submission;
• a mailbox username and password are not appropriate for a connector that authenticates by certificate or approved source address; and
• “direct send,” client submission, and provider relay have different recipient, authentication, anti-abuse, and domain-authentication boundaries.

For Microsoft 365 applications and multifunction devices, current Microsoft guidance distinguishes authenticated client submission, connector-based SMTP relay, and direct send. Choose the documented model for the workload. Do not cycle through the three models as interchangeable troubleshooting guesses.

Diagnose authentication without weakening it

RFC 4954 defines SMTP authentication. Authentication can fail because the account, token, mechanism, tenant setting, application consent, sender authorisation, or security layer is wrong.

A password prompt does not prove that password authentication is supported. Modern providers can require OAuth or a provider-native account flow. Microsoft documents that Exchange Online SMTP AUTH supports OAuth and can be controlled at organisation and mailbox level in its current SMTP AUTH guidance.

Safe checks include:

• confirm the provider’s current supported submission method for that app or device;
• confirm the account is enabled, licensed where required, and authorised to send as the selected address;
• check whether SMTP submission is intentionally disabled for the organisation or mailbox;
• confirm the OAuth application, consent, token scope, and token freshness where OAuth is used;
• separate a bad credential from a blocked mechanism or unauthorised sender; and
• inspect sign-in and application logs without exposing secrets.

Do not disable MFA, security defaults, conditional access, or organisation-wide authentication controls merely to make one legacy device send. Use a supported workload-specific method, a bounded relay, an updated device or application, or replace the component that cannot meet the security requirement.

Diagnose TLS without bypassing trust

RFC 8314 treats cleartext email submission and access as obsolete. Providers commonly document submission using STARTTLS on port 587 or implicit TLS on port 465, but the correct host, port, certificate name, minimum TLS version, and authentication method must come from that provider.

Check:

• the client is reaching the documented hostname rather than an old IP or MX host;
• the system clock is correct enough for certificate validation;
• the certificate chains to a trusted root and matches the intended hostname;
• an intercepting firewall or gateway is not presenting an unexpected certificate;
• the client and server share a supported TLS version and cipher set;
• STARTTLS is actually negotiated when the selected submission mode requires it; and
• the application does not send credentials before a protective security layer exists.

Do not accept all certificates, ignore a name mismatch, enable obsolete TLS globally, or switch to cleartext. Those changes can expose credentials and message content while hiding the actual fault.

Server-to-server SMTP over port 25 has different TLS behaviour and policy mechanisms from authenticated client submission. A successful encrypted client test does not prove the remote relay path, and an opportunistic relay path does not justify unencrypted credential submission.

Check DNS and routing at the right stage

For inbound delivery, confirm the recipient domain’s current MX records and authoritative DNS. For outbound application submission, use the provider’s documented submission endpoint; do not infer it from MX.

When a sending queue reports routing failure, check:

• the exact domain being resolved;
• authoritative and recursive DNS results;
• MX preference and target names;
• address records for the chosen target;
• DNSSEC or resolver failures where relevant;
• stale cached results after an approved change;
• firewall or provider egress restrictions; and
• whether a connector or smart host overrides public MX routing.

Do not edit MX, SPF, or DMARC simply because “email uses DNS.” MX controls receiving routes. SPF, DKIM, and DMARC authenticate domain use and can influence receiver policy; they do not repair a bad mailbox password or application submission host.

If the rejection specifically concerns SPF, DKIM, or DMARC, use What DMARC Actually Entails to map the sender and alignment before changing records. Never add an unverified sender broadly to SPF just to silence one rejection.

Run controlled comparison tests

Use test recipients and domains you are authorised to use. Send a small plain-text message with a unique non-sensitive marker. Avoid attachments, links, marketing templates, signatures, and large recipient lists on the first test so content variables remain limited.

Choose one comparison that isolates the suspected boundary:

• same sender and message to a different authorised recipient domain;
• same recipient from another known-good authorised sender;
• same application through its documented test or alternate supported route;
• one ordinary mailbox message versus one application-generated message; or
• one affected recipient versus one unaffected recipient in the same organisation.

Do not change several variables together. Do not flood the recipient or repeatedly trigger an authentication lockout. Record every test’s exact time, route, Message-ID, and result.

The aim is not merely to produce one successful email. It is to explain why the failed and working paths differ.

Common symptoms mapped to the next check

Make the smallest reversible correction

Once the failed stage and cause are evidenced, record:

• the exact setting, account, connector, DNS record, policy, or sender being changed;
• why the evidence points there;
• the expected result;
• who approved it;
• the rollback value or configuration;
• the test message and authorised recipients; and
• the time after which cached or queued evidence becomes meaningful.

Examples of bounded corrections include fixing one recipient, renewing one application consent, enabling a supported submission method for one approved mailbox, correcting one connector scope, updating one provider endpoint, repairing one DKIM configuration, or removing one obsolete route.

Examples of unbounded changes include disabling TLS validation, enabling basic authentication across a tenant, allowing anonymous relay from a broad network, bypassing all spam checks, allowlisting an entire domain without validation, or replacing an SPF record with a copied example.

Verify the outcome end to end

A repair is not complete when the application reports “sent.” Prove:

1. the application submitted the new test message;
2. authentication and TLS used the intended supported path;
3. the sending service recorded and routed it;
4. the remote hop accepted it, or the temporary condition cleared;
5. the recipient system recorded the expected final action;
6. the message reached the intended mailbox or downstream system;
7. SPF, DKIM, and DMARC results remain as intended where applicable;
8. no broad bypass or unintended relay was introduced; and
9. the original business workflow—not only the simplified test—works.

Remove temporary diagnostic access, test connectors, verbose logs containing sensitive data, and test messages according to the approved retention practice. Keep the non-sensitive incident record and final configuration evidence.

Build a useful escalation pack

When another provider or administrator owns the failed stage, send a compact evidence pack:

• business impact and affected direction;
• one or two representative timestamps with time zone;
• redacted sender and recipient details sufficient to search;
• full Message-ID or provider trace ID through a secure channel;
• complete SMTP and enhanced status response;
• issuing host and last verified handoff;
• scope: one address, domain, connector, application, or all mail;
• controlled comparison result;
• relevant recent changes; and
• what has been ruled out without weakening security.

Ask a precise question: “Why did your host return 5.X.X for this Message-ID at this time?” is actionable. “Our email is broken” is not.

Diagnose the handoff, not the whole internet

SMTP delivery becomes manageable when each system is asked to prove only the handoff it owns. The application proves submission. The sender’s platform proves queue and next hop. The remote response proves acceptance or rejection at that server. The recipient’s systems prove filtering and mailbox delivery.

Start with one message, preserve the complete response, find the last verified event, and change only the failed boundary. That method is slower than guessing for the first few minutes—and far faster than recovering from an insecure workaround or a mail-flow change that nobody can explain.