Microsoft rejected your message because it failed DMARC for the domain in your From: address, and that domain tells receivers to reject mail that fails. Check the policy, SPF and DKIM records below, then find the sending service that doesn’t align and fix it.
Last verified 1 October 2026.
The bounce reads:
550 5.7.509 Access denied, sending domain [domain] does not pass DMARC verification and has a DMARC policy of reject.
Three things happened, in this order:
p=reject. For a subdomain without its own DMARC record, the parent’s sp= tag sets the policy (it defaults to p=). Microsoft honours reject, so it refused the message during delivery instead of putting it in junk.It comes from Outlook.com and Hotmail inboxes and from Microsoft 365 organisations, whose anti-phishing policies honour the sender’s DMARC policy when “Honor DMARC record policy” is on (Microsoft recommends it). A 5xx code is a permanent rejection: resending the same message from the same service gets the same bounce.
5.7.509 vs 5.7.515: 550 5.7.515 is Outlook.com’s high-volume sender rule: your domain doesn’t meet the required authentication level (SPF, DKIM and a DMARC record), whatever its policy. 5.7.509 is about your own policy: the domain asked for failing mail to be rejected, and this message failed.
Sources: Microsoft Learn, Set up DMARC to validate email in Microsoft 365 (DMARC for inbound mail, alignment troubleshooting, trusted ARC sealers); RFC 9989 (DMARC, which replaced RFC 7489 in May 2026) (checked 1 October 2026).
Enter the domain named in the bounce (the one in your From: address). The lookups run in your browser against public DNS and show the DMARC policy that applies, whether SPF is valid, and whether DKIM keys are published at the common selectors.
DNS shows what the domain publishes, not which sender failed. To see that, read the Authentication-Results header of a bounced or delivered message (how).
What this can and can’t tell you: it reads the records the domain publishes right now, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). It can’t check alignment, because that depends on the Return-Path and DKIM d= domains inside each message. DKIM keys can’t be listed from DNS, so it checks three common selectors (Microsoft 365’s selector1 and selector2, Google Workspace’s google); your services may sign with others. For a subdomain without its own record, it finds the organisational domain’s record by walking up the name, using a built-in list of common public suffixes rather than the full Public Suffix List. For the full A–F grade with MTA-STS, BIMI and DNSSEC, use the DMARC checker.
Every service that sends with your From: address must pass DMARC on its own: your mailbox provider, your newsletter tool, your CRM, help desk, invoicing and website forms. The bounce, or a copy of the same mail delivered to any mailbox you control, tells you which one failed. Open the message source (Outlook: File > Properties > Internet headers; Gmail: Show original) and find the Authentication-Results header. Microsoft’s looks like this:
Authentication-Results: spf=pass (sender IP is 198.51.100.10)
smtp.mailfrom=bounces.mailer.example.net; dkim=pass (signature was verified)
header.d=mailer.example.net; dmarc=fail action=oreject
header.from=example.com;compauth=fail reason=000header.from= | The From: domain DMARC is checked for (example.com). |
|---|---|
smtp.mailfrom= | The Return-Path (envelope sender) domain SPF was checked for. Here it’s the service’s domain, so SPF passed but doesn’t align. |
header.d= | The domain that signed DKIM. Again the service’s own, so DKIM passed but doesn’t align. |
dmarc=fail action=oreject | Neither aligned, and the domain’s policy is reject. action=pct.reject means pct= is below 100 and Microsoft didn’t apply the reject policy to this message. |
The sending IP, the smtp.mailfrom domain and the Received: lines name the service. If you can’t get a header, your DMARC aggregate reports (the rua= address) list every IP that sent as your domain and whether SPF and DKIM aligned.
One aligned pass is enough for DMARC, and DKIM is the sturdier one because it survives forwarding. Do both where the service supports it.
Set the service up to sign with d=yourdomain.com (or a subdomain of it, under relaxed alignment). This is usually called domain authentication or custom DKIM, and means publishing one or two records the service gives you.
selector1._domainkey and selector2._domainkey CNAMEs it shows, then turn on signing. Without this, Microsoft 365 signs with your onmicrosoft.com domain, which doesn’t align.google._domainkey and click Start authentication.For SPF to align, the envelope sender (smtp.mailfrom) must be your domain or, under relaxed alignment, a subdomain such as bounces.yourdomain.com, and that name’s SPF record must list the service. Many services set this up as a “custom return-path” or “custom MAIL FROM” CNAME. Adding the service’s include: to your root SPF record only helps when the Return-Path is your root domain. Keep a single SPF record (merge duplicates) under 10 DNS lookups (how to cut them); a broken record fails SPF for every message.
With aspf=s or adkim=s in your DMARC record, only an exact match with the From: domain aligns: a bounces.yourdomain.com Return-Path or a d=mail.yourdomain.com signature fails. Switch to relaxed (remove the tag) unless you need strict.
When a recipient forwards your mail, or a mailing list resends it, the new server isn’t in your SPF, and a list that edits the subject or adds a footer breaks your DKIM signature. Mail signed with your domain survives plain forwarding, so DKIM is the fix on your side. The rest is the receiver’s: intermediaries can add an ARC seal, and a Microsoft 365 organisation can add the forwarder or list as a trusted ARC sealer.
p=quarantineIf a business-critical sender bounces and the fix will take days, you can change p=reject to p=quarantine (and sp=, if set) at _dmarc.yourdomain.com. Microsoft then delivers failing mail to junk instead of refusing it. This lowers your protection: spoofed mail using your domain reaches junk folders instead of being refused. Do it only while you fix the sender, then go back to p=reject. A cleaner long-term setup is to send that service from its own subdomain with its own DMARC record.
DMARC needs SPF or DKIM to pass for a domain that aligns with the From: address. A service that sends with its own Return-Path (smtp.mailfrom) and signs DKIM with its own domain (header.d) passes both checks for its domain, not yours, so DMARC fails. Fix it by having the service use a Return-Path on your domain or sign DKIM with d= set to your domain.
No. DNS shows the policy and records you publish, not what happened to a particular message. The Authentication-Results header of a failing message, or your DMARC aggregate reports, show which server sent it and whether SPF and DKIM aligned.
Only as a short-term measure while you fix the sender. Changing p=reject to p=quarantine stops the 5.7.509 rejections, but failing mail, including spoofed mail, is then delivered to junk folders instead of being refused. Fix the sender’s alignment, then move back to p=reject.
Forwarding sends the message from a new server, so SPF fails, and a mailing list that edits the subject or adds a footer breaks the DKIM signature. With both broken, DMARC fails. Mail you sign with DKIM survives plain forwarding. For lists and gateways, the receiving organisation can trust the intermediary’s ARC seal; Microsoft 365 calls this a trusted ARC sealer.
If you manage sending domains for clients or brands, Email Security Signals runs the same DNS checks on a whole list and returns one row per domain with the DMARC policy, SPF lookup count, DKIM selectors found and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →