Password reset emails going to spam: the five checks that usually fix it

A password reset email lands in spam for one of five reasons, and the first two account for most cases: the message is not signed by your own domain, or your domain's reputation is being spent by something else you send. The rest are the message itself, the link inside it, and a domain that is simply too new. Check them in that order — each takes about a minute — and you will usually find the cause before you reach the third.

Key takeaways

• Open the message in Gmail, choose Show original, and read the SPF, DKIM and DMARC lines. That tells you which of the five you have in under a minute.
• A reset mail signed with the provider's key instead of yours is the single most common cause, and one DKIM record fixes it.
• Newsletters and resets from the same domain share one reputation. A campaign with a bad afternoon takes the resets with it.
• Filters are suspicious of a message that is a single link and nothing else. Say who you are, why the mail arrived, and what to do if it was not requested.
• A reset is the one message where "eventually" is not a delivery. It needs its own queue, not a place in line behind a broadcast.

Why does a reset get filtered when the receipt does not?

Because a reset looks like phishing. It arrives unexpectedly, it asks for a click, the link carries a token, and it usually says very little else. Every one of those properties is shared with a credential-harvesting mail, and filters weigh them accordingly. A receipt has a body, an amount, an order number and no urgent request; a reset has a button.

That is why the reset is where authentication and reputation problems show up first. A message that is borderline on content needs the identity signals to be clean — and when they are not, the reset is the first thing to go.

Check 1: is the message signed by your domain?

In Gmail, open the message and choose Show original. The summary at the top has three lines: SPF, DKIM and DMARC. What you want is DKIM: PASS with domain yourdomain.com. What you often find is PASS with domain followed by the provider's domain — amazonses.com, sendgrid.net, mailgun.org — or no DKIM line at all.

A pass on the provider's domain means the provider signed the message with its key, not yours. Receivers treat that as "somebody sent this on their behalf", which is technically true and exactly what a phishing mail looks like. Gmail marks it with via; other filters mark it down silently. The fix is a DKIM key on your own domain: your provider gives you a TXT record, you publish it, and from then on the signature aligns with the From address. We wrote up why Gmail shows 'via' and how to remove it if you want the detail.

While you are there, check the SPF line. It should pass on a domain of yours too — a bounce subdomain your provider gave you, such as bounce.mail.yourdomain.com. If it passes on the provider's domain instead, DMARC has only one aligned identifier to work with, which is enough for now but fragile.

On PigeonAtlas a domain cannot send until both records resolve. The domain page shows each record with its own tick, and the reason is precisely this check: a reset from an unverified domain is a reset that arrives in spam.

Check 2: what else is being sent from this domain?

Reputation is per domain, and often per subdomain. If your resets go out from yourdomain.com and so does your monthly newsletter, the two share one reputation at every receiver. The newsletter is the larger volume, it goes to people who did not ask for anything today, and it collects the spam reports. On the afternoon it does, the reset that follows it is filtered too, though it did nothing wrong.

Look at the complaint rate for the domain, not for the message type. Gmail's threshold is 0.3 percent, and AWS reviews a sender above 0.1 percent. If a broadcast has pushed the domain near either number, resets are paying for it. The fix is structural: transactional mail from one domain or subdomain, marketing from another, so a bad campaign cannot spend the reputation a reset needs. We explain the split in don't send newsletters from your transactional domain.

The same applies to queues. A reset that waits behind ten thousand newsletter messages is late, and a late reset is one the user has already given up on and requested again — which is now two resets, one of which will be reported. PigeonAtlas runs broadcasts and transactional mail on separate queues for this reason; a broadcast cannot delay a reset by a second.

Check 3: what does the message say?

Read your reset email as a filter would. If it is a logo, a button and a footer, it is a link with decoration. Filters have seen millions of those and most were not sent by the company on the logo.

Three things help, and none is a trick:

1. Say why it arrived. "Someone asked to reset the password for the account with this address" is context a phishing mail rarely bothers with.
2. Say what to do if it was not requested. "If this was not you, ignore this message — your password has not changed" is a sentence filters and people both read as reassurance.
3. Send a plain-text part with the HTML. An HTML-only message is a known signal; a proper multipart/alternative with a text version is what a legitimate sender's tooling produces by default. On PigeonAtlas, pass text alongside html in the API request and the message is built with both.

Keep the subject specific and calm. "Reset your password" or "Your password reset link" is fine. "Urgent: action required" is what the phishing mail says.

Check 4: where does the link go?

The link is the part of the message that filters inspect most closely, and three things about it cause trouble.

A URL shortener. bit.ly and the rest are used by spammers to hide destinations, and filters treat them accordingly. Link to your own domain.

A tracking domain that is not yours. Many providers wrap links through their own click-tracking host. The reader sees your name and a link to click.provider.com, which is the mismatch filters look for. Turn click tracking off for the domain that sends transactional mail. On PigeonAtlas it is off by default and set per domain, so the domain that sends resets can stay untracked while a marketing domain keeps its click statistics — the link in a reset is then exactly the link you put there.

A domain that differs from the From. If the mail comes from yourdomain.com and the link goes to yourapp.io, that is a legitimate pattern for many products, but it is one more thing to explain to a filter. Where you can, send from the domain the link points to.

Check 5: how old is the domain?

A domain that has never sent mail has no reputation, and no reputation is treated as slightly bad. This is the least common cause of the five, but it is the one you will hit on launch day, when the first users sign up and the first resets are the first messages the domain has ever sent.

There is no shortcut. Send real mail, in growing volume, and the reputation follows within a couple of weeks. What you can do is make sure the other four checks pass from the first message, so the reputation being built is a good one; and keep the earliest volume transactional, where every recipient asked for the mail and none will report it.

The one-minute version

1. Show original in Gmail. DKIM must pass on your own domain. If not, publish DKIM and stop here; that was probably it.
2. Check the domain's complaint rate. If a broadcast shares the domain, move it to a different one.
3. Read the message. Context, reassurance, a plain-text part.
4. Follow the link. Your domain, no shortener, no third-party click host.
5. If the domain is under two weeks old, keep sending; it will settle.

PigeonAtlas does the first two for you: a domain must have its own DKIM, SPF and MAIL FROM records before it can send, and transactional messages never wait behind a broadcast. The free plan covers a thousand messages a month, which is most products' resets for a long time.

Frequently asked questions

The reset arrives in Gmail but not in Outlook. Why? Receivers weigh the same signals differently. Outlook is harder on new domains and on unaligned SPF than Gmail is, and its junk folder is the default destination for a sender it does not recognize. The five checks are the same; Outlook simply fails a sender on fewer of them.

Does sending from noreply@ hurt? Not by itself. What hurts is a mailbox that bounces replies, because a reply that bounces looks like a sender that does not exist. Use an address that accepts mail, even if nobody reads it, or set a Reply-To that does.

Should the reset link expire quickly? For security, yes — an hour is common. For deliverability it makes no difference. What matters is that the message arrives within seconds of the request, which is a queue question rather than a link question.

Will a DMARC policy fix this? DMARC does not improve placement on its own; it tells receivers what to do with mail that fails alignment. Publish it once checks 1 and 2 pass, at p=none first, so that a misconfiguration produces a report rather than a rejected reset.

We use a shared IP. Is that the problem? Rarely, on a reputable provider — the provider polices its shared pools. Domain reputation matters more than IP reputation for a low-volume sender, and it is entirely yours to manage.