Enhanced Status Code 5.7.32: From Header Not Aligned with SPF or DKIM
Enhanced Status Code 5.7.32 means “From Header Not Aligned with SPF or DKIM.” SPF or DKIM passed, but for a different domain than the one in the visible From header. Alignment is what DMARC actually tests, and passing the underlying check is not enough on its own.
550 5.7.32 Message blocked. The From header is not aligned with SPF or DKIM authentication
What does 5.7.32 mean?
Google returns 5.7.32 when a message is blocked because the From header is not aligned with SPF or DKIM. It is not an IANA-registered code; it belongs to the set Google introduced with its February 2024 sender requirements. It describes the failure mode that surprises people most, because every individual check appears to pass.
Alignment is the requirement that the domain which passed authentication matches the domain your recipient sees. SPF authenticates the envelope sender, the MAIL FROM address, which is often a bounce domain belonging to your sending platform. DKIM authenticates whatever domain signed the message, which is often the platform's own domain rather than yours. Either can pass cleanly while the From header shows your brand, and DMARC then fails because neither passing domain matches it.
This is the single most common reason a sender who has configured SPF and DKIM correctly still fails DMARC. The fix is not to add authentication, it is to make the authentication belong to your domain: a custom return-path on a subdomain you control so SPF aligns, and DKIM signing with your own domain and selector rather than the platform's shared one. Most platforms support both and many do not enable them by default.
How 5.7.32 plays out
5.7.32 rejectionWhere 5.7.32 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.7.32 is | ✓ this code |
What each provider means by 5.7.32
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.7.32
- The platform signs with its own DKIM domain rather than yours
- The envelope sender uses the platform bounce domain, so SPF authenticates that instead of yours
- A custom return-path was never configured on the sending platform
- DKIM uses relaxed alignment but the signing domain is not even a parent of the From domain
- The From header was changed to a different domain after the platform was set up
- Mail is relayed through a service that re-writes the envelope sender without signing as you
How to fix 5.7.32
- Configure a custom return-path on a subdomain you control so SPF aligns with From
- Enable DKIM signing with your own domain and selector rather than the platform default
- Read the Authentication-Results header and compare the spf and dkim domains to the From domain
- Check DMARC aggregate reports, which show alignment separately from pass and fail
- Repeat this for every platform sending as your domain, since each aligns independently
- Use relaxed alignment if you sign with a subdomain, but confirm the organisational domain matches