Email deliverability for developers: make sure your product's email actually lands

Most developers treat email as a solved problem. You wire up SendGrid or Postmark, you send a confirmation, you move on. But "sent" and "delivered" are not the same thing. A user who never sees your password reset email does not file a bug report. They just stop using your product. Email deliverability is a product problem, and it deserves the same attention you give to any other part of the user experience.

The difference between sending and delivering

Your email provider accepts the message and puts it on the wire. That is the end of your involvement, as far as the API is concerned. But the receiving mailbox (Gmail, Microsoft, Yahoo) has its own opinion about whether that message belongs in the inbox or the spam folder. It makes that decision based on a set of signals it can look up in real time: your domain's authentication records, your sending IP's reputation, and whether your sending pattern looks normal. If any of those signals are weak, the message gets filtered, and you will not know unless you check.

The records you own

Even when you send through a third-party provider, the authentication records live on your domain, not theirs. That means you are responsible for them, and a misconfiguration on your side will sink every email your provider sends on your behalf.

SPF. A list of the servers allowed to send for your domain. If your provider's sending IPs are not in your SPF record, every email fails authentication. Most providers give you the exact include statement to add. Check it with the SPF checker.
DKIM. A signing key that proves the email came from you. You generate the key pair, publish the public key in your DNS, and hand the private key to your provider so it can sign outgoing mail. Use a strong key (2048-bit or longer). Check it with the DKIM checker.
DMARC. A policy that tells receivers what to do when SPF or DKIM fails. Start with p=none and rua reporting so you can see what is failing, then tighten to p=quarantine or p=reject once you are confident. Check it with the DMARC checker.
MX and PTR. Your domain needs a valid MX record, and your sending IP needs a matching reverse DNS record. A bare IP with no PTR is one of the fastest ways to get filtered.
TLS / STARTTLS. Your mail server should offer a modern TLS version. A server that only offers an old cipher is a signal a receiver will use against you.

The provider problem

When you send through SendGrid, Postmark, Mailgun, or Resend, you are inheriting their infrastructure. Their sending IPs have their own reputation, and their configuration can change under you. A provider that rotates its IP pool, changes its signing key, or tightens its own authentication can quietly break your deliverability without you ever seeing a single error in your logs. The API still returns 200. The email still gets accepted. But the receiving mailbox now filters it.

This is why "it worked yesterday" is not a guarantee. The only way to know is to check the live records and the live sending IP, not to assume the provider has not changed anything.

Monitoring: the difference between finding out and being told

A one-time audit tells you the state of your records right now. It does not tell you what happens tomorrow when your provider rotates an IP, or when a DNS change propagates, or when your sending volume spikes and triggers a heuristic. The developers who avoid deliverability incidents are the ones who monitor their sending domain on a schedule and get alerted the moment a check flips from pass to fail.

That is the difference between finding out about a deliverability drop from a user who says "I never got my password reset email" and finding out from an alert that says "DKIM check failed on your sending domain 6 hours ago." The second one is a 10-minute fix. The first one is a support ticket and a lost user.

The developer workflow

Run the audit on your sending domain. Read the score, then read each failed check and apply the exact record the tool hands you. Confirm your sending IP is not on a blocklist. Re-run the audit to confirm the score climbed. Then set up monitoring so the next time a record breaks or your IP gets listed, you find out before your users do. Run a free audit on your sending domain and get the score, the exact records to fix, and the option to monitor them daily.