Gmail 550 5.7.30: DKIM Authentication Failed

What the bounce says

Google documents this one clearly. The message attached to the code is:

550 5.7.30 This message was blocked because it didn't pass DKIM
authentication. Gmail requires bulk email senders to authenticate.

A 5xx code is permanent. Gmail is not deferring your message for later, it is refusing it. Nothing will retry into a successful delivery.

What DKIM actually is

DKIM stands for DomainKeys Identified Mail, and it is simpler than the name suggests.

Your mail server holds a private key. When it sends a message it signs the headers and body with that key and attaches the signature to the message. You publish the matching public key in DNS on your domain. When Gmail receives the message, it fetches your public key, checks the signature, and learns two things at once.

First, that the message really was sent by something authorised to sign for your domain. Second, that the content was not altered in transit. If someone changed the message on the way, the signature no longer matches and the check fails.

That is the whole idea. A cryptographic signature, a public key in DNS, and a receiver that can verify both. Our DKIM explainer goes into more detail.

Why SPF passing is not enough

This is where owners get stuck. SPF is green, the domain has been sending for years, and Gmail is still rejecting the mail.

SPF and DKIM answer different questions. SPF asks whether the server that connected is on your approved list. DKIM asks whether the message itself carries a valid signature from your domain. SPF says nothing about the content, and it breaks whenever a message is forwarded, because the forwarding server is not on your list.

DKIM survives forwarding, because the signature travels with the message. That is exactly why bulk senders are required to have it. At volume, Gmail wants a signal that does not fall apart the moment a mailing list or a corporate forwarder touches the message.

So for bulk senders it is not SPF or DKIM. It is SPF and DKIM and DMARC, all three.

Alignment, the step people skip

Having DKIM is not the same as having DKIM that helps you.

Gmail requires bulk senders to have a From: header that aligns with either the SPF domain or the DKIM domain. If your From: address is on your own domain but your sending platform signs with its own domain, you have a valid signature that does not align, and DMARC still fails.

Every serious sending platform supports signing with your domain instead of theirs. It is usually described as domain authentication, custom domain, or branded sending, and it is a handful of DNS records. Do that rather than accepting the platform's default signing domain.

Getting DKIM working

The order below is the same regardless of which platform you send through.

1.Find the DKIM setting in your mail platform. Google Workspace, Microsoft 365, and every reputable sending service have one. Do not try to generate keys yourself.
2.Generate the key pair there and choose the selector when prompted. A selector is just a label, which lets you have more than one key on the same domain and rotate between them.
3.Publish the DNS record the platform gives you, exactly as given, on the selector hostname it specifies. This is a TXT record containing the public key.
4.Use at least a 2048-bit key. The documented minimum is 1024-bit, and 2048-bit is recommended. If your DNS provider struggles with the longer record, that is a reason to fix the DNS, not to drop to 1024.
5.Turn signing on in the platform once the record has propagated. Publishing the key does nothing on its own. The platform has to actually start signing.
6.Do the same for every service that sends as you, then confirm each one signs with your domain rather than theirs. Our fix guides cover the common setups.

Checking it worked

Send a message to a Gmail address you control and look at the message headers. The Authentication-Results header tells you the outcome of every check in one line.

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass (p=REJECT) header.from=example.com

You want dkim=pass, and you want the domain after header.i to be your own domain, not your sending platform's. If it says dkim=none, the platform is not signing. If it says dkim=fail, the published key does not match the one being used to sign.

The 2026 context

Do not treat this as something to get to next quarter. Google's own statement on enforcement:

Starting November 2025, Gmail is ramping up its enforcement on
non-compliant traffic. Messages that fail to meet the email sender
requirements will experience disruptions, including temporary and
permanent rejections.

Permanent rejection is what you are seeing. This is no longer a deliverability problem where mail lands in spam. The mail simply does not arrive.

One thing that catches people out

Bulk sender obligations do not lapse. Google states that bulk sender status doesn't have an expiration date.

If you crossed roughly 5,000 messages a day to personal Gmail addresses once, during a launch or a seasonal campaign, you do not get released from the requirements by going quiet afterwards. Owners assume it resets. It does not.

The practical answer is to set up SPF, DKIM and DMARC properly once, keep alignment correct, and stop worrying about which side of the threshold you are on. See the 550 5.7.26 page for the full requirements list.

Frequently asked questions

What is the difference between 5.7.30 and 5.7.26?

The 5.7.30 code points specifically at DKIM: the message did not pass DKIM authentication and you are being treated as a bulk sender. The 5.7.26 code is broader, covering both a failed DMARC policy and having no SPF or DKIM at all. If you see 5.7.30, go straight to DKIM signing.

Can I just fix SPF instead?

Not for this bounce. Bulk senders need SPF and DKIM and DMARC together, so a passing SPF record does not satisfy the DKIM requirement. There is also a practical reason: SPF breaks when mail is forwarded, while a DKIM signature travels with the message and survives.

What key length should I use?

The documented minimum is 1024-bit and 2048-bit is recommended, so use 2048-bit. Some older DNS interfaces struggle with the longer TXT record. If yours does, split the record according to your provider's instructions rather than dropping the key length.

Do I need to generate the keys myself?

No, and you should not. DKIM is configured through your email provider or sending platform, which generates the key pair and hands you the exact DNS record to publish. Your job is to publish that record and turn signing on. Hand-rolled keys are a common source of mismatches.

DKIM passes but Gmail still rejects. Why?

Check alignment. Your From: domain has to align with the DKIM domain or the SPF domain. A signature from your sending platform's own domain is technically valid but does not align with your From: address, so DMARC still fails. Configure the platform to sign with your domain instead.