Fix Gmail 550-5.7.1 unauthenticated email

Confirm the exact 550-5.7.1 wording

The 550-5.7.1 code family can accompany more than one Gmail policy rejection. Use this page when the explanatory text names unauthenticated email, failed authentication, or the sender domain's DMARC policy.

The rejection happens during SMTP, so the message never reaches the recipient's inbox or Spam folder. Keep the complete response because the text identifies which authentication path Gmail rejected.

• The message bounced with a different Gmail response — start with the general SMTP rejection workflow
• There was no bounce and the message landed in spam — diagnose placement and reputation instead

Identify the three domains involved

Record the visible From domain, the envelope sender or Return-Path domain used for SPF, and the d= signing domain used by DKIM. They may be different when a CRM, support platform, or marketing provider sends on your behalf.

DMARC does not require every domain to be identical. It requires at least one successful authentication path whose domain aligns with the visible From domain.

Check the SPF authentication path

Verify that the real sending IP is authorised by the SPF record for the envelope sender domain. Confirm there is one valid SPF policy and that the provider actually uses the MAIL FROM domain you expect.

An SPF pass is not enough for DMARC when the authenticated envelope domain does not align with the visible From domain. Configure a custom return path or another provider-supported aligned MAIL FROM when SPF is the intended path.

Check the DKIM authentication path

Read the selector and d= domain from the DKIM-Signature used by the real message. Verify that the selector resolves, the public key is valid, and the sending platform signs with the matching private key.

A cryptographically valid DKIM signature still cannot satisfy DMARC when its d= domain does not align with the visible From domain. Enable provider support for signing with your own domain when DKIM is the intended aligned path.

Verify DMARC alignment and policy

Check the DMARC record on the visible From domain. Determine whether SPF or DKIM should provide the aligned pass and verify that path end to end.

Do not weaken a legitimate enforcement policy merely to hide the rejection. Correct the authorised sender and alignment first. Change policy only as part of a deliberate rollout based on known legitimate senders.

Apply and verify the fix

Confirm the real provider and sending IP, repair SPF authorisation or DKIM signing, restore alignment, and allow DNS changes to propagate. Send a new controlled message and compare the new authentication evidence with the original bounce.

When a test can be received, inspect Authentication-Results to confirm the expected SPF, DKIM, and DMARC identities. A DNS lookup alone cannot prove that the production sender is using the intended envelope and signing domains.