5.7.32

Enhanced Status Code 5.7.32: From Header Not Aligned with SPF or DKIM

Permanent failure Critical severity Authentication RFC 7489
What it means

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.

At a glance
Code5.7.32
Bounce typeHard (permanent)
SeverityCritical
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7489
What it looks like in your mail logs
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

Your server attempts delivery
The recipient server returns a permanent 5.7.32 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.32 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
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.

Gmail Message blocked because the From header is not aligned with SPF or DKIM Reference

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

Frequently asked questions

What does 550 5.7.32 mean?
It means Gmail blocked the message because the From header is not aligned with the domain that passed SPF or DKIM. Authentication succeeded, but for a domain other than the one your recipient sees, so DMARC fails. This is why a sender can have working SPF and working DKIM and still be rejected.
What is DMARC alignment in plain terms?
It is the requirement that the domain which passed authentication is the same domain shown in the From header. SPF authenticates the envelope sender and DKIM authenticates the signing domain; neither is necessarily the domain your recipient reads. DMARC passes only when at least one of them matches From. Alignment, not authentication, is what DMARC actually tests.
How do I fix alignment on a sending platform?
Two changes, and most platforms support both. Configure a custom return-path, usually a CNAME on a subdomain like bounce.yourdomain.com, so the envelope sender belongs to you and SPF aligns. Then enable DKIM signing with your own domain and selector instead of the platform shared key. Many platforms leave both switched off by default.
Why do my headers show spf=pass and dkim=pass but DMARC still fails?
Because the passes belong to the wrong domain. Look at the domain named beside each result in the Authentication-Results header and compare it to your From domain. If SPF passed for the platform bounce domain and DKIM signed as the platform domain, neither aligns with your From header and DMARC fails despite two green results.
Does strict or relaxed alignment matter here?
Relaxed is the default and it accepts a subdomain of the organisational domain, which is why signing as mail.yourdomain.com aligns with yourdomain.com. Strict requires an exact match. If you have set aspf=s or adkim=s in your DMARC record, a subdomain that would otherwise align will fail, so check those tags before changing anything else.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes