[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-a32e947a-259e-46cc-b95f-dc943b0d05ae":3},{"id":4,"body":5,"uuid":6,"created_at":7,"updated_at":8,"brand":9,"header":10,"short_body":11,"image":12,"published":13,"published_at":14,"tags":15},9,"\u003Cp>Password reset emails are the most time-sensitive messages your application sends, and they are also the ones most likely to land in spam. A user who can't find their reset link within a minute or two doesn't file a support ticket — they churn. Poor \u003Cstrong>email deliverability\u003C\u002Fstrong> on these critical transactional messages quietly costs SaaS companies sign-ups, retention, and revenue, and most engineering teams never see it happen because the email simply vanishes into a junk folder.\u003C\u002Fp>\n\u003Cp>If your \u003Cstrong>password reset email spam\u003C\u002Fstrong> rate is high, it is almost never a coincidence or a one-off filtering glitch. It is the predictable result of authentication gaps, reputation problems, content patterns, and infrastructure choices that mailbox providers like Gmail, Outlook, and Apple Mail evaluate on every single send. The good news: every one of these factors is measurable and fixable.\u003C\u002Fp>\n\u003Cp>This guide breaks down exactly why reset emails get filtered, how mailbox providers decide what is spam, and the concrete steps developers and SaaS teams can take to keep authentication emails in the inbox.\u003C\u002Fp>\n\u003Ch2>What \"Email Deliverability\" Actually Means\u003C\u002Fh2>\n\u003Cp>Email deliverability is the measure of whether your messages reach the recipient's inbox rather than the spam folder, a quarantine, or a silent drop. It is distinct from \"delivery\": a message can be \u003Cem>delivered\u003C\u002Fem> (accepted by the receiving server) but still be placed in spam, which counts against deliverability even though the SMTP transaction succeeded.\u003C\u002Fp>\n\u003Cp>For transactional email — password resets, email verifications, magic links, receipts — deliverability is the entire product. Unlike marketing email, where a 2% open rate dip is a nuisance, a reset email that lands in spam blocks a user from accessing their account \u003Cem>right now\u003C\u002Fem>.\u003C\u002Fp>\n\u003Cp>Three layers determine whether a reset email reaches the inbox:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Layer\u003C\u002Fth>\n\u003Cth>What it controls\u003C\u002Fth>\n\u003Cth>Who evaluates it\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Authentication\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Proof the message is really from your domain\u003C\u002Ftd>\n\u003Ctd>SPF, DKIM, DMARC checks at the receiving server\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Reputation\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>History of your sending IP and domain\u003C\u002Ftd>\n\u003Ctd>Mailbox providers, blocklists\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Content & engagement\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>The message body, links, and how users react\u003C\u002Ftd>\n\u003Ctd>Spam filters, machine-learning models\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>A failure at any layer can route your reset email to spam. Most teams obsess over content while ignoring authentication and reputation — which is backwards, because authentication failures are the single most common cause of password reset email spam.\u003C\u002Fp>\n\u003Ch2>Why Password Reset Emails Are Especially Vulnerable\u003C\u002Fh2>\n\u003Cp>Reset emails have characteristics that spam filters are trained to distrust:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Urgent, action-driven language\u003C\u002Fstrong> — \"Reset your password now,\" \"This link expires in 15 minutes.\" Urgency and deadlines are classic phishing signals.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>A single prominent link or button\u003C\u002Fstrong> — Phishing emails are built around one call-to-action link. So are reset emails.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sent to users who may not be expecting them\u003C\u002Fstrong> — A reset triggered days after sign-up arrives with no recent engagement to vouch for it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Often sent from a separate IP or subdomain\u003C\u002Fstrong> — Many teams route transactional mail through a different path than their main domain, fragmenting reputation.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Spiky, irregular volume\u003C\u002Fstrong> — Reset volume jumps during a breach scare or a login outage, and sudden spikes look like compromise to filters.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>In short, a legitimate password reset email and a credential-phishing attempt look structurally similar. That is exactly why your authentication and reputation signals have to be airtight — they are what tell the mailbox provider \"this urgent link email is genuinely from the domain it claims.\"\u003C\u002Fp>\n\u003Ch2>Reason 1: Broken or Missing Email Authentication\u003C\u002Fh2>\n\u003Cp>Authentication is the foundation of email deliverability, and it is where most password reset spam problems originate. Modern mailbox providers — especially Gmail and Yahoo, following their 2024 bulk-sender requirements — increasingly reject or junk mail that fails authentication outright.\u003C\u002Fp>\n\u003Cp>There are three records you must get right.\u003C\u002Fp>\n\u003Ch3>SPF (Sender Policy Framework)\u003C\u002Fh3>\n\u003Cp>SPF is a DNS TXT record that lists which servers are authorized to send mail for your domain. When a receiving server gets your reset email, it checks whether the sending IP is in your SPF record.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">v=spf1 include:_spf.postwing.app -all\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Common SPF failures that send reset emails to spam:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Too many DNS lookups.\u003C\u002Fstrong> SPF allows a maximum of 10 DNS lookups. Chaining many \u003Ccode>include:\u003C\u002Fcode> mechanisms (every vendor you've ever added) blows past the limit and causes a \u003Ccode>permerror\u003C\u002Fcode>, which filters treat as a failure.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>~all\u003C\u002Fcode> instead of \u003Ccode>-all\u003C\u002Fcode>.\u003C\u002Fstrong> A soft-fail (\u003Ccode>~all\u003C\u002Fcode>) tells receivers \"probably not authorized, but accept anyway.\" A hard-fail (\u003Ccode>-all\u003C\u002Fcode>) is a stronger, more trusted signal.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sending from a new provider without updating SPF.\u003C\u002Fstrong> Switch ESPs and forget to update the record, and every email fails SPF instantly.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>DKIM (DomainKeys Identified Mail)\u003C\u002Fh3>\n\u003Cp>DKIM adds a cryptographic signature to each message using a private key; the receiver verifies it against a public key published in your DNS. DKIM proves the message wasn't altered in transit and genuinely originated from your domain.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>DKIM is more important than SPF because it survives forwarding. If a user forwards your reset email or it passes through a mailing list, SPF often breaks but a valid DKIM signature still authenticates. Reset emails with no DKIM signature are heavily penalized.\u003C\u002Fp>\n\u003Ch3>DMARC (Domain-based Message Authentication, Reporting & Conformance)\u003C\u002Fh3>\n\u003Cp>DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails. It requires \u003Cem>alignment\u003C\u002Fem> — the domain in the \u003Ccode>From:\u003C\u002Fcode> header must match the authenticated domain.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-dns\">_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>DMARC policy\u003C\u002Fth>\n\u003Cth>Effect\u003C\u002Fth>\n\u003Cth>Recommendation\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=none\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Monitor only, no enforcement\u003C\u002Ftd>\n\u003Ctd>Start here to gather reports\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=quarantine\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Failing mail goes to spam\u003C\u002Ftd>\n\u003Ctd>Intermediate step\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=reject\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Failing mail is rejected outright\u003C\u002Ftd>\n\u003Ctd>Target for transactional domains\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>A published DMARC record with at least \u003Ccode>p=quarantine\u003C\u002Fcode> is now effectively mandatory for bulk senders to Gmail and Yahoo. Without it, your reset emails are increasingly likely to be junked regardless of content.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>Featured-snippet answer:\u003C\u002Fstrong> Password reset emails go to spam most often because of failed email authentication — missing or misconfigured SPF, DKIM, and DMARC records. Fixing these three DNS records resolves the majority of deliverability problems for transactional email.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>Reason 2: Poor Sender Reputation\u003C\u002Fh2>\n\u003Cp>Even perfectly authenticated email lands in spam if the sending domain or IP has a poor reputation. Mailbox providers maintain a reputation score for both, built from your sending history.\u003C\u002Fp>\n\u003Ch3>Shared IP contamination\u003C\u002Fh3>\n\u003Cp>If you send through a shared IP pool — common on entry-level email plans — your deliverability is hostage to every other sender on that IP. One spammer on the pool can drag your reputation down even when your own practices are flawless. For volume senders, a dedicated IP with proper warm-up isolates your reputation.\u003C\u002Fp>\n\u003Ch3>Domain reputation and subdomains\u003C\u002Fh3>\n\u003Cp>Domain reputation now matters more than IP reputation at most providers. A best practice is to separate your sending streams by subdomain:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>mail.yourdomain.com\u003C\u002Fcode> for transactional (resets, receipts)\u003C\u002Fli>\n\u003Cli>\u003Ccode>news.yourdomain.com\u003C\u002Fcode> for marketing\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This way, an aggressive marketing campaign that triggers spam complaints can't poison the reputation of the subdomain carrying your password reset emails. Keep your transactional subdomain pristine.\u003C\u002Fp>\n\u003Ch3>Blocklists\u003C\u002Fh3>\n\u003Cp>Your IP or domain can land on a blocklist (Spamhaus, Barracuda, SpamCop) after spam complaints, hitting spam traps, or a compromised account blasting mail. Listed senders see deliverability collapse. Monitor your status and have a remediation\u002Fdelisting process ready.\u003C\u002Fp>\n\u003Ch2>Reason 3: Content and Formatting Triggers\u003C\u002Fh2>\n\u003Cp>Reset email content can trip spam filters even when authentication and reputation are solid. Spam-detection engines like SpamAssassin score messages against hundreds of rules.\u003C\u002Fp>\n\u003Cp>Common content triggers in password reset emails:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Image-only or image-heavy emails.\u003C\u002Fstrong> A reset email that is one big banner image with little text reads as evasion. Maintain a healthy text-to-image ratio.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>URL shorteners and mismatched links.\u003C\u002Fstrong> Never use bit.ly-style shorteners in reset links — they hide the destination and are a phishing hallmark. Display URLs must match their \u003Ccode>href\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Link domains that differ from your sending domain.\u003C\u002Fstrong> If you send from \u003Ccode>yourdomain.com\u003C\u002Fcode> but the reset link points to \u003Ccode>app-reset-3847.cloudfront.net\u003C\u002Fcode>, filters flag the mismatch.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Spam-trigger phrases.\u003C\u002Fstrong> \"Click here immediately,\" \"Verify your account now or it will be deleted,\" excessive capitalization, and multiple exclamation marks all raise the score.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Broken HTML.\u003C\u002Fstrong> Malformed or unclosed tags and bloated nested-table markup increase spam scores.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Missing plain-text part.\u003C\u002Fstrong> Always send a \u003Ccode>multipart\u002Falternative\u003C\u002Fcode> message with both HTML and plain text. HTML-only emails look more suspicious.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>A clean reset email structure\u003C\u002Fh3>\n\u003Cp>Here's what a deliverability-friendly password reset email body looks like — clear text, one obvious link on your own domain, and a plain-text fallback:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Subject: Reset your password\n\nHi Alex,\n\nWe received a request to reset the password for your account.\nClick the link below to choose a new password. This link\nexpires in 30 minutes.\n\nhttps:\u002F\u002Fyourdomain.com\u002Freset?token=eyJhbGciOi...\n\nIf you didn't request this, you can safely ignore this email —\nyour password won't change.\n\n— The YourApp Team\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Note the absence of urgency-baiting language, the link on the sending domain, and the reassuring \"if you didn't request this\" line — which also reduces complaints.\u003C\u002Fp>\n\u003Ch2>Reason 4: Infrastructure and Sending Patterns\u003C\u002Fh2>\n\u003Cp>How you send matters as much as what you send.\u003C\u002Fp>\n\u003Ch3>Sending reset email from your app server\u003C\u002Fh3>\n\u003Cp>Sending SMTP directly from your application server is one of the most common causes of password reset spam. App servers usually run on cloud IPs (AWS, GCP, DigitalOcean) that are widely blocklisted because so much spam originates from them. They also lack the authentication setup, feedback loops, and reputation management a dedicated sending service provides.\u003C\u002Fp>\n\u003Cp>Use a transactional email API or relay built for deliverability instead of raw SMTP from your app.\u003C\u002Fp>\n\u003Ch3>No bounce or complaint handling\u003C\u002Fh3>\n\u003Cp>If you keep emailing addresses that hard-bounce, or ignore spam complaints via feedback loops, your reputation erodes fast. A real sending platform processes bounces and complaints automatically and suppresses bad addresses.\u003C\u002Fp>\n\u003Ch3>TLS and connection quality\u003C\u002Fh3>\n\u003Cp>Mailbox providers expect opportunistic TLS on the SMTP connection. Sending unencrypted, or with misconfigured reverse DNS (PTR records), signals a low-quality sender.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Infrastructure factor\u003C\u002Fth>\n\u003Cth>Spam risk\u003C\u002Fth>\n\u003Cth>Fix\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>SMTP direct from app server\u003C\u002Ftd>\n\u003Ctd>High\u003C\u002Ftd>\n\u003Ctd>Use a transactional email API\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>No PTR \u002F reverse DNS\u003C\u002Ftd>\n\u003Ctd>Medium\u003C\u002Ftd>\n\u003Ctd>Set PTR matching your sending hostname\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>No bounce handling\u003C\u002Ftd>\n\u003Ctd>High\u003C\u002Ftd>\n\u003Ctd>Automatic suppression lists\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>No TLS on connection\u003C\u002Ftd>\n\u003Ctd>Medium\u003C\u002Ftd>\n\u003Ctd>Enable opportunistic TLS\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Shared IP with spammers\u003C\u002Ftd>\n\u003Ctd>High\u003C\u002Ftd>\n\u003Ctd>Dedicated IP or reputable provider\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>A Practical Deliverability Checklist for Reset Emails\u003C\u002Fh2>\n\u003Cp>Run through this before your next deploy. Each item maps directly to one of the spam causes above.\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>SPF\u003C\u002Fstrong> — Published, under 10 DNS lookups, ends in \u003Ccode>-all\u003C\u002Fcode>, includes your current ESP.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DKIM\u003C\u002Fstrong> — Signing enabled on the exact domain in your \u003Ccode>From:\u003C\u002Fcode> header; key length 1024-bit minimum (2048 preferred).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DMARC\u003C\u002Fstrong> — Published at \u003Ccode>p=quarantine\u003C\u002Fcode> or \u003Ccode>p=reject\u003C\u002Fcode> with aligned SPF\u002FDKIM.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Dedicated subdomain\u003C\u002Fstrong> — Transactional mail isolated from marketing.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reverse DNS (PTR)\u003C\u002Fstrong> — Set and matching your sending hostname.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>From address\u003C\u002Fstrong> — A real, monitored address (not \u003Ccode>noreply@\u003C\u002Fcode> on a domain you can't receive replies to). A consistent, recognizable \u003Ccode>From:\u003C\u002Fcode> improves engagement.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Plain-text part\u003C\u002Fstrong> — Every reset email is \u003Ccode>multipart\u002Falternative\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Links on your own domain\u003C\u002Fstrong> — No shorteners, no mismatched destinations.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bounce & complaint handling\u003C\u002Fstrong> — Automatic suppression in place.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Monitoring\u003C\u002Fstrong> — DMARC reports reviewed, blocklist status checked, deliverability tested across Gmail\u002FOutlook\u002FApple.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>How to Test Whether Your Reset Emails Reach the Inbox\u003C\u002Fh2>\n\u003Cp>You can't fix what you don't measure. Use these methods:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Seed-list \u002F inbox-placement testing.\u003C\u002Fstrong> Tools like Mail-Tester, GlockApps, or your provider's seed testing send to a set of monitored inboxes across providers and report where each lands. Mail-Tester also gives you a SpamAssassin score and flags content issues.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Send to your own accounts.\u003C\u002Fstrong> Trigger a real reset to Gmail, Outlook, Yahoo, and iCloud test accounts and check the placement. Cheap and revealing.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Read the headers.\u003C\u002Fstrong> Open the raw message and inspect \u003Ccode>Authentication-Results\u003C\u002Fcode>. You want to see \u003Ccode>spf=pass\u003C\u002Fcode>, \u003Ccode>dkim=pass\u003C\u002Fcode>, and \u003Ccode>dmarc=pass\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode>Authentication-Results: mx.google.com;\n  dkim=pass header.i=@yourdomain.com;\n  spf=pass smtp.mailfrom=mail.yourdomain.com;\n  dmarc=pass (p=REJECT) header.from=yourdomain.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Three passes is the baseline. If any line shows \u003Ccode>fail\u003C\u002Fcode>, \u003Ccode>softfail\u003C\u002Fcode>, or \u003Ccode>none\u003C\u002Fcode>, you've found your problem.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Monitor DMARC aggregate reports.\u003C\u002Fstrong> They tell you which sources are sending as your domain and whether they authenticate — exposing both misconfigured services and spoofing attempts.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Code Example: Sending a Reset Email via a Transactional API\u003C\u002Fh2>\n\u003Cp>Here's how sending a reset email through a deliverability-focused API looks in practice, compared to raw SMTP. The API handles authentication, reputation, bounce processing, and retries for you.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-python\">import requests\n\ndef send_password_reset(email: str, reset_token: str):\n    reset_url = f"https:\u002F\u002Fyourdomain.com\u002Freset?token={reset_token}"\n\n    response = requests.post(\n        "https:\u002F\u002Fapi.postwing.app\u002Fv1\u002Fmessages",\n        headers={"Authorization": "Bearer YOUR_API_KEY"},\n        json={\n            "from": "YourApp <support@mail.yourdomain.com>",\n            "to": email,\n            "subject": "Reset your password",\n            "text": (\n                "We received a request to reset your password.\\n\\n"\n                f"Reset it here (expires in 30 min): {reset_url}\\n\\n"\n                "Didn't request this? You can ignore this email."\n            ),\n            "html": render_reset_html(reset_url),\n        },\n        timeout=10,\n    )\n    response.raise_for_status()\n    return response.json()\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The key wins over SMTP-from-app-server: the request goes out from an IP pool with established reputation, the message is automatically DKIM-signed for \u003Ccode>mail.yourdomain.com\u003C\u002Fcode>, bounces and complaints are tracked, and you get a message ID to trace delivery. None of that exists when you \u003Ccode>smtplib.sendmail()\u003C\u002Fcode> from your web server.\u003C\u002Fp>\n\u003Ch2>Common Mistakes That Send Reset Emails to Spam\u003C\u002Fh2>\n\u003Cp>Even experienced teams repeat these. Avoid them.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Using \u003Ccode>~all\u003C\u002Fcode> (soft-fail) in SPF instead of \u003Ccode>-all\u003C\u002Fcode>.\u003C\u002Fstrong> Weakens the authentication signal; switch to hard-fail once you've confirmed all legitimate senders are included.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Skipping DKIM because \"SPF is enough.\"\u003C\u002Fstrong> It isn't. DKIM survives forwarding and is weighted more heavily. Sign every reset email.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Leaving DMARC at \u003Ccode>p=none\u003C\u002Fcode> forever.\u003C\u002Fstrong> Monitoring is the start, not the goal. Move to enforcement so spoofers can't impersonate your reset emails.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sending transactional and marketing from the same domain\u002FIP.\u003C\u002Fstrong> One bad campaign tanks your reset deliverability. Separate the streams by subdomain.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sending SMTP directly from the app server.\u003C\u002Fstrong> Cloud IPs are pre-distrusted. Use a transactional sending service.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>From: noreply@\u003C\u002Fcode> on an unmonitored domain.\u003C\u002Fstrong> Hurts engagement and means you miss replies. Use a real, monitored sender address.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ignoring bounces and complaints.\u003C\u002Fstrong> Repeatedly mailing dead addresses or spam-complainers destroys reputation. Suppress them automatically.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Urgency-bait subject lines.\u003C\u002Fstrong> \"URGENT: Reset NOW!!!\" is a phishing pattern. Keep it calm: \"Reset your password.\"\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Not testing across providers.\u003C\u002Fstrong> Gmail, Outlook, and Apple filter differently. Test all three before assuming you're fine.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Forgetting to update DNS after switching ESPs.\u003C\u002Fstrong> A provider change without an SPF\u002FDKIM update means instant authentication failure.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Ch3>Why do my password reset emails go to spam but my marketing emails don't?\u003C\u002Fh3>\n\u003Cp>Usually because the two streams share a domain or IP and the transactional path was set up as an afterthought. Reset emails often get sent directly from the app server (a blocklisted cloud IP) or without proper DKIM signing, while the marketing email goes through a configured ESP. Reset emails also structurally resemble phishing — one urgent link — so they're held to a higher authentication standard. Isolate transactional mail on a dedicated, fully authenticated subdomain.\u003C\u002Fp>\n\u003Ch3>How do I check if my email authentication is set up correctly?\u003C\u002Fh3>\n\u003Cp>Send a test email to a Gmail account, open it, and view the original\u002Fraw source. Look at the \u003Ccode>Authentication-Results\u003C\u002Fcode> header — you want \u003Ccode>spf=pass\u003C\u002Fcode>, \u003Ccode>dkim=pass\u003C\u002Fcode>, and \u003Ccode>dmarc=pass\u003C\u002Fcode>. You can also use Mail-Tester (send to the address it gives you and get a 0–10 score) or check DNS records directly with \u003Ccode>dig TXT yourdomain.com\u003C\u002Fcode> for SPF and \u003Ccode>dig TXT _dmarc.yourdomain.com\u003C\u002Fcode> for DMARC.\u003C\u002Fp>\n\u003Ch3>Does sending password reset emails from my app server hurt deliverability?\u003C\u002Fh3>\n\u003Cp>Yes, significantly. Application servers run on cloud provider IPs (AWS, GCP, DigitalOcean) that are widely blocklisted because so much spam originates from them, and they lack DKIM signing, feedback loops, and reputation management. Route reset emails through a transactional email API or relay built for deliverability instead of calling \u003Ccode>smtplib\u003C\u002Fcode> directly from your web server.\u003C\u002Fp>\n\u003Ch3>What's the single most important fix for password reset email spam?\u003C\u002Fh3>\n\u003Cp>Email authentication — specifically getting SPF, DKIM, and DMARC all passing with proper alignment. Authentication failures are the most common cause of reset emails being junked, especially after Gmail and Yahoo's 2024 bulk-sender requirements. If you fix only one thing, make sure DKIM is signing on the exact domain in your \u003Ccode>From:\u003C\u002Fcode> header and DMARC is published at \u003Ccode>p=quarantine\u003C\u002Fcode> or stricter.\u003C\u002Fp>\n\u003Ch3>Should I use a dedicated IP for transactional emails?\u003C\u002Fh3>\n\u003Cp>It depends on volume. At high, steady volume (tens of thousands of messages a day or more), a properly warmed dedicated IP gives you full control over your reputation. At lower volume, a dedicated IP can actually \u003Cem>hurt\u003C\u002Fem> you because there isn't enough traffic to establish a reputation — a reputable shared pool is better. More important than IP type is separating transactional mail onto its own authenticated subdomain.\u003C\u002Fp>\n\u003Ch3>Why do reset emails sometimes arrive late or not at all?\u003C\u002Fh3>\n\u003Cp>Late or missing reset emails usually trace to one of three things: greylisting (the receiver temporarily defers a first-time sender and accepts on retry), reputation throttling (the provider rate-limits a low-reputation sender), or a soft bounce that your system didn't retry. A transactional email service with automatic retries and good reputation minimizes all three. If emails never arrive, check that they aren't being silently dropped due to a DMARC \u003Ccode>p=reject\u003C\u002Fcode> authentication failure.\u003C\u002Fp>\n\u003Ch3>Will a DMARC policy of p=reject block my legitimate reset emails?\u003C\u002Fh3>\n\u003Cp>Only if those emails fail authentication — which is the point. Before moving to \u003Ccode>p=reject\u003C\u002Fcode>, run at \u003Ccode>p=none\u003C\u002Fcode> and review the aggregate (\u003Ccode>rua\u003C\u002Fcode>) reports to confirm every legitimate sending source passes SPF or DKIM with alignment. Once your reports are clean, \u003Ccode>p=reject\u003C\u002Fcode> blocks spoofers impersonating your reset emails without touching your real mail. Always make this transition gradually: \u003Ccode>none\u003C\u002Fcode> → \u003Ccode>quarantine\u003C\u002Fcode> → \u003Ccode>reject\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>How long does it take to fix reset email deliverability?\u003C\u002Fh3>\n\u003Cp>DNS authentication fixes (SPF, DKIM, DMARC) propagate within minutes to a few hours and improve deliverability almost immediately. Reputation repair takes longer — days to weeks — if your domain or IP was already damaged by spam complaints or blocklisting. Content and infrastructure fixes (clean templates, dedicated subdomain, a proper sending service) take effect on the next send.\u003C\u002Fp>\n\u003Ch2>Conclusion\u003C\u002Fh2>\n\u003Cp>Password reset emails go to spam for reasons that are entirely within your control. The pattern is consistent: failed or missing authentication, a fragmented or damaged sender reputation, phishing-like content, and sending infrastructure that mailbox providers distrust by default. Each of these is measurable, and each has a concrete fix.\u003C\u002Fp>\n\u003Cp>Start with authentication — SPF, DKIM, and DMARC passing with alignment solves the majority of password reset email spam cases. Then isolate transactional mail on a dedicated subdomain, clean up your templates, stop sending SMTP directly from your app server, and test inbox placement across Gmail, Outlook, and Apple before you ship. Email deliverability for transactional messages isn't luck; it's the sum of these specific, verifiable decisions.\u003C\u002Fp>\n\u003Cp>For a SaaS product, a reset link that reliably hits the inbox is the difference between a user who logs back in and one who silently leaves. Treat your authentication emails as critical infrastructure, because to your users, they are.\u003C\u002Fp>\n\u003Ch2>Send Reset Emails That Land in the Inbox with Postwing\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fpostwing.app\">Postwing\u003C\u002Fa> is a transactional email delivery platform built for exactly this problem. It handles DKIM signing, reputation management, bounce and complaint suppression, and inbox-focused infrastructure out of the box — so your password reset, verification, and magic-link emails reach users instead of their spam folders.\u003C\u002Fp>\n\u003Cp>Built for developers and SaaS teams, Postwing offers a clean API, deliverability monitoring, and authentication guidance, with billing in \u003Cstrong>USDC on Base\u003C\u002Fstrong> — no card required, no recurring lock-in. Point your transactional email through a sending path engineered for the inbox and stop losing users to the spam folder.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Ca href=\"https:\u002F\u002Fpostwing.app\">Start sending with Postwing →\u003C\u002Fa>\u003C\u002Fstrong>\u003C\u002Fp>","a32e947a-259e-46cc-b95f-dc943b0d05ae","2026-06-24T18:28:18.011497+03:00","2026-07-15T23:42:31.509882+03:00","postwing","Why Your Password Reset Emails Go to Spam","Password reset emails go to spam more than any other message. Learn the email deliverability fixes that get reset links into the inbox, every time.","https:\u002F\u002Fapi.postwing.app\u002Fmedia\u002Fblog\u002Frecord_a32e947a-259e-46cc-b95f-dc943b0d05ae\u002FWhy_Your_Password_Reset_Emails_Go_to_Spam.png",true,"2026-07-02T09:00:00+03:00",[16,17],"email deliverability","password reset email spam"]