SMTP 550 5.7.26 Unauthenticated Email: SPF, DKIM and DMARC Fix

Gmail returns 550 5.7.26 when a message fails its authentication checks badly enough to be refused outright. Google's sender guidelines say that unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error". The bounce begins like this:

550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked.

The rest of the text lists which checks failed: SPF, DKIM, or both, and for SPF which IP it saw. Always read that part, because it points straight at the repair. Google's exact wording changes over time, so treat the text of your own bounce as the source of truth.

Other receivers use different codes for the same problem. Outlook.com and Hotmail return 550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level, which Microsoft documents for high-volume senders. Mailbox providers that enforce a domain's published DMARC reject policy tend to bounce failing mail with 5.7.x text that mentions DMARC; the wording varies, so check the provider's current documentation.

Why it happens now

Since February 2024, Google requires senders of more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, to align the From domain with the SPF or DKIM domain, and to support one-click unsubscribe for marketing mail. The DMARC policy may be p=none. Microsoft documents a similar rule for its consumer mail services: about 5,000 messages or more, with SPF, DKIM and DMARC. Senders below those volumes can still be rejected when mail fails every check.

Decision order

1. Read which checks failed in the bounce text.
2. Look at a real message's Authentication-Results header (Gmail: Show original).
3. Check SPF includes every system that sends as your domain.
4. Check DKIM signing is on, for your domain, with a published key.
5. Check DMARC alignment between the From domain and the SPF or DKIM domain.
6. Think about forwarding and mailing lists, which can break otherwise valid mail.

Step 1: inspect the headers

Send a test message to a Gmail address you control, open it, choose Show original, and read:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=mail header.b=abc123;
       spf=pass (google.com: domain of bounce@mail.example.com designates 203.0.113.9 as permitted sender) smtp.mailfrom=bounce@mail.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

You need spf=pass or dkim=pass, and the passing domain must match (align with) the header.from domain for DMARC to pass. A DKIM pass for d=sendgrid.net while the From is example.com is not aligned. The same is true for an SPF pass on a return-path domain that belongs to your email provider.

Step 2: repair SPF

dig +short TXT example.com

Look for one v=spf1 record. Two records, a missing sender, or more than 10 DNS lookups all cause SPF to fail. Paste the domain into the SPF रिकॉर्ड चेकर. If it reports too many lookups, read fix SPF too many DNS lookups. The sending IP shown in the bounce must be covered by an ip4:, ip6:, include: or a/mx mechanism.

The SPF and DMARC Generator can build a clean record from the senders you list.

Step 3: repair DKIM

DKIM needs a public key in DNS and a private key signing outgoing mail. Verify the published key:

dig +short TXT mail._domainkey.example.com

Replace mail with the selector from the DKIM-Signature header (s=). If the answer is empty, the DNS record is missing or on the wrong name. If you run your own signer such as OpenDKIM:

opendkim-testkey -d example.com -s mail -vvv

Google states DKIM keys must be at least 1024 bits, and recommends 2048 bits if your provider supports it. Full setup is in DKIM setup and troubleshooting.

Step 4: publish DMARC

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Start with p=none and read the aggregate reports, then move to quarantine and reject once all legitimate senders align. The staged approach is in DMARC rollout, with background in SPF, DKIM and DMARC explained.

Step 5: third-party senders

Most real-world 5.7.26 cases come from a vendor sending as your domain: a CRM, a ticketing system, a newsletter tool. For each, make sure it uses your domain in the return-path or signs with a DKIM key for your domain, and that you added the include it asks for. Microsoft's guidance for its 5.7.515 error says the same: the service must use your domain in the envelope sender, sign with your key, and be authorized in SPF.

Step 6: forwarding and lists

Forwarding changes the connecting IP, so SPF fails for the forwarded copy, and a mailing list that edits the subject or footer can break the DKIM signature. DMARC passes if either SPF or DKIM passes and aligns, which is why DKIM is the more robust choice. Make sure every system you control signs mail.

How to verify

Resend a message to Gmail and confirm dkim=pass, spf=pass and dmarc=pass in Show original. Then use the ईमेल डिलीवरेबिलिटी टेस्ट for a broader view, and re-run the Email DNS Checker after record changes. DNS caching can delay changes; see how long DNS propagation takes.

अगले कदम

• Check your sending domain with the SPF रिकॉर्ड चेकर.
• Read SPF, DKIM and DMARC explained.
• See SMTP 550 5.7.1 rejected for reputation-based refusals.
• सीखें email going to spam fixes if mail is accepted but filtered.

सामान्य प्रश्न

Is 5.7.26 about spam content?

No. It is about authentication. A message with perfect content is still rejected if SPF and DKIM both fail.

Do I need to publish a strict DMARC policy?

For Google's bulk sender rules, p=none is allowed. A stronger policy protects your domain from spoofing but is a separate decision.

Why did it start suddenly?

Receiver enforcement tightened, or a vendor changed their sending IPs or DKIM setup. Compare the failing message's headers with an older passing one.

Can I fix this only on the receiving side?

No. The sender controls the DNS records and signing. Recipients can only ask the sender to fix them.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.