Deliverability and authentication
Diagnose email authentication failures and bounce codes
Map SMTP evidence to identity, policy, reputation or recipient problems.
Map SMTP evidence to identity, policy, reputation or recipient problems. The safest starting point is to understand who controls the domain, what people need from email each day, and which parts must keep working while the change is made. DMARC.org, Cloudflare
A simple plan you can follow
Work through these steps in order
- 1
Save the complete bounce
Keep the code, text, recipient provider, time and original message ID.
- 2
Group similar failures
Separate invalid recipients from authentication, rate, policy and temporary errors.
- 3
Check the matching layer
Inspect DNS only for identity failures; inspect list quality for bad recipients.
- 4
Retest one case
Make a controlled correction and send to a suitable test recipient.
| Option | Good choice when | Check before deciding |
|---|---|---|
| Keep the current setup | The problem is temporary and the present provider still meets the team's daily needs | Confirm the same failure will not return after the immediate fix |
| deliverability platform | Its specialist features matter more than a simpler mailbox and migration experience | Check pricing, support, exports and the exact email authentication failed requirement |
| Venmail | The team wants custom-domain mail, guided setup and a clear migration path | Choose another provider when a full office suite or infrastructure-only API is the main need |
Before you call the job finished
- Full error text is saved
- Temporary and permanent failures are separated
- The correct team owns the fix
- A controlled retest passes
- Repeated bad recipients are suppressed
Receiver wording can vary across providers and languages. Preserve the original text and code, then use the provider's official documentation when available.
A practical workflow you can start for free
Create a free incident sheet with columns for time, sender, recipient provider, status code and next action. Keep a safe message ID from Venmail when available. The word authentication may refer to SMTP credentials or to sender-domain checks; those need different fixes. checkdmarc
Try it on a small example
- 1
Read the complete error
An SMTP login rejection points toward connection credentials. A receiver's domain-policy rejection points toward the sending identity or policy. Do not replace DNS to fix a wrong password.
- 2
Retest the same layer
After the specific correction, use a new controlled message and compare the result. Preserve the original error so support can see what changed.
Use the bounce and the received header for different questions
A bounce describes a rejected delivery attempt. Authentication-Results belongs to a received message and may describe a different attempt or the bounce notification itself. Use the free Venmail Email Header Analyzer linked below for a received test; keep the full SMTP response as separate evidence.
| Evidence | What it can tell you | Practical next action |
|---|---|---|
| 535 plus an authentication-credentials error | The SMTP login attempt was rejected. This is not a DMARC result. | Verify the sending application’s credentials and provider-required connection settings. |
| 550 plus a sender-domain authentication rejection | This receiving server rejected the attempt under its policy. The response text matters. | Check the domain and authentication requirement named in the response; retain the timestamp and a safe message reference. |
| A received test reports dmarc=fail | That receiver reports a DMARC failure for this received message. | Confirm it is the same sender route as the failed attempt, then investigate alignment and signing. |
| A received test reports temperror | A temporary authentication evaluation problem was reported. | Retest later and consult the provider if it persists instead of repeatedly editing DNS. |
Response wording and enhanced status codes vary by provider. Do not diagnose from the three-digit number alone. The analyzer does not parse a bounce body or promise to identify the cause of a rejected message. RFC Editor, Google
Before sending your support note
- Separate the original rejection from the later received test.
- Include the exact response text in your private incident record.
- Use the tool’s private summary for authentication status; share full headers only through an appropriate support channel.
- After correcting one cause, send a new controlled test and record the outcome.
Ready for the next practical step?
Read a received message’s reported SPF, DKIM and DMARC results. No account or upload required.
Open the free email header analyzerRelated practical guides
Email deliverability services: platform, specialist or agency?
Diagnose the failure first, then hire the right kind of help.
Read the guideWhen to hire an email deliverability specialist
Know which evidence and access a credible specialist should request.
Read the guideSources and review method
Venmail publishes this guide and may be one of the products discussed. We compare providers on consistent dimensions, link to primary documentation and state non-fit cases. Product limits and pricing should be rechecked before purchase.
- DMARC.org: DMARC overview
- Cloudflare: DMARC management
- Amazon Web Services: Creating and verifying identities
- Venmail: Current plans and free workspace features
- checkdmarc: Free SPF and DMARC analysis utility
- RFC Editor: RFC 8601: Authentication-Results and trust boundaries
- Google: Email sender guidelines