Email Infrastructure

Email looks simple and is secretly one of the most intricate systems on the internet. This is the lecture that turns “why is our mail in spam?” from a mystery into a checklist.

⏱ ~18 min · 🟡 Intermediate · Prerequisites: Lectures 1–3 (especially MX records)

🎯 What you’ll be able to do

• Explain how a message travels via SMTP and how you read it via IMAP/POP
• Distinguish a mailbox, an alias, and a forward — and why the difference saves money
• Set up the three deliverability records (SPF, DKIM, DMARC) and explain what each proves
• Separate “human mailboxes” from “app-sent transactional mail” — and why you should

The mental model

Email is letters between post offices. Your provider’s mail server is your post office. To send, it hands the letter to the recipient’s post office (found via their MX record). To prevent forgery, modern email makes the sender prove the letter is really from your domain — that’s SPF/DKIM/DMARC.

The protocols: SMTP vs IMAP/POP

SENDING  →  SMTP  (Simple Mail Transfer Protocol)   — pushes mail server→server
READING  →  IMAP  (keeps mail on the server, syncs across devices)  ← prefer this
         or  POP  (downloads to one device, often deletes from server) ← legacy

Note

Use IMAP, not POP, on modern accounts — it keeps your mail on the server so your phone, laptop, and webmail all show the same thing. Note: Zoho’s free plan disables IMAP — one reason the migration plan picks the paid Mail Lite tier.

Mailbox vs Alias vs Forward — the money-saver

This distinction is where you save (or waste) money:

sales@      ─┐
support@    ─┼──►  all aliases of  ──►  darshan@  (one real, paid mailbox)
info@       ─┘

The lesson

You rarely need a paid mailbox per address. One paid mailbox + many free aliases covers role addresses (sales@, support@, info@). Only addresses that need their own login and storage (a real person) should be a paid mailbox.

Deliverability: SPF, DKIM, DMARC

Because anyone can claim to send “from” your domain, mailbox providers check three TXT-based records. Get these wrong → spam folder. Get them right → inbox.

Email arrives claiming to be from assure.ayrisglobal.com
   → SPF:   is the sending IP on the domain's approved list?     (TXT record)
   → DKIM:  does the cryptographic signature verify?            (TXT record)
   → DMARC: if either failed, follow this policy (reject/quarantine)  (TXT record)

Watch the same envelope run that gauntlet twice — once as legit mail you sent, once as a spoofer pretending to be your domain — and see exactly which check catches the fake:

The classic mistake

When you send mail from two systems on one domain — e.g. Zoho (human mail) and a transactional service (app mail) — your SPF record must authorize both, and each needs its own DKIM. Forget one and that system’s mail silently lands in spam. Best practice: send app mail from a dedicated subdomain (e.g. send.ayrisglobal.com) so its reputation and records are isolated from your human mail.

The two kinds of email (don’t mix them)

Never send app mail through your mailbox provider

It tanks deliverability and can get your human mailboxes throttled or blocked. Transactional providers are built for volume, give you per-message logs, and (when sent from a subdomain) keep your primary domain’s reputation clean.

Quick check: will it land in the inbox?

🧪 Try it yourself

# Where does mail for the domain get delivered? (the inbound provider)
dig assure.ayrisglobal.com MX

# Read the SPF record (the sender guest-list)
dig ayrisglobal.com TXT | findstr spf      # Windows
dig ayrisglobal.com TXT | grep spf         # Mac/Linux

# Look up a DMARC policy (lives at a special subdomain)
dig _dmarc.ayrisglobal.com TXT

Then paste your domain into mxtoolbox.com — it audits MX/SPF/DKIM/DMARC in one shot and flags what’s missing. This is the tool the pros open first when “email is broken.”

✅ Check yourself

📚 Resources

• 🟢 Cloudflare — What is email security (SPF/DKIM/DMARC): cloudflare.com/learning/email-security
• 🟢 MXToolbox — instant domain mail audit: mxtoolbox.com
• 🟡 Google — email sender guidelines: support.google.com/mail/answer/81126
• 🔴 AWS SES — SPF/DKIM/DMARC setup: docs.aws.amazon.com/ses

🧾 Key terms

SMTP · sending · IMAP/POP · reading (synced / downloaded) · MX · inbound mail destination · Mailbox · paid inbox · Alias / Forward · free extra addresses · SPF · sender guest-list · DKIM · signature/seal · DMARC · fail policy · Transactional email · automated app mail.

One-line summary

Mail is delivered to a domain’s MX, sent via SMTP, read via IMAP, and trusted via SPF/DKIM/DMARC. Pay for mailboxes (real people), get aliases free, and send app mail through a dedicated transactional provider on its own subdomain.

Still Unclear?

Copy-paste any of these into Claude to go deeper:

Walk me through what SPF, DKIM, and DMARC each check when an email
arrives, in the order a mailbox provider runs them. Use a concrete
example of a spoofed email getting caught.

I send human mail from Zoho and app mail from a transactional
service on the same domain. Show me exactly what my SPF, DKIM, and
DMARC records need to look like so neither stream goes to spam.

Explain the difference between a mailbox, an alias, and a forward
like I'm setting up email for a small business with 7 addresses but
only 3 real people. What's the cheapest correct setup?

Why AI Can’t Do This For You

AI can write you a textbook-perfect SPF record, but it can’t see your DNS, your two-system sending setup, or the fact that someone added a transactional service last month and never updated the guest-list. Deliverability bugs are diagnosed by reading the actual records and headers of your domain and reasoning about which check failed and why — the exact judgment you build by running dig and mxtoolbox on real domains yourself. The day mail mysteriously lands in spam, the person who understands the SPF/DKIM/DMARC chain fixes it in minutes; the person who copy-pasted a config stares at a black box.

Module done? Add it to today’s tracker