App emails going to spam? Fix SPF, DKIM and DMARC

Your app's emails go to spam mostly because the receiving server can't confirm they really come from your domain. The fix is to send through a proper email service from your own domain and publish three DNS records: SPF (which servers may send for you), DKIM (a signature on each message) and DMARC (what to do when those checks fail), with the From address aligned to them. Since 2024 Gmail and Yahoo require this for anyone sending at volume.

This guide covers why app emails end up in spam, what each record does, the exact order to set them up, and how to prove the fix worked before your users tell you.

Why do my app's emails land in spam?

The usual causes, roughly from most to least important:

1. No authentication. The domain has no SPF or DKIM, so the message can't be tied to you.
2. Misalignment. The From address says hello@yourapp.com, but the message is signed by the provider's domain. DMARC only passes when SPF or DKIM authenticates the same domain as the From header.
3. A shared or default sender. Many builders and backends ship with a default mail service meant for testing. Supabase's built-in email, for example, only delivers to members of your project's team and is limited to 2 messages per hour. Real users need a custom SMTP or email API.
4. No reputation yet. A brand-new domain sending hundreds of emails on day one looks like spam, even when it's authenticated.
5. Complaints. People who click "Report spam" teach the mailbox provider to filter you. Marketing emails without an easy unsubscribe make this worse.
6. Content signals. Link shorteners, links to domains other than yours, image-only emails. These matter less than the first five.

What do SPF, DKIM and DMARC actually do?

SPF and DKIM prove a message is legitimate. DMARC ties them to the From address people see and tells receivers how strict to be.

What do Gmail and Yahoo require now?

From Google's email sender guidelines and Yahoo's sender best practices:

• Everyone must use SPF or DKIM, have valid forward and reverse DNS for sending IPs, and keep the spam complaint rate below 0.3%. Gmail also requires TLS and advises staying under 0.10%.
• Bulk senders (Gmail defines it as more than 5,000 messages a day to its users) must use both SPF and DKIM, publish a DMARC policy of at least p=none, align the From domain with SPF or DKIM, and offer one-click unsubscribe on marketing messages. Yahoo also asks that unsubscribes be honored within 2 days.

Even if you're far below 5,000 a day, follow the bulk rules. They cost nothing extra and they are what keeps password resets out of the spam folder.

How do I set it up, step by step?

1. Pick a sending service and verify your domain

Use a transactional email provider (an email API or SMTP service) rather than your personal mailbox. In its dashboard, add your domain. Many providers recommend a subdomain such as mail.yourapp.com or send.yourapp.com, which keeps app email reputation separate from your team's inbox.

The provider then shows you a few DNS records, usually one or more DKIM records and an SPF or return-path record. Copy them exactly into your DNS host. If you're unsure where that is, our guide to DNS records explains how to find it.

2. Keep a single SPF record per name

If your root domain already has v=spf1 include:_spf.google.com ~all for your team's mailbox and the provider asks for SPF on the same name, merge them:

v=spf1 include:_spf.google.com include:<provider value> ~all

Two separate v=spf1 records on the same name make SPF fail.

3. Add a DMARC record

Start in monitoring mode so nothing gets blocked while you check:

Name:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com

The reports sent to that address show which services send as your domain. After a few weeks with everything passing, move to p=quarantine, and later p=reject if you want the strongest protection against spoofing.

4. Point your app at the new sender

Update the app's SMTP or API settings and set the From address to the verified domain. For Supabase Auth emails, this is the custom SMTP setting in your project's authentication settings. Store the API key or SMTP password as a server-side secret, never in front-end code. If your project was built with Lovable, our guide to sending emails from a Lovable app walks through the wiring.

5. Warm up gently

If the domain is new, start with the emails people expect (sign-up confirmations, password resets, receipts) before sending any newsletter. Expected email gets opened, which builds reputation.

How do I check that it worked?

1. Send a real email from the app to a Gmail address.
2. In Gmail, open it, click the three-dot menu and choose Show original. You should see SPF, DKIM and DMARC each marked PASS, and the DKIM domain should be your domain or subdomain.
3. Do the same with an Outlook or Yahoo address if your users use them.
4. Register your domain in Google Postmaster Tools to watch spam rate and reputation over time.
5. Read the first DMARC reports. Any source you don't recognize is either a service you forgot or someone spoofing you.

If DMARC fails while SPF and DKIM pass, the problem is alignment: the From address uses a different domain than the one being authenticated.

How do I keep emails out of spam later?

• Send transactional and marketing email from different subdomains or streams.
• Add a visible unsubscribe link and the one-click unsubscribe header to anything that isn't transactional.
• Never buy lists or import contacts who didn't sign up.
• Watch bounces: if a sign-up form lets typos through, validate addresses before sending.

Quick answers

Can I send from my Gmail address through my app? Don't. Your provider can't authenticate gmail.com, so DMARC will fail. Send from your own domain.

Is p=none enough? It meets the minimum requirement for bulk senders and gives you reports. Move to a stricter policy once all legitimate sources pass.

Why do Supabase confirmation emails never arrive? The default service only sends to your team's addresses and has a low hourly limit. Our guide to Supabase not sending confirmation emails covers the fix in detail.

How long until reputation improves? It builds over days to weeks of consistent, wanted email. Authentication helps immediately; reputation takes longer.

Want your email setup checked?

Email touches DNS, your backend and your sending provider at once, so a small mismatch is easy to miss. Our maintenance and support work includes setting up and verifying email authentication. You can start with the free health check or tell us what's happening.