550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.26: “Multiple authentication checks failed” in the IANA registry (RFC 7372), in the group security or policy status (RFC 3463 §3.8).

A 5.7.26 bounce means your message did not authenticate: neither SPF nor DKIM passed, or your domain's DMARC policy told the receiver to reject mail that fails. To the receiver, it looks like it may not come from you.

What it means

RFC 7372 §3.4 defines X.7.26, "multiple authentication checks failed", for a message that failed more than one check, such as SPF and DKIM together. With 550 in front the refusal is permanent: sending the same message from the same setup will fail again.

Common causes

• The message is not DKIM signed, and the sending server is not in your SPF record.
• SPF hard fails: your record explicitly rejects any server it does not list, and the sending IP is not listed.
• DKIM is present but broken (wrong key in DNS, or the message changed after signing).
• Your domain publishes a DMARC reject policy, and the passing SPF or DKIM domain does not match your From: domain.
• Someone is spoofing your domain, and the receiver did its job.

How providers use it

Gmail uses this code family in three ways (Google's SMTP error reference):

• 550 5.7.26: unauthenticated (no SPF or DKIM pass), an SPF hard fail, or a rejection under the domain's DMARC policy.
• 421 4.7.26: unauthenticated mail, rate limited rather than blocked.
• 451 4.7.26: DMARC requires authentication, but DNS lookups failed temporarily, so the receiver will retry.

Microsoft uses 4.7.26 when mail sent over IPv6 passes neither SPF nor DKIM, and has its own code for a DMARC reject, 5.7.509 (Exchange Online NDR reference).

How to fix it

1. Open the bounce, or a delivered copy's Authentication-Results header, to see which check failed.
2. SPF: check the record with the SPF checker and add every service that sends as your domain.
3. DKIM: turn on signing in each sending service and publish its key. Check it with the DKIM checker.
4. DMARC: check your policy with the DMARC checker. For DMARC to pass, SPF or DKIM must pass for a domain that matches the From: address (see 5.7.32).
5. Bulk senders to Gmail need SPF, DKIM and DMARC together, per Google's sender guidelines.
6. Resend after the DNS changes are live.

What to do with the address

Keep it. This bounce is about your domain's authentication, not the recipient's mailbox.

Related codes

• 550 5.7.23: SPF validation failed
• 550 5.7.30: DKIM failed for a bulk sender (Gmail)
• 5.7.509: DMARC failed and the domain’s policy is reject (Microsoft 365)
• 5.7.32: From: domain not aligned with SPF or DKIM (Gmail)

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.