Why are Hotmail emails being rejected after setting up DMARC?
Updated on 20 Oct 2026: We clarified Microsoft's rejection codes and tightened the checks for SPF, DKIM, forwarding, and temporary DMARC policy changes.
If the bounce is 5.7.509, Hotmail is rejecting the message because it fails DMARC and the applicable policy asks receivers to reject failed mail. The bounce 5.7.509 means the receiving Microsoft system checked the message, found that neither the SPF path nor the DKIM signature gave DMARC an aligned pass, then applied your p=reject policy under its local handling rules.
If a legitimate sender cannot be repaired promptly, a temporary containment option is to change its applicable DMARC policy to p=none while keeping reporting active. This reduces spoofing protection and does not guarantee delivery. A common cause is SPF authenticating a MAIL FROM domain that does not match the visible From domain for DMARC. This often happens when a marketing platform, CRM, help desk, website, or forwarding system uses its own envelope sender while the user-visible From address uses your domain.
Do not wait for Hotmail to "catch up" without checking DNS. Verify the published record and its previous TTL, then test the same sending source. Once the current record is visible, repeated 5.7.509 rejections need authentication diagnosis rather than more waiting.
What the Hotmail bounce means
The exact diagnostic often looks like this:
Typical Hotmail DMARC rejectiontext
550 5.7.509 Access denied, sending domain [EMAIL.MYDOMAIN.COM] does not pass DMARC verification and has a DMARC policy of reject.
That diagnostic identifies a DMARC failure for the domain in the From header. Microsoft DMARC setup documents the same basic rule: DMARC passes when SPF or DKIM passes and its authenticated domain matches the From domain under the applicable alignment mode. If both aligned paths fail, DMARC fails.
If you only control the receiving Hotmail mailbox, send the full non-delivery report to the sender's administrator. Adding the address to safe senders does not repair authentication or reverse a rejection that happened before delivery.
- Policy: Your p=reject instruction asks receivers to reject mail that fails DMARC.
- SPF path: SPF must pass for the envelope sender domain, and that domain must match the visible From domain under your DMARC mode.
- DKIM path: DKIM must pass, and the d= signing domain must match the visible From domain under your DMARC mode.
- Receiver action: Hotmail can reject at SMTP time when it honors the published policy, although final handling remains the receiver's decision.
DMARC flowchart showing Hotmail checking SPF and DKIM before applying a reject policy.
Check whether the bounce is 5.7.509 or 5.7.515
Outlook.com has separate authentication requirements for high-volume senders, introduced on May 5, 2025. Microsoft's high-volume sender requirements cover domains reaching its 5,000-message daily threshold across consumer email services, including Hotmail and Outlook.com. Its current support guidance defines a high-volume sender as 5,000 or more messages using the same visible From domain.
|
|
|
|---|---|---|
550 5.7.509 | DMARC failed and the applicable policy is reject. | Repair a passing SPF or DKIM path with the required domain match; review the effective policy. |
The sending domain did not meet Microsoft's required authentication level. | Make both SPF and DKIM pass, publish a valid DMARC record, and pass DMARC through at least one matching domain. |
Different Microsoft authentication rejections need different fixes.
For high-volume compliance, p=none is an acceptable DMARC policy, but the messages still need to pass authentication. Changing p=reject to p=none alone does not fix 5.7.515. Ordinary DMARC needs one aligned authentication pass; Microsoft's high-volume requirements also call for SPF and DKIM to pass individually.
How to restore legitimate mail
When legitimate mail is actively bouncing with 5.7.509, repair the failing sender first if that can be done promptly. Otherwise, temporarily reduce enforcement on the affected From domain while keeping reporting active. A monitoring policy does not request DMARC-based rejection, but Microsoft still applies its other authentication and filtering rules.
Temporary monitoring DMARC recorddns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace example.com and the reporting address with your own domain and a working report destination. If the From address uses email.example.com, check _dmarc.email.example.com and any inherited policy before changing the parent. Then send a real message through the same system that bounced. Do not test only a personal mailbox when the failure is in a CRM or another sending service.
- Contain: If an immediate sender repair is unavailable, temporarily change the affected domain's applicable policy to p=none and keep aggregate reporting enabled.
- Collect: Keep the full NDR and any attached original headers. If the receiving system's results are absent, request delivery logs from the sending provider.
- Inspect: Check spf=, dkim=, dmarc=, smtp.mailfrom, header.d, and header.from.
- Repair: Configure the sender so SPF or DKIM uses a domain that matches the visible From domain under the applicable alignment mode.
- Reapply: Move to p=quarantine after real traffic is clean, then decide whether p=reject fits the domain's indirect-mail risk.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A record check will not prove every sender is correct, but it will catch obvious DNS mistakes before you chase header issues. Suped's DMARC checker parses the policy and reporting syntax before you test live messages.
Why SPF passes but DMARC still fails
A common mistake is assuming an SPF pass equals a DMARC pass. It does not. SPF can pass for a bounce domain owned by a sending platform while the visible From address uses your domain. If those domains do not match under DMARC, SPF cannot provide the DMARC pass.
SPF passes but DMARC fails
- Visible From: The recipient sees mail from billing@example.com.
- Envelope sender: SPF passes for mailer.net.
- Result: DMARC fails because the SPF domain does not match example.com and no aligned DKIM signature passes.
SPF passes and DMARC passes
- Visible From: The recipient sees mail from billing@example.com.
- Envelope sender: SPF passes for bounce.example.com.
- Result: DMARC passes under relaxed alignment because the domains share example.com as their organizational domain.
DKIM has the same domain requirement. If a message signs with d=vendor.com and the From domain is example.com, DKIM can pass cryptographically without providing a DMARC pass. The fix is usually to enable custom DKIM signing in the sending platform, often with a selector such as s1 or selector1 and a DNS CNAME or TXT record under your domain. If DKIM itself fails, check that signing is enabled and the selector resolves to the current public key, especially after key rotation.
|
|
|
|---|---|---|
SPF pass, DMARC fail | Wrong MAIL FROM domain | Use custom return path |
DKIM pass, DMARC fail | Wrong d= | Enable custom DKIM |
DMARC fail | No aligned path | Fix SPF or DKIM |
Only forwards fail | Forwarding changes the connecting IP; message edits can break DKIM | Preserve DKIM; inspect ARC |
Common Hotmail DMARC failure patterns
Forwarding changes the connecting IP, so SPF often fails at Hotmail even when direct delivery succeeds. Microsoft's SRS documentation explains why Sender Rewriting Scheme (SRS) can restore SPF for the forwarder's domain without restoring SPF alignment with the original From domain. Preserve the original DKIM signature by avoiding changes to signed headers or content, including added footers. Authenticated Received Chain (ARC) can give Microsoft earlier authentication results to assess, but it does not make DMARC pass or guarantee acceptance.
If the case is stranger, such as SPF and DKIM both passing but DMARC still failing, compare it with this DMARC failure. The usual answer is that the pass happened for a different domain than the one in the visible From address.
How relaxed and strict alignment change the result
The optional aspf and adkim tags control SPF and DKIM alignment. Both default to relaxed alignment, r, which accepts domains with the same organizational domain. Strict alignment, s, requires an exact domain match.
|
|
|
|---|---|---|
example.com | Pass | Pass |
bounce.example.com | Pass | Fail |
example.net | Fail | Fail |
Alignment examples for a visible From domain of example.com
If aspf=s is published, a custom return path such as bounce.example.com will not match a From domain of example.com, even when SPF passes. Use relaxed SPF alignment or make the MAIL FROM domain match exactly, unless the strict setting is intentional.
What to check in the headers
Keep the full non-delivery report, including any attached original headers. An SMTP rejection does not always return the receiving server's Authentication-Results header. Use Microsoft-added results from a delivered retest or request the sending provider's SMTP logs; an earlier gateway's pass does not prove Hotmail saw the same result. Compare the envelope sender, visible From domain, DKIM signing domain, and any ARC chain.
Illustrative headers: SPF passes for an unrelated domaintext
Authentication-Results: outlook.com; spf=pass smtp.mailfrom=bounces.mailer.net; dkim=fail header.d=example.com; dmarc=fail header.from=example.com From: Billing Team <billing@example.com> Return-Path: <bounces@bounces.mailer.net>
DMARC needs only one aligned authentication pass. SPF or DKIM can provide it. Microsoft's high-volume sender requirements separately require both to pass individually. Relying on SPF alone is also fragile because forwarding changes the connecting IP.
If the failing source is a third-party sender, the most durable fix is custom DKIM for your domain. If that platform also supports a custom bounce or return-path domain, configure it too. Then send test mail to a Hotmail or Outlook.com recipient, read the received headers, and confirm dmarc=pass for the exact From domain in use.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a broader check, Suped's domain health checker reviews the published authentication records. Combine those DNS checks with a test message's received headers to verify the actual sender and DKIM selector.
Why waiting for DNS changes does not fix DMARC
DNS visibility depends on the previous record's TTL and resolver caching, rather than a fixed three-day wait. Check the authoritative DNS answer and a cached lookup for the exact name in use. Verify one DMARC policy record at the applicable _dmarc name and one SPF policy record at the MAIL FROM domain. Publishing SPF at the visible From domain does not help when SPF is checking another domain. Waiting cannot repair a domain mismatch.
Safer DMARC policy stages
Use enforcement only after legitimate sources have clean DMARC results.
Monitor
p=none
Discover and classify every legitimate sender.
Test enforcement
p=quarantine
Use this after legitimate sources pass in reports.
Review indirect mail
Headers and reports
Check forwarding and mailing-list failures before rejection.
Reject if appropriate
p=reject
Use this only when the domain's mail flows support it.
A staged rollout matters because DMARC reports show which systems are sending as your domain. RFC 9989 marks the pct tag as historic after inconsistent receiver handling, so do not rely on percentage sampling to contain mistakes. Stage by policy and, where practical, by separate sending subdomains. With Suped's DMARC monitoring, you can review sources and policy actions before enforcing failures.
If the record has no rua address, add one before new enforcement. If the current record is hard to manage, Suped's DMARC record generator creates a policy with aggregate reporting included. Use a working report destination; an external destination also needs report-receiving authorization in DNS.
Quarantine-stage exampledns
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
For a general-purpose domain whose users post to mailing lists, p=quarantine can be the safer enforcement endpoint. Current DMARC guidance warns that p=reject can reject authorized indirect mail that DMARC cannot describe reliably.
How to diagnose the source
Start by identifying which system sent the rejected message. The sending IP and hostname in the headers usually point to the source faster than the From address. Map that source to its SPF authorization, DKIM selector, and bounce domain. A custom tracking domain does not determine whether SPF or DKIM matches the From domain.
- Find source: Use the sending IP, hostname, and return path to identify the platform that created the message.
- Check SPF: Confirm the platform is authorized in the SPF record for the MAIL FROM domain, then check that domain against the From domain under the applicable alignment mode.
- Check DKIM: Confirm the signature passes and uses your domain or an aligned subdomain in d=.
- Check subdomain: Check the From subdomain's own DMARC record first. If it inherits policy, inspect the ancestor record's sp tag, or p when sp is absent.
- Retest Hotmail: Send through the same source and inspect the headers on the received message.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped turns aggregate DMARC reports into source-level issues and repair steps. In this workflow, it helps separate verified senders from unknown sources, compare alignment pass rates, and track whether the failing Hotmail source has been repaired before policy enforcement changes again.
The practical target is that every legitimate sender passes DMARC before enforcement. Confirm SPF and DKIM both pass for Microsoft high-volume compliance. Once the failing source is repaired, retest at Hotmail; a DMARC pass does not guarantee inbox placement.
Common fixes by sending setup
The right fix depends on the source. A single domain often has multiple senders, and each one needs its own treatment. Do not move the parent domain back to reject just because Microsoft 365 user mail passes. Your marketing, website, invoicing, support, and product mail need the same review.
|
|
|
|---|---|---|
Microsoft 365 | DKIM not enabled | Enable DKIM for the custom From domain |
CRM | Vendor bounce domain | Custom DKIM; configure a matching return path where supported |
Marketing | Vendor DKIM | Custom DKIM |
Website | Local PHP mail | Use authenticated SMTP with authorized SPF and custom DKIM |
Forwarding | SPF breaks | Preserve DKIM; inspect ARC |
Fixes by source type
If only Hotmail rejects but another mailbox provider accepts, do not assume Hotmail is wrong. Receivers apply local policy differently, and some reject during the SMTP transaction. The sender still needs an aligned SPF or DKIM path for the From domain. For a deeper explanation of legitimate sources failing, compare legitimate email failures with your own headers.
Do not fix this by adding every IP you find to SPF. SPF's evaluation limit is 10 DNS-querying terms, including nested includes and redirects; exceeding the limit produces permerror. Multiple SPF policy records at the same domain also cause a permanent error. Fix the actual MAIL FROM domain, remove obsolete authorizations, and configure matching DKIM signing for third-party senders.
Views from the trenches
Best practices
Use p=none temporarily for broken legitimate mail while repairing the source and reviewing reports.
Read the full NDR headers before editing DNS, because the short bounce hides the source.
Use aligned custom DKIM on third-party senders so forwarding does not depend on SPF.
Add rua reporting before enforcement so legitimate failures become visible in reports.
Common pitfalls
Publishing p=reject before checking legitimate senders can block mail that still fails DMARC.
Treating an SPF pass as DMARC pass ignores the required match with the From domain.
Testing only user mail misses failures in website, CRM, product, billing, and support messages.
Removing aggregate reporting leaves teams blind when Hotmail starts rejecting mail.
Expert tips
Use sending subdomains so one third-party source does not control the parent policy.
Compare Return-Path and DKIM d= with the visible From domain before changing policy again.
Prefer matching DKIM for legitimate messages that will pass through an external forwarder.
Review mailing-list traffic before choosing p=reject for a domain used for general email.
Marketer view
Marketer from Email Geeks says the full bounce and original headers usually show which domain did not match DMARC.
2024-02-08 - Email Geeks
Marketer view
Marketer from Email Geeks says moving straight to p=reject without report review creates avoidable delivery failures.
2024-02-08 - Email Geeks
Frequently asked questions
No. A 5.7.509 rejection means the message failed DMARC and the applicable policy requested rejection. A 5.7.515 rejection concerns Microsoft's required authentication level. Even DMARC-passing messages remain subject to other filtering.
No. If a legitimate sender cannot be repaired promptly, temporarily change its applicable policy to p=none while keeping reporting active. This reduces spoofing protection and does not guarantee delivery. Removing DMARC also removes the reporting request that helps with diagnosis.
Yes. SPF can pass for the envelope sender domain while that domain does not match the visible From domain under the applicable alignment mode. DMARC fails if no aligned DKIM signature passes either.
Wait until aggregate reports show that legitimate sending sources pass DMARC consistently, then use quarantine and review indirect-mail failures. For a general-purpose domain used with mailing lists, staying at quarantine can avoid rejecting authorized mail.
Start with the receiving Microsoft system's Authentication-Results, then compare smtp.mailfrom, header.d, and header.from. If the NDR lacks receiver results, use a delivered retest or ask the sending provider for SMTP logs.
Do not depend on it. RFC 9989 marks the pct tag as historic because receivers applied percentage values inconsistently. Stage enforcement with p=none, then p=quarantine, and separate sending subdomains where practical.
