Email Deliverability · Email Authentication · SMTP Troubleshooting

SMTP 550 Error Troubleshooting: Symptom-Led Guide

· InboxPlacement.io Team

Updated

SMTP 550 error troubleshooting guide showing an evidence checklist, authentication failure example, and controlled verification steps

Short answer: An SMTP 550 reply is a hard rejection from the recipient or an intermediate relay — it means the receiving server refused to accept that message, but the 550 text alone does not prove why, whether authentication failed, or whether the message would have reached an inbox.

Direct diagnosis: what the symptom usually means and what it does not prove

Observed fact

  • SMTP 550 is a permanent rejection code returned during an SMTP conversation. It indicates the remote server (or a relay) refused to accept the message.

What a 550 usually implies

  • The receiver rejected the envelope or message during SMTP. Common immediate reasons are authentication failures, policy blocks, or blocked sender/IP lists.

What a 550 does NOT prove

  • It does not prove that SPF, DKIM, or DMARC passed or failed; you must inspect Authentication-Results or the receiver’s diagnostic text.
  • It does not prove inbox placement or final user disposition (delivered to inbox, spam, or quarantined).
  • It does not prove your DNS, mail flow, or sending reputation are globally healthy — a 550 is a single-server decision that requires correlation with other evidence.

Every illustrative scenario below is labeled illustrative unless you collect the evidence named in the next section.

Evidence to collect before changing anything

Collecting the right artifacts avoids unnecessary or harmful changes. Below is a practical checklist and table you can use immediately.

Checklist (minimum)

  • Full SMTP session transcript (from your MTA logs) that includes the 550 reply.
  • Original message headers from the sending MTA (including Authentication-Results if present).
  • Envelope MAIL FROM and RCPT TO values and the sending IP address.
  • Recent sending volume and rate to the same recipient domain (illustrative).
  • Any DMARC aggregate/forensic reports for the sending domain (if configured).

Decision table: what to grab and why

Observed itemWhere to collect itWhat it may indicate (illustrative)
SMTP transcript with 550 textMTA / mail server logsReceiver policy, explicit rejection reason, or blocklists
Authentication-Results header or receiver logMessage headers or receiver feedbackWhether SPF, DKIM, and DMARC were evaluated by the receiver (does not prove placement)
Sending IP and HELO/EHLOMTA logsIP reputation, wrong HELO may trigger policy blocks
DNS TXT records (SPF/DKIM/DMARC)Public DNS lookupsConfiguration problems, missing or misformatted records
Recent send rate to domainSending system metricsBulk-sender throttling or enforcement risk (illustrative)

Label every unverified scenario illustrative: until you have the SMTP transcript and headers, any root-cause guess is illustrative.

Illustrative Spam Test showing an unauthorized SPF sender, failed DKIM verification and DMARC failure.

Demo example. Authentication failure diagnosis. Synthetic results for feature explanation; not a live test or customer outcome.

A symptom-to-cause decision tree

Use this compact decision flow to progress from observed symptom to most likely investigative action:

  1. Do you have the SMTP transcript with the 550 text?

    • No → collect the transcript from the sending MTA logs first.
    • Yes → proceed.

  2. Does the 550 include a clear diagnostic (for example, “SPF fail”, “blocked”, or “user unknown”)?

    • Yes → treat the text as a lead and collect Authentication-Results and receiver-facing details.
    • No → collect Authentication-Results, check sending IP reputation and relay behavior.

  3. Does Authentication-Results show SPF, DKIM, or DMARC failure for this message?

    • Yes → follow authentication troubleshooting (DNS records, signing, and alignment).
    • No or absent → consider IP blocklists, rate limits, content/policy filters, or user-level issues.

  4. Is the sending IP in blocklists or recently changed?

    • Yes → review blocklist removal procedures and confirm no compromised sending behavior.
    • No → inspect message content and sending patterns; escalate to the recipient postmaster if evidence supports it.

All paths above are diagnostic guidance. Each “Yes” or “No” should be supported by the evidence listed earlier.

Most common root causes, ordered by likelihood and impact

The list below is ordered for typical operational impact and how often each cause appears in practice (illustrative).

  1. Authentication failures (SPF/DKIM/DMARC misconfiguration) — high impact, often resolvable

    • Illustrative: missing SPF record, incorrect DKIM selector, or alignment failures.
    • Microsoft documents common SPF failure modes (no record, permerror, softfail) and how they map to symptoms. See Microsoft guidance for troubleshooting SPF and how SPF, DKIM, and DMARC interact.

  2. IP reputation or blocklisting — high impact, may require third-party remediation

    • Illustrative: sending IP appears on one or more RBLs used by the receiver.

  3. Receiver policy enforcement (rate limits, bulk-sender rules, explicit blocks) — medium to high impact

    • Illustrative: bulk-sender thresholds or postmaster policy at large providers can cause temporary or permanent rejections. Google’s sender guidelines outline sender requirements and the use of Postmaster Tools for monitoring.

  4. Content or spam classification at SMTP time — medium impact

    • Illustrative: message content or headers trigger an SMTP-time policy reject.

  5. Incorrect envelope or recipient address (user unknown, mailbox disabled) — low to medium impact

    • Illustrative: typo in RCPT TO or account removed.

Safe remediation steps with clear limitations

Separate what you should do now (safe, reversible) from what requires caution or authorization.

Observed evidence → Recommended safe actions (illustrative)

  • Authentication failures (for example, SPF missing)

    • Safe actions:
      • Publish or correct the SPF TXT record to authorize known senders.
      • Verify DKIM selectors and private key configuration on the sending system.
      • Use DMARC with p=none for monitoring while validating SPF/DKIM (do not change to quarantine/reject without owner authorization and a rollback plan).
    • Limitations:
      • Publishing SPF/DKIM/DMARC does not guarantee delivery; these are authentication signals used by receivers.

  • DKIM signing problems

    • Safe actions:
      • Confirm your MTA signs outbound mail, check DNS for published DKIM keys, and validate selector names.
    • Limitations:
      • Key rotation or a wrong selector can cause intermittent failures; change during low-volume windows and retain old keys until propagation is verified.

  • Blocklisted IP

    • Safe actions:
      • Identify the blocklist entries, confirm whether sending behavior or compromise caused the listing, and follow the listed removal steps.
      • If compromise is suspected, pause bulk sends from the affected IP and rotate to a clean IP with proper authentication.
    • Limitations:
      • Delisting timelines vary; do not immediately switch reputation-sensitive domains without coordinating stakeholders.

  • Receiver policy / bulk-sender enforcement

    • Safe actions:
      • Reduce sending rate to the affected destination, improve list hygiene, and use Postmaster or support channels at the receiver if available.
    • Limitations:
      • Policy changes at large providers may be irreversible for bulk senders; consult the receiver’s published guidelines first.

DMARC policy changes: Never advise weakening an existing DMARC enforcement policy except as an explicit emergency action with documented owner authorization, narrow scope, a time limit, and rollback criteria. If you must use emergency changes, record who authorized it, exactly what DNS change was made, why, and when it must be reverted.

How to verify the change with a real message or controlled test

Verification should be evidence-based and controlled.

Step 1 — Prepare a controlled test

  • Use a single controlled recipient you control (not a public mailbox) for initial verification.
  • Keep message content simple and representative of normal traffic.
  • Ensure the sending environment uses the corrected DNS records, keys, and the same sending IP and HELO/EHLO.

Step 2 — Send and collect the artifacts

  • Capture the full SMTP transcript from the sending MTA.
  • Retrieve the received message headers at the recipient end, including the Authentication-Results header.
  • Record the envelope addresses and sending IP.

Step 3 — Evaluate results and what they prove

  • Authentication-Results: shows how the receiver evaluated SPF, DKIM, and DMARC. This is evidence that the receiver processed your authentication signals, but it does not prove inbox placement. Authentication-Results is an important diagnostic signal, not a delivery certificate.
  • SMTP 250 or absence of 550: indicates the receiver accepted the message; acceptance is not the same as inbox placement (delivery versus final placement).
  • Delivery to mailbox or spam folder: this is the only direct evidence of placement, but it is one mailbox’s experience — extrapolate cautiously.

What you cannot prove with these tests

  • A single successful test cannot prove global inbox placement for all recipients or all receivers.
  • Authentication-Results passing does not guarantee the message bypasses spam filters or lands in the inbox.

When broader verification is required, use controlled tests across multiple mailbox providers and volumes. For a repeatable, multi-recipient check of authentication signals and placement, consider inbox placement testing tools and provider postmaster dashboards.

Anonymized Spam Test example retaining the supplied report score of 98/100 and its 12 passed checks, one warning and passing authentication.

Anonymized example adapted from a supplied product report. Selected figures retained; identifiers and layout reconstructed. Not a new live test.

Prevention and monitoring checklist

  • Publish and monitor SPF, DKIM, and DMARC records; use DMARC monitoring and reporting to gather feedback.
  • Ensure TLS is used to transmit mail where supported (Gmail’s guidelines recommend TLS).
  • Monitor sending IP reputation and blocklists regularly.
  • Use provider postmaster tools (for example, Gmail Postmaster Tools) to monitor spam rates and compliance status.
  • Keep sending patterns consistent; avoid sudden spikes in volume to large providers.
  • Maintain an incident playbook that includes who can authorize emergency DNS changes and the rollback plan.
  • Automate collection of MTA logs and delivery artifacts for faster diagnosis.

FAQ

What does the Authentication-Results header tell me?

Authentication-Results shows how the receiving system evaluated SPF, DKIM, and DMARC for that message. It documents the receiver’s checks but does not guarantee delivery or inbox placement.

Can fixing SPF/DKIM/DMARC immediately stop 550 errors?

Fixing authentication often resolves many delivery rejections, but it is not guaranteed. A corrected DNS record or signing configuration is necessary but not sufficient to prove inbox placement. Confirm with controlled tests and receiver feedback.

When should I contact the recipient’s postmaster?

Contact the recipient’s postmaster after you have collected SMTP transcripts, Authentication-Results, sending IP and time, and when evidence points to receiver-side policy or blocklisting that you cannot resolve. Provide the collected evidence when requested.

Run an InboxPlacement test to verify authentication signals and mailbox placement after applying the recommended changes.

Sources

Related Reading