Email “550 rejected”: what it actually means and how to get unblocked

What “550 rejected” really means (and what it doesn’t)

SMTP status codes are the email world’s version of “computer says no.” 550 is a permanent failure
at the SMTP layer: the receiving server won’t accept the message as sent. “Permanent” means the receiver is telling
you “don’t retry like a robot; fix something.”

But here’s the catch: 550 is a bucket. The number alone is nearly useless. The important part is the
enhanced status code (like 5.7.1) and, even more, the text after it.
Receivers overload 550 for everything from “no such user” to “your IP smells like spam” to “your HELO is nonsense.”

550 vs 450/451: why “permanent” matters operationally

If you see 450 or 451, that’s typically a temporary failure: greylisting, throttling,
transient policy checks, or the receiver having a bad day. Your MTA should retry.
With 550, retrying usually makes you look worse: you keep hammering a receiver that already said “no.”

That doesn’t mean “never retry a 550.” Some receivers incorrectly send 550 for temporary policy blocks.
But treat 550 like an incident: pause, inspect, and target your fix.

What 550 is not

• Not necessarily a problem with your mailbox provider. This is often your domain, your IP, your authentication, your content, or your sending behavior.
• Not proof you’re “blacklisted everywhere.” One receiver rejecting you can still ruin your day, but it’s rarely universal.
• Not always spam-related. It can be user unknown, misrouted mail, broken DNS, or a misconfigured relay.

One operational rule: don’t let the sales team set your incident severity based on vibes.
Severity comes from scope: which domains are rejecting, which mail streams are impacted (transactional vs marketing),
and whether you’re losing critical business mail.

Interesting facts and a little history (because email is old)

• SMTP predates the web. The core SMTP spec was published in 1982. Most of your “modern” email problems are bolt-ons.
• Enhanced status codes (like 5.7.1) were introduced later to make failures less ambiguous. Many systems still treat them as optional decoration.
• SPF started as a response to forged sender addresses in the early 2000s. It helps, but it’s not an identity system; it’s a “who is allowed to send for this domain” hint.
• DKIM became mainstream to protect message integrity and provide a stable signing domain even when forwarding happens.
• DMARC is policy and reporting glue that tells receivers what you want done when SPF/DKIM fail and gives you visibility via reports.
• Greylisting was a spam-fighting trick that relied on spammers not retrying. Legit MTAs retry; spam bots often didn’t. Some still use it.
• RBLs (real-time blackhole lists) grew because SMTP has no built-in reputation system. The internet outsourced “trust” to lists and feedback loops.
• IPv6 made reputation harder at first because address space is enormous; naive blocking can be either useless or devastating.
• “Postmaster” and “abuse” mailboxes became de facto standards because operators needed a human to yell at when a server misbehaved.

Email is the oldest still-critical distributed system most companies run. It’s also the one people assume “should just work,”
which is adorable, like assuming a printer should just work.

Joke #1: Email is the only system where a 40-year-old protocol still runs the global economy, and we’re shocked it has feelings about DNS.

Fast diagnosis playbook (first/second/third)

First: classify the rejection in 60 seconds

1. Grab the exact SMTP transcript or bounce text. “550 rejected” isn’t enough. You need the enhanced code and the policy text.
2. Identify the receiver family. Consumer (Gmail, Microsoft) vs corporate gateway (Proofpoint, Mimecast) vs custom Postfix/Exim. Their failure modes differ.
3. Check scope: Is it one recipient? one domain? many domains? only new recipients? only attachments?

Second: decide if this is identity, reputation, or routing

• Identity/authentication: SPF fail, DKIM fail, DMARC fail, alignment issues, missing rDNS/PTR, bad HELO/EHLO, TLS requirements.
• Reputation/policy: IP or domain reputation, RBL listing, complaint rate, rate limiting, content filtering, URL reputation.
• Routing/recipient: user unknown, relay denied, sender not allowed, recipient policy (external sender blocked), wrong MX, wrong port, broken DNS.

Third: pick the shortest path to unblocking

1. If it’s routing/recipient: fix addressing, MX, relay, or the recipient policy; you can usually resolve quickly.
2. If it’s authentication: fix SPF/DKIM/rDNS/HELO and retry with a controlled test.
3. If it’s reputation: stop the bleeding (rate-limit, block compromised accounts, pause marketing), then work delisting and warming.

The key: don’t start by changing everything. You’ll lose the ability to attribute the fix and you’ll waste time arguing with yourself later.
Make one targeted change, test, then proceed.

Decode the bounce: the words that matter

Common enhanced status codes you’ll see with 550

• 550 5.1.1: recipient address rejected (often “user unknown”). Could be a typo or a deprovisioned mailbox.
• 550 5.1.10 (varies by vendor): recipient not found or invalid recipient.
• 550 5.2.0 / 5.2.2: mailbox full or storage/policy limit (sometimes misused).
• 550 5.7.1: delivery not authorized / message refused by policy. This is the big one: authentication, reputation, content, or admin policy.
• 550 5.7.26: authentication required or DMARC-related rejection (common with major providers).
• 550 5.7.0: generic security/policy status.

Policy text patterns and what they usually imply

• “SPF fail” / “SPF softfail”: your sending IP isn’t authorized in SPF, or your SPF is malformed/too long.
• “DKIM signature invalid”: signature broke (often header rewriting, wrong selector, or key mismatch).
• “DMARC policy reject”: SPF/DKIM failed alignment per DMARC policy; receiver is honoring your published stance (or theirs).
• “blocked using …”: often RBL or internal reputation. The named list matters.
• “reverse DNS required”: missing or mismatched PTR; some gateways are strict.
• “HELO/EHLO rejected”: your MTA introduces itself with a bogus hostname or an IP literal the receiver dislikes.
• “Relay access denied”: you’re trying to use a server as an open relay, or your client isn’t authenticated/allowed.
• “Message content rejected”: URL reputation, attachment type, or content heuristics (including “too many links” or “looks like phishing”).

Treat bounce text like log lines: noisy but rarely random. Your best move is to capture several bounces over a short window
and look for consistent wording. If every rejection has the same clause, that clause is your root cause candidate.

Practical tasks: commands, outputs, decisions (12+)

These are the checks I run in the first hour. Each task includes: a command, what the output means, and what decision you make.
Run them from a host with network access to DNS and the internet (or at least to your resolver).

Task 1: Extract the exact SMTP rejection from your logs (Postfix)

cr0x@server:~$ sudo grep -R "status=bounced" /var/log/mail.log | tail -n 3
Jan  3 01:10:12 mx1 postfix/smtp[22103]: 9C2D12A03F: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=5.7.1, status=bounced (host mx.example.net[203.0.113.10] said: 550 5.7.1 Message rejected due to policy restrictions (in reply to end of DATA command))

Meaning: You’ve got enhanced code 5.7.1 and a policy rejection after DATA. That’s usually authentication, reputation, or content.

Decision: Don’t chase “user unknown.” Go straight to auth/reputation/content checks.

Task 2: Verify the sending IP you actually used

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5      2140 Fri Jan  3 01:11:44  alerts@corp.example
                                         user@example.net

-- 1 Kbytes in 1 Request.

Meaning: A queue exists; you need to see which transport and source IP is used for outbound.

Decision: Confirm outbound NAT or multi-homed behavior; the “wrong” egress IP can break SPF and reputation assumptions.

Task 3: Check your outbound public IP from the mail host

cr0x@server:~$ curl -s ifconfig.me
198.51.100.25

Meaning: This is the IP many receivers will score for reputation and SPF “ip4” mechanisms.

Decision: Use this IP when validating SPF, rDNS, and RBL status.

Task 4: Look up the recipient domain MX records (routing sanity)

cr0x@server:~$ dig +short MX example.net
10 mx1.example.net.
20 mx2.example.net.

Meaning: You know where you’re delivering. If this is empty or weird, you might be sending to the wrong place.

Decision: If MX is missing or points to unexpected hosts, fix DNS/recipient expectations before touching auth.

Task 5: Open an SMTP session to see the rejection stage

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP
EHLO mx.corp.example
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
MAIL FROM:<alerts@corp.example>
250 2.1.0 Ok
RCPT TO:<user@example.net>
550 5.7.1 Recipient address rejected: Access denied

Meaning: Rejected at RCPT TO: often recipient policy, blocklists, sender reputation, or “external sender not allowed.”

Decision: If RCPT fails, content is less likely. Focus on policy, reputation, and recipient-side allow/block rules.

Task 6: Check SPF for the envelope-from domain

cr0x@server:~$ dig +short TXT corp.example | grep -i spf
"v=spf1 ip4:198.51.100.25 include:spf.mailvendor.example -all"

Meaning: SPF exists and explicitly allows your outbound IP.

Decision: If your actual sending IP doesn’t match, update SPF or fix egress routing. If SPF is missing, add it now.

Task 7: Validate SPF evaluation with a local tool (quick-and-dirty)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 198.51.100.25 -sender alerts@corp.example -helo mx.corp.example
pass

Meaning: SPF passes for this sender/IP/HELO combination.

Decision: If this returns fail/softfail/permerror, treat SPF as a primary suspect and fix before anything else.

Task 8: Check DKIM DNS selector record exists

cr0x@server:~$ dig +short TXT selector1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt0..."

Meaning: DKIM public key is published for selector1.

Decision: If missing, you’ll get DKIM=none or fail; publish the record or fix selector mismatch in your MTA/ESP.

Task 9: Confirm your outbound message is actually DKIM-signed

cr0x@server:~$ sudo apt-get -y install swaks >/dev/null
cr0x@server:~$ swaks --to user@example.net --from alerts@corp.example --server mx1.example.net --data "Subject: test

hello" --quit-after DATA
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<= 220 mx1.example.net ESMTP
=> EHLO mx.corp.example
<= 250-mx1.example.net
<= 250-STARTTLS
=> QUIT

Meaning: This test didn’t include your production signing path; swaks is useful for probing, but DKIM signing depends on your sending pipeline.

Decision: Send a real message through your MTA and inspect headers (next task). Don’t “prove” DKIM with a test that bypasses it.

Task 10: Inspect a sent message’s Authentication-Results and DKIM headers

cr0x@server:~$ sudo grep -R "DKIM-Signature" /var/log/mail.log | tail -n 2
Jan  3 01:14:02 mx1 opendkim[1402]: 9C2D12A03F: DKIM-Signature field added (s=selector1, d=corp.example)

Meaning: Your MTA is adding DKIM signatures for d=corp.example.

Decision: If you see “no signature data” or nothing at all, fix opendkim/opendmarc integration or your signing table.

Task 11: Check DMARC policy and alignment expectations

cr0x@server:~$ dig +short TXT _dmarc.corp.example
"v=DMARC1; p=reject; rua=mailto:dmarc@corp.example; adkim=s; aspf=s"

Meaning: DMARC is strict: both DKIM and SPF alignment are “strict” (s). That can break legitimate flows like subdomains, forwarders, and third-party senders.

Decision: If you’re blocked and you recently set p=reject with strict alignment, confirm all mail streams are aligned; relax alignment only if you understand the trade-off.

Task 12: Verify reverse DNS (PTR) for your outbound IP

cr0x@server:~$ dig +short -x 198.51.100.25
mx.corp.example.

Meaning: PTR exists and points to mx.corp.example.

Decision: If no PTR, or PTR points to something generic, fix it with your ISP/cloud provider. Many gateways hard-fail without rDNS.

Task 13: Confirm forward DNS matches your PTR (not required everywhere, but helps)

cr0x@server:~$ dig +short A mx.corp.example
198.51.100.25

Meaning: Forward-confirmed reverse DNS (FCrDNS) is consistent.

Decision: If A record doesn’t match the PTR IP, expect suspicion. Fix naming and IP mapping where possible.

Task 14: Check your HELO/EHLO name matches something real

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mx.corp.example
smtp_helo_name = mx.corp.example

Meaning: You identify as mx.corp.example.

Decision: If HELO is “localhost” or an internal hostname, fix it. Some receivers reject outright; others score you down.

Task 15: Check if your IP is on common RBLs (DNS-based check)

cr0x@server:~$ for rbl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
ip=198.51.100.25; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); \
ans=$(dig +short ${rev}.${rbl} A); \
echo "$rbl: ${ans:-not-listed}"; \
done
zen.spamhaus.org: not-listed
bl.spamcop.net: not-listed
b.barracudacentral.org: 127.0.0.2

Meaning: Listed on one RBL (example: Barracuda-style response).

Decision: Stop bulk sends and investigate compromise/content immediately; then pursue delisting per that list’s process. Being listed is a symptom, not the disease.

Task 16: Detect outbound spikes (compromised account or script gone feral)

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 20
Postfix log summaries for: Fri Jan  3 2026

Grand Totals
------------
messages processed:                    18432
messages delivered:                    12010
messages deferred:                      5200
messages bounced:                       1222
rejected connections:                    410

Meaning: High volume + high deferrals/bounces + rejections: classic outbreak profile.

Decision: Treat as security + deliverability incident. Lock down credentials, rate-limit, and separate transactional from bulk.

Task 17: Check Postfix SASL auth usage (hunting compromised credentials)

cr0x@server:~$ sudo grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head
  8420 sasl_username=support@corp.example
  3011 sasl_username=noreply@corp.example
   188 sasl_username=dev@corp.example

Meaning: One account dominates outbound auth.

Decision: If the top sender is unexpected, rotate the password/token, check source IPs, and add MFA/SMTP submission restrictions.

Task 18: Confirm submission vs relay separation (port 587 with auth)

cr0x@server:~$ sudo ss -lntp | grep -E ":25|:587"
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1010,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1010,fd=15))

Meaning: Both SMTP (25) and submission (587) are listening.

Decision: Ensure port 25 isn’t allowing unauthenticated relay, and 587 enforces auth/TLS. Misconfigurations here become “550 rejected” elsewhere after you get listed.

Operational note: every command above is designed to answer a decision. If a check doesn’t change your next move, it’s trivia.
Trivia is how you burn daylight while mail burns down.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company migrated their outbound mail from an old VM to a shiny new cloud instance. Same hostname, same Postfix config,
same DKIM keys. They did the change during a quiet window and sent a celebratory “it worked” email to themselves. It arrived.
They closed the change.

Monday morning, invoice emails to a large customer started bouncing with 550 5.7.1 rejected. Internally, everything “looked fine.”
The mail logs showed successful deliveries to personal Gmail accounts. The team assumed the customer’s mail gateway was broken,
because of course it was. They opened a ticket with the customer’s IT and waited.

The customer replied: “Your mail is failing SPF.” That sounded impossible—SPF record was unchanged. The wrong assumption was subtle:
they assumed the outbound IP was the instance IP. In reality, outbound traffic was NAT’d through a different egress IP in the cloud network.
SPF still authorized the old IP, not the NAT.

Fix took ten minutes: update SPF with the actual egress IP and add a second include for their new relay path. Unblocking took longer:
the customer had already added a temporary block because repeated retries looked like abuse.

The postmortem was short and slightly embarrassing. The lesson was blunt: always measure your actual sending IP.
“We moved the server” is not an email change. “We changed the IP identity the world sees” is.

Mini-story 2: The optimization that backfired

Another company decided to “optimize deliverability” by centralizing all outbound mail through one high-capacity MTA.
The logic was tidy: one place to manage DKIM, one place to tune TLS, one IP to warm up. They even bought a “premium” IP from their provider.
Someone made a slide. It had arrows.

It worked—until marketing ran a campaign with a new link-tracking domain and an aggressively compressed HTML template.
The centralized MTA suddenly carried transactional receipts and the campaign blast. Complaint rates rose.
A few corporate recipients started rejecting with 550 policy blocks; then Microsoft-family domains began throttling; then the RBL listings started.

The backfire wasn’t that marketing sent mail. It was that the organization collapsed multiple risk profiles into one reputation bucket.
Receivers don’t care that one message is a password reset and the other is “One weird trick.” They see the same IP, the same behavior,
and they score you as a whole.

Recovery required splitting streams: separate IPs and sometimes separate domains for bulk vs transactional, plus strict rate limits and content hygiene.
They also had to rebuild trust with receivers—slowly—because reputation recovers at the speed of consistent good behavior, not at the speed of panic.

Optimization is great. Unifying blast radius is not. Make systems simpler, but not in a way that makes failure catastrophic.

Mini-story 3: The boring but correct practice that saved the day

A healthcare-adjacent firm had a boring practice: every outbound mail change included a checklist item to send test messages to a small set
of seed mailboxes hosted on different providers and domains. They kept the headers. They tracked authentication results. Nobody got promoted for it.

One night, their DNS provider had a partial outage that didn’t take domains down, just caused intermittent TXT lookup failures in some regions.
SPF lookups started returning timeouts. Some receivers treated that as permerror and rejected with 550 5.7.1.
Others accepted but scored them down. It was messy and inconsistent.

The seed tests lit up within minutes: DKIM passed, but SPF was flapping. The on-call didn’t guess. They compared resolvers, confirmed the DNS issue,
and failed over DNS to a secondary provider they had set up months earlier because someone insisted it was “best practice.”

Mail flow stabilized before customers noticed. The only dramatic part was the chat thread where people asked how they detected it so quickly.
The answer was profoundly unsexy: they had a baseline and they watched it.

Joke #2: The best email deliverability tool is a calendar reminder to not do creative things on Friday afternoons.

Common mistakes: symptom → root cause → fix

1) “550 5.7.1 rejected” only for one big customer

Symptom: Gmail works, small domains work, one enterprise rejects everything.

Root cause: The customer has an allowlist/denylist policy, strict inbound gateway rules, or requires TLS/auth alignment; your IP/domain reputation might be locally blocked.

Fix: Get the exact rejection text; ask the customer for the policy reason; provide your sending IPs, envelope-from domain, and DKIM d= domain; implement rDNS and consistent HELO; request allowlisting only after authentication is correct.

2) “550 5.1.1 user unknown” after a migration

Symptom: Previously valid addresses now bounce as unknown.

Root cause: You’re delivering to the wrong MX (stale cached DNS, wrong domain, or mis-typed recipient domain), or the recipient changed tenants and your old route is dead.

Fix: Verify MX records, confirm the domain is correct, and validate the recipient exists through the recipient’s directory process (not by guessing). Stop retry storms.

3) “550 reverse DNS required”

Symptom: Immediate rejection early in SMTP conversation.

Root cause: No PTR record, generic PTR, or mismatch between PTR and A record; HELO doesn’t match either.

Fix: Set PTR to a stable hostname; ensure that hostname resolves back to the same IP; configure Postfix/your MTA HELO accordingly.

4) “550 relay denied” when apps send mail

Symptom: Apps can’t send; humans can.

Root cause: App is connecting to port 25 without auth; submission should be on 587 with SMTP AUTH and STARTTLS; or your relay restrictions are correct and the app expects an open relay (it shouldn’t).

Fix: Point apps to submission port 587, enable auth, restrict by IP where appropriate, and confirm the app uses valid envelope-from.

5) “550 5.7.26 DMARC reject” on forwarded mail

Symptom: Forwarding breaks; direct delivery works.

Root cause: SPF fails on forwarders (because forwarding changes sending IP) and DKIM is absent or broken; DMARC policy is reject and alignment fails.

Fix: Ensure DKIM signing survives transit (don’t rewrite signed headers); consider using ARC on forwarders you control; for third-party forwarders, focus on DKIM alignment.

6) “550 message content rejected” after adding a new link tracker

Symptom: Only marketing templates fail; transactional mail works.

Root cause: URL/domain reputation of the tracking domain is poor, or content triggers phishing heuristics; sometimes attachments are blocked.

Fix: Remove or replace the suspect URLs; ensure the tracking domain has proper DNS and reputation; avoid URL shorteners; keep HTML sane; split streams/IPs.

7) “550 rejected” started right after tightening SPF

Symptom: You changed SPF to -all and now things bounce.

Root cause: You forgot a legitimate sender (helpdesk, CRM, payroll, printers, old app server) or exceeded DNS lookup limits causing permerror.

Fix: Inventory senders, reduce includes, flatten SPF if needed, and validate each stream. Don’t use SPF as a weapon against your own estate.

8) Random 550s with “policy restrictions” across many receivers

Symptom: Not all mail fails; there’s noise.

Root cause: Reputation degradation plus inconsistent receiver scoring; or intermittent DNS/TLS issues causing some receivers to refuse.

Fix: Check for volume spikes, compromised accounts, DNS reliability, TLS handshake errors, and queue health; then stabilize behavior and warm back up.

The meta-failure in most of these: teams treat email rejections as “the other side’s problem.”
Sometimes it is. Most of the time, it’s yours, just expressed through someone else’s server.

Checklists / step-by-step plan to get unblocked

Step 0: Stop making it worse

• Pause bulk/marketing campaigns immediately if you suspect reputation issues.
• Rate-limit outbound mail if you see spikes or unknown senders.
• Disable compromised accounts or rotate credentials before you “work on deliverability.”
• Preserve evidence: save bounce messages, SMTP transcripts, and headers.

Step 1: Identify the failing stream

• Is it transactional (password resets, invoices) or bulk (newsletters)?
• Is it one sender address, one domain, or all outbound?
• Is it one recipient domain or multiple?

If you can’t separate streams, do it now. This is not “nice to have.” It’s blast-radius control.

Step 2: Fix identity basics (the “do these before you beg for delisting” set)

• Correct SPF for the actual egress IPs and vendors.
• Enable DKIM signing consistently for the visible From domain (or an aligned subdomain).
• Publish DMARC with a policy you can support (start with p=none if you’re blind; move up when aligned).
• Set rDNS/PTR and match HELO/EHLO to a resolvable hostname.
• Ensure TLS works; some receivers enforce STARTTLS and modern ciphers.

Step 3: Confirm your behavior doesn’t look like a botnet

• Keep sending rates stable; avoid sudden 10x spikes.
• Use consistent envelope-from and From domains; don’t rotate identities to “evade blocks.” That screams abuse.
• Implement bounce handling and suppress invalid addresses.
• Make unsubscribe work for bulk mail. Yes, this affects rejections.

Step 4: Targeted unblocking actions

• If an RBL lists you: identify why (compromise, open relay, spam complaint patterns), fix root cause, then request delisting.
• If a single enterprise blocks you: provide their admins with your sending IPs, DKIM domain, and examples; request temporary allowlist only after fixes.
• If consumer providers block you: focus on authentication, reputation, and content; warm up slowly and monitor bounces/complaints.

Step 5: Prove the fix with controlled testing

• Send a minimal plain-text email (no links, no attachments) to the failing domain. If it delivers, content is a suspect.
• Send one typical transactional template; then one marketing template.
• Compare headers and authentication results across messages.

Step 6: Set up boring monitoring so you don’t repeat this next quarter

• Alert on bounce rate, deferrals, and rejections by domain.
• Track authentication pass/fail rates by stream (SPF/DKIM/DMARC).
• Keep an inventory of legitimate senders and vendors.
• Reputation doesn’t need daily panic, but it does need weekly attention.

One quote to keep you honest:

“Hope is not a strategy.” — general engineering maxim, commonly attributed to operations leaders (paraphrased idea)

Email deliverability is where hope goes to be rate-limited.

FAQ

1) Is “550 rejected” always my fault?

No. Sometimes the recipient has a strict policy (external senders blocked, allowlist-only, misconfigured gateway).
But assume it’s your fault until you can prove otherwise with authentication checks and clean behavior. That mindset resolves incidents faster.

2) What’s the difference between 550 5.7.1 and 550 5.1.1?

5.1.1 is usually “bad recipient” (user unknown). 5.7.1 is “policy/security.”
The first is often a directory/data problem. The second is identity/reputation/content/policy.

3) If SPF passes, can I ignore DKIM and DMARC?

You can’t ignore them if you care about consistent delivery. SPF breaks under forwarding and some relays.
DKIM provides a durable identity signal. DMARC ties it together and gives receivers a clear policy and you reporting visibility.

4) Why did this start after we moved to a new cloud provider?

New IP reputation, new egress/NAT identity, missing rDNS, and subtle TLS differences are common triggers.
Cloud IPs often start with neutral reputation at best. Warm up slowly and keep authentication impeccable.

5) Can I just change IPs to get around a block?

Sometimes it works briefly. It’s also how you train receivers to distrust your entire domain.
Fix root cause first. If you must rotate IPs for business continuity, do it transparently and stabilize behavior immediately.

6) What if we’re listed on an RBL but we’re not sending spam?

RBLs list behaviors, not your self-image. You may have a compromised mailbox, an exposed submission port, a vulnerable web app sending mail,
or a vendor using your domain poorly. Identify the sending source and stop it. Then delist.

7) Our emails are rejected only when they include attachments. Why?

Attachments trigger malware scanning, file-type policies, and size limits. Some gateways reject certain extensions or password-protected archives.
Test with a plain-text email first; then add the attachment back. If the attachment is required, use approved formats and consider secure download links (with reputable domains).

8) Does rDNS really matter in 2026?

Yes. Not universally, but enough that you’ll trip over it in corporate gateways and older policy stacks.
A missing PTR is a low-effort reason to distrust you, and receivers love low-effort.

9) Why do we deliver to Gmail but not to Microsoft-hosted domains?

Different scoring models, different tolerance for borderline signals, and different throttling behaviors.
Treat it as a clue: compare authentication results, TLS, and sending patterns. Often Microsoft-family filtering is less forgiving of sudden volume changes.

10) How long does it take to recover reputation after a block?

If it’s a simple auth misconfig, it can be minutes to hours after you fix it. If it’s reputation damage from abuse or high complaint rates,
think days to weeks of consistent, clean sending. You don’t negotiate with algorithms; you outlast them.

Conclusion: next steps you can execute today

“550 rejected” is the receiver telling you they don’t trust this message, this sender, or this behavior. Your fastest path out is not
a random walk through settings. It’s disciplined triage and targeted fixes.

1. Capture the exact rejection (enhanced code + text) and determine whether it’s identity, reputation, or routing.
2. Validate the fundamentals: real sending IP, SPF pass, DKIM present/valid, DMARC alignment, rDNS, HELO, TLS.
3. Stop the bleeding: pause bulk, rate-limit, hunt compromised accounts, clean your lists.
4. Prove the fix with controlled tests that isolate content vs policy vs recipient issues.
5. Prevent repeats by separating streams and monitoring rejection patterns by domain and authentication outcomes.

Email deliverability isn’t magic. It’s operations: identity, hygiene, and reputation, all under continuous change.
Treat it like production, and it behaves like production. Treat it like a utility, and it will eventually invoice you in outages.