@Mail Domain Check

Microsoft 365 | SMTP submission | Send As

Microsoft 554 5.2.252 SendAsDenied: System SMTP Account, User From

When an application authenticates one system mailbox and then puts the current user's address in From, Microsoft can reject the message at the end of DATA. The safe default is the authenticated system mailbox in From and a validated user address in Reply-To, unless a narrow Send As grant is an intentional product requirement.

Target incident

A CRM signature invitation fails with 554 5.2.252 SendAsDenied after its system mailer overwrites From with the active user's address. The copied OTP path has the same identity mismatch.

Separate four identities and outcomes

SMTP authentication
The account or OAuth principal that opens the provider submission session.
Envelope sender
The RFC 5321 MAIL FROM used for transport status and bounces.
Visible From
The RFC 5322 author identity shown to the recipient and evaluated by Send As policy.
Reply-To
The address that should receive a reply when it intentionally differs from the visible author.

Browser-local SendAsDenied planner

Choose the first repair boundary

No email address, tenant, SMTP hostname, username, credential, OAuth token, recipient, message body, complete transcript, provider payload, configuration dump, or raw log is requested or transmitted.

What the reviewed CRM path does

The open SinergiaCRM issue 1349 includes the exact Microsoft rejection. At reviewed commit c439c83, sendToSign() calls setMailerForSystem(), obtains the system defaults, and then replaces From with $current_user->email1 when present.

The same repository contains a second affected path: the OTP message setup repeats the system-mailer plus current-user-From sequence. Fixing only the invitation would leave the next signature step vulnerable to the same permanent rejection.

Use From for identity and Reply-To for replies

The lowest-risk default keeps the mailbox authorized by the active SMTP transport in From. If the application has validated the current user's address and replies should go there, put that address in Reply-To.

$mail->setMailerForSystem();
$defaults = $mail->getSystemDefaultEmail();

$mail->From = $defaults['email'];
$mail->FromName = $defaults['name'];

if (!empty($current_user->email1)) {
    $mail->addReplyTo($current_user->email1, $current_user->name);
}

This is the repair shape, not a blind patch. In this mail stack, outbound preparation may rewrite headers. Inspect the final submitted From and Reply-To after prepForOutbound() or equivalent hooks.

Use Send As only when impersonation is intentional

Microsoft defines Send As as a delegated mailbox permission. It is distinct from Send on behalf and from merely sharing a domain, alias, display name, or directory. Grant it only when the product is deliberately designed to send as another mailbox and the permission can be scoped, audited, and regression-tested.

RFC 5322 section 3.6.2 separates the message author, transmitting agent, and reply destination. That makes system From plus user Reply-To an explicit identity model, not a deliverability workaround.

Do not change DNS for this rejection

554 5.2.252 SendAsDenied occurs at Microsoft submission authorization. SPF, DKIM, and DMARC are important later controls, but they do not grant one authenticated mailbox permission to write a different mailbox into From. A recipient, PTR, or retry-rate change also cannot repair the mismatch.

The first digit in 554 is permanent under RFC 5321 section 4.2.1. Stop unchanged retries. Repair the identity contract, then submit one controlled message.

Regression contract

  1. Cover both signature invitation and OTP message paths.
  2. Test a user with no email: the final From remains the system default and no empty Reply-To is added.
  3. Test a user whose address equals the system mailbox: no unnecessary delegated identity is introduced.
  4. Test a different validated user address without Send As: From is system, Reply-To is user, and Microsoft returns final 250.
  5. Test any deliberately delegated mailbox separately and verify the exact principal, mailbox, permission, and propagation.
  6. Inspect final headers after outbound preparation, not only values assigned before the mailer rewrites them.
  7. Assert that a 554 5.2.252 is terminal for the unchanged attempt and does not enter an immediate retry loop.
  8. Keep addresses, credentials, tenants, recipients, message bodies, and complete SMTP transcripts out of public telemetry.
Have only the redacted Microsoft reply?

Decode the provider boundary locally before changing the mailer or DNS.

Open the fixed local sample

Primary references