Why Your Magic Links Land in Spam (and How to Fix It)

A user signs up for your app. They tap "Send me a login link." They wait. They check their inbox. Nothing.

Then they check spam. There it is, sitting between a fake invoice and a crypto scam.

You're not sending spam. You know that. Your users know that. But their email provider doesn't know that. And it's the one making the call.

This guide is for app owners who use magic links (passwordless login) and want to understand why legitimate emails sometimes don't arrive, what's actually happening behind the scenes, and what needs to be in place to keep your login emails out of the spam folder. You don't need to become a DNS expert. You do need to understand the landscape well enough to ask the right questions and make informed decisions.

Email is a reputation system

Here's the mental model that makes everything else click: email delivery is a trust system, and your app starts with zero trust.

Every time your app sends a magic link, the email passes through a series of checkpoints before it reaches your user's inbox. The recipient's email provider (Gmail, Outlook, Yahoo) is asking one question at every checkpoint: should I trust this?

If the answer is yes at each checkpoint, the email lands in the inbox. If the answer is "not sure" at any point, it gets downgraded. Spam folder. Promotions tab. Or worst case, silently dropped. Your user never sees it, and you never get an error.

The good news: trust is buildable. The bad news: it doesn't come automatically. You have to set it up.

The three checkpoints (SPF, DKIM, DMARC)

You'll hear these three acronyms a lot. You don't need to memorize what they stand for. You need to understand what they do.

Think of it like this. Your app sends an email that says "Hi, I'm from yourapp.com." The recipient's email provider wants to verify that claim. It checks three things:

SPF is like a guest list. It's a record on your domain that says "these specific mail servers are authorized to send email on my behalf." When a customer receives an email claiming to be from yourapp.com, it checks the guest list. If the sending server isn't on it, that's a red flag.

DKIM is like a wax seal. It's a cryptographic signature attached to every email your app sends. It proves the email hasn't been tampered with in transit and really did come from who it says it came from. If the seal is missing or broken, providers get suspicious.

DMARC is the policy that ties SPF and DKIM together. It tells email providers: "Here's what to do if an email claims to be from my domain but fails the other two checks." Block it? Quarantine it? Let it through anyway? DMARC is your domain saying "I take authentication seriously, and here's how to handle imposters."

All three are configured as DNS records on your domain. DNS records are settings attached to your domain name (like yourapp.com) that tell the internet how to handle various things: where your website lives, where your email should go, and who's authorized to send email on your behalf. Your developer sets these up. What you need to know: if any of the three are missing or misconfigured, your emails start with a trust deficit. Some providers will still deliver them. Others won't.

Getting all three in place is table stakes. It's the minimum. Not having them is like opening a storefront with no sign and no business license, then wondering why people are skeptical.

Your domain's reputation score

Even with perfect authentication, there's another layer: your domain's reputation.

Email providers keep a running score on every domain that sends email. Think of it like a credit score, but for sending mail. A brand-new domain has no history. No history means no trust. And no trust means providers are cautious about putting your emails in the inbox.

Reputation builds over time through consistent, authenticated sending. It degrades through:

• High bounce rates. If you're sending to a lot of addresses that don't exist, providers notice.
• Spam complaints. If users mark your emails as spam (even accidentally), your reputation takes a hit.
• Sudden volume spikes. If your domain normally sends 50 emails a day and suddenly sends 5,000, that looks like a compromised account.
• Inconsistent sending patterns. Long periods of silence followed by bursts look suspicious.

This is why launching a new app on a new domain requires planning. You can't flip a switch on launch day and send 10,000 magic links. More on that in a moment.

Your sending service matters

Your app doesn't send email directly. It sends email through a service: SendGrid, Postmark, AWS SES, Resend, or one of many others. That service operates mail servers that actually transmit the email on your behalf.

Here's where it gets interesting. Many of these services use shared IP addresses. That means your emails are being sent from the same servers as other customers' emails. If another sender on that shared IP is behaving badly (sending actual spam, getting complaints), it can drag down the reputation of the IP itself. And that affects your deliverability, even though you did nothing wrong.

The alternative is a dedicated IP address, where your emails go through a server that only you use. Your reputation is entirely your own. The trade-off: dedicated IPs need to be "warmed up" (more on this below), and they're typically more expensive.

For most apps, a reputable sending service with good shared IP management is fine. The key is choosing a service that actively monitors and protects their IP reputation. Ask your developer which service you're using and how they handle IP reputation.

The warm-up period

This catches a lot of new app owners off guard.

When you start sending email from a new domain (or a new dedicated IP), you can't send at full volume immediately. Email providers watch for sudden, unexplained volume from unfamiliar senders. It's one of the strongest spam signals there is.

Warming up means starting with low volume and gradually increasing over days or weeks. Send to your most engaged users first (they're least likely to mark you as spam). Let providers build a pattern of "this sender is legitimate, their emails get opened, nobody complains." Then scale up.

This means your launch plan needs to account for the warm-up period. If you're expecting 5,000 signups on day one, you need to start warming up your sending domain before launch day. Your developer can set this up, but you need to know it's a thing so you can plan for it.

The "from" address matters more than you think

The email address your magic links come from affects how providers categorize your mail.

Sending from noreply@yourapp.com is common, but "noreply" addresses can carry slightly lower trust with some providers. More importantly, you should consider using a subdomain for transactional email: something like mail.yourapp.com or auth.yourapp.com rather than your root domain.

Why? Isolation. If you also send marketing emails from yourapp.com and those get spam complaints, it can affect the reputation of all email from that domain, including your magic links. Using a subdomain for transactional email keeps your login emails insulated from whatever else is happening on your domain.

This is a configuration decision. Your developer handles the setup. You just need to know it's worth doing.

What to watch

Email deliverability isn't a "set it and forget it" situation. Things drift. Reputation changes. Providers update their algorithms. Here are the metrics someone on your team (or your development partner) should be monitoring:

• Delivery rate. What percentage of emails are actually accepted by the recipient's provider? Anything below 95% needs investigation.
• Bounce rate. Hard bounces (invalid addresses) should stay below 2%. Soft bounces (temporary issues) are normal in small numbers.
• Spam complaint rate. This should be below 0.1%. Even a small number of complaints has outsized impact on reputation.
• Open rate. For magic links specifically, open rates should be high (users requested these emails). A sudden drop might mean emails are landing in spam.

Most email sending services provide these metrics in their dashboard. If nobody's looking at them, that's a gap worth closing.

When things go wrong

A user tells you they didn't get their magic link. Before panicking, here's a mental model for what might be happening:

Check the basics first. Did the email go out at all? Your sending service's logs will show whether the email was sent and whether the recipient's provider accepted it. If it was sent and accepted, the problem is likely on the recipient's end (spam filter, full inbox, typo in email address).

Look for patterns. Is it one user, or many? Is it specific to one email provider (all Gmail users, for example)? Patterns point to specific causes. A single user is probably a typo or an aggressive personal spam filter. All Gmail users is probably an authentication or reputation issue.

Check your authentication. Are SPF, DKIM, and DMARC all passing? Your sending service should show authentication status for each email. A sudden failure here means something changed in your DNS records.

Check your reputation. Google offers a tool called Postmaster Tools that shows your domain's reputation with Gmail specifically. If reputation has dropped, look at recent bounce rates and complaint rates for clues.

The key thing to remember: email deliverability issues are almost always diagnosable. They feel mysterious ("the email just didn't show up"), but there's a trail. The right question isn't "why didn't it work?" It's "where in the chain did it stop?"

The checklist

Here's what should be in place before your app sends its first magic link:

1. SPF, DKIM, and DMARC records configured on your domain
2. A reputable email sending service with good IP reputation management
3. A subdomain for transactional email to isolate magic links from marketing email
4. A warm-up plan if launching on a new domain or dedicated IP
5. Monitoring for delivery rate, bounce rate, spam complaints, and open rate
6. Logging so you can trace what happened when a user reports a missing email

None of these are things you need to configure yourself. But all of them are things you should know exist, so you can ask the right questions and make sure they're handled.

Your users are trying to log in. Every magic link that lands in spam is a user who might not come back. The good news: this is a solved problem. It just needs the right setup, a bit of patience during warm-up, and someone keeping an eye on the dashboard.