SPF, DKIM and DMARC Explained for Developers

Short answer: SPF lists who may send for your domain, DKIM cryptographically signs messages, and DMARC tells receivers what to do when those checks fail. For transactional email APIs like Notify, you publish the SPF/DKIM records from the dashboard, then send with a from on that verified domain.

You cannot skip this and expect password resets to land reliably.

Key takeaways

• SPF, DKIM, and DMARC are DNS — not application code
• An email API does not replace domain authentication
• Get SPF + DKIM green before tightening DMARC
• Prefer a dedicated sending domain/subdomain for transactional mail
• Notify shows exact records during domain verification

Why developers should care

Receiving inboxes ask: “Is this reset email actually from the domain it claims?” Without authentication, your carefully written HTML still looks like spam infrastructure.

Transactional mail (auth, billing, invites) is high trust. Fail DNS and users never complete signup.

Pipeline context: How email sending works.

SPF (Sender Policy Framework)

One sentence: A TXT record that publishes which servers may send mail for your domain.

When a message claims a From domain of yourproduct.com, the receiver can check SPF: did this connection come from an allowed source?

What your provider gives you: usually an include: mechanism pointing at their SPF policy (Notify includes this in the verification UI).

Developer pitfalls:

• Too many stacked include: lookups (SPF has a lookup limit)
• Editing the wrong apex vs subdomain
• Assuming SPF alone is enough (forwarding often breaks SPF — DKIM matters)

DKIM (DomainKeys Identified Mail)

One sentence: The provider signs each message with a private key; you publish the matching public key as DNS TXT (often selector._domainkey.yourdomain.com).

If the signature verifies, receivers know the message is tied to your domain’s key and wasn’t altered in transit.

Developer pitfalls:

• Typos in host or value (verification stays pending)
• CDN/DNS “proxy” modes interfering with TXT
• Rotating keys without the provider’s instructions

For most modern transactional setups, DKIM is the record you must get right.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

One sentence: A policy at _dmarc.yourdomain.com that requires alignment with SPF/DKIM results and says monitor (none), quarantine, or reject on failure — plus where to send reports.

Rollout that won’t burn you:

1. SPF + DKIM passing for real traffic
2. DMARC p=none with a rua mailbox you read
3. Tighten only when reports are clean

Transactional-only domains are easier to harden than domains that also send marketing.

How this maps to Notify (and any email API)

Typical path:

1. Create an API key
2. Add a domain in the dashboard
3. Publish the SPF/DKIM TXT records shown
4. Wait for verification
5. Send with from on that domain via POST /api/email/send

Until verification completes, use sandbox / test so engineering can proceed.

Provider-specific DNS:

• Cloudflare
• Route 53

Example mental model

you@app --HTTPS--> Notify --(DKIM signed)--> Gmail/Microsoft/...
                      ^
                      |
              DNS: SPF + DKIM (+ DMARC)

Your Node/Next code never “implements DKIM.” You publish DNS; Notify signs.

Common failure modes

| Symptom | Likely cause | |---------|----------------| | Domain pending forever | Wrong TXT name/value, propagation, proxy | | Gmail junks resets | Failed auth, cold domain, bad content | | Works to Gmail, fails corp | Stricter DMARC/policy at receiver | | Forwarded mail “fails SPF” | Expected — lean on DKIM + DMARC alignment |

Minimal SaaS checklist

• [ ] Pick a sending identity (mail.yourproduct.com or apex you control)
• [ ] SPF + DKIM live and verified in Notify
• [ ] DMARC at p=none with a monitored inbox
• [ ] Production from only on verified domains
• [ ] Marketing (if any) on a different subdomain later

Why Notify is a good fit once DNS is done

After authentication, you want the smallest send surface:

await fetch('https://notify.cx/api/email/send', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'x-api-key': process.env.NOTIFY_API_KEY!
  },
  body: JSON.stringify({
    from: 'noreply@your-verified-domain.com',
    to: user.email,
    subject: 'Verify your email',
    message: html
  })
});

Free 1,000/mo · Pro $10 / 10,000 · Scale $50 / 100,000 — pricing. No newsletter suite attached to your DKIM identity.

Next: Minimal transactional stack · Best practices 2026 · Quick start