Categories About Us Contact Us Become a Member

How to fix “5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant”

This is a Microsoft 365 bounce telling you the message has no valid From address, which breaks the RFC 5322 rule for the From field. It almost always comes from an app, a printer or a script that sends mail without setting a proper sender. Jump to your situation below or work through the methods in order.

By Neeraj Singh ~8 min Updated Jun 2026 94% found this helpful
Error message
550 5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant and include a valid From address.
Summary

Error 5.7.512 is a Microsoft 365 or Exchange Online bounce (a non-delivery report) that means the message was submitted without a valid From address. RFC 5322 section 3.6.2 defines the From field, and Exchange Online now rejects mail that has a missing, empty or malformed sender. In practice this almost never comes from a normal mailbox, it comes from a device or system that relays mail through Microsoft 365, such as a multifunction printer or scanner, a line-of-business app, a script, or a website contact form. The fix is to configure the sender so it always sets a real, licensed From address in the correct format, for example Display Name <user@yourdomain.com>, and to make sure the relay or SMTP connector is set up the right way. It is not a problem with the recipient or their mailbox.

What this error means

The error is a delivery status notification from Exchange Online, not a failure on the recipient side. RFC 5322 section 3.6.2 requires every message to carry a properly formed From header, and Microsoft 365 enforces that. When a message arrives with no From address, a blank one, or a malformed one, Exchange refuses it with 5.7.512.

Because a normal Outlook mailbox always sets a valid From, this is nearly always raised by something automated: a printer that scans to email, an application that sends notifications, or a script that relays through Microsoft 365 without specifying a sender. Fixing the sender configuration so it always supplies a real From address clears the bounce.

Common causes

The message was submitted with no From header at all.
The From header has only a display name and no email address.
The From address is malformed, for example missing the angle brackets or domain.
A printer, scanner or MFP is set to send with a blank or invalid sender.
An app or script relays through Microsoft 365 without setting a sender.
The sending address is not a real, licensed mailbox in the tenant.
The SMTP relay or connector is misconfigured for the sending device.
Expert insight

“This one trips people up because they go looking at the recipient, and the problem is on their own side. Microsoft tightened things up so a message with no proper From address just bounces with 5.7.512. The usual offender is a photocopier or a little app that someone set up years ago to scan to email, and it was never given a real sender. The fix is almost always one field: set the From to a genuine, licensed mailbox in the right format. Once the device sends as a real person or a shared mailbox, the bounce disappears.”

How to fix it

Method 1

Confirm the bounce and the sender

1Open the non-delivery report and confirm it is 5.7.512 and references the From or sender address.
2Note which system sent the message, a person, a printer, an app, or a script.
3In the Exchange admin center you can run a message trace to see exactly what was submitted.
Method 2

Set a valid From address

1Make sure the message carries a real, properly formatted From header, for example:
From: Reports <reports@yourdomain.com>
2The address must be a licensed mailbox or an accepted sender in your Microsoft 365 tenant.
3Never send with an empty or display-name-only From.
Method 3

Fix a printer, scanner or MFP

1On the device, open the email or scan-to-email settings and set the From or Mail from field to a valid mailbox.
2Do not leave it blank or set to something like device@local that is not a real address.
3Use a dedicated shared mailbox for the device so the sender is consistent and licensed.
Method 4

Fix an app or script

1In the sending code, set both the envelope sender and the From header to a valid address.
2Do not issue an empty MAIL FROM, and do not rely on the server to invent a sender.
3Send a real address that your tenant accepts, then test.
Method 5

Check the SMTP relay or connector

1Confirm you are using the right submission method for the device: client SMTP submission, direct send, or an SMTP relay connector.
2For a relay connector, make sure the sending IP and the From domain are accepted by the connector.
3Microsoft documents each method, pick the one that matches the device and licence.
Method 6

Use authenticated SMTP submission

1Where the device supports it, use authenticated submission to smtp.office365.com on port 587 with a licensed mailbox.
2Authenticated submission sets a valid From automatically from the signed-in mailbox.
3This is the most reliable way to satisfy the RFC 5322 requirement.
Method 7

Send a test and verify

1Send a test message from the device or app and confirm it is delivered, not bounced.
2If it still fails, run a message trace in the Exchange admin center to see the submitted headers.
3Check SPF and DKIM for the sending domain so the valid From also passes authentication.

5.7.512 is about your own sending configuration, not the recipient, so do not ask them to change anything. The sender must always supply a real, licensed From address in valid format. A dedicated shared mailbox for each device or app is the cleanest way to guarantee that, and it also keeps SPF and DKIM aligned so the mail is trusted.

Frequently asked questions

What does error 5.7.512 mean?
It is a Microsoft 365 bounce that the message was sent without a valid From address, which breaks RFC 5322 section 3.6.2. Exchange Online rejects mail that has a missing, empty or malformed sender.
Why am I getting this from my printer or scanner?
Scan-to-email devices often send with a blank or invalid sender. Set the device's From or Mail from field to a real, licensed mailbox, ideally a dedicated shared mailbox.
Is the problem on the recipient's side?
No. 5.7.512 is raised by your sending side because the message has no valid From address. The recipient and their mailbox are not involved.
What is a valid From format?
A display name and a real address in angle brackets, for example Reports <reports@yourdomain.com>. The address must be a licensed mailbox or an accepted sender in your tenant.
How do I fix it for an app or script?
Set both the envelope sender and the From header to a valid address, never send an empty MAIL FROM, and prefer authenticated submission to smtp.office365.com on port 587.
How do I stop it happening again?
Give every device and app a dedicated, licensed sending mailbox, use authenticated submission where possible, and keep SPF and DKIM aligned for the sending domain.

Still not working?

If the From address looks correct but the bounce continues, run a message trace in the Exchange admin center to see the exact headers Microsoft 365 received, since a device can silently strip or rewrite the sender. Confirm the sending method matches Microsoft's guidance for relay, direct send or client submission. You can also submit your error to us for a tailored fix.

Was this fix helpful? Thanks for your feedback!