SMTP authentication failed: checklist for custom domain send-as

Quick answer for SMTP authentication failed

SMTP AUTH is the login step in IETF RFC 5321 — Simple Mail Transfer Protocol. The client presents a username and secret, usually over STARTTLS or implicit TLS. If that handshake fails, you have smtp authentication failed. If the handshake succeeds and the server later returns 550 5.7.1, you have an identity or plan refuse. Those two screenshots look similar in a WordPress plugin. They are not the same hop.

MailerZ send-as is Off on Free. Solo is $40 per year only, with SMTP On and API Enabled. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99 monthly or $990 yearly. Confirm numbers on MailerZ pricing. Those ceilings are not an inbox-placement promise. A Free domain that still tries AUTH will fail for a boring reason: the product will not accept the session.

The safe sequence is short. Name the client. Copy the dashboard host, port, and TLS together. Paste the SMTP username and secret the dashboard issued. Set Header From to an identity you created on that domain. Submit one message to a mailbox you do not control. If AUTH still fails, you have a pair, TLS, or plan problem. If AUTH passes and DATA is refused, stop calling it authentication failed.

Inbound leftover MX is a hard stop for Gmail confirmation mail, not for the password itself. Mixed aspmx plus MailerZ MX can make Send mail as look broken while Outlook AUTH already works. Split those tickets. Product path for the outbound hop: send and reply.

The real decision behind a failed AUTH

People search smtp authentication failed after a red banner in Gmail, Outlook, WordPress, or a cron script. They reset the secret. They add a second SPF record. They buy a Workspace seat. The useful decision is narrower: did the TCP session reach MailerZ, did TLS match the port, and did the secret belong to this product?

Decision one: paid or Free. Free has send-as Off, SMTP Off, and API Off. No amount of correct host text will log you in. Decision two: whose password is in the field. A Gmail app password authenticates to Google, not to MailerZ. Decision three: is the error AUTH, or is it MAIL FROM after AUTH? Plugins collapse both into “authentication failed.” History will not.

When this checklist is enough

• You can open the MailerZ dashboard and copy the SMTP pair.
• The domain is on a paid plan that includes SMTP On.
• You can send to a third mailbox and read the hop.
• You will not paste the secret into a ticket.

When AUTH failed is the wrong title

• History shows accept then destination 550. That is their refuse, not your login.
• History is empty and public MX still lists aspmx. That is leftover MX.
• The message landed in junk. AUTH already worked.
• You need Calendar and a hosted mailbox. That is a suite, not a relay.

Agencies should keep one domain per AUTH ticket. A contractor who reused one SMTP secret across five client sites will keep “fixing” Brand A while Brand B fails. Separate credentials. Revoke when the contract ends. Agency capacity is 100 domains, 500 aliases, 50 seats, 20,000 outgoing, 60 per hour. Confirm pricing. Capacity is not a shared password.

Do not treat a green Gmail self-send as a close. Gmail can short-circuit. The checklist ends on a received copy at a mailbox you do not control, plus a hop line you can read out loud.

Technical mail flow: connect, AUTH, then From

The client connects to the host and port the dashboard names. TLS must match that port. Then AUTH runs. Only after a successful AUTH does MailerZ evaluate the envelope sender and Header From against approved identities. Envelope SRS applies on inbound forwards. Outbound send-as signs with your domain’s DKIM after the session is accepted. AUTH failed never reaches that sign.

Header From, Subject, Date, Message-ID, body, and MIME are never rewritten on a MailerZ hop. That rule is about identity honesty, not about logging in. Forging From to “help AUTH” is backwards. If you cannot log in, change the pair. If you logged in and From was rejected, change the identity or the plan.

DNS still matters around the edges. One SPF TXT, the DKIM selector the dashboard shows, and DMARC when you are ready. Two v=spf1 records permerror outbound. They do not repair AUTH. Publishing prettier SPF because a plugin said “authentication failed” is a common Friday regression. Read IETF RFC 7208 — Sender Policy Framework (SPF) for lookup limits after AUTH already works.

Gmail Send mail as has an inbound confirmation step. That confirm is ordinary mail to your domain. Exclusive MailerZ MX and leftover host removal decide whether the confirm arrives. Operators call the missing confirm smtp authentication failed. The password field was never reached. Cut leftover MX first. Guide: Google Gmail Help — Send mail from a different address.

Step-by-step SMTP authentication failed checklist

1. Capture the exact line. Client log, plugin log, or Outlook SMTP response. AUTH failed, 535, TLS handshake, or 550 after MAIL FROM are different.
2. Name the plan. Free cannot finish send-as. Leave Free before you debug a password.
3. Copy the dashboard trio. Host, port, and TLS mode as one pair. Do not mix implicit TLS on a STARTTLS port.
4. Use the MailerZ secret. Not the Gmail password. Not an Outlook password. Not an old registrar SMTP leftover.
5. Set From to an approved identity. Creating inbound hello@ does not approve outbound. Catch-all does not mint a From.
6. Submit one unique subject to a mailbox you do not control. Open the received copy. Confirm the hop.
7. Only then touch DNS if AUTH already passed and Authentication-Results looks wrong. One SPF. Dashboard DKIM. No second MX.

Worked examples

A shop pasted the Gmail password into WP Mail SMTP. The plugin said authentication failed. Google was never the host. They created a MailerZ SMTP secret on Solo, copied the dashboard pair, set From to hello@, and the next contact form arrived at a third mailbox. The homepage form was not a bulk list. Hourly cap on Solo is 20 outgoing. They stayed under it.

An agency reused one SMTP user across three client WordPress sites. Two sites passed. The third failed after they rotated the secret on Client A. They issued per-client credentials, revoked the shared pair, and the third site authenticated. Agency at $39 or $390 buys capacity. It does not buy a house password.

Outlook showed authentication failed while the same secret worked in swaks. The Outlook account used implicit TLS on the STARTTLS port. Matching the dashboard pair fixed it. No DNS edit. No new mailbox.

Gmail Send mail as sat on “confirmation sent.” Public MX still listed aspmx. AUTH was never the defect. They deleted leftover Google MX, waited TTL, and the confirm landed. Then Send mail as completed. Related: email forwarding.

A founder on Free pointed a cron script at MailerZ SMTP. AUTH failed immediately. They moved the domain to Solo at $40 per year, created the identity, and the script signed in. The 550 they saw the week before on a leftover test was unauthorized From, not this week’s AUTH. Two tickets, two proofs.

Failure modes and proof

Proof is the client line plus the hop plus a received copy. Registrar UI is not the internet. A marketing page that says “SMTP enabled” is not AUTH. Do not mail the secret to support. Send the 535 or 550 text, a timestamp, and a Message-ID. Rotate if the secret already leaked. More on that habit: how to avoid sending credentials to support.

Broken DKIM after AUTH already passed is a later layer. Do not reopen the password ticket. Publish the dashboard selector. One SPF TXT. Under ten lookups. IETF RFC 6376 — DomainKeys Identified Mail (DKIM) is the signature story. AUTH is not.

MailerZ workflow and product boundary

Secuno LLC operates MailerZ. Site: mailerz.net. App: mail.mailerz.net. Inbound MX plus authenticated SMTP. Envelope SRS only on the forward. Header From is never rewritten. Unauthorized send is 550 / 550 5.7.1. Not an open relay.

What MailerZ does

• Issue SMTP credentials on paid plans.
• Accept AUTH only for those credentials.
• Refuse unhosted or unauthorized From after AUTH.
• Sign outbound mail with the dashboard DKIM once accepted.
• Keep delivery history for hops this layer saw.
• Hold or reject unknown inbound on Free. Paid unknown mail Forward is a plan default, not a send-as grant.

What MailerZ does not do

• Send-as, SMTP, or API on Free.
• Host IMAP, Calendar, or a Workspace suite.
• Accept a Gmail or Outlook password as the SMTP secret.
• Guarantee Primary or any inbox placement rate.
• Run bulk lists. Hourly and monthly outgoing caps are hard stops.
• Wear a SOC 2, ISO 27001, or HIPAA badge. Controls: Security and Trust Center.

Plans: pricing. Free $0, 1 domain, 10 aliases, 1 seat, 14-day store, send-as Off, SMTP Off, API Off, unknown mail hold or reject. Solo $40/year, 5 domains, 25 aliases, 90-day store, 2,500 outgoing, 20/hour, send-as On. Starter $8 or $80, 8/50/5, 5,000, 40/hour. Business $19 or $190, 25/200/25, 12,000, 60/hour. Agency $39 or $390, 100/500/50, 20,000, 60/hour. Unlimited $99 or $990, uncapped domains and aliases, 180-day store, 100,000 outgoing, 300/hour. Annual Starter, Business, and Agency include two months free versus monthly. Solo is yearly only.

Cost, alternatives, and trade-offs

Best practice for smtp authentication failed: paid plan, dashboard pair, MailerZ secret, approved From, third-mailbox proof. Do not invent review counts. Do not promise Primary. A suite is cheaper only if you need the suite.

Transactional volume that outgrows hourly caps belongs on a dedicated sending product that signs as its own domain or a dedicated subdomain. Do not stack every include onto apex SPF and hope AUTH starts working. Lookups still cap at ten. AUTH still needs the right secret.

Field notes you can reuse

WordPress plugins often have a “default WordPress send” fallback. A green test can hide a production path that never called AUTH. Disable the fallback. Watch history on the next real form submit, not the plugin’s test button alone.

Cron and server alerts should use the same pair as the form, or a dedicated identity if you want revocation without taking the site down. Do not put the secret in a ticket. Env files and rotate-on-leak are the operational habit. Related: SMTP credentials in env files.

Outlook versions label SMTP differently. The constant is the dashboard trio. If a version cannot do STARTTLS on the documented port, use the implicit TLS pair the dashboard shows. Do not invent a third port from a forum thread.

After a domain transfer, people still paste the old registrar SMTP host. AUTH fails against a box that no longer knows you. Screenshot the current dashboard host. Save the old MX set before you delete anything, because leftover MX is the usual companion ticket.

Proof packet: plan name, dashboard host and port, TLS mode, AUTH line or 550 line, timestamp, Message-ID, public MX from two resolvers if confirm mail is involved, received copy at a third mailbox. That packet ends “just reset the password” advice.

Retention is 14 days on Free and 90 on Solo through Agency. Unlimited is 180 days. Export the hop while it lives. The destination inbox is the archive, not this store.

If two products still share MX after you explained the coin flip, stop adding SMTP users. Exclusive MX is a hard stop for inbound confirms. smtp authentication failed cannot be closed on a split path if the only symptom is a missing Gmail confirm.

Teaching a junior: draw two boxes. Box A is AUTH. Box B is From. Most “authentication failed” screenshots are Box B wearing Box A’s name. Unmix the boxes in the first reply.

Quarterly refresh is a floor. Recheck when you rotate a secret, change the CMS plugin, transfer the domain, or the dashboard host changes. An include added in a panic still permerrors SPF. It will not unstick AUTH.

How to run the checklist without making it worse

Change one fact at a time. If you rotate the secret and change the port in the same minute, you will not know which edit worked. Write the last change on the ticket. Probe. Then change the next fact.

Do not add a backup MX while you debug AUTH. Dual MX creates a second random inbound path for confirms and does not help a password. Do not add a second SPF TXT. Do not rewrite Header From to match a username. MailerZ will not offer a From-replace control.

Shared team inboxes accumulate old SMTP identities in Gmail. Someone added hello@ last year with a dead secret. Gmail still tries it. Remove the stale Send mail as identity, then add the current pair. Two identities for the same From is how “sometimes AUTH failed” tickets last a month.

Contractors should get a credential they can lose. When they leave, revoke that user. Do not rotate the only house secret and break every form at once if you can avoid it. Starter through Agency include more seats for dashboard operators. Seats are not mailboxes. Confirm the live cards.

If the client insists the password is correct, ask them to AUTH with swaks or openssl against the dashboard host. A pass there and a fail in the plugin means the plugin is ignoring the host or using a fallback. A fail there means pair, TLS, plan, or secret. That split saves an hour of theme debugging.

Destination mailbox full, destination policy refuse, and hourly caps all produce 550 after AUTH. Read the text. Queue the send. Free the mailbox. Do not republish DKIM. Solo’s 2,500 outgoing per month and 20 per hour are product caps, not a dare.

If leadership wants a dashboard, give them AUTH success and hop accept, not a fake Primary rate. Those two numbers are yours. The folder is not. Inbox placement is not a MailerZ promise.

Related reading stays on shipped routes: send and reply, troubleshooting, tools, pricing. If the hop is clean and the folder is junk, say so. That is not smtp authentication failed.

One operational habit: store the last good received source next to the SMTP host screenshot. When a new teammate sees authentication failed, you can show what a healthy pair already looks like. Most mysteries are Free, a Gmail password, a TLS mismatch, or leftover MX on the confirm path.

Do not paste customer message bodies into chat to “check AUTH.” You need the SMTP line and the envelope facts. Bodies belong in the mailbox. If a secret appeared in chat, rotate it. The ticket is now a leak plus a login problem.

When a vendor’s form host cannot do TLS on the documented port, do not lower TLS to “make AUTH work.” Fix the client or use a host that can. A cleartext password on the public internet is not a MailerZ feature.

If you also receive on the domain, keep AUTH out of the inbound change window. Publish exclusive MX, delete leftovers, prove inbound from another mailbox. Then return to send-as. Mixing the windows is how a Friday MX delete gets blamed on “SMTP being off.”

WordPress clones are a special case. An agency that copies a working site also copies the SMTP secret. The clone AUTH works until someone rotates the original. Then both sites fail and the ticket says smtp authentication failed on a domain that never changed DNS. Issue a new user for the clone. Do not share the pair. Do not leave the old secret in wp-config on a staging URL that search engines can still reach.

If AUTH passes in swaks and fails only inside Gmail Send mail as, you are usually on the confirm path or on a stale identity. Remove the dead Send mail as row. Cut leftover MX. Wait TTL. Add the current pair once. One From, one secret, one hop you can quote.

FAQ

Key takeaways

• SMTP authentication failed is a login or TLS pair problem until proven otherwise.
• Free has SMTP Off. Leave Free before you debug a password.
• Use the MailerZ secret, not a Gmail or Outlook password.
• Copy host, port, and TLS as one dashboard pair.
• 550 after AUTH is From, plan, cap, or destination — not a reset.
• Leftover MX breaks Gmail confirm mail, not the secret itself.
• Third mailbox proof. Self-send can lie.
• One SPF TXT after AUTH already works. Do not permerror outbound.
• 14- or 90-day hop store is not an archive.
• MailerZ is not a mailbox suite and does not sell inbox placement.

Conclusion and next action

If you came here for an SMTP authentication failed checklist for custom domain send-as, the useful picture is small. Paid plan. Dashboard pair. Product secret. Approved From. A received copy you can quote. Unmix leftover MX before you blame the password for a missing Gmail confirm.

MailerZ is built for that split: inbound MX with Header From intact, paid SMTP with dashboard records when you need to send. Next action: read the exact client line, confirm the plan, copy the trio, and prove the hop from another mailbox.

Review quarterly, or sooner if dashboard SMTP hosts, TLS pairs, or plan cards change. Author: MailerZ editorial, Secuno LLC.