WordPress portal emails can fail even when the site, form, and email plugin are working correctly. In this case, both automated notifications and a SendPress broadcast failed for recipients on Microsoft-hosted domains, while messages to other providers were delivered. Mailgun logs revealed the exact cause: Outlook was rejecting mail from a banned sending IP. Mailgun rotated the affected IP address, restoring delivery without requiring changes to WordPress.
Issue background
A WordPress portal experienced two email-delivery symptoms at the same time:
- Automated request notifications were not reaching the person who submitted the request or the internal support recipients.
- A broadcast sent through SendPress reached some recipients but not others.
Messages to personal email accounts were delivered, while recipients using certain business domains did not receive them. Repeated test messages to the affected addresses also failed.
Because both transactional notifications and SendPress broadcasts were affected, the problem initially appeared to be a sitewide WordPress email failure.
Diagnosis
The first diagnostic step was to determine whether WordPress was generating and handing off the messages successfully. Mailgun delivery logs confirmed that the affected emails had reached the email service.
The failed messages shared a specific response from Microsoft’s receiving infrastructure:
5.7.606 Access denied, banned sending IP [204.220.184.28]This response established that the WordPress site was not the source of the failure. The site had generated the messages, and Mailgun had attempted to deliver them. Outlook rejected the messages because the shared Mailgun sending IP had been blocked.
The pattern also matched the user reports:
- Messages sent to providers not using Microsoft infrastructure could still arrive.
- Recipients on Microsoft-hosted business domains consistently failed.
- Multiple WordPress email functions were affected because they used the same outbound Mailgun service.
Resolution steps
- Confirm that WordPress generated the message. Review the relevant form, portal, ecommerce, or newsletter logs. Determine whether the email event was triggered successfully.
- Check the transactional email provider. Open Mailgun logs and search by recipient, subject, sending domain, or approximate timestamp.
- Read the complete delivery response. Do not rely only on a generic “failed” status. The SMTP response usually identifies whether the problem is an invalid mailbox, authentication issue, spam rejection, rate limit, or blocked IP.
- Compare affected recipient domains. Identify whether failures are concentrated at Microsoft 365, Outlook, Gmail, or another provider. Provider-specific failures often indicate reputation or policy blocking rather than a WordPress problem.
- Verify the error code. In this case,
5.7.606 Access denied, banned sending IPmeant Microsoft had blocked the Mailgun sending IP. - Escalate to the email provider. Contact Mailgun when a shared or dedicated sending IP is blocked. The provider can investigate reputation, request delisting, or rotate the sending IP.
- Avoid unnecessary site changes. Do not replace SendPress, rewrite form notifications, or alter SMTP settings when logs show that the receiving provider rejected an otherwise valid delivery attempt.
- Retest after remediation. Send controlled tests to affected Microsoft-hosted addresses and to unrelated providers. Confirm the result in Mailgun logs as well as the recipient inbox.
- Monitor bounces and complaints. Continue reviewing delivery logs after the IP change to verify that the block does not recur and that authentication remains valid.
For reliable delivery, the sending domain should also have valid SPF, DKIM, and DMARC records. These records do not override a banned IP, but they improve authentication and make future reputation problems easier to diagnose.
Final outcome
Mailgun rotated the affected sending IP address. Because the issue existed at the email-delivery layer, no WordPress, SendPress, portal, or form configuration changes were required.
The site resumed using its existing email workflows, with monitoring recommended for messages sent to Microsoft-hosted recipients. The diagnosis prevented unnecessary plugin changes and focused the resolution on the service that was actually returning the error.
The key lesson is to follow the message through every stage of delivery. When WordPress creates an email but the recipient never receives it, provider logs and SMTP response codes can distinguish a site failure from an external reputation block.
For help troubleshooting WordPress email delivery, SendPress broadcasts, Mailgun errors, or Microsoft 365 rejections, contact Freshy.
