550 5.7.515 Access Denied: What It Means and How to Fix It
The 550 5.7.515 access denied bounce is a hard reject, not a spam-folder placement. Microsoft has checked the domain in your From address against its authentication requirements, decided it does not meet the bar, and refused the message outright. Retrying the send will not change the outcome. The fix runs in a fixed order: repair SPF first, sign with DKIM second, then publish a DMARC record at p=none with alignment between your visible From domain and whichever of SPF or DKIM you use to authenticate.
What the 550 5.7.515 "access denied" error means
This bounce means Microsoft's mail servers rejected your message at the SMTP handshake because the sending domain failed the authentication level Microsoft requires of high volume senders, not because a spam filter judged the content.
The rejection text, in full, reads: "550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level" (Microsoft Support). Search for that exact string and you have landed on the right error.
Outlook checks three things before it accepts a message from a domain sending in volume: does SPF pass for that domain, does DKIM pass and align, and is there a DMARC record published for it at all. Alignment here compares two domains, the 5321.MailFrom domain your server presents during the SMTP handshake and the 5322.From domain your recipient actually sees in the message header, and at least one of them needs to carry a passing SPF or DKIM check. A domain that fails any leg of that check, or has no DMARC record whatsoever, gets this rejection. For background on how SPF, DKIM, and DMARC work together, each protects a different layer of the same From-domain claim.
Who this affects: the 5,000-message high-volume sender threshold
You cross into Microsoft's high volume sender category once your domain sends 5,000 or more messages to Microsoft consumer email services (Outlook.com, Hotmail, Live) in a day, using the same domain in the visible From address (Microsoft Support). Microsoft began enforcing this requirement on May 5, 2025, for domains crossing that volume threshold (URIports). Below that threshold, the same misconfigured SPF or DKIM record produces a soft failure or spam-folder placement instead of this hard block.
Microsoft is not the only mailbox provider drawing this line. Gmail and Yahoo introduced comparable authentication requirements for bulk senders in 2024, ahead of Microsoft's own enforcement (URIports). If your list crosses several major providers, the same SPF and DKIM records generally need to satisfy all three, since none of them accept an unauthenticated domain at scale anymore.
Why it's a hard reject, not a spam-folder problem
Before this policy, a domain with a broken SPF or DKIM record still had a shot at the inbox, usually a reduced one, landing in Junk. Microsoft has removed that middle outcome for high volume senders: a domain that fails authentication is rejected at the SMTP level and the message is never delivered to any folder (Palisade).
That distinction matters for how you diagnose it. A message sitting in spam is a sender reputation problem you can improve gradually through engagement and list hygiene. A 550 5.7.515 bounce is a binary authentication failure: the record is either correct and aligned, or the message does not arrive, full stop. There is no partial credit, and no amount of resending fixes a record that was never published correctly in the first place.
Fix order: SPF, then DKIM, then DMARC alignment
Work through these in sequence. Each layer depends on the one before it, so skipping ahead to DMARC before SPF and DKIM both pass just produces a DMARC failure instead of an SPF failure.
- Confirm SPF authorizes every server that sends on your domain's behalf, including your own mail servers and any ESP, then confirm the record resolves with a TXT record lookup rather than trusting what you typed into the DNS panel.
- Sign every outbound message with DKIM under your own domain, not a shared or default signing domain from your ESP, since Microsoft checks whether the DKIM signature's domain aligns with your visible From domain.
- Publish a DMARC record at v=DMARC1; p=none as the minimum viable policy, with either SPF or DKIM aligned to the 5322.From domain (Microsoft Support requires only one of the two to align, not both).
Start DMARC at p=none and read your DMARC aggregate reports for a few weeks before you consider moving to p=quarantine or p=reject (Valimail). p=none still satisfies Microsoft's minimum requirement while you confirm your own legitimate traffic is passing before you start rejecting anything that fails.
Configuring third-party ESPs so they don't break your alignment
Every ESP sending on your behalf, whether that's your CRM, your transactional mail provider, or a marketing platform, has to be added to your SPF record and configured to sign with DKIM under your domain, not theirs (Microsoft Support). Adding a new ESP without doing both is the single most common way this bounce reappears after you thought it was fixed.
Watch for multiple SPF records on the same domain as you add senders. Two separate v=spf1 lines for one domain is invalid by the SPF specification and will fail the check even if each line individually looks correct; every ESP and mail server needs to live inside a single merged record. Each ESP you add through an include mechanism also counts against SPF's 10 DNS lookup limit, so a domain with several ESPs stacked into one record can hit a permanent SPF failure purely from lookup count, independent of whether any individual sender is misconfigured (URIports). If you send through several ESPs and want to keep a mistake in one from touching your primary domain's reputation, isolating that ESP on a subdomain, such as marketing.yourdomain.com, keeps its authentication separate from your root domain's alignment (Valimail).
Sending from a personal domain like Yahoo? Why you can't fix this yourself
If you are sending from a personal Yahoo, Outlook.com, or similar consumer mailbox rather than a domain you control, you cannot edit that domain's SPF, DKIM, or DMARC records: only the mailbox provider itself holds those DNS records, and it manages authentication policy for every user on that domain at once (Microsoft Q&A). There is no per-account setting that gets your individual messages exempted.
Microsoft does not manually bypass the 550 5.7.515 block for individual senders, and a consumer provider is unlikely to change domain-wide authentication because one user is sending in volume (Microsoft Q&A). The two practical options are to move your sending to a custom domain where you control SPF, DKIM, and DMARC directly, or to keep your volume under the threshold on a provider like Gmail or Outlook.com where the authentication is already handled for you.
Why authentication can still fail after you think you've fixed it
Some senders publish correct-looking SPF and DKIM records and still get this bounce. Microsoft checks alignment at final delivery, not at the moment you sent the message, so a handful of conditions between your server and the recipient's inbox can break the check (Suped):
- One-leg DMARC passes hide a weak spot: DMARC passes if either SPF or DKIM aligns, so a domain can look compliant while its SPF is actually broken and only DKIM is carrying the pass, or the reverse.
- Forwarding changes what Microsoft sees: a message forwarded through another mailbox before reaching Microsoft often loses its original SPF pass, because the forwarding server is now the one connecting, not your original sending IP.
- Content modification breaks DKIM signatures: any system that rewrites the message body or headers after signing, including some forwarding and mailing-list software, invalidates the signature and produces a DKIM temperror or outright fail.
- DNS resolver variance returns stale records: a record you just corrected can still fail checks for a period if Microsoft's resolvers cached the previous, broken version.
- Recipient-specific or tenant-level restrictions sit outside authentication entirely: an individual mailbox, account, or tenant-level block can produce a similar-looking rejection that no SPF, DKIM, or DMARC change will resolve (Palisade).
Before changing any DNS record again, pull the full message headers or the bounce's diagnostic information and confirm exactly which check failed and on which domain. Guessing at a second fix before you've confirmed the first one actually failed just adds a new variable to the problem.
FAQ
What does the 550 5.7.515 error mean? It means Microsoft rejected your message because the sending domain in your From address failed the SPF, DKIM, or DMARC checks required of high volume senders. It is an outright block at delivery, not a spam-folder placement, and the exact rejection text is "550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level."
Will retrying the send fix a 550 5.7.515 bounce? No. Retrying sends the identical message from the identical unauthenticated domain, so Microsoft rejects it again. The message only goes through once SPF, DKIM, and DMARC are corrected and aligned to your 5322.From domain.
Is 550 5.4.1 the same error as 550 5.7.515? No. 550 5.4.1 is a recipient address rejection, meaning the mailbox provider does not recognize the recipient's address as valid. 550 5.7.515 is a sender authentication failure and has nothing to do with whether the recipient's address exists. Treat them as unrelated problems with unrelated fixes.
Can I still hit this error sending from Gmail or Yahoo? Yes, if you're sending from a personal mailbox on either provider in high volume, since the provider's shared domain-wide authentication applies to every user. You cannot adjust SPF, DKIM, or DMARC for an individual Gmail or Yahoo account; a custom domain is the only way to control those records yourself.
Is the 5,000-message threshold still enforced in 2026? Yes. Microsoft's high volume sender requirements, in place since May 2025, remain active in 2026 with no signaled rollback, and Gmail and Yahoo continue to enforce their own comparable bulk sender rules alongside it.
