Sending, receiving, and organizing email in Outlook.com
The sending domain’s administrator or email provider must inspect the complete bounce code and correct its sender authentication; if the code is 550 5.7.515, configure SPF, DKIM, and DMARC as described below.
If the bounce contains 550 5.7.515
This code means Hotmail/Outlook.com rejected the sending domain because it did not meet the required authentication level. Microsoft applies these requirements to domains sending at least 5,000 messages per day to its consumer email services.[^1^](https://support.microsoft.com/outlook/fix-ndr-error-550-5-7-515-in-outlook-com "Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support")
Ask whoever manages the domain’s DNS and outgoing email to:
- Check the authentication results
- Open the full headers of a message sent through the same mail system.
- Locate
Authentication-Resultsand record the results forspf,dkim, anddmarc. - Compare the domain in the visible
Fromaddress with the domains shown for SPF and DKIM.
- Correct SPF
- Maintain one SPF TXT record for the sending domain.
- Include every legitimate mail service or sending IP.
- Confirm SPF passes for the envelope sender domain.
- Enable DKIM
- Configure the mail service to DKIM-sign outgoing messages.
- The signing domain should match, or align with, the domain in the visible
Fromaddress.
- Publish DMARC
- Create a TXT record at
_dmarc.yourdomain. - A basic monitoring policy is:
v=DMARC1; p=none- Confirm DMARC passes through an aligned SPF or DKIM result.
- Create a TXT record at
- Check third-party senders
- If a website, CRM, newsletter platform, scanner, or other service sends on the domain’s behalf, add its authorized values to SPF and configure it to DKIM-sign with the organization’s domain.
- Ensure that it does not send using its own unrelated envelope and signing domains while displaying your domain in
From.
Microsoft documents that SPF and DKIM must pass for affected high-volume senders, a DMARC record must exist, and SPF or DKIM must align with the visible From domain.[^1^](https://support.microsoft.com/outlook/fix-ndr-error-550-5-7-515-in-outlook-com "Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support")
If the bounce has a different code
Copy the complete non-delivery report, especially:
- The SMTP status code, such as
550 5.7.x - “Diagnostic information for administrators”
- The remote-server response
- The sender domain and sending service, with personal addresses removed
The wording about a “trusted location” does not refer to Microsoft Office Trusted Locations. A different status code can indicate an authentication, reputation, blocklist, or account restriction issue, so the exact code determines the remediation.
For a custom or business domain, the mail administrator should also verify:
- The sending server has valid reverse DNS.
- It does not identify itself using a private/non-routable address.
- The sending IP and domain have not developed a poor spam reputation.
- The server is not compromised or sending unsolicited bulk mail.
Microsoft’s Outlook.com sender guidance states that delivery can be affected by IP/domain reputation, reverse-DNS failures, authentication, complaint rates, and sending behavior.^2^
Escalate after authentication passes
If SPF, DKIM, and DMARC pass and mail to other providers works, but Hotmail/Outlook.com still rejects it:
- Open Outlook.com Sender Support.
- Use its deliverability troubleshooting form.
- Submit the sending IP, domain, exact SMTP error, approximate timestamps, and evidence that authentication passes.
That channel covers delivery to hotmail.com, outlook.com, live.com, and msn.com; submitting a case does not guarantee delivery.^2^
If the sending address itself is a personal Outlook.com/Hotmail account rather than a custom domain, use Outlook.com’s send/receive troubleshooting instead, because domain DNS changes do not apply to an address managed entirely by Microsoft.^3^
References