SendGrid access & transactional email

SendGrid sends the email your application generates: password resets, receipts, notifications, verification links. This is transactional email: triggered by something a user did, and expected to arrive within seconds.

Teammates and access

Open Settings → Teammates in the SendGrid dashboard.

Invite by email, choosing Restricted Access rather than Admin. The third option, Read-only Access, lets someone see a feature without changing it. Restricted Access then offers presets (Developer, Marketer, Accountant) or Custom Access if none of them fit.

Grant only what's needed. For diagnosing delivery problems, that's typically Mail Send, Stats, Suppressions, and Email Activity, not billing or teammate management. Be especially careful with Admin: an Admin teammate can create more teammates, including other Admins, and reach your billing settings.

Enable two-factor authentication. An account that can send mail as your domain is worth protecting.

How many people you can add depends on the plan: SendGrid's Free and Essentials plans allow one teammate per account, and its higher plans allow many more plus single sign-on. Invitations expire, so send them when the person is ready to accept.

API keys

Your application uses an API key, not a login. Create keys under Settings → API Keys. The permission choice matters: pick Custom Access and grant Mail Send only, rather than Full Access.

A full-access API key is a serious liability

Full Access grants every API endpoint full access to your account. That means a leaked key can send mail as your domain, read your activity, change settings, and create more keys, so an attacker can send convincing phishing from your own authenticated domain. Scope keys to Mail Send, store them as environment variables, and rotate on offboarding.

SendGrid displays a key's value only once, at creation. Store it immediately in your password manager and your hosting platform's environment variables.

Sender authentication

Before any meaningful volume, authenticate your domain. This means adding DNS records that let receiving servers verify the mail genuinely came from you.

Start domain authentication. Go to Settings → Sender Authentication, and click Get Started in the Domain Authentication section.

Add the DNS records SendGrid provides to your domain. See DNS access.

Verify in the dashboard. Records can take a little time to propagate.

Add a DMARC record once SPF and DKIM are passing. See SPF, DKIM and DMARC.

This is not just about spam folders. Google's own sender guidelines say messages that aren't authenticated with SPF, DKIM and DMARC may be marked as spam or rejected outright, and Google requires bulk senders to have all three.

SPF and DKIM are two separate checks on the same email: one on the sending server, one on the signature. DMARC is not a third check: it is the policy that tells receiving servers what to do with emails that fail SPF or DKIM.

Read this as text

An email arrives claiming to be from your domain. The receiving mail server runs two checks on it. SPF checks the envelope: is this mail server on the approved list? DKIM checks the letter: was this email signed by the claimed domain, and is the signature still intact?

If both checks pass, the email has been authenticated and there is nothing for your DMARC policy to act on. Authentication on its own is not a promise of the inbox: spam filters also weigh things like your message content.

If either check fails, your DMARC policy tells the receiving server what to do. A policy of none delivers the email anyway and sends reports to you as the domain owner. Quarantine puts it in the spam or junk folder. Reject blocks it entirely, so it never reaches the recipient.

Suppressions: why one person stops receiving mail

SendGrid maintains suppression lists: bounces, blocks, invalid emails, spam reports, and unsubscribes. An address on one of these lists stops receiving your mail, silently.

This is the usual explanation for "our customer never got their password reset". Check the Email Activity Feed and the suppression lists before assuming the application is broken. Addresses can be removed from a suppression list, but understand why it was added first: repeatedly mailing an address that reported you as spam damages your sending reputation.

Transactional and marketing must stay separate

Don't send newsletters from your transactional setup

If marketing mail generates spam complaints on the same domain or IP that sends your password resets, the resets stop arriving too. Use a separate subdomain, and ideally a separate service, for marketing. See transactional vs marketing email.

Common questions

Our emails go to spam. Where do we start?

In order: confirm domain authentication passes; check the From address is at your authenticated domain; confirm the recipient isn't on a suppression list; check whether marketing mail shares the domain. See improving deliverability.

Can we reply to these emails?

Not by default: SendGrid sends, it doesn't host mailboxes. Set the Reply-To header to a real monitored mailbox. A no-reply@ address guarantees you never see the customer who replies to explain what went wrong, which is usually reason enough to avoid it.

How do we know an email was delivered?

The Email Activity Feed shows a status per message (processed, delivered, deferred, opened, clicked, bounced, dropped, spam report) for recent messages. For anything longer-term, configure the Event Webhook so your application records delivery status itself.

Who should own the account?

You. It's tied to your domain's sending reputation: an asset that takes months to build and is difficult to transfer. See transferring ownership to you.