Sender setup

The records, in plain words

When your app sends an email, the receiving server asks your domain’s DNS three questions. The answers are records you add once, at whoever hosts your DNS (Cloudflare, Vercel, Namecheap, GoDaddy, Route 53…).

DMARC passes when SPF or DKIM passes for the domain in your From address. That is why the provider’s own records aren’t enough: they prove the email came from Resend or SendGrid, not from you. Since 2024 Gmail and Yahoo require SPF, DKIM and a DMARC record from anyone sending in bulk.

Check your domain

Ask your agent. It reads your code to find which provider sends your email, then calls check_sender_domain, which looks your domain up in public DNS. Nothing is sent and no test run is needed.

Check our sending domain with Flowproof's check_sender_domain. Work out which email provider this app sends with from the code, pass it, and tell me exactly which DNS records to add.

You get one line you can act on, then each record with exactly what to add:

check_sender_domain   domain "acme.com", provider "resend"

2 of 4 ready: add DKIM and DMARC.

SPF          ready     SPF at send.acme.com authorises your provider (include:amazonses.com).
DKIM         missing   add  TXT  resend._domainkey.acme.com  p=<the public key Resend shows>
DMARC        missing   add  TXT  _dmarc.acme.com  v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.com
Return path  ready     send.acme.com sends bounces back to Resend.

Values in <angle brackets> differ for every account: copy them from your provider’s dashboard. DNS changes can take up to an hour to show up, so give it a moment before you check again. The check is limited to 20 domains per 10 minutes per account.

Records for each provider

Hosts are relative to your sending domain: send means send.yourdomain.com. Each provider shows your exact values on the page named under its heading; add those, not the examples.

Don’t launch on your auth provider’s built-in mailer

Supabase, Auth0, Cognito and Firebase all send sign-up and password-reset emails out of the box, from their own domain. That is fine while you build. In production it breaks in ways you won’t see:

• Supabase’s built-in email sends only a few emails an hour; past that, sign-ups and password resets silently get no email.
• Auth0’s built-in provider is for testing only, with a low limit and no deliverability promises.
• Cognito’s default email sends a limited number a day for the whole user pool, then stops.
• Firebase sends from a shared firebaseapp.com address your users don’t recognise.

And none of them can pass DMARC for your domain, because the email isn’t from your domain. Connect your own provider (custom SMTP in Supabase and Firebase, Amazon SES in Cognito, an email provider in Auth0), send from an address on your domain, add the records above, and a Flowproof run will stop flagging shared_auth_mailer.

DMARC: start at none, then tighten

Start with p=none and a rua= address: receivers deliver as normal and send you daily reports of who is sending as your domain. Once the reports show only your own services passing, move to p=quarantine (failures go to spam), and later p=reject. Moving too early sends your own misconfigured email to spam, so fix alignment first.

Have exactly one DMARC record and one SPF record per name. Two of either is an error, and receivers then ignore both.

Then test the real thing

DNS says what you published; it can’t say what a receiver made of a real email. Once the check is all ready, have your agent send each email through your provider to a Flowproof test address: the report grades SPF, DKIM and DMARC as the receiving server saw them. See how a test run works.