The bounce export says “rejected.” The authentication test you ran this morning still says pass. Both can be true, because a pass only means the receiver agreed you are allowed to use that domain. It can still refuse the message for a different reason, and it will say so in the SMTP reply if you read the reply instead of the bounce percentage.
Last verified: 26 September 2026, against RFC 5321, RFC 3463, and Microsoft’s 550 5.7.515 article.
SMTP 2xx, 4xx, and 5xx: the three classes that matter first
RFC 5321 groups replies by the first digit:
| First digit | Name | What you do |
|---|---|---|
| 2xx | Positive completion | The server accepted the message. Inbox versus spam is a later question. |
| 4xx | Transient negative | Retry later. This is a deferral, not a dead address. |
| 5xx | Permanent negative | Do not keep repeating the same attempt unchanged. Then read why. |
The second digit narrows it. A x.1.x style problem is about the address. A x.2.x problem is about the mailbox system, including a full mailbox. A x.7.x problem is a policy. Those enhanced codes are defined in RFC 3463. The human sentence next to the number is part of the answer. Do not strip it off and keep only “550.”
A short map of common 4xx and 5xx codes
| What you see | How to treat it |
|---|---|
| 550 5.1.1, user unknown, mailbox not found | Hard bounce. Suppress that address. |
| 452 or 552, mailbox full, or a 4.2.2 | Temporary, unless it repeats for weeks. |
| 421, 450, 451, “try again”, “rate”, “greylist” | Deferral. Cut new volume if it is a wave. |
| 550 5.7.1 or similar policy text, authentication results still pass | The receiver is refusing you on policy or reputation, not on a missing SPF record. |
| 550 5.7.515 | Microsoft’s high-volume authentication rejection. Use the Outlook 550 5.7.515 guide. It is not a spam-folder event. |
Providers invent wording around these codes. If two lines in the same bounce disagree, prefer the provider’s own documentation for that exact code, then the SMTP text, then your ESP’s hard/soft label.
Authentication passed, and the mail was still rejected
SPF, DKIM, and DMARC answer a narrow question: was this message authorized for the visible From domain, under that receiver’s rules? They do not prove the mailbox exists. They do not remove a blocklist hit. They do not satisfy a volume or complaint policy the provider enforces separately.
A 5xx rejection with spf=pass and dkim=pass in the same conversation is a policy, reputation, or recipient decision, not a DNS problem. The exception is when the receiver evaluates authentication differently from your test, as Microsoft does for 5.7.515, so check the Authentication-Results header the receiver actually wrote before you rule DNS out:
- The recipient address is bad (5.1.1). Suppress the address, not the domain.
- The receiving system is applying a block or a rate policy (often 5.7.x or a 4xx rate reply). Fix the cause named in the text. A blocklist listing is one cause. It is not the only one, and a listing does not by itself mean the mail that did get through went to spam.
- You are looking at Microsoft’s 5.7.515, which means the high-volume From domain did not meet Outlook’s authentication bar. That article is the procedure. Do not “fix” it by deleting customers.
Gmail’s bulk-sender rules can also end in SMTP rejection for non-compliant mail. That is a requirement failure, distinct from a spam-folder placement of mail that was accepted. The Gmail troubleshooting guide separates those. This page stops at the code.
Why the error shows up before reputation does
Reputation dashboards summarize mail that was sent and, for Gmail’s spam rate, mail that reached an engaged inbox and was marked spam. A 5xx rejection never becomes that click. A 4xx throttle is the provider slowing you before it bothers to file anything. Waiting for a Postmaster reputation card to drop from High to Low will make you late. Google has said those cards will be retired and has not given a date. The response code is already the incident.
If the same code hits every provider in the same hour, look at a shared change: a new IP, a DNS edit, a list import. If it hits one provider, stay on that provider’s page. Provider-specific placement is the router once you are sure the mail was accepted. Until then, stay in the bounce log.
InboxEagle
Read what the receiver actually wrote
Paste the bounce notice or the message headers into the analyzer. It shows the Authentication-Results the receiver recorded and the hop that refused the mail, so you know whether a 5xx is about you or the address.
Sources
- SMTP, RFC 5321. Reply code classes.
- Enhanced mail system status codes, RFC 3463. What the second and third digits mean.
- Fix NDR 550 5.7.515, Microsoft. A permanent rejection for high-volume From domains, not a spam-folder placement.
- Email sender guidelines, Google. Bulk-sender requirements, which can end in rejection rather than filing.