I’m planning to switch multiple clients from Mandrill to another email service provider. After testing with one small account, I encountered a delivery failure to what appears to be a legitimate email address.
The error message I received was: Server response: 554 554 BigPond Inbound Connection refused. IB112
This seems like the recipient’s email provider is blocking messages from the service’s IP addresses. I’m concerned about this because I rarely had such issues with my previous provider.
Has anyone experienced similar delivery problems? I’m hesitant to move over 20 client accounts if there are widespread deliverability concerns, especially since these are critical transactional emails for online stores that need reliable delivery.
I’ve fought email delivery issues for years at different companies. BigPond’s just the start - wait till you deal with Outlook’s spam filters or Gmail’s bulk sender rules.
You’re thinking about this wrong though. Don’t pick one provider and pray it works for everyone. Build a system that adapts instead.
I use Latenode to create email workflows that test delivery rates automatically and switch providers based on performance. BigPond blocks Mailgun? Routes through Amazon SES. SES gets throttled? Tries SendGrid.
The system learns which providers work best for each client’s audience. E-commerce client mostly hitting Gmail? Uses the provider with the best Gmail reputation. Another client targeting corporate domains? Different routing.
You can add automatic retry logic with exponential backoff and bounce categorization. Critical transactional emails get priority routing through your most reliable channels.
No more migrating 20 accounts and hoping for the best. Build it once, never stress about provider-specific delivery problems again.
Hit the same IB112 error when I ditched Mandrill eight months ago. BigPond blocks shared IP ranges hard, but Mailgun’s IP management has really gone downhill. Their shared pools are trashed by people blasting marketing emails with garbage lists. Before you move those 20 accounts, test Amazon SES alongside Mailgun. SES has way cleaner IP reputation here in Australia and delivers better to local ISPs. Setup’s more technical but totally worth it for transactional stuff. Here’s what nobody tells you - watch your bounce rates during the trial. Mailgun’s bounce classification sucks compared to Mandrill. Hard bounces get marked as soft bounces, which screws up your retry logic for order confirmations. I ended up splitting clients between SES for Australian traffic and Mailgun for international sends. Works way better than jamming everything through one provider that can’t handle regional filtering.
I’ve hit this exact problem managing email for multiple clients. That BigPond error screams IP reputation issues - you’re stuck sharing infrastructure with users who have terrible sending habits.
Traditional email services put you at their mercy. Their IP pools and reputation management can tank your business emails without warning, even with premium providers.
I solved this by setting up automated email routing through Latenode. Instead of one provider, I built workflows that route emails through multiple services based on recipient domains and real-time delivery rates.
Mailgun throws a 554 error? The system instantly reroutes through SendGrid or Amazon SES. Takes seconds and customers never notice.
I also monitor delivery rates per client and auto-switch providers when performance drops. No more putting all 20 accounts at risk with one failure point.
The automation handles retries, error sorting, and separate IP warming schedules for dedicated IPs later. Way more reliable than hoping shared IPs stay clean.
bigpond’s crazy aggressive with blocking - they’re notorious for it. I ran into the same thing last year switching from postmark. wasn’t just mailgun either, happened with sendgrid too. they’ll block entire subnets sometimes.
before you ditch mailgun completely, try switching regions. their eu servers often have cleaner ip reputation than us ones. also check if your domain has any reputation issues that might be triggering the blocks.
I’ve used Mailgun for three years across multiple client setups - BigPond’s always a pain. It’s not really Mailgun’s fault though. BigPond runs aggressive filters that flag most shared IPs as sketchy right off the bat. Here’s what worked for me: contact BigPond’s postmaster team directly. Send them your delivery logs and show you’re legit. Takes around two weeks, but they’ll whitelist your sending patterns. Also, check how many of your clients’ customers actually use BigPond. If it’s just a small chunk of your recipients, might be easier to live with the occasional bounce instead of switching everything. I’d run a full deliverability test first - try Mail-tester or GlockApps before you commit to migrating. Sometimes better the devil you know.
BigPond’s filtering is brutal - they blacklist shared IP ranges from major email providers all the time. Hit the same problem six months ago moving a client from SendGrid to Mailgun. It’s usually because Mailgun’s shared IPs get trashed by other users sending spam or running terrible campaigns. I got around it by requesting a dedicated IP pool through Mailgun support, but you need higher volume and have to warm the IP properly. Before switching all 20 accounts, test delivery with the big Australian ISPs - BigPond, Optus, TPG. Use your typical email content for testing. Double-check your SPF and DKIM records too. BigPond gets really picky about authentication failures. Keep your current provider as backup during the switch. I’ve watched businesses lose order confirmations when deliverability tanks unexpectedly during migrations.