Three addresses you have to keep apart
A single send carries three different identities, and this message appears when two of them disagree:
- The signed-in account — what your program identified with at the server.
- The envelope sender (
MAIL FROM) — where non-delivery reports go. - The From header — what the recipient sees.
Microsoft 365 requires the signed-in account to be allowed to carry the From header. Without that permission you get 5.7.60 — regardless of whether SPF and DKIM are fine.
The typical triggers
- Sending from a shared mailbox. An employee signs in with their own account and sets
info@as the sender. Without the “Send As” permission on the shared mailbox this is refused. “Send on behalf of” does not cover it — that writes a visibleSender:header and is something else. - An application with a service account. A monitoring system, an ERP or a web form signs in with a technical account but wants to send as
noreply@. The same missing permission. - Alias instead of mailbox. An alias is not its own sending identity. Many environments do not allow sending under a secondary address without explicit configuration.
- The wrong submission path. Sending under a foreign domain does not belong on the authenticated submission server; it needs a connector set up for it — the server then no longer checks the sender identity against an account.
Why SPF does not help here
A valid SPF record permits an IP to send for a domain. It says nothing about which signed-in account may carry which sender address. These are independent layers: SPF governs the handover between servers, the Send As permission governs access inside a tenant. That is why 5.7.60 persists even with a flawless SPF record — and why loosening that record is the wrong reflex here.
After granting the permission
Permission changes do not take effect instantly; in hosted environments propagation can take up to an hour. Anyone who retests right after setting it and sees the same message has usually done nothing wrong — they measured too early.