Contact us

Fix: Emails Bouncing to Yahoo with “554 Message Not Allowed” Policy Error

Microsoft Exchange logo

A professional services firm contacted us because multiple staff members were getting bounce-back errors when sending emails to clients with Yahoo email addresses. The non-delivery reports mentioned a policy violation but gave no clear explanation of what was wrong. SPF, DKIM, and DMARC authentication were all passing, yet Yahoo was still rejecting the messages. Here is what caused it and how to fix it.

Symptoms

When sending emails from Microsoft 365 (Outlook) to recipients with Yahoo or other external email addresses, the sender receives a non-delivery report (NDR) with one of the following errors:

550 5.0.350 Remote server returned an error -> 554 Message not allowed - [PH01] Email not accepted for policy reasons.

You may also see variations such as:

550 5.7.1 [TSS04] Messages from [IP] temporarily deferred due to unexpected volume or user complaints

421 4.7.0 [TSS] Messages from [IP] temporarily deferred - 4.16.55. Please refer to https://senders.yahooinc.com/error-codes

Common characteristics of this issue:

  • Multiple staff members are affected, not just one sender
  • The problem is specific to certain recipient domains (Yahoo, AOL, sometimes Gmail)
  • Emails to other recipients (Outlook.com, corporate domains) deliver successfully
  • The bounce-back mentions “policy reasons” without specifying the exact cause
  • SPF, DKIM, and DMARC may all show as “pass” in the email headers, yet the email is still rejected

Affected Software

  • Sending Platform: Microsoft 365 (Exchange Online)
  • Affected Recipients: Yahoo Mail, AOL, and other providers with strict email authentication requirements
  • Related Services: DNS (SPF, DKIM, DMARC records), any third-party email sending services (MailChimp, Postmark, etc.)

Cause

Yahoo, Google, and other major email providers have progressively tightened their email authentication requirements. Since early 2024, Yahoo requires all bulk senders to have properly configured SPF, DKIM, and DMARC records. Even for low-volume senders, weak DNS authentication settings can cause emails to be rejected.

The most common causes of this rejection are:

  • DMARC policy set to “none”: A DMARC policy of p=none tells receiving servers to take no action on unauthenticated emails. Yahoo and Gmail now view this as a signal that the domain may not be properly secured, and may reject or quarantine messages from domains with weak DMARC policies
  • SPF set to soft fail (~all): A soft fail SPF record (~all) suggests that emails from unlisted senders are “probably not legitimate” but does not instruct recipients to reject them. Strict providers prefer a hard fail (-all)
  • Missing or misconfigured DKIM signing: If DKIM is not enabled for your domain in Microsoft 365, emails may fail integrity checks at the recipient’s end
  • Third-party services sending as your domain: If you use services like MailChimp, Postmark, or a website contact form that sends as your domain, these must be included in your SPF record and have DKIM signing configured

Resolution

Step 1: Check Your Current DNS Records

Before making changes, check your current email authentication setup. Use a tool like MXToolbox or DMARCLY to look up your domain’s SPF, DKIM, and DMARC records.

DMARC DKIM and SPF alignment report showing passing authentication results for a domain

Step 2: Update Your DMARC Record

Your DMARC record is a TXT record in your domain’s DNS. If your current policy is p=none, update it to p=quarantine as a starting point.

Current (weak):

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Updated (recommended):

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

After monitoring for a few weeks and confirming no legitimate emails are being quarantined, you can tighten this further to p=reject:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

The rua tag specifies where DMARC aggregate reports are sent. Use a dedicated mailbox or a DMARC reporting service to monitor these reports.

Step 3: Update Your SPF Record to Hard Fail

If your SPF record ends with ~all (soft fail), change it to -all (hard fail):

Current (soft fail):

v=spf1 include:spf.protection.outlook.com ~all

Updated (hard fail):

v=spf1 include:spf.protection.outlook.com -all

Make sure all legitimate sending services are included in your SPF record before switching to hard fail. Common includes:

  • include:spf.protection.outlook.com (Microsoft 365)
  • include:servers.mcsv.net (Mailchimp)
  • include:spf.mtasv.net (Postmark)
  • include:_spf.google.com (Google Workspace)

Step 4: Enable DKIM Signing in Microsoft 365

If DKIM is not already enabled for your domain:

  1. Sign in to the Microsoft 365 Defender portal
  2. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM
  3. Select your domain
  4. Toggle Sign messages for this domain with DKIM signatures to Enabled
  5. If prompted, add the CNAME records shown to your DNS and then enable DKIM

Step 5: Verify and Monitor

  1. After updating DNS, wait 24-48 hours for propagation
  2. Send a test email to a Yahoo address and confirm delivery
  3. Use MXToolbox DMARC Lookup to verify your records are correct
  4. Monitor DMARC aggregate reports for any legitimate emails being blocked
  5. If using a DMARC reporting service like DMARCLY, check the alignment charts to ensure DMARC, DKIM, and SPF are all showing as aligned

Important Notes

  • Do not jump straight to p=reject. Start with p=quarantine and monitor for at least two weeks. If you have third-party services sending as your domain that are not properly authenticated, a reject policy will block those emails entirely
  • Identify all third-party senders before changing SPF. Ask your team whether any services send email as your domain (marketing platforms, CRM systems, website forms, scanners). Each one needs to be included in your SPF record or configured with DKIM signing
  • SPF has a 10 DNS lookup limit. If your SPF record includes too many services, it can exceed the limit and fail validation. Use MXToolbox SPF Lookup to check your lookup count
  • These changes improve your overall email security posture, not just Yahoo deliverability. Properly configured DMARC, SPF, and DKIM protect your domain from being spoofed in phishing attacks
  • If emails are still bouncing after making these changes, check Yahoo’s Sender Error Codes page for the specific error code in your NDR

If you need help fixing email deliverability issues or configuring your domain’s email authentication records, get in touch with our team.

Was this article helpful?
Yes No

About The Author

Elliot Munro building AI automation solutions at GCIT
Elliot Munro
Elliot Munro is GCIT's Chief Information Security Officer and leads GCIT's security and AI work. He holds Anthropic's Claude Certified Architect - Professional credential and is Microsoft Certified as a Cybersecurity Architect Expert, Microsoft 365 Administrator Expert, Identity and Access Administrator Associate and Security Operations Analyst Associate. Read Elliot's profile.
Ready to secure and simplify your IT? Talk to a GCIT expert today.
Sales 0755 999 999 Book a free consultation