Quick answer
An Outlook 5.7.512 bounce means Microsoft 365 rejected your message because it arrived without a valid From email address in the header. The full text is Access denied, message must be RFC 5322 section 3.6.2 compliant, and per Microsoft it specifically means the message was sent without a valid From email address. This is a message-construction problem, not an authentication or reputation problem, so SPF, DKIM, and DMARC are irrelevant here. The fix is to make the sending system emit a properly formatted From header with a real mailbox, for example From: Alerts <alerts@yourdomain.com>.
What the 5.7.512 code means
Microsoft's NDR table defines 5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant as "Message was sent without a valid 'From' email address." This rejection is Office 365 only. Each message must contain a valid email address in the From header field, and proper formatting includes angle brackets around the address, for example <security@contoso.com>. Without an address in that format, Microsoft 365 / Office 365 rejects the message.
RFC 5322 section 3.6.2 is the "Originator Fields" section of the internet message format standard, and it defines the From field. The code is pointing you at exactly one thing: the message that reached Microsoft did not carry a well-formed From header. Either the header was missing entirely, or it held a value that is not a valid mailbox in the format the standard requires.
It helps to keep 5.7.512 separate from the authentication codes it is easy to confuse it with, because they have completely different fixes:
- 5.7.512 — the
Fromheader is missing or malformed. Fix how the sending system constructs the message. - 5.7.23 — the message failed SPF for the sender's domain. Fix your SPF record.
- 5.7.509 — the message failed DMARC under the domain's reject policy. Fix DMARC alignment.
A 5.7.512 is a header-format rejection. It is not an SPF failure, not a DMARC failure, and not a reputation ban, so chasing your DNS records will not clear it.
Why Outlook returns 5.7.512
Microsoft returns 5.7.512 when a message reaches it over SMTP with no usable From header. This almost never comes from a normal mail client, which always sets a proper From. It almost always comes from an automated sender that builds the message itself and skips or mangles the header. The common sources are:
- An application or script that sends mail through an SMTP library but never sets the
Fromfield, or sets it to a bare string that is not a valid address. - A device such as a scanner, printer, or monitoring system with a scan-to-email or alerting feature configured with a blank or placeholder sender.
- A CRM, helpdesk, or marketing tool that builds outbound mail from a template where the
Fromaddress was left empty or stored in the wrong field. - A custom mailer or notification service that emits a
Fromvalue without the required mailbox format — for example a display name with no address, or an address with no angle brackets where the surrounding software expects them.
Because the decision is made purely on the shape of the header Microsoft received, the fix is always on the sending side. Nothing about your domain's DNS, IP reputation, or authentication setup changes the outcome until the From header itself is valid.
How to diagnose a 5.7.512
Start by identifying which system sent the message. A 5.7.512 rarely comes from a person clicking send in a mail app, so the bounce points at automation: a script, a device, or a service. Read the full NDR and the message Received: headers to trace the originating host, then map that host to the application or device that runs on it.
Once you know the sender, inspect the actual From header that system emits. Capture a copy of the raw message it produces — most SMTP libraries and many devices can log the outgoing message, or you can send a test to a mailbox you control and view the source. Look at the literal From: line. You are checking for two failure modes: the header is absent, or its value is not a valid mailbox.
A valid value carries a real address and, for reliable interoperability, wraps that address in angle brackets, with an optional display name in front of it. So From: Alerts <alerts@yourdomain.com> is valid, and a bare alerts@yourdomain.com is usually accepted, while an empty header, a display name with no address, or a malformed token is what trips 5.7.512.
This is not an authentication check, so do not spend time on SPF, DKIM, or DMARC while diagnosing a 5.7.512. Those records can be perfect and the message will still bounce until the From header is well-formed. Confirming the header is the whole job.
How to fix a 5.7.512
The fix is to make the sending system emit a valid From header on every message. Work through the sender, not your DNS.
- Read the NDR and confirm the code is
5.7.512so you are solving the header-format problem and not an authentication failure. - Find the sending system — the application, script, device, or service that produced the bounced message — from the
Received:headers and the originating host. - Inspect the
Fromheader it emits by capturing the raw outgoing message, and confirm whether the header is missing or malformed. - Set a valid
Fromaddress with a real, properly formatted mailbox. Use angle brackets around the address and an optional display name, for exampleFrom: Alerts <alerts@yourdomain.com>. - If you send through an API or SMTP library, set the
Fromfield explicitly in code or configuration rather than relying on a default, and make sure the value is a complete address and not a bare display name or empty string. - For a device or service, fill in the sender / "mail from" / "from address" setting with a real mailbox on a domain you control, replacing any blank or placeholder value.
- Re-test by sending a single message to a mailbox you control, view the source to confirm the
From:line is now well-formed, and then send again to the original recipient.
What this does not prove
A 5.7.512 is decided entirely on the From header in the message Microsoft received, so a clean bill of health on your domain's public records tells you nothing about it. Your SPF, DKIM, and DMARC can all be correct and the message will still be rejected until the sending system emits a valid From address. Conversely, fixing the From header does not fix any separate authentication or reputation problem you may have.
A public DNS and authentication check confirms whether your domain's records are in order; it cannot see the From header a specific application or device emits, cannot read the raw message that bounced, and cannot reconstruct how your sending system builds its mail. The header lives in the sending system, so that is where both the diagnosis and the fix have to happen.