Home Others How to Fix Error 550 5.7.515 — Email Authentication via Google Workspace

How to Fix Error 550 5.7.515 — Email Authentication via Google Workspace

Last updated on Aug 03, 2026

When to use this

  • You use Google Workspace and the messages you send from Cloud Chat to Microsoft recipients (Outlook, Hotmail, Live, Microsoft 365) are being rejected with error 550 5.7.515
  • Sending directly from Gmail works, but sending from Cloud Chat (or any other third-party platform) fails
  • You need to configure SPF, DKIM, and DMARC aligned to your domain in order to meet Microsoft's requirements

Prerequisites

  • Super Admin access to Google Workspace (admin.google.com)
  • Access to your domain's DNS provider (Registro.br, Cloudflare, GoDaddy, AWS Route 53, etc.)
  • Gmail enabled on the domain for at least 24 to 72 hours before generating the DKIM key
  • Email inbox connected — see How to connect a Google email inbox to Cloud Chat

Replace SEUDOMINIO.COM.BR with your actual domain throughout this document. The examples use this placeholder for illustration only.

About this article

This error is not a Cloud Chat weakness — the same thing would happen with any customer service platform that sends emails on behalf of your domain.

When you send directly from Gmail, the message leaves Google's servers — which are already authorized in SPF and automatically sign DKIM with your domain. Everything passes.

When the email leaves through Cloud Chat (or any third-party platform), it comes from different servers, which are not in your domain's SPF and do not have access to its DKIM key. The result: SPF fails, DKIM does not align, DMARC does not pass, and Microsoft rejects the message with 550 5.7.515:

550 5.7.515 Access denied, sending domain SEUDOMINIO.COM.BR doesn't meet
the required authentication level. The sender's domain in the 5322.From
address doesn't meet the authentication requirements defined for the
sender. Spf=Fail , Dkim=Pass , DMARC=None

The root cause: the domain does not have SPF, DKIM, and DMARC properly configured. Sending directly from Gmail "hides" the problem because Google handles it automatically for its own servers. Any sending from outside exposes the gap.

This guide fixes that configuration in Google Workspace and at your DNS provider. Once applied, authentication passes both through Gmail and through Cloud Chat.

Diagnosis

Microsoft rejects your messages because there is no authentication aligned with the domain in the From: header. The bounce header usually shows:

  • SPF = Fail — the SPF record does not include _spf.google.com, or does not exist

  • DKIM = Pass, but without alignment — Google signs with d=gmail.com instead of d=<your-domain>. It technically passes, but it does not count toward DMARC

  • DMARC = None — no DMARC record is published

Since late 2024, Microsoft requires at least one authentication mechanism aligned with the From: header for high-volume senders (≥ 5,000 messages to outlook.com, hotmail.com, live.com, msn.com). If you are already getting this error, your domain has crossed that threshold.

About alignment: for DMARC to pass, only SPF or DKIM needs to be aligned. This guide configures both for greater reliability, but aligned DKIM (Step 2) is the main component.

Inspect the header of a bounced message

Before touching DNS, confirm the current state. Find a bounced message with code 550 5.7.515, open it in Gmail, and click Show original. Look for the Authentication-Results line:

Authentication-Results: ...
  spf=fail (sender IP is ...) smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=gmail.com;       ← d=gmail.com = NO alignment
  dmarc=none action=none header.from=<seu-dominio>;

If this is the pattern you see, follow this guide. If it is different (for example, SPF pass, DMARC quarantine), the investigation needs to go another way — open a support ticket.

Step by step

Step 1 — Publish the SPF record

At your DNS provider, publish (or update) a TXT record at the domain apex:

Field Value
Type TXT
Host / Name @ (or the domain itself)
Value v=spf1 include:_spf.google.com ~all
TTL 3600

There can only be one single SPF record per domain. If one already exists, edit it and merge the includes:

v=spf1 include:_spf.google.com include:outro-servico.com ~all

Verification:

dig TXT <seu-dominio> +short
# Should return a line containing v=spf1 include:_spf.google.com ~all

Step 2 — Configure DKIM in Google Workspace (main step)

This is the most important step. It makes Google sign your messages with d=<your-domain> instead of d=gmail.com, solving the alignment problem.

2.1 — Generate the DKIM key

  1. Go to admin.google.com as a Super Admin

  2. Go to Menu → Apps → Google Workspace → Gmail → Authenticate email

  3. Select your domain and click Generate new record

  4. Configure: 2048 bits, selector prefix: google

  5. Copy the two values shown:

    • DNS host name: google._domainkey

    • TXT value: a long text starting with v=DKIM1; k=rsa; p=MIIBIjAN...

Button disabled? Wait 24–72h after Gmail was enabled on the domain.

2.2 — Publish the DKIM record in DNS

Field Value
Type TXT
Host / Name google._domainkey
Value Text copied from the Admin console
TTL 3600

2.2.1 — CharacterStringTooLong error when publishing DKIM

Symptom

When publishing the google._domainkey TXT record, the provider shows an error similar to:

⚠️ An error occurred. Please try again later. CharacterStringTooLong (Value is too long) encountered with '"v=DKIM1; k=rsa; p=XXXXXXXX..."'

The record is not saved and DKIM authentication cannot be turned on.

Cause

RFC 1035 (section 3.3) limits each character-string in a TXT record to 255 characters. The 2048-bit RSA public key generated by Google Workspace exceeds that limit (≈400 characters), so the provider rejects it when the value is sent as a single string. It is not a problem with the key or with Google Workspace — it is a DNS protocol limitation.

Solution

Break the value into multiple strings of up to 255 characters, each one in double quotes and separated by a space. The DNS server automatically concatenates them on delivery, and the resolver sees a single continuous DKIM key.

Expected format:

"v=DKIM1; k=rsa; p=XXXXXXXXXXXXXXXXXXXXXXXXXXXX...ate_255_chars" "continuacao_ate_255_chars..." "parte_final_da_chave"

How to break up the key

  1. Paste the value copied from the Admin console (v=DKIM1; k=rsa; p=...) into a text editor

  2. Every 255 characters of content, insert " " (quote — space — quote)

  3. Wrap the entire value in double quotes at the beginning and at the end

  4. Paste the result into the Value / Content field of the TXT record

Tip: Do not count the outer quotes toward the 255 limit — only the string content.

Behavior by DNS provider:

Provider How to paste
Cloudflare Paste the already-split value with quotes and spaces into the Content field. The UI accepts it directly.
AWS Route 53 Paste the split strings with quotes into the Value field. Each string on a separate line also works.
Registro.br Multiple quoted strings on a single line.
GoDaddy / HostGator / others They accept the same format. If the UI refuses quotes, look for the raw or advanced option.

Verification

After saving and waiting for propagation (up to 30 minutes), validate:

dig TXT google._domainkey.<seu-dominio> +short

The output should show the concatenated key. If the response shows several separate strings, it is still valid — what matters is that the reconstructed RSA key is identical to the value in the Admin console. To confirm, compare the key returned by dig with the one from the generation step in Google Workspace.

2.3 — Turn on authentication

  1. Go back to Gmail → Authenticate email in the Admin console

  2. Click Start authentication

  3. Wait for the status to change to Authenticating email with DKIM

It can take up to 48 hours to start working.

Verification:

dig TXT google._domainkey.<seu-dominio> +short
# Should return the complete v=DKIM1; k=rsa; p=...

Step 3 — Publish the DMARC record

Only publish DMARC after SPF and DKIM have been authenticating correctly for at least 48 hours.

Field Value
Type TXT
Host / Name _dmarc
Value v=DMARC1; p=none; rua=mailto:dmarc-reports@<seu-dominio>; pct=100; adkim=s; aspf=s
TTL 3600

Create a mailbox or alias dmarc-reports@<seu-dominio> to receive the aggregate reports (XML) that providers send daily.

Hardening roadmap

Only move to the next phase after at least one week with no false positives in the reports.

Phase Week Policy Effect
1 — Monitoring 0 p=none Only generates reports
2 — Partial quarantine ≥ 1 p=quarantine; pct=10 10% of unauthenticated messages go to spam
3 — Full quarantine ≥ 2–3 p=quarantine; pct=100 All of them go to spam
4 — Rejection ≥ 4 p=reject; pct=100 The server rejects unauthenticated messages

Quick unblock (if it is urgent)

If you need to unblock sending to Microsoft recipients right away, publish only:

  1. Step 1 — the SPF record

  2. Step 3 — the DMARC record with p=none (without waiting the 48h for DKIM)

In most cases this alone ends the 550 5.7.515 error, because Microsoft specifically targets domains with no DMARC at all. Having a published DMARC (even a permissive one) already changes how you are treated.

Step 2 (aligned DKIM) is still the definitive fix and must be carried out afterwards — without it, SPF and DMARC rest on a fragile foundation.

Final verification

After propagation (30 min for SPF/DMARC, up to 48h for DKIM):

dig TXT <seu-dominio> +short                          # SPF
dig TXT google._domainkey.<seu-dominio> +short        # DKIM
dig TXT _dmarc.<seu-dominio> +short                   # DMARC

Functional test

Send a test email to any @outlook.com or @hotmail.com address or Microsoft 365 account. In the header of the received email, check:

Authentication-Results: ...
  spf=pass smtp.mailfrom=<seu-dominio>;
  dkim=pass header.d=<seu-dominio>;   ← proof of alignment
  dmarc=pass header.from=<seu-dominio>;

If all three lines show pass with header.d=<seu-dominio> and header.from=<seu-dominio>, the configuration is correct — the 550 5.7.515 error will not happen again.

If dkim=pass still shows header.d=gmail.com, Step 2.3 has not been completed yet or DNS is still propagating. Wait a few more hours and test again.

Official sources

Notes