Stop your ERP from getting your company’s domain blacklisted. Learn the right way to handle bulk email sending, from quick fixes to robust, scalable cloud architectures.

So, Your ERP is Sending Bulk Emails. Let’s Talk Before You Get Blacklisted.

I still remember the call. It was 4:45 PM on a Friday. The CFO was on the line, which is never a good sign. “Darian,” he said, his voice tight, “None of our emails are going through. Not to clients, not even internally. What is going on?” A quick check confirmed it: our primary domain was on three major spam blacklists. The culprit? Our brand new, multi-million dollar ERP system, which some well-meaning soul in accounting had configured to send 20,000 end-of-month invoices directly from the server’s IP address. We spent the entire weekend getting our domain delisted. Don’t be that team. I’m going to save you that weekend.

First, Let’s Understand the “Why”

You might be thinking, “It’s just SMTP. Port 25 is open. What’s the big deal?” The problem isn’t connectivity; it’s reputation. Internet mail servers are incredibly skeptical. When a random server IP like 10.20.30.40 (let’s call it erp-app-prod-01) suddenly starts blasting out thousands of emails, mail gateways at Google, Microsoft, and elsewhere see a massive red flag. They don’t know you. They have no history with your IP. This looks exactly like a compromised server being used as a spambot.

Your server’s IP address lacks the necessary authentication and reputation markers like SPF, DKIM, and DMARC records that are properly configured and “warmed up.” Sending directly from the application server is the digital equivalent of a stranger in a trench coat handing out flyers on a street corner. You’re going to get shut down, fast.

The Solutions: From Duct Tape to Dedicated Architecture

I’ve seen this movie a dozen times, and it always ends one of three ways. Let’s walk through the options, starting with the quick and dirty fix and moving to the “do it right once” solution.

1. The Quick Fix: The Local SMTP Relay

This is the “It’s 5 PM and we need to get these invoices out NOW” solution. It’s a band-aid, but it’s an effective one. Instead of letting the ERP talk to the world, you force it to talk to a local service on the server that’s smarter about email.

The How: You install a local mail transfer agent (MTA) like Postfix on the ERP server itself. Then, you configure that local Postfix to act as a “smart host” or relay. All it does is receive email from the ERP (which thinks it’s sending locally) and then forwards it through a legitimate, authenticated external SMTP service, like your company’s Office 365 or Google Workspace account.

You point your ERP’s SMTP settings to localhost on port 25. Postfix listens, grabs the mail, and then uses proper TLS authentication on port 587 to send it via smtp.office365.com using a dedicated service account.

Here’s a conceptual Postfix main.cf snippet:

# /etc/postfix/main.cf

# ... other configs ...

# This is the magic part. All mail goes here.
relayhost = [smtp.office365.com]:587

# Enable SMTP authentication
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes

Warning: This is still a bottleneck and puts a lot of faith in that one service account. Your provider (Google/Microsoft) has rate limits. If you send too much, they’ll throttle or block you, and you’re back to square one. Use this to buy yourself time to implement a real solution.

2. The Permanent Fix: Use a Transactional Email Service

This is the professional standard. You accept that your company is not in the business of running email infrastructure and you offload the problem to someone who is. Services like AWS Simple Email Service (SES), SendGrid, or Mailgun are built for this exact purpose.

The How: You sign up for one of these services. They guide you through properly configuring your domain’s DNS records (SPF, DKIM) to authorize their servers to send email on your behalf. This instantly gives you a massive reputation boost. Your ERP then sends email either through their high-availability SMTP endpoints (just like the relay, but better) or, ideally, via their REST API.

Using the API is superior because it’s a simple, authenticated HTTP request. It’s easier to secure, gives you better feedback (you get a synchronous success/fail response), and often provides detailed tracking and analytics.

Instead of the ERP’s clunky SMTP module, your developers might call an endpoint like this:

POST /v3/mail/send HTTP/1.1
Host: api.sendgrid.com
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "personalizations": [{"to": [{"email": "customer@example.com"}]}],
  "from": {"email": "invoices@yourcompany.com"},
  "subject": "Your Invoice is Ready",
  "content": [{"type": "text/html", "value": "<p>Hello, world!</p>"}]
}

Pro Tip: My personal preference is AWS SES. It’s incredibly cheap, integrates natively with the rest of the AWS ecosystem, and its performance is rock-solid. The initial setup can be a bit more “AWS-like” (read: more complex), but it’s worth it for a long-term solution.

3. The ‘Nuclear’ Option: The Decoupled Email Microservice

Sometimes, the ERP is a black box. You can’t modify its code to call an API, and its SMTP client is ancient and unreliable. For mission-critical email that absolutely must get delivered, you decouple the entire process.

The How: This is a true architectural solution.

1. The ERP is configured to drop “email jobs” into a message queue like RabbitMQ or AWS SQS. The “job” is just a simple JSON message containing the recipient, subject, and body. This is a very fast, fire-and-forget operation for the ERP.
2. You build a small, dedicated microservice (we call ours `email-sender-svc`). Its only job is to listen to the queue.
3. When a message appears, the service picks it up, makes the API call to your transactional email provider (like SES), and handles the response.

Why is this the ‘nuclear’ option? Because it gives you ultimate reliability and scalability. If SendGrid has a momentary outage, the service can implement retry logic. If you suddenly need to send 100,000 emails, you can scale out the number of `email-sender-svc` consumers. The ERP doesn’t even notice; it just keeps dropping messages in the queue.

Comparison at a Glance

Look, the temptation to just point your ERP at the internet is real. It’s the easy path. But trust me, the cost of getting your domain blacklisted—in lost revenue, customer trust, and frantic weekend work—is far higher than the cost of setting up a proper email sending solution. Save yourself the headache. Start with option 2.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions