Your app sends a password reset, a booking confirmation or an invoice reminder. The user never receives it. They assume the product is broken, contact support or leave. Email deliverability problems are among the most common and least visible reasons new apps struggle, and they are almost always fixable.

This guide explains in plain language why emails get filtered, what SPF, DKIM and DMARC mean and the practical steps that give your messages the best chance of reaching the inbox.

Why it matters

• Sign-up and password reset emails are how users get in.
• Notifications bring people back to the product.
• Invoices and reminders affect your cash flow.
• Unreliable email damages trust quickly.

Why emails get filtered

Mailbox providers want to know that a message really comes from who it claims to come from and that recipients want it. If a message looks forged, is sent from a poorly set-up domain or generates complaints, it may be sent to spam or rejected. Major providers have tightened requirements for authentication, particularly for senders of large volumes, so a proper setup matters more than it used to.

The three records, in plain language

All three are set up as records in your domain’s settings. Your email provider gives you the exact values to add.

A practical setup checklist

1. Use a proper email sending service, not a personal mailbox or the platform’s default sender, for anything customer-facing.
2. Send from your own domain, such as notifications@yourdomain.com, rather than a free webmail address.
3. Set up SPF and DKIM using your provider’s instructions.
4. Add a DMARC record, starting with a monitoring policy so you can see what is happening, then tightening it as you gain confidence.
5. Consider separate subdomains for transactional email and marketing email, so a problem with one does not harm the other.
6. Test by sending to several providers and checking where messages land.
7. Monitor bounces and complaints, and remove invalid addresses promptly.

Content and behaviour that help

• Send only to people who signed up or are existing users.
• Include a clear, working unsubscribe link in marketing messages.
• Use a recognisable sender name and a clear subject line.
• Avoid heavy images, misleading subjects and large attachments.
• Keep the volume steady rather than sending huge bursts from a new domain.
• Honour opt-outs immediately.

Build it into the project

Email setup is easy to forget until launch day. Planning it as part of the build, including templates, sender domains and a test routine, avoids the scramble. It belongs in the PRD alongside integrations. See our process from discovery to launch and what maintenance involves.

Cost and first step

Builds start at $3,500, with the final quote based on the scope in your PRD, and typical launches take 2 to 6 weeks. The best first step is a Discovery Sprint: a $345 plan covering scope, user flows, architecture and cost, delivered within 24 hours and credited toward the build. See our cost guide for what moves the price. Email service fees are separate and depend on the provider and your volume.

Frequently asked questions

Can I just use my Gmail or Outlook address to send from the app?

It is not recommended. Personal mailboxes are not designed for application email and are more likely to cause deliverability problems.

How long do DNS changes take?

Often minutes to a few hours, though it can take longer. Test after changes.

What if my emails still go to spam?

Check the authentication records, the sending reputation of your domain and the content. A professional review can pinpoint the cause.

Do I need all three records?

They work together, and the current expectation among large providers is to have them. Set them all up.