IT Toolbox
Procedure

Fix an SMTP 550 Sender mismatch error

Fix an SMTP 550 Sender mismatch by aligning the authenticated SMTP account, visible From address, envelope MAIL FROM, aliases or delegations, and WordPress forms without impersonating the visitor address.

Email

Objective

Resolve a rejection where the SMTP relay considers the sender identity unauthorized for the authenticated account. Compare SMTP AUTH, the visible From header, and MAIL FROM/Return-Path, validate aliases or delegation, correct web forms, and confirm delivery without granting unnecessarily broad sending rights.

Prerequisites

  • The complete 550/5.7.x response and the exact test time.
  • The SMTP account used for AUTH.
  • The application From address and any Return-Path or envelope sender.
  • The provider list of aliases, delegations, or Send As identities allowed for the account.
  • Access to the WordPress plugin or application settings that build the message.

Step-by-step procedure

1

Record the three sending identities

Record the SMTP AUTH account, the visible From header, and the MAIL FROM envelope separately. Many applications can set these values independently, so the first task is to identify which identity the relay is rejecting.

Expected result
  • AUTH account, From, and MAIL FROM are known separately.
2

Read the exact 550 response and rejection point

If the server rejects MAIL FROM, the policy usually concerns the envelope sender. If rejection happens after DATA, the relay may be comparing message headers with the authenticated account. Keep the enhanced status code and relay hostname so the correct provider policy can be applied.

Expected result
  • The policy check is located within the SMTP transaction.
3

Test with the exact SMTP account address

Temporarily set both From and the envelope sender to the exact authenticated account, then send a minimal message. If this succeeds, the problem is probably an unauthorized alias or sender identity rather than the SMTP secret or network path.

Expected result
  • The test distinguishes authentication failure from sender-authorization failure.
4

Check aliases and Send As permissions

If the application must send as contact@example.com while SMTP AUTH uses site@example.com, verify that contact@example.com is an alias or explicitly delegated sender for that account. Owning the DNS domain alone does not automatically authorize every mailbox identity.

Expected result
  • The final From address is authorized for the authenticated account.
5

Correct WordPress or application settings

Use a dedicated address from your controlled domain as From and force it when the SMTP plugin supports that option. Put the visitor address in Reply-To so human replies still reach the visitor without asking the relay to impersonate an external address.

Expected result
  • Forms use an authorized domain From address and a dynamic Reply-To.
6

Check Return-Path and MAIL FROM

Some plugins and libraries set the envelope independently of From. If the relay also enforces MAIL FROM alignment, enable a supported Return-Path option or let the relay choose its supported envelope sender. Do not force an external address into the envelope.

Expected result
  • The sending envelope is consistent with relay policy.
7

Check SPF, DKIM, and DMARC after relay acceptance

After the 550 error is resolved, send to an external mailbox and inspect Authentication-Results. A message accepted by the relay can still fail later if domain authentication is wrong, so confirm the expected SPF, DKIM, and DMARC behavior.

Resolve-DnsName -Type TXT <DOMAINE>
Resolve-DnsName -Type TXT _dmarc.<DOMAINE>
Expected result
  • The received message passes the expected authentication checks or any remaining mismatch is clearly identified.
8

Test all important application scenarios

Test contact forms, password resets, e-commerce notifications, and other critical functions that may construct their own headers. A plugin test message does not prove that every extension uses the same From identity.

Expected result
  • Critical transactional messages all use an authorized sender identity.
9

Document the final sender mapping

Document the SMTP account, authorized From address, expected Reply-To behavior, and where the secret is managed. Do not record the password itself. Consider a dedicated account per application when that reduces the impact of credential compromise.

Expected result
  • The working configuration can be reproduced without exposing the secret.

Validation

The procedure is validated when:

  • The authenticated account and From/MAIL FROM identities are consistent or explicitly authorized.
  • The relay no longer returns SMTP 550 Sender mismatch.
  • Web forms use visitor addresses in Reply-To rather than From.
  • SPF, DKIM, and DMARC are checked on a received message after the relay issue is fixed.
  • All important application notification paths have been tested.

Rollback

  • Restore the previous From address only if it was authorized and working.
  • Remove any temporary alias or delegation that is not required by the final design.
  • Revoke temporary SMTP credentials created for troubleshooting.
  • If the provider still rejects the alias, use the exact SMTP account address until the correct delegation is configured.

Troubleshooting / common errors

  • If only form messages fail, compare their actual headers with the plugin test message.
  • If MAIL FROM differs from From, check whether the provider validates both identities.
  • If relay acceptance succeeds but external delivery fails, continue with SPF, DKIM, and DMARC diagnostics.
♡ 0