# Outlook 550 5.7.515 "access denied": fix SPF, DKIM and DMARC If your email to Outlook.com, Hotmail, Live.com or MSN addresses comes back with this bounce, Microsoft has decided your domain doesn't meet its authentication rules for high-volume senders: ``` 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. ``` The rejection is about the domain in your **From** address, not about one message or one recipient. The fix is the same three DNS records that Gmail asks for, with one difference covered below. ## Who this applies to Microsoft's rules apply to domains that send **more than 5,000 messages a day** to Microsoft's consumer mailboxes (Outlook.com, Hotmail, Live.com, MSN). They took effect on **5 May 2025**. Microsoft first sends non-compliant mail from those domains to the Junk folder. If the problem isn't fixed, messages may be rejected with 5.7.515. Once your domain is over the threshold, the requirements apply to every message sent with that From domain, including the low-volume ones such as invoices and password resets. ## What Microsoft requires All three must be in place: 1. **SPF passes.** Your SPF record lists every server that sends for you. 2. **DKIM passes.** Messages are signed, and the public key is published in your DNS. 3. **DMARC passes.** A DMARC record is published (`p=none` is enough), and at least one of SPF or DKIM is **aligned** with the From domain. The minimum DMARC record looks like this: ``` _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` The difference from Gmail: for its higher tier, Google asks for SPF, DKIM and DMARC, but accepts DMARC passing through either SPF or DKIM. Microsoft's page says SPF and DKIM must **both pass**. A setup where DKIM passes but SPF fails, for example mail from a service that isn't in your SPF record, can satisfy DMARC and still fall short here. ## Step 1: read the headers Find a message from the affected stream that reached an Outlook.com mailbox (it may be in Junk), or send a test to one you control. Open the message headers and look at the authentication results: ``` Authentication-Results: spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=example.com; dkim=pass (signature was verified) header.d=example.com; dmarc=pass action=none header.from=example.com; ``` Check three things: - `spf=` and `dkim=` both say `pass`. - `smtp.mailfrom=` (the Return-Path domain) or `header.d=` (the DKIM domain) matches the From domain, or is a subdomain of it. - `dmarc=pass`. ## Step 2: fix what failed ### SPF fails 1. Find the sending IP in the headers and the service it belongs to. 2. Add the service to your SPF record using the value from its setup guide. 3. Keep to **one** SPF record per domain, and stay within SPF's limit of 10 DNS lookups. See [SPF "too many DNS lookups"](/guides/spf-too-many-dns-lookups). ### DKIM fails or is missing 1. Turn on DKIM signing in each service that sends as you: Microsoft 365, Google Workspace, your marketing platform, CRM, helpdesk, billing system. 2. Publish the DKIM records each one gives you. 3. Make sure each signs with **your** domain (`header.d=example.com`), not the service's own domain. ### DMARC fails or there is no record 1. Publish the record above if you have none. 2. If DMARC fails while SPF and DKIM pass, the passes are for someone else's domain. Set the service to use your domain in the Return-Path (often called a "custom bounce domain" or "custom MAIL FROM"), and to sign DKIM with your domain. ### Third-party senders Microsoft's guidance is that any service sending for you should use your domain in the MAIL FROM address, sign with your DKIM key and be included in your SPF record. Check each service, not only your main mailbox provider. ## Step 3: confirm and keep watching Send a new test to an Outlook.com address and check the headers again. Then read your DMARC aggregate reports for a week or two. They list every source sending as your domain and whether it passed, which is how you find the forgotten tool that will trigger the next bounce. When everything passes, `p=none` meets Microsoft's rule but still lets anyone spoof your domain. [DMARC p=none to p=reject](/guides/dmarc-none-to-reject) shows how to tighten it safely. If Gmail is bouncing your mail too, see [Gmail 550 5.7.26](/guides/550-5-7-26). Bounced with 5.7.509 instead? That's DMARC `p=reject`: see [550 5.7.509](/guides/550-5-7-509). ## Check your domain The [free scan](/#scan) checks your SPF, DKIM and DMARC records and shows what would fail at Outlook.com and Gmail. For single checks, use the [DMARC checker](/tools/dmarc-checker) and the [SPF lookup counter](/tools/spf-lookup-counter). ## Sources - [Microsoft Support: Fix NDR error "550 5.7.515" in Outlook.com](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) - [Outlook.com postmaster: policies, practices and guidelines](https://substrate.office.com/ip-domain-management-snds/postmaster/Policies) - [Google: Email sender guidelines](https://support.google.com/a/answer/81126) - [RFC 7208: SPF](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 7489: DMARC](https://www.rfc-editor.org/rfc/rfc7489) - [RFC 8601: Authentication-Results header](https://www.rfc-editor.org/rfc/rfc8601) --- Source: https://nameward.app/guides/550-5-7-515 (updated 2026-10-30)