SMTP 550 Rejected Email Ubuntu 24.04: 7 Security Fixes
Fix SMTP 550 rejection errors on Ubuntu 24.04 by hardening your mail server security. Covers SPF, DKIM, reverse DNS, and IP reputation checks.

On this page
- Understanding the SMTP 550 Threat Model
- Pre-Flight Audit Checklist for Ubuntu 24.04 Mail
- Hardening Reverse DNS and Hostname Alignment
- Configuring SPF and DKIM Authentication
- Postfix Security Hardening for Outbound Mail
- Testing and Verifying Secure Configuration
- IP Reputation and Blacklist Remediation
- Logging and Ongoing Maintenance
TL;DR — Key takeaways
- SMTP 550 rejections on Ubuntu 24.04 stem from missing reverse DNS, failed SPF/DKIM checks, IP blacklisting, or recipient policy blocks
- Hardening requires configuring SPF records, DKIM signing, valid PTR records, and TLS encryption before sending production mail
- Test with swaks and mail-tester.com after each configuration change to verify authentication passes without exposing production traffic
- Monitor /var/log/mail.log and check blacklist status weekly to catch reputation damage before it blocks critical business email
A 550 rejection means the receiving mail server looked at your message and said no. The error appears in your mail logs, often with a cryptic reason code. On Ubuntu 24.04 running Postfix, the most common triggers are missing reverse DNS, failed authentication checks, or a blacklisted sending IP.
This guide covers the security configuration needed to eliminate 550 rejections before they damage your domain reputation. We'll walk through the threat model, build an audit checklist, apply hardening steps, and verify the configuration meets modern email standards.
Understanding the SMTP 550 Threat Model
SMTP 550 is not a single error. It's a class of permanent delivery failures where the receiving server rejects your message at the protocol level. The three-digit code tells you the message was refused, but the text after the code explains why.
Receiving mail servers use 550 to enforce sender authentication, reputation thresholds, and content policy. A missing PTR record signals an unconfigured server, often associated with spam. Failed SPF or DKIM checks indicate forged sender addresses. A blacklisted IP means prior abuse from your network range.
In support tickets I handled, the usual culprit was a fresh Ubuntu server deployed without any DNS records. The operator assumed mail would work because Postfix installed cleanly. Major providers rejected every outbound message within hours.
The threat model breaks into four categories: DNS hygiene failures, authentication bypass attempts, IP reputation damage, and recipient policy violations. Each requires a different fix.
Pre-Flight Audit Checklist for Ubuntu 24.04 Mail
Before changing configuration files, audit your current state. Log into your server and run 'hostname -f' to confirm your fully qualified domain name. Then check 'dig -x your_public_ip' to see if a PTR record exists. If the PTR query returns NXDOMAIN or points to a generic hosting hostname, you'll hit 550 rejections immediately.
Check /etc/postfix/main.cf for the myhostname and mydomain directives. These must match your DNS A record and the domain you're sending from. Run 'postconf myhostname mydomain' to verify.
Query your SPF record with 'dig txt yourdomain.com' and look for a line starting with v=spf1. If nothing appears, your domain has no SPF policy. Same for DKIM—query 'dig txt default._domainkey.yourdomain.com'. No result means no DKIM key published.
Test your current IP reputation by visiting MXToolbox Blacklist Check and entering your server's public IP. If you see listings on Spamhaus, Barracuda, or Spamcop, expect 550 rejections until you delist.
Hardening Reverse DNS and Hostname Alignment
Reverse DNS is the PTR record that maps your IP back to a hostname. When a receiving server connects to your mail server, it performs a forward-confirmed reverse DNS check: it looks up the PTR for your IP, then verifies that hostname resolves back to the same IP.
Most cloud providers and VPS hosts let you set PTR records through a control panel or API. Some require opening a support ticket. The PTR value should match your mail server's canonical hostname—typically mail.yourdomain.com.
After updating the PTR record, verify alignment with 'host your_ip_address', then 'host mail.yourdomain.com'. Both commands should return matching results. If the PTR points to mail.yourdomain.com but that hostname resolves to a different IP, you'll still see 550 rejections from strict MTAs.
In /etc/postfix/main.cf, set 'myhostname = mail.yourdomain.com' and 'mydomain = yourdomain.com'. Reload Postfix with 'systemctl reload postfix'. This ensures your HELO/EHLO greeting matches your PTR record.
Configuring SPF and DKIM Authentication
SPF is a DNS TXT record that lists which IP addresses are authorized to send mail for your domain. Create a record at your domain registrar or DNS provider with this content: 'v=spf1 mx ~all'. That policy says 'accept mail from the IPs listed in my MX records, soft-fail everything else.'
For tighter security, replace ~all with -all to hard-fail unauthorized senders. But use -all only after you've verified all legitimate sending sources. A misconfigured -all policy will cause your own mail to be rejected.
DKIM adds a cryptographic signature to outbound messages. Install the OpenDKIM package on Ubuntu 24.04 with 'apt install opendkim opendkim-tools'. Generate a key pair by running 'opendkim-genkey -s default -d yourdomain.com' in /etc/opendkim. This creates default.private and default.txt.
Publish the public key from default.txt as a TXT record at 'default._domainkey.yourdomain.com'. The record content looks like 'v=DKIM1; k=rsa; p=MIGfMA0GCS...' followed by a long base64 string. Keep the private key secure on your server and configure Postfix to sign outbound mail using OpenDKIM as a milter.
Postfix Security Hardening for Outbound Mail
Back up your existing configuration with 'cp /etc/postfix/main.cf /etc/postfix/main.cf.backup'. Open main.cf and set these directives to enforce authenticated relay and reject open relay attempts.
Set 'smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination'. This blocks relaying unless the client authenticates via SASL or connects from a trusted network.
Enable mandatory TLS for submission with 'smtpd_tls_security_level = encrypt' in the submission section of master.cf. This forces clients connecting on port 587 to use STARTTLS before authentication.
Configure SASL authentication by setting 'smtpd_sasl_auth_enable = yes' and 'smtpd_sasl_type = dovecot' if you're using Dovecot for IMAP. Point smtpd_sasl_path to Dovecot's auth socket, usually 'private/auth'.
Disable plaintext authentication on port 25 to prevent credential leaks. Add 'smtpd_tls_auth_only = yes' so clients must upgrade to TLS before AUTH commands are accepted.
Testing and Verifying Secure Configuration
Install swaks with 'apt install swaks' to test outbound mail from the command line. Run 'swaks --to [email protected] --from [email protected] --server localhost --port 587 --tls --auth LOGIN --auth-user your_user --auth-password your_password'. Watch the output for successful TLS negotiation and 250 OK responses.
If swaks fails with a 550 rejection, check /var/log/mail.log for the exact error. Look for lines containing 'rejected' or 'does not resolve'. A PTR mismatch shows up as 'hostname verification failed'. SPF failures appear as 'SPF check failed'.
Send a test message to [email protected] to get an automated SPF, DKIM, and DMARC report. The reply email will show whether your signatures pass and if alignment is correct.
Use mail-tester.com by sending a message to the unique address they provide. Their report scores your configuration and flags missing authentication, blacklist hits, and content issues. Aim for a score above 8/10 before routing production traffic through the server.
IP Reputation and Blacklist Remediation
Even with perfect DNS and authentication, a blacklisted IP will trigger 550 rejections. Check your server's public IP on MXToolbox, Spamhaus, and SORBS at least once before sending production mail.
If you find a listing, follow the blacklist's delisting procedure. Spamhaus requires you to investigate the cause, fix the issue, and submit a removal request through their portal. Some lists auto-expire after a set period if no further abuse is detected.
New VPS IP addresses sometimes carry prior reputation damage from previous tenants. If you see listings on multiple blacklists immediately after provisioning, contact your hosting provider and request a different IP.
Monitor your IP reputation weekly by setting up a cron job that queries MXToolbox's API or uses a monitoring service. Catching a new listing within hours lets you delist before it impacts critical business email.
Logging and Ongoing Maintenance
Postfix logs all SMTP transactions to /var/log/mail.log. Grep for '550' to find rejection patterns. Look for recurring recipient domains that block your mail—it might indicate a specific policy violation rather than a global configuration issue.
Set up log rotation to prevent /var/log/mail.log from filling your disk. Ubuntu 24.04 includes logrotate by default, but verify /etc/logrotate.d/rsyslog includes mail.log and rotates weekly.
Enable verbose logging temporarily with 'postconf -e smtpd_tls_loglevel=1' when diagnosing TLS handshake failures. Revert to loglevel 0 after troubleshooting to avoid log bloat.
Review authentication failures monthly. Grep for 'authentication failed' in mail.log to spot brute-force attempts. If you see repeated failures from unknown IPs, consider adding fail2ban rules to block SASL brute-force attacks on port 587.
Quick troubleshooting checklist
- Back up /etc/postfix/main.cf and /etc/postfix/master.cf before editing
- Verify PTR record matches your sending domain's A record
- Add SPF TXT record with v=spf1 mx ~all minimum policy
- Generate DKIM keys with opendkim-genkey and publish public key in DNS
- Configure Postfix to use submission port 587 with mandatory TLS
- Set smtpd_relay_restrictions to reject unauthenticated relay attempts
- Enable SASL authentication for outbound mail with valid credentials
- Test outbound mail with swaks targeting external addresses
- Check IP reputation on MXToolbox and Spamhaus before production use
- Set up log rotation for /var/log/mail.log to prevent disk exhaustion
FAQ
What causes SMTP 550 rejected email errors on Ubuntu 24.04?
SMTP 550 rejections happen when the receiving server refuses your message due to missing reverse DNS, failed SPF or DKIM authentication, IP blacklisting, or recipient policy violations. The receiving MTA returns a 550 code when it determines the message violates its acceptance policy. Check your mail.log for the exact rejection reason, which usually appears after the 550 status code.
How do I fix reverse DNS for my Ubuntu 24.04 mail server?
Contact your hosting provider or VPS control panel to set a PTR record for your server's public IP that matches your mail server's hostname. The PTR record must resolve back to an A record pointing to the same IP. Verify with 'dig -x your_ip_address' and confirm the returned hostname matches 'hostname -f' output on your server. Most providers require a support ticket to update PTR records.
Can I send email without SPF and DKIM on Ubuntu 24.04?
You can send mail without SPF and DKIM, but major providers like Gmail, Outlook, and Yahoo will likely reject or spam-folder your messages. Modern email infrastructure treats missing authentication as a red flag. SPF and DKIM are baseline requirements for deliverability. Without them, your IP reputation degrades quickly and 550 rejections become frequent.
Related articles
- Hosting OperationsSelf-Hosted App Deployment Fails? Check DNS, SSL, Reverse Proxy, and Logs FirstTroubleshoot failed self-hosted app deployments by checking DNS, SSL, reverse proxy routing, container status, logs, and ports.
- Hosting OperationsSelf-Hosted PaaS on a VPS: What to Check Before Installing Coolify, Dokploy, or CapRoverA hosting support checklist for preparing a VPS before installing self-hosted PaaS tools like Coolify, Dokploy, or CapRover.
- Hosting OperationsLinux Server Security Lessons from the Arch Linux Malware Package IncidentPractical Linux server security checklist for VPS admins after package malware concerns, with safe checks, rollback steps, and support guidance.
- Hosting OperationsAWS Lightsail Hong Kong VPS Latency: Practical Hosting Guide for IndonesiaLearn how to test AWS Lightsail Hong Kong VPS latency, compare regions, migrate safely, and troubleshoot hosting performance.
- Hosting OperationsCloudflare Tomorrow Watchlist: A Practical Hosting Operations GuidePractical Cloudflare troubleshooting checklist for DNS, SSL, caching, WAF, origin health, safe testing, and rollback planning.
- Hosting OperationsNetwork Safety Checklist for AI Agent Skills in Hosting OperationsAudit AI agent skills safely with network checks, secret protection, sandbox testing, rollback steps, and hosting support troubleshooting guidance.