Fix Gmail 5.7.26 & Outlook 550 5.7.515 rejections

When Gmail or Outlook rejects a message with a 5.7.x code, the mail was delivered to their edge and refused on purpose — this is not a full mailbox or a typo in the address. The provider evaluated your authentication, found it insufficient for the volume or policy involved, and bounced the message back. The fix lives in your DNS and your sending configuration, not in the recipient’s inbox. Below, the two most common provider-specific rejections and the exact steps to clear them.

What Gmail 5.7.26 actually means

A bounce that reads something like 550-5.7.26 This mail has been blocked because the sender is unauthenticated is Gmail telling you the message failed authentication for your From: domain. Since Google enforced its bulk-sender rules in early 2024, mail to Gmail users must pass SPF or DKIM — and for bulk senders, must have a valid, aligned DMARC record. "Aligned" is the operative word: the domain that passes SPF or DKIM has to match the domain in the visible From: address.

The trap most senders fall into: you route mail through a platform, SPF passes for the platform’s return-path and DKIM is signed with the platform’s key, so both look green — yet Gmail still rejects, because neither passing domain matches your From:. Unaligned passes don’t satisfy DMARC, and 5.7.26 is the result.

What Outlook 550 5.7.515 means

Microsoft’s 550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level is the Outlook.com / Hotmail equivalent. Microsoft began enforcing authentication requirements for high-volume senders to consumer mailboxes, and 5.7.515 is what you get when your domain sends bulk mail without compliant SPF, DKIM and DMARC. The message is a policy rejection: your mail is authenticated too weakly for the volume Microsoft is seeing from you. As with Gmail, the cure is proper authentication with alignment on your own domain — not a support ticket asking to be let through.

Why it’s (almost) always an alignment problem

Both errors share a root cause more often than any other: SPF and DKIM technically pass, but they authenticate a domain other than the one your recipients see. DMARC only counts a check as a pass when the authenticated domain aligns with the From: domain. So you can have a perfect-looking SPF record and a valid DKIM signature and still be "unauthenticated" in Gmail’s and Microsoft’s eyes.

Three things must be true:

1. SPF passes and aligns. The return-path (envelope-from) domain should be a subdomain of, or match, your From: domain. Platforms give you a custom Return-Path (usually a CNAME) to make this align.
2. DKIM passes and aligns. The d= tag in the DKIM signature should match your From: domain. Configure the platform to sign with a selector on your domain, using the DNS record it provides.
3. DMARC is published. At minimum v=DMARC1; p=none, so a DMARC policy exists for the receiver to evaluate. One aligned pass (SPF or DKIM) is enough for DMARC to pass.

The exact DNS fixes

Work through these in order and re-check after each change (DNS can take up to a few hours to propagate):

• SPF. Publish a single TXT record at your domain root: v=spf1 include:_spf.yourplatform.com ~all. Include every service that sends on your behalf, stay under the 10-DNS-lookup limit, and keep exactly one SPF record. Verify with the SPF Checker.
• DKIM. Add the selector record your platform gives you (e.g. selector1._domainkey.yourdomain) and confirm the signature’s d= is your domain. Verify with the DKIM Checker.
• DMARC. Publish _dmarc.yourdomain TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain" to start. Verify with the DMARC Checker, and if you don’t have one yet, build it with the DMARC Generator.

If you send through a marketing platform, the alignment step is where the fix usually lives: set up the custom Return-Path (SPF alignment) and the branded DKIM signing (DKIM alignment) the platform documents. Once one of them aligns to your From: domain, both Gmail 5.7.26 and Outlook 5.7.515 clear.

Verify the fix before you resend

Don’t guess — confirm it end to end. Send a real message from your production setup to the Email Deliverability Test; it reports the actual SPF, DKIM and DMARC results and whether each aligns to your From: domain, which is exactly what the receivers evaluate. For an at-a-glance view of your domain’s records, run the Email Health Check. Once alignment is green, start monitoring aggregate reports via DMARC monitoring so a broken sender shows up in your dashboard before Gmail or Outlook rejects it again.

When it isn’t alignment

• Reputation, not authentication. If auth is fully aligned but you’re still throttled or filtered, the issue has moved to reputation and complaints — see check and repair your sender reputation and keep complaints under 0.3% (ideally <0.1%).
• You’re on a blacklist. A 5.7.1 or provider block referencing an RBL is a listing problem — work through avoiding email blacklists and getting delisted.
• Bounces with other codes. If the number isn’t 5.7.26 or 5.7.515, decode it with common SMTP bounce codes explained, and clean your list to cut hard bounces with the Email Verifier — see reduce your email bounce rate.

The canonical references worth bookmarking: Google’s sender guidelines, Microsoft’s Smart Network Data Services and postmaster pages, and the DMARC specification itself, RFC 7489. For the underlying concepts, our SPF, DKIM & DMARC guide walks through each record in depth.