Gmail 550 5.7.26: what it means and how to fix it

The three messages behind the code

Google's Gmail SMTP errors and codes table lists three messages under 550 5.7.26, so read the text that follows the code in your bounce before you change anything.

Message 1: neither SPF nor DKIM passed.

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass.

Message 2: SPF hard fail.

The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [ip-address]. To best protect our users from spam and phishing, the message has been blocked.

Message 3: your DMARC policy.

Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. Contact the administrator of domain-name domain if this was legitimate email.

Google's DMARC troubleshooting guide shows the third message with slightly different wording, and says of it: "The DMARC policy for your domain is causing this issue." The domain in the message is the one to look at, and the IP address, where shown, is the server that sent the message to Gmail.

Gmail applies this to all senders, not only large ones. Google's email sender guidelines require everyone sending to Gmail accounts to set up SPF or DKIM, and warn that unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error".

Who has to fix it

The fix belongs to whoever controls the sending domain's DNS or its mail service, because the problem is in how the mail was authenticated. Google's third message says as much when it tells the reader to contact the domain's administrator.

• You sent an ordinary message from a mail app. Gmail Help suggests looking for the setting that controls your outgoing server and using "the server that matches the email address you want to send from". If that does not help, contact your email provider.
• You manage the domain. Keep reading.
• You never sent the message. A bounce can be the result of someone else using your domain: section 7.2 of RFC 9989 describes failure notices for fraudulent mail going to the envelope address. If your reports show the source is not yours, your policy did its job, and there is nothing to fix.

Find the cause, step by step

1. Copy the full bounce. Note which of the three messages it is, the domain it names and, if present, the IP address.
2. Work out which service sent the message. Your mailbox provider, a newsletter platform, a CRM and a contact form on your website are all different senders, and each needs its own authentication. The bounce usually comes back through the service that sent the mail.
3. Check your published records. Run the domain through the domain health check, or use the DMARC checker, SPF checker and DKIM checker one at a time. The DKIM checker probes common selectors, so a service with an unusual one may not show up; How to find your DKIM selector covers that case.
4. Read a real message's results. Google says email headers contain the results for SPF, DKIM and DMARC. Because Gmail refused this message, send one through the same service to another mailbox you control, then paste its headers into the email header analyzer. It shows whether the SPF and DKIM domains align with your From domain.
5. Check your reports. Google's guide says to check your DMARC reports to identify which outgoing messages don't pass. If your record has a rua address, upload a report from Google to the DMARC report analyzer and look for the source that fails. RFC 9990 reports carry the policy result for each source in disposition; How to read DMARC aggregate reports explains the fields.

Fix it by cause

Message 1: neither SPF nor DKIM passed

The sending service is not authenticating as your domain. Set up what is missing for that service:

• DKIM. Turn on DKIM signing in the service, using a key published under your domain. If you run your own server, the DKIM generator creates a key pair in your browser.
• SPF. Add the service to your one SPF record, as its documentation describes. The SPF generator builds a single record for all your senders.

Patchkit's setup guides list the records for common services, such as Google Workspace. Gmail's minimum for all senders is SPF or DKIM, but Google recommends always setting up both.

Message 2: SPF hard fail

The message names the envelope domain and the IP address that SPF rejected. Under RFC 7208, a fail is an explicit statement that the client is not authorized to use that domain. Run the SPF checker on the domain, then choose:

• If the IP belongs to a service you use, add that service to the SPF record.
• If the record looks right but still fails, check for a second SPF record or too many DNS lookups. Both make SPF fail for reasons unrelated to the IP.
• If the IP is not one you recognize, do not authorize it. Find out who is sending first.

Authorize the real sender rather than editing the ending of the record. Google's message mentions -all, but its documentation does not say that switching to ~all clears this error, and unauthenticated mail stays unauthenticated. SPF ~all vs -all covers that choice separately.

Message 3: your DMARC policy

To pass, Google says messages "must pass either SPF or DKIM", and its sender FAQ adds that the From domain must align with the SPF or DKIM organizational domain. So SPF can pass and this error can still appear, which is what DMARC fails even though SPF passes explains. There are three things to check:

• DKIM domain. Have the service sign with your domain, so that d= aligns with the From domain. One aligned pass is enough for DMARC.
• Envelope domain. If the service offers a custom return-path, set it to a subdomain of yours so that SPF can align too. Google recommends aligning both.
• Strict alignment. Google's guide warns that "a DMARC policy with strict alignment increases the likelihood that messages are rejected or sent to spam". If your record has adkim=s or aspf=s and a subdomain is what fails, remove the tag unless you need it for the reasons in DMARC alignment explained.

If you are unsure how the policy tags work, What is DMARC? and the DMARC record tags reference cover them.

If the message was forwarded

When a forwarding server relays your message, SPF will most likely fail, while DKIM signatures generally survive, according to section 7.4 of RFC 9989. Gmail's forwarding advice says the same in its own words: forwarded messages often fail SPF, and DKIM is especially important for them. So aligned DKIM is the sender's side of the fix. The rest belongs to whoever runs the forwarder, and Google asks them to avoid changing the body and the headers DKIM protects.

If real mail is bouncing right now

For message 3 only, you can buy time by lowering the policy while you fix the sender. Google's DMARC setup guide describes p=none as "take no action on the message and deliver it to the intended recipient", and RFC 9989 section 5.4 says a discovered p=none must not modify existing mail handling. Edit your existing record rather than adding a second one, and keep its rua tag:

• It stops protecting your domain from spoofing while it is in place, so treat it as temporary.
• Resolvers can keep serving the old record until its DNS TTL expires, so the change is not instant.
• Do not expect it to clear messages 1 and 2. Google ties only message 3 to your DMARC policy; the other two are about SPF and DKIM.

Do not count on t=y here. Google's setup guide still documents the older pct tag and does not mention t, so there is no Google documentation on how Gmail treats it. And with p=reject; t=y RFC 9989 still expects quarantine, which sends the mail to spam. When the fix is in, move back up in stages: Moving from p=none to p=reject has the plan.

Confirm the fix

1. Re-run the checker for whatever you changed, so you know the new record is what DNS now returns.
2. Send a new message through the same service to a Gmail address. A message that already bounced has to be sent again.
3. In Gmail, read the headers and look for pass results on SPF, DKIM and DMARC. Google's guide asks you to verify all three.
4. If you lowered your policy, Google says SPF and DKIM should be authenticating messages for at least 48 hours before turning on DMARC, so give them that long before raising it again.
5. Watch the following days of reports for other services with the same problem. A one-off upload to the report analyzer covers a single file; DMARC monitoring collects them for you.

Codes that look similar

Gmail uses neighbouring codes for related problems, listed in the same Google table. The checks above apply to these too, though the 4xx ones are temporary replies and do not mean a permanent rejection: