How to fix 550 5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant
This is a Microsoft 365 rejection meaning the message arrived without a usable From header. It is almost always a device, app or relay that never set one. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~14 min Updated Jul 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
550 5.7.512 is a Microsoft 365 and Exchange Online rejection meaning the message did not carry a usable From header. RFC 5322 section 3.6.2 is the part of the internet message format standard that defines the originator fields, and it makes the From field mandatory, so a message with no From, an empty From or a malformed one is rejected outright. The key thing to understand is that this is about the header From that you see in a mail client, not the envelope sender used during SMTP transport, which is why the fix is almost never in your DNS or your connector IP. In practice it comes from something that submits mail without setting a sender: a printer, scanner or MFP, a line-of-business app or script or a website form. The fix is to make that sender always set a real, licensed address in the form Display Name <user@yourdomain.com>. A second, less obvious case exists: inbound bounces and NDRs can be rejected with 5.7.512 because they carry a null sender, which is expected behaviour rather than a misconfiguration.
What 5.7.512 is actually complaining about
Microsoft 365 returns 550 5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant and include a valid From address when a message reaches it without a usable sender in the message header. It is a permanent rejection, so the message is not retried and the sender gets a non-delivery report.
RFC 5322 is the internet message format standard, and section 3.6.2, Originator Fields, defines the From, Sender and Reply-To fields. The standard is blunt about it: the only required header fields on a message are the origination date and the originator address, so a message without a valid From is not a valid message at all. Microsoft is not applying a custom policy here, it is enforcing the base standard.
Figure 1: three different senders, only one causes this error
RFC5322.From Header From
The From: line inside the message, shown in the mail client.
Defined by RFC 5322 section 3.6.2 and required.
This is what 5.7.512 checks.
RFC5321.MailFrom Envelope sender
The MAIL FROM value in the SMTP conversation, used for bounces.
Can legitimately be empty on a bounce.
Not what the 5.7.512 text refers to.
Mixing these two up is the single biggest time-waster on this error. Teams start checking SPF records, connector IP addresses and DNS, which all relate to the envelope, while the actual complaint is that the header inside the message has no usable address. A message can pass every authentication check and still be refused here.
Figure 2: what section 3.6.2 accepts and what it does not
From: Scanner <scanner@contoso.com>Valid. Display name plus an address in angle brackets.
From: scanner@contoso.comValid. A bare address is fine, the display name is optional.
From: ScannerRejected. A display name with no address is not a mailbox.
From:Rejected. The field is present but empty.
(no From line at all)Rejected. From is one of only two header fields the standard requires.
From: a@contoso.com, b@contoso.comNeeds a Sender: header. If From lists more than one mailbox, section 3.6.2 requires Sender to name the one agent that actually sent it.
RFC 5322 requires only two header fields on a normal message: the origination date and the originator address. From is the second of those, which is why a missing or empty one is a hard failure rather than a warning. Note the last row: a multi-address From without a Sender header is non-compliant, and it catches out apps that send on behalf of several people.
Common causes of a 5.7.512 rejection
The message was submitted with no From header at all.
The From header is present but empty.
The From header has only a display name and no email address.
The From address is malformed, for example missing the domain or the angle brackets.
From lists several mailboxes but no Sender header names the sending agent.
A printer, scanner or MFP is set to send with a blank or invalid sender.
An app, script or website form 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.
An inbound bounce or NDR carries a null sender, which Exchange Online refuses by design.
Expert insight
“The first question I ask is what sent it, because a person in Outlook basically cannot trigger this. Outlook will not let you send without a From. So it is a printer, an app, a script or a form, and one of them is submitting a message with no sender in the header. The trap is that people go straight to SPF and connector IPs, and those are the envelope, not the header, and 5.7.512 is complaining about the header. Set a real licensed address in the form Display Name and the address in angle brackets, and it goes away. The one case that fools everyone is a bounce coming back in and getting refused: that is a null sender, and it is expected, not something you broke.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it
Work out what submitted the message first, because that decides everything else. A person sending from Outlook essentially cannot cause this, so the sender is almost always a device, an app or an automated bounce.
If step 1 lands on the third option, stop. A refused bounce is not a fault you introduced, and no amount of connector work will change it.
Method 1
Read the NDR and find what sent it
1Open the bounce and confirm the code reads 550 5.7.512 with the RFC 5322 section 3.6.2 text.
2Identify the sending system. Outlook users essentially cannot trigger this, so look for a device, an app, a script or a web form.
3Note the address it claims to send from. If the NDR shows no sender at all, that is your answer.
Method 2
Set a valid From address
1Set the sender to a real, licensed mailbox in your tenant, in either accepted form:
From: Scanner
From: scanner@contoso.com
2A display name on its own is not an address. From: Scanner is rejected, because there is no mailbox in it.
3Use a domain that is an accepted domain in your tenant, then send a test.
Method 3
Add a Sender header if From lists several people
1If the message legitimately has more than one address in From, section 3.6.2 requires a Sender header naming the single agent that transmitted it.
2Add it alongside the From line:
From: Alice , Bob
Sender: App
3If you do not need multiple authors, the simpler fix is to send from one address.
Method 4
Fix a printer, scanner or MFP
1In the device's email or SMTP settings, find the From, Sender or Device email address field and set it to a real mailbox, for example scanner@contoso.com.
2Some devices leave this blank by default, or fill it with a name only. Both are rejected.
3Save, then scan to email to test. Microsoft has a diagnostic for devices that send through Microsoft 365 if it still fails.
Method 5
Fix an app, script or web form
1Set the sender explicitly in the mail library rather than relying on a default. Most 5.7.512 cases from apps are a sender that was never assigned.
2Contact forms are a common offender: they often set the visitor's address as From, which fails if it is empty or unvalidated. Send from your own mailbox and put the visitor in Reply-To.
3Redeploy and send a test.
Method 6
Check the SMTP relay or connector
1If the device sends through an Exchange Online connector, confirm the connector matches your current public IP address and that the sending domain is an accepted domain in the tenant.
2Relay lets you send for any accepted domain, so the From address must still belong to one of them.
3Re-test after any connector change.
Method 7
Use authenticated SMTP submission
1For a device or app that can sign in, use SMTP AUTH client submission to smtp.office365.com on port 587 with STARTTLS.
2The account must be a licensed mailbox with authenticated SMTP enabled, and it must send from its own address unless it has Send As permission on the other one.
3Send a test to an internal mailbox first, then an external one.
Method 8
Bounces and NDRs refused with 5.7.512
1If the refused message is itself a bounce, NDR or delivery-status notification, it carries a null sender by design, because a bounce must not be bounceable.
2Microsoft treats refusing these as expected behaviour, since a report cannot be returned to an address that is not valid. It is not a misconfiguration on your side.
3If a filtering service holds and later releases such a message, it can hard bounce the same way. Retrieve it from that service rather than trying to force the release.
Method 9
Run a message trace and read the header
1In the Exchange admin center, run a message trace for the send and open the details.
2Where you can capture the message, read the raw header and look at the From: line directly. That confirms the fault in one look.
3Remember you are checking the header, not the envelope, so SPF and connector results are not the answer here.
Method 10
Send a test and verify
1Send one test to an internal mailbox and one to an external address.
2Open the delivered message and check the From shows the address you configured, not a bare name.
3If the internal test delivers but the external one fails, the problem has moved on to relay or authentication rather than the From header.
If you are checking SPF records, DKIM or your connector IP address, you are probably looking in the wrong place. Those all describe the envelope and the domain, while 5.7.512 is complaining about the From line inside the message. A message can pass every authentication check you have and still be refused here, because the header has no usable mailbox in it.
Make sure it is really 5.7.512
Printers and apps throw a family of similar-looking 5.7.x rejections, and they have completely different fixes. Check the digits before you spend an afternoon on the wrong one.
Figure 4: 5.7.512 against the errors it gets confused with
550 5.7.512 ... must be RFC 5322 section 3.6.2 compliant
MeansNo usable From header in the message.ActionYou are on the right page.
550 5.7.60 Client does not have permissions to send as this sender
MeansThe From address does not match the account that signed in.ActionDifferent error. Match the address, or grant Send As.
550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP
MeansYour public IP is not on the connector.ActionDifferent error. Update the connector IP.
550 5.7.64 TenantAttribution; Relay Access Denied
MeansThe relay could not attribute the mail to your tenant.ActionDifferent error. Fix the connector or certificate.
530 5.7.57 Client was not authenticated to send anonymous mail during MAIL FROM
MeansThe device did not sign in but the path requires it.ActionDifferent error. Use SMTP AUTH or a relay connector.
The pattern is worth remembering. Only 5.7.512 is about the content of the message header. Every other row is about permission or transport: who signed in, which IP connected, whether the tenant could be identified. That is why the fixes have nothing in common.
Frequently asked questions
What does error 550 5.7.512 mean?
It means Microsoft 365 rejected the message because it did not include a usable From header. RFC 5322 section 3.6.2 defines the originator fields and makes From mandatory, so a message with no From, an empty one or a malformed one is refused outright.
What is RFC 5322 section 3.6.2?
It is the part of the internet message format standard that defines the originator fields: From, Sender and Reply-To. The standard requires only two header fields on a message, the origination date and the originator address, so a valid From is not optional.
Why am I getting this from my printer or scanner?
Because the device is submitting mail without a sender. Many printers leave the From field blank by default, or hold only a display name. Set it to a real, licensed mailbox such as scanner@yourdomain.com in the device's email settings.
What is a valid From format?
Either a bare address, such as scanner@contoso.com, or a display name followed by the address in angle brackets, such as Scanner <scanner@contoso.com>. A display name on its own is not an address and is rejected.
Is 5.7.512 about SPF, DKIM or my connector?
No, and this is the most common misdiagnosis. Those relate to the envelope sender and your domain. 5.7.512 is about the From header inside the message, so a message can pass every authentication check and still be refused.
Why was an incoming bounce or NDR rejected with 5.7.512?
Bounces carry a null sender by design, because a bounce must not itself be bounceable. Exchange Online refusing them is expected behaviour rather than a fault, since a report cannot be returned to an address that is not valid.
Do I need a Sender header?
Only if the From field lists more than one mailbox. Section 3.6.2 requires a Sender header in that case to name the single agent that actually transmitted the message. Sending from one address avoids the requirement entirely.
Is the problem on the recipient's side?
Almost never. The rejection is about your message not carrying a valid From header, so the fix sits with whatever submitted it. The one exception is an inbound bounce with a null sender, where nothing is broken at either end.
How do I fix it for an app or script?
Set the sender explicitly in the mail library rather than relying on a default. For contact forms, send from your own mailbox and put the visitor's address in Reply-To, since an empty or unvalidated visitor address is a common cause.
How do I confirm what the message actually sent?
Run a message trace in the Exchange admin center, and where you can capture the message read the raw header and look at the From line directly. That shows in one look whether an address was present.
Still not working?
If the device sets a valid From and still fails, capture the raw header from a message trace and confirm what actually left the device, since some firmware silently drops the field. Where the device cannot set a sender at all, the honest answer is that it does not support the send path you are using, and a relay connector with a fixed From, or a small forwarding service in front of it, is the way out. You can also submit your error to us for a tailored fix.
