# 5.7.509 Access denied: sending domain does not pass DMARC URL: https://iblockspam.com/smtp-errors/5-7-509-access-denied Last updated: 2026-10-09 Code: 550 5.7.509 (permanent failure, the message bounced) Provider: Microsoft 365 / Outlook.com Microsoft 365 rejected the message because it failed DMARC, and the domain in the From address publishes a DMARC policy of reject. What the bounce says: ``` Access denied, sending domain [] does not pass DMARC verification and has a DMARC policy of reject. ``` Microsoft's text for 5.7.509, as listed in its Exchange Online NDR reference (Microsoft shows the domain as $SenderDomain). Microsoft's NDR reference says 5.7.509 is returned when the sender's domain in the 5322.From address (the From header people see) doesn't pass DMARC, and that domain's DMARC policy is set to reject. Microsoft is doing what the domain owner asked. Passing DMARC needs SPF or DKIM to pass **and** to align with the From domain. A message can pass SPF for a service's own bounce domain and still fail DMARC, because that domain isn't yours. Microsoft lists three reasons DMARC fails: missing or incorrect DMARC or DNS records (alignment issues, missing SPF, policy issues), missing DKIM (no public key in DNS, or the message wasn't signed), and forwarding that breaks SPF or DKIM. If the domain in the bounce is yours, find the service that sent the message and make it authenticate as your domain, usually by turning on DKIM signing with your domain. If the domain isn't yours and you're the sender, you can't send "as" another organization's domain through your own systems; use your own domain in the From address. ## Common causes - A service sending as your domain isn't DKIM-signing with your domain and isn't aligned for SPF. - SPF passes only for the service's own bounce domain, not yours (no alignment). - DKIM is missing: no public key published, or the message wasn't signed. - The message was forwarded and the forwarder broke SPF or DKIM. ## How to fix it (sender) - Identify the sending service from the bounce headers and enable DKIM signing with your domain there. - Add the service to your SPF record and set a custom bounce (Return-Path) domain if it offers one. - Use your DMARC aggregate reports to find every source that fails before tightening the policy. - Don't fix this by switching DMARC to p=none for good: that removes the protection against spoofing. ## How to fix it (recipient or admin) - No action is usually needed: Microsoft is applying the sender domain's own policy. If a needed partner is affected, ask them to fix their authentication. **Q: Why did 5.7.509 start appearing when nothing changed?** Either your domain's DMARC policy was moved to reject, or a service sending as your domain changed how it signs mail. Check your DMARC reports to see which source started failing. **Q: Should I set DMARC back to p=none to stop 5.7.509?** Only briefly, while you fix the failing source. With p=none, receivers no longer reject mail that spoofs your domain. Fix alignment for the legitimate sender and keep the stronger policy. Sources: - Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn): https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online - Set up DMARC to validate email in Microsoft 365 (Microsoft Learn): https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure --- Source: iBlockSpam, https://iblockspam.com/smtp-errors/5-7-509-access-denied (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt