Gmail and Outlook email bounces Read the error, find the cause

Four things to read in a bounce message

A delivery failure notice is often called an NDR or DSN. It usually contains a readable explanation, machine-readable delivery status, and part of the original message. Forwarding can lose some of that structure. Use “Show original” or save the original message file where possible.

Reporting-MTA: dns; smtp.crm.example

Final-Recipient: rfc822; buyer@example.net
Action: failed
Status: 5.7.26
Remote-MTA: dns; mx.receiver.example
Diagnostic-Code: smtp; 550 5.7.26
 This email has been blocked because the sender is unauthenticated.

The addresses and server names are examples. A real notice may also include the sending IP, authentication results, provider hostnames, and a help link. A wrapped line can continue the previous field, so a screenshot of only the first line may lose the useful part.

Reporting-MTA identifies the server that generated the notice. It is not necessarily the server that rejected the message. A CRM server can receive a rejection from Gmail and then create the bounce you see. Confusing the two can send your support request to the wrong provider. Delivery status notification format ↗

An enhanced status beginning with 4 describes a temporary failure; 5 describes a permanent failure category. “Permanent” does not mean your domain is blocked forever. It means simply retrying under the same conditions is unlikely to resolve the failure. With Action: delayed, the sending server may still be retrying. Check the queue and final outcome first. Enhanced status code definitions ↗

Identify the sending service, not just the app

“Sent from Outlook” does not identify the sending provider. The Outlook app can connect to Google Workspace, NAVER WORKS, Microsoft 365, and other accounts. Conversely, a quote bearing your company address may have left through a CRM server rather than your normal employee email service.

If webmail works and the CRM fails, investigate those paths separately. Successful login or a CRM status of “sent” may establish only that the service accepted the request. A bounce can arrive later.

Compare the visible From address, sending IP, envelope MAIL FROM domain, and DKIM signing domain. MAIL FROM supplies the return address used for delivery failures. In a received message it is usually reflected in Return-Path, and it can differ from the visible From address. Microsoft’s explanation of SPF and sender addresses ↗

Authorizing employee email in your SPF record does not automatically authenticate the CRM. Use the SPF setup guide to match the actual sender to the domain being checked. For the broader picture, start with how email authentication works.

Gmail 550 5.7.26 has several different explanations

Google uses 550 5.7.26 for more than one authentication failure. Look for the wording below and retain the accompanying domain and IP. These are search clues, not complete copies of the responses.

Google lists these as distinct cases. Removing the IP or domain from a support request removes evidence needed to tell them apart. Gmail SMTP errors and codes ↗

If the sender is described as unauthenticated

A DNS record can exist while a message still fails authentication. Publishing a DKIM public key does not add a signature if signing has not been enabled in the sending service. A signature may also fail because its selector points to the wrong key or signed content changed in transit.

Compare the service’s domain-authentication settings with an actual message. Google Workspace’s DKIM setup, for example, involves publishing DNS, starting signing, and checking sent mail. For another service, follow its issued values and activation process. Google Workspace’s DKIM setup process ↗

If the response mentions SPF -all and an IP

-all produces an SPF fail when earlier mechanisms do not authorize the connecting server. First establish whether that server is an approved sender. For a genuine CRM, compare its official SPF instructions, actual MAIL FROM, and your existing sender inventory. Do not authorize an unfamiliar IP simply because it appears in a bounce.

Adding SPF to your company’s root domain will not change a check performed against a provider-owned domain. Changing -all to ~all changes the failure result; it does not make an omitted server pass. SPF identities and failure results ↗

If the response cites DMARC policy

The From address can use your company domain while SPF and DKIM pass only for the sending provider’s domains. DMARC also requires a passing method to align with From. Check the service’s company-domain DKIM signing or custom MAIL FROM setup. Alignment follows specific domain rules, not a visual resemblance between names. DMARC authentication and alignment ↗

Lowering the policy to p=none does not turn authentication failure into PASS or remove the receiver’s other rejection criteria. On a domain already protected by an enforcement policy, review the affected scope and recovery plan and correct the legitimate sending path first.

Outlook.com 550 5.7.515: check both SPF and DKIM

550 5.7.515 concerns high-volume sender authentication at Microsoft’s personal services, including Outlook.com, Hotmail, Live, and MSN. It is not an Outlook app login error or a general description of every Microsoft 365 business-mail rejection.

When investigating a domain’s volume, include newsletters and CRM messages using the same From domain as employee email. If this error appears, compare the domain named in the response with the service that actually sent the message.

Check all three. Aligned DKIM alone can make DMARC pass, but does not remove the bulk-sender requirement for SPF. Microsoft also requires a valid DMARC policy; its minimum includes p=none. That is not an instruction to weaken an existing policy. Microsoft’s 5.7.515 guidance ↗

If employee email succeeds but newsletters fail, check the three results on the newsletter path. A DNS lookup alone is insufficient: ask which domain the newsletter service actually signs with.

Worked example: webmail succeeds but CRM quotes bounce

Fictional Gaon Trading already uses p=reject but overlooks authentication when adding a CRM. Staff send from sales@example.com in both systems. Webmail arrives; CRM quotes bounce at Gmail with a DMARC-related 5.7.26 response. The administrator compares the CRM logs and configuration as follows.

Adding an arbitrary CRM include to the company’s SPF would miss the relevant distinction: the CRM’s passing SPF domain is mailer.example.net, not example.com. Because this CRM supports company-domain DKIM, configuring that signature addresses the alignment failure. DMARC alignment for external sending services ↗

1. Get the values issued by the CRM

   Confirm that it supports domain authentication and obtain the DKIM TXT or CNAME name and value issued for example.com. Do not substitute another company’s key or the employee-mail provider’s values.

2. Publish DNS and activate signing

   Check for selector conflicts, verify DNS, complete the CRM’s activation process, and confirm that signing applies to actual quote messages.

3. Send a new quote through the same CRM

   A successful webmail workaround does not test the fix. Use the affected template and sending path, obtain a new Message-ID, and compare the result.

From: Gaon Trading Sales <sales@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=example.com; s=crm; ...

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=mailer.example.net;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Return-Path is unchanged, but the company-domain DKIM signature now passes, giving DMARC an aligned result. SPF and DKIM both pass in this copy. That gives the team useful evidence for the Outlook.com requirements too, although Outlook.com delivery must still be tested separately. Success at Gmail does not prove acceptance elsewhere.

A rejected message may never acquire authentication headers from the final receiver. Do not expect to find the example above in every bounce. Compare the original error and sending logs before the change with a newly received message after it. For configuration details, use the DKIM setup guide and alignment troubleshooting guide.

PTR, TLS, and IP blocks need different fixes

If mail still bounces, read the new error. Fixing the first failed check can expose another problem further along the path. These issues need investigation beyond DKIM keys or a DMARC policy.

PTR is reverse DNS: an IP resolves to a hostname. Check whether that hostname also resolves back to the IP. If you use a provider’s shared sending IP, this is usually outside your company’s DNS settings. SMTP TLS is also separate from the HTTPS certificate on your website. Google’s sending infrastructure requirements ↗ Gmail error reference ↗

A resolved incident at a Korean provider illustrates the distinction

On March 4, 2026, NAVER WORKS reported that some messages to Microsoft’s personal email domains were bouncing with S3150. The provider requested removal of the block from Microsoft. Its notice records resolution at 19:00 that same day; this is not an account of an ongoing outage. NAVER WORKS resolution notice, in Korean ↗

For a provider IP or network issue, give that provider the actual response and sending IP before editing each customer domain’s SPF. Treating S3150 as equivalent to the authentication error 5.7.515 would send the investigation in the wrong direction. Use the provider’s official support route when coordinating a removal request.

Send support enough information to trace one failure

“Gmail delivery is broken” may describe several unrelated problems on the same day. Use a request like this for your mail provider, CRM vendor, or internal administrator. Share personal addresses and body content only as needed, through an appropriate private channel.

[Symptom]
CRM quotes bounce for Gmail recipients.
Company webmail to the same recipient arrives.

[Incident details]
Sending date, time, and time zone: YYYY-MM-DD HH:mm, [zone / UTC offset]
Actual sending service and feature: [service / automated quotes]
Visible From domain: [company domain]
Recipient domain and confirmed service: [for example, gmail.com / Gmail]
Scope: [all / certain domains / selected recipients; checked counts]
Recent changes: [DNS, SMTP, plugin, or template changes]

[Trace details — use the official private support channel]
Original Message-ID: [if known]
Provider message ID or queue ID: [if known]
Remote server and sending IP: [if present in the bounce or logs]
Error code and full explanation: [include continuation lines]

[Request]
Please identify the failing sending path and authentication domain.
Separate the required DNS changes from changes inside the sending service.
Please explain how to verify the fix through the same sending path.

A Message-ID identifies a message; a provider’s message ID or queue ID may be a different identifier. Keep the original labels. If the recipient cannot supply the original, start with the evidence available in the sending service’s logs.

Passwords, SMTP credentials, and DKIM private keys are not needed as attachments to this request. If support needs the original message, use the company’s approved private channel and agree on the scope of recipient information being shared. The aim is to connect a particular failed delivery to the right log.

Confirm the fix with a new message

A green DNS status does not establish recovery. DNS caching, signing activation, or differences between sending servers can still affect the result. Old messages preserve old results, so send a fresh one after the change.

1. Retest the affected path with a small number of messages

   Keep webmail, CRM, and website notifications separate. Check Gmail and Outlook.com independently and record each test’s time and Message-ID.

2. Match sending logs to the received original

   Check whether the old error has cleared and compare SPF, DKIM, DMARC, and their domains. Record any forwarding or intermediate server.

3. Record acceptance and final location separately

   Check whether the final server accepted the message and whether it appeared in the inbox or spam. Follow queued retries through to their final outcome.

Once a quote arrives, test other templates and automated jobs using the same service. A salesperson’s manual send and a month-end batch can take different paths. Keeping per-sender verification records makes the next change easier to test.

If the bounce disappears but the message lands in spam, move to why authenticated email can still go to spam and investigate reputation and recipient results.

A public DNS check can help you start assessing domain authentication, but it cannot prove the cause of a particular bounce or guarantee inbox delivery. Bring together the full bounce, the actual sending path, and the result of a new message. That evidence makes it much easier to identify what your team can fix and what the sending provider needs to investigate.