can no longer send email with Outlook.

The sending domain’s administrator or email provider must correct its SPF, DKIM, and DMARC configuration; repairing or reinstalling Classic Outlook will not resolve this rejection.

A bounce stating “Message lacks SPF/DKIM/DMARC Auth Records” means Outlook successfully submitted the message, but the receiving mail system rejected it because it could not authenticate the sender’s domain. Missing records, an unauthorized sending service, domain misalignment, or a message modified by an intermediary can produce this result.^1^

If you use a custom email domain

For an address such as [Email], send the complete non-delivery report (NDR) to whoever administers the domain or hosts its email. They should:

1. Check the exact NDR code and authentication results.
   • Look for results such as spf=none/fail, dkim=none/fail, and dmarc=fail.
   • Verify that the visible From domain matches, or “aligns” with, the domain authenticated by SPF or DKIM.
2. Correct SPF in the domain’s DNS.
   • There must be one SPF TXT record authorizing every legitimate sending service.
   • Common failures include multiple SPF records, omitted third-party senders, and exceeding the ten-DNS-lookup limit.^1^
3. Enable DKIM signing.
   • Publish the DKIM records supplied by the mail provider and enable signing.
   • A dkim=none result indicates that the message was not signed; dkim=fail can indicate a missing selector, mismatched key, or message modification after signing.
4. Publish a valid DMARC TXT record at _dmarc.yourdomain.com.
   • DMARC must use a valid policy such as p=none, p=quarantine, or p=reject.
   • DMARC passes when aligned SPF or aligned DKIM passes; both do not need to provide alignment.^2^
5. Check every third-party sender. If a website, CRM, newsletter service, scanner, or relay sends using your domain, it must be included in SPF or DKIM-sign with your domain. Forwarders and gateways that alter messages can also break authentication.^1^

Do not replace an existing SPF record with a guessed value. The correct record depends on every service authorized to send for the domain.

If the NDR code is 550 5.7.515

This specific code applies when a domain sends at least 5,000 messages to Microsoft consumer services using the same From domain. Microsoft then requires:

• SPF and DKIM records, with both checks passing.
• A published DMARC record.
• DMARC validation through aligned SPF or DKIM.[^3^](https://support.microsoft.com/outlook/fix-ndr-error-550-5-7-515-in-outlook-com#why-did-i-get-this-bounce-message "Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support")

The domain administrator must also verify any external sending platform is authorized in SPF and configured to DKIM-sign using the custom domain.

If this is a personal address

If the From address ends in @outlook.com, @hotmail.com, @live.com, or @msn.com, there are no personal DNS records for you to edit. Try sending the same short, attachment-free message from Outlook on the web:

• Webmail also returns the same authentication bounce: contact Outlook support using Help (?) → Contact Support and provide the complete NDR, including its numeric code and timestamp.
• Webmail succeeds but Classic Outlook fails without generating an NDR: that is a separate client-side issue. Classic Outlook troubleshooting—connection status, Safe Mode, profile repair, and Office repair—then becomes relevant.^4^

If only messages to one organization or to Outlook.com/Hotmail recipients fail, the same NDR still needs to be investigated by the sending-domain administrator; the recipient cannot add authentication records for your domain.

References

1. Troubleshoot email authentication in Microsoft 365
2. Set up DMARC to validate email in Microsoft 365 - Microsoft Defender ...
3. Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support
4. [Classic Outlook](https://support.microsoft.com/outlook/i-can-t-send-or-receive-messages-in-outlook#make-sure-you're-connected-to-the-internet)