How to Fix Error 550 5.7.515 — Email Authentication via Google Workspace
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
:::error 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
:::info 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.
:::
:::info 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 |
:::error 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...
:::warning 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
:::info 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
:::warning 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
:::error 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.
:::warning 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>;
:::success 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.
:::
:::warning 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
- Set up DKIM — Google Workspace Admin Help
- Turn on DKIM for your domain — Google Workspace Admin Help
- Set up SPF — Google Workspace Admin Help
- Define your SPF record — Google Workspace Admin Help
- Add your DMARC record — Google Workspace Admin Help
- Recommended DMARC rollout — Google Workspace Admin Help
- Email sender guidelines — Google Workspace Admin Help
- Microsoft: Fix NDR error 550 5.7.515 — Outlook.com
Notes
- To connect a Gmail inbox to Cloud Chat: How to connect a Google email inbox to Cloud Chat
- To connect an Outlook inbox to Cloud Chat: How to connect an Outlook/Microsoft email inbox to Cloud Chat
- To understand how email attachments work: How email attachments work in Cloud Chat
