Domains, Email and Deliverability

Sending email from your own domain is not typing an address into a "from" field. Modern mail providers silently discard unauthenticated mail, not bounce, discard, with no error and nothing in spam. This chapter is the DNS you need so your email actually exists.

The concept

Two surprises await every first-time founder:

1. A support email on your own domain is a store requirement, not a nicety. support@gmail.com in a listing reads as a hobby.
2. Email deliverability is a DNS problem, and it will humble you. The default failure mode of unauthenticated email is silent disappearance.

The domain

• Buy a per-product domain for anything a customer touches. A studio subdomain (yourapp.mystudio.com) reads as a side project to a paying customer.
• When your first choice is taken, the normal outcome for any good short name, add a word from your product, not filler. A qualifier that means something beats "get-", "-app", "try-".
• Register through a registrar with clean DNS (Cloudflare, Namecheap). ~$12/year.

Email has three separate jobs: use three mechanisms

The most common mistake is trying to make one tool do all three. They have genuinely different requirements:

 RECEIVING       support@you.com → your inbox
   → email forwarding / routing (Cloudflare Email Routing is free)

 REPLYING (human)   as support@you.com
   → your mail client's "send as" + your sending provider's SMTP

 SENDING (automated)   confirmations, receipts, notifications
   → a transactional email provider over an AUTHENTICATED domain

⭐ The three DNS records that make email real

You cannot just set a "From" address. The receiving server verifies your domain's DNS before it accepts your mail:

 SPF    a TXT record listing who may send for your domain
        v=spf1 include:spf.provider.com ~all

 DKIM   a public key in DNS; your provider cryptographically signs each message
        provider1._domainkey  →  (provider's value)

 DMARC  what to do when SPF/DKIM fail, and where to send reports
        _dmarc  →  v=DMARC1; p=none; rua=mailto:you@you.com

Missing these → your mail is an unauthenticated message claiming to be from a domain with no sending policy → the exact signature of phishing → silently discarded. Present → delivered.

Start DMARC at p=none ("report, don't reject"). Watch the reports for a couple of weeks, confirm all your legitimate senders pass, then tighten to p=quarantine and eventually p=reject. Going straight to p=reject silently kills mail from some service you forgot about.

Major mailbox providers now require authentication (SPF + DKIM + DMARC) for bulk senders, plus one-click unsubscribe. This is no longer optional.

The avatar and the logo

• The inbox sender avatar (the circle next to your name) is not controlled by your email. It comes from a Gravatar on the sending address, or BIMI (which needs DMARC enforcement and a paid certificate). Set a Gravatar; skip BIMI until you're large.
• Logos in email break. Clients block remote images by default, and transparent PNGs composite on unpredictable backgrounds. Ship a solid-background logo, hosted on your domain, with meaningful alt text (Chapter 13).

Sending limits fail on your best day

Free tiers are per-day, not per-month, for a reason: a per-day limit fails on the day your campaign works. Know the number, and upgrade before a launch, not during (Chapter 31).

📐 Best practice

Buy a per-product domain for customer-facing surfaces.

Set up SPF + DKIM + DMARC the day you buy the domain, before any sending code.

Three mechanisms for three jobs, routing, send-as, transactional.

Start DMARC at p=none, tighten gradually.

Use a real transactional provider, not your mailbox's built-in send.

Set a catch-all forwarding rule, people guess hello@, contact@.

Set a Gravatar on the sending address.

Ship a solid-background email logo with alt text.

Send yourself the real email before shipping, rendering bugs are invisible from code.

Test with a deliverability checker before your first real send.

Know your daily send limit and upgrade before a campaign.

💀 Common mistakes

Setting a From address and assuming it sends. DNS decides whether it's accepted.

No SPF/DKIM/DMARC. Silent discard, the default failure.

Debugging "not arriving" as a spam problem when it's authentication.

"It's in my Sent folder" as proof. Sent means your client accepted it; delivery is separate.

Sending transactional mail from your personal mailbox. Low limits, unbranded, poor deliverability.

Wrong credential type. Providers issue SMTP keys and API keys; they're not interchangeable, and mixing them gives a cryptic 401.

Confusing "not in spam" with "delivered." Not-in-spam means never accepted, a stronger signal than in-spam.

No catch-all. Guessed addresses bounce and you never know.

Transparent email logos. Render on unpredictable backgrounds.

DMARC p=reject from day one. Kills mail from a forgotten service.

Hitting a daily limit mid-campaign. Silent failures on your best day.

A studio subdomain on a consumer product. Reads as a hobby.

The professional workflow

 1. BUY THE DOMAIN (per-product); DNS on a clean provider

 2. RECEIVING — email routing: support@ + a catch-all → your inbox

 3. SENDING PROVIDER — sign up; authenticate the domain
    → it gives you DKIM + SPF records

 4. ADD DNS RECORDS
    SPF · DKIM (provider values) · DMARC (p=none, with a report address)

 5. WAIT for propagation. Verify with a DNS/mail checker.
    Aim for 9-10/10 on a deliverability test.

 6. REPLYING — "send as" in your client, using provider SMTP

 7. AVATAR — Gravatar on the sending address

 8. SEND YOURSELF THE REAL EMAIL. Check rendering + the logo.

 9. KNOW THE DAILY LIMIT; upgrade before campaigns

10. Tighten DMARC to quarantine → reject once reports are clean

Tools, websites & costs

The entire email stack is free except the ~$12/year domain. mail-tester.com is the single most useful tool, send it a message, get a 0-10 score with a line-by-line SPF/DKIM/DMARC breakdown. Run it before your first real send.

Alternatives & trade-offs

Forwarding + send-as vs a full mailbox. Cloudflare routing plus your existing Gmail's "send as" is free and equivalent to a paid mailbox for one person. A full mailbox (Workspace) gives real accounts, shared inboxes, and calendars, worth it once you have a team.

Transactional provider vs SMTP relay vs mailbox send. A transactional provider (Resend, Postmark) gives the best deliverability and logs; a mailbox's built-in send has low limits and poor reputation for volume. Use a provider for anything automated.

Self-managed mail server. Never. IP reputation alone is a full-time job.

One domain vs subdomain for sending. Many teams send transactional mail from a subdomain (mail.you.com) to isolate reputation from their primary domain. Worth doing once volume is real.

Checklist

• Domain is per-product, not a studio subdomain
• DNS on a clean provider
• Email routing: support@ + a catch-all
• SPF, DKIM, DMARC all published
• DMARC starts at p=none with a report address
• Verified with a checker; mail-tester score ≥ 9/10
• Automated mail sends via a transactional provider
• "Send as" configured for human replies
• Gravatar set on the sending address
• Email logo is solid-background with alt text
• I have received the real email and checked rendering
• Daily send limit known, with a plan for exceeding it

📓 Case Study: email in the Sent folder, and nowhere else

Project: SOLIS. The best debugging story in the book, because every single step reported success.

The stack, once it worked, three mechanisms for three jobs: free email routing forwarded support@ (plus a catch-all) to a personal inbox for receiving; the mailbox's "send as" plus a provider's SMTP handled human replies; and a transactional provider over a DKIM-authenticated domain sent the automated confirmations. Cost: $0 plus the domain.

💀 The saga. The waitlist confirmation emails weren't arriving:

"i never recieved a confirmation email after joining waitlist (in the sheet its recorded tho)"

Two rounds were spent on the obvious suspect, send permissions, wrongly:

"i have already authorized still didnt get the email" "provided the necessary permissions still didnt sreceive email"

The obvious cause was not the cause. Then the clue that cracked it:

"its there in sent, but its not there in spam or any other folder in reciver side? (is it autodeleting or something?)"

Read that carefully. In Sent, so the send succeeded. Not in the inbox. And not in spam either.

📐 Not-in-spam is the tell. Spam means "delivered and filed away." Absent from spam means it was never accepted, the receiving server discarded it upstream. The instinct, "is it autodeleting?", was exactly right.

The root cause: the mail was sent from support@ on a domain with no SPF, no DKIM, no DMARC, an unauthenticated message claiming to be from a domain that had never published any sending policy. That is the precise signature of phishing, so major providers discard it silently, with no bounce (bounces get abused too).

The message was perfect. The domain had no cryptographic identity.

The fix was to authenticate the domain, add the provider's DKIM records and SPF to DNS, and send via the transactional API rather than the mailbox alias. One more trap on the way:

"Error: Brevo API 401: {"message":"Key not found"}"

The provider issues several credential types, an SMTP key and an API key, that look similar and aren't interchangeable. Wrong key, cryptic 401.

Resolution, and a last instructive detail:

"it worked, i got the email now… but just a note: i didnt see it in sent of [my mailbox] now"

Correct, the mail was now sent by the provider's servers, not the mailbox, so it appears in the provider's log, not the Sent folder. Not a bug; the architecture working, but it feels wrong if you don't know why, and it's the kind of thing that makes people "fix" a working system.

⚠️ Deviation: the DNS records were added reactively, after the failure, rather than the day the domain was bought. Fifteen minutes of setup up front, SPF, DKIM, DMARC via the provider's wizard, would have eliminated the entire evening's debugging.

Lessons

1. A support address on your own domain is a store requirement. Plan it early.
2. Setting a From address is not being allowed to use it. DNS decides.
3. ⭐ Silent discard is the default failure. No bounce, no spam folder, check authentication first.
4. "It's in Sent" proves nothing. Delivery is a separate event.
5. Not-in-spam is stronger evidence than in-spam. It means never accepted.
6. Three jobs, three mechanisms, receiving, human replies, automated sending.
7. Set up SPF/DKIM/DMARC the day you buy the domain. Fifteen minutes; a whole failure class gone.
8. API keys and SMTP keys differ. Check the type before debugging further.
9. Send yourself the real email. Rendering bugs are invisible from code.
10. Provider-sent mail isn't in your Sent folder. Expected, don't "fix" it.

Next: Chapter 36: App Store Preparation →