You wired up an email API, sent a test message, and it landed in spam. The body looked fine, the subject was clean, so what flagged it? Almost always the answer is authentication: the receiving server checked SPF, DKIM, and DMARC, found a misaligned or missing signature, and downgraded the message. These three DNS-based protocols decide whether Gmail, Outlook, and Yahoo trust that you’re allowed to send as the address in the from field.
This page explains what each protocol does, why they govern inbox placement, and how the address you send from changes everything. Send through a connected mailbox and you inherit the provider’s existing SPF and DKIM setup. Send from a custom domain and you own the DNS records yourself.
What are SPF, DKIM, and DMARC?
Section titled “What are SPF, DKIM, and DMARC?”SPF, DKIM, and DMARC are three DNS records that prove an email is legitimate. SPF (RFC 7208) lists which IP addresses may send for a domain. DKIM (RFC 6376) attaches a cryptographic signature the receiver verifies against a published public key. DMARC (RFC 7489) ties the two together and tells receivers what to do when checks fail.
Each protocol solves a different attack. SPF stops an unauthorized server from claiming your domain in the envelope sender. DKIM stops tampering: any change to a signed header or the body breaks the signature. DMARC adds the missing piece, alignment, requiring that the domain SPF and DKIM authenticate matches the visible from domain. Receivers honor your DMARC policy of none, quarantine, or reject. As of 2024, Google and Yahoo require all three for bulk senders pushing 5,000 or more messages per day, so missing records now block delivery outright rather than just lowering your score.
How do I set up email authentication when using an email API?
Section titled “How do I set up email authentication when using an email API?”The setup depends on which address you send from. When you send through a connected user mailbox with POST /v3/grants/{grant_id}/messages/send, the message routes through the provider’s own infrastructure, so the existing SPF and DKIM records for that domain already apply. You configure nothing. The provider signs and aligns the message exactly as it would for mail sent from the native web client.
This is the single biggest deliverability advantage of sending from the user mailbox. A message from [email protected] through their Google Workspace grant is signed by Google’s DKIM key for acme.com, passes the SPF check against Google’s IP address ranges, and aligns with the DMARC policy acme.com already publishes. The request below sends one authenticated message and returns the sent message object in the API response, with the OAuth token refreshed automatically.
curl --request POST \ --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages/send' \ --header 'Authorization: Bearer <NYLAS_API_KEY>' \ --header 'Content-Type: application/json' \ --data '{ "subject": "Your weekly report is ready", "body": "Your account summary for this week is attached.", "to": [{ "name": "Jordan Lee", "email": "[email protected]" }] }'Because the send originates from the mailbox itself, there’s no separate domain to authenticate.
Why does sending from the user mailbox inherit provider alignment?
Section titled “Why does sending from the user mailbox inherit provider alignment?”Sending from the connected mailbox inherits alignment because the message physically leaves the provider’s mail servers, not a third-party relay. Google, Microsoft, and Yahoo already publish SPF records covering their sending IP addresses and rotate DKIM keys for every hosted domain. Mail you send through /v3/grants/{grant_id}/messages/send travels the same path, so DMARC alignment passes by default.
Alignment is where most third-party sending breaks. DMARC (RFC 7489) requires that the domain validated by SPF or DKIM matches the from header domain. A traditional relay sends as [email protected] but authenticates against the relay’s own domain, so SPF aligns to the wrong place and DKIM needs a delegated subdomain key. Routing through the mailbox sidesteps both: the authenticating domain and the visible from domain are identical, so alignment passes by default. Broken alignment is one of the most common reasons legitimate mail lands in spam, and provider-native sending removes that failure mode entirely across all 6 supported providers.
How do I authenticate email at scale without getting flagged as spam?
Section titled “How do I authenticate email at scale without getting flagged as spam?”At scale, authentication is necessary but not sufficient. You also need a clean sending reputation, low complaint rates, and a DMARC policy receivers can act on. Keep your spam complaint rate under 0.3%, the threshold Google enforces in Postmaster Tools, and make sure every message passes SPF, DKIM, and DMARC. Provider-native sending handles the authentication half automatically; the reputation half is on you.
Two patterns cover high-volume sending. For mail that should come from each user’s own address, the grant-based send inherits their provider authentication and respects the per-mailbox daily cap, near 2,000 messages per day on Google Workspace. For application-owned mail from a single brand address, the custom-domain send through /v3/domains/{domain_name}/messages/send requires you to publish SPF, DKIM, and DMARC records for that domain yourself, then verify them once. Pair either path with the send email reliably at scale design for backoff and idempotency, since a retry storm on 429 responses looks like abuse to receivers. To stop sending to addresses that fail permanently, wire up bounced email handling so hard bounces feed a suppression list.
Mailbox send vs custom-domain send
Section titled “Mailbox send vs custom-domain send”Both send paths produce fully authenticated mail, but they differ in who owns the DNS records and which address appears in the from field. Sending through a grant uses the connected mailbox and inherits that provider’s authentication across all 6 providers. Sending through a verified domain uses your own brand address and requires you to publish 3 DNS records. The path that needs zero DNS work is the grant-based send, in bold below.
| Concern | Custom-domain send | Grant-based mailbox send |
|---|---|---|
| Endpoint | /v3/domains/{domain_name}/messages/send | /v3/grants/{grant_id}/messages/send |
| SPF / DKIM records | You publish and verify them | Inherited from the provider |
| DMARC alignment | You configure the domain | Aligned automatically |
| From address | Your brand domain | The user’s own address |
| DNS setup time | Hours, plus DNS propagation | None |
| Best for | Transactional brand mail | Mail sent as the user |
Pick the custom-domain path when every message must come from one brand address like [email protected]. Pick the grant-based path when mail should appear to come from the user, which covers shared inboxes, agent accounts, and reply-on-behalf flows. The custom-domain route trades setup work for control over the sending identity, which is the right call for one-to-many transactional mail.
How do I check whether my email passed authentication?
Section titled “How do I check whether my email passed authentication?”Inspect the Authentication-Results header on a received message, which every major provider stamps with the SPF, DKIM, and DMARC verdict. Send yourself 1 test message, open the original source, and look for spf=pass, dkim=pass, and dmarc=pass. Google’s documentation states a result of dmarc=pass means “the message passed DMARC”, confirming the from domain aligned with an authenticated identity.
For ongoing monitoring, publish a DMARC record with a rua reporting address and you’ll receive aggregate XML reports every 24 hours from every receiver that processed your mail. These reports show the percentage of your volume passing alignment, which is the metric to watch as you scale. Google’s Postmaster Tools graphs authentication pass rates and spam complaint rates for domains sending meaningful volume, and Microsoft offers the equivalent through its Smart Network Data Services. When you send through a connected grant, these dashboards report on the provider’s own authenticated stream, so a healthy mailbox already shows healthy numbers.
What’s next
Section titled “What’s next”- Send email without SMTP to route mail through the user mailbox with one request
- Send email reliably at scale for queueing, backoff, and idempotency on high volume
- Detect and handle bounced email to suppress addresses that fail permanently
- Getting started with Nylas to create a project, connector, and your first grant