You want your AI agent to send and receive email. Simple, right? Fire off an SMTP call, point an MX record somewhere, and you're done. Except you're not. Without proper infrastructure, your agent's emails land in spam, get rejected outright, or never arrive at all. The difference between "my agent can email" and "my agent's emails actually get delivered" is a stack of acronyms most developers never wanted to learn.
This guide breaks down every layer of email infrastructure you need to understand — and why platforms like Dead Simple exist so you don't have to manage it yourself.
MX Records: The Front Door
MX (Mail Exchange) records are DNS entries that tell the world which servers accept email for your domain. When someone sends an email to agent@yourdomain.com, their mail server looks up the MX records for yourdomain.com and delivers the message to the server listed there.
MX records have a priority value — lower numbers get tried first. A typical setup might look like this:
yourdomain.com. MX 10 mx1.mailprovider.com.
yourdomain.com. MX 20 mx2.mailprovider.com.If mx1 is down, senders will fall back to mx2. Without MX records, nobody can deliver email to your domain at all. It's the most basic piece of email infrastructure, and it's the one most developers get right because it's obvious when it's missing — email just doesn't arrive.
SPF: Who's Allowed to Send
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourdomain.com, it checks the SPF record to see if the sending server's IP address is on the approved list.
yourdomain.com. TXT "v=spf1 include:_spf.deadsimple.email ~all"This record says: "Emails from yourdomain.com are legitimate if they come from Dead Simple's mail servers. Everything else is suspicious." The ~all at the end is a soft fail — it tells receivers to flag unauthorized senders but not necessarily reject them. A stricter -all tells receivers to reject anything not on the list.
Without SPF, anyone can spoof your domain. With a misconfigured SPF, your legitimate emails get flagged. It's a narrow path, and one that AI agent developers frequently get wrong when self-hosting because they forget to update their SPF record every time they change mail providers or add a new sending service.
DKIM: Proving the Email Wasn't Tampered With
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and the receiving server verifies it using a public key published in your DNS records.
selector._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."DKIM proves two things: the email actually came from your domain, and it wasn't modified in transit. This matters more than you might think. Email passes through multiple servers between sender and recipient, and any of them could theoretically alter the content. DKIM catches that.
The tricky part is key management. You need to generate key pairs, publish the public key in DNS, configure your mail server to sign with the private key, and rotate keys periodically. If you're running your own mail infrastructure, this is manual work that's easy to get wrong and hard to debug when it fails. A misconfigured DKIM signature doesn't break delivery outright — it just quietly tanks your deliverability score over time.
DMARC: The Policy Layer
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. It also gives you reporting so you can see who's sending email as your domain — both legitimate and fraudulent.
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"The policy options are:
- none — Monitor only. Collect reports but don't take action. Use this while you're setting up.
- quarantine — Send failing messages to spam.
- reject — Block failing messages entirely. This is the goal.
DMARC is the enforcement mechanism. SPF and DKIM authenticate; DMARC decides what happens when authentication fails. Without DMARC, SPF and DKIM failures are suggestions. With DMARC set to reject, they're rules.
The reporting feature is underrated. DMARC aggregate reports show you every server that sent email using your domain. This is how you discover that a marketing tool you forgot about is still sending as your domain, or that someone in another country is spoofing your addresses.
Why Deliverability Matters for AI Agents
Deliverability isn't a binary pass/fail — it's a reputation score that changes over time. Every email your agent sends contributes to your domain's reputation. Send too many emails too fast from a new domain? Reputation drops. Get marked as spam by a few recipients? Reputation drops. Fail SPF or DKIM checks? Reputation drops.
For AI agents, this is especially critical because:
- Agents send at scale. A support agent might send hundreds of replies per day. A sales agent might send thousands of outreach emails per week. Volume amplifies both good and bad sending practices.
- Agents don't notice soft failures. A human notices when their emails aren't getting replies. An agent just keeps sending, potentially digging a deeper reputation hole.
- Reputation is per-domain, not per-inbox. One badly behaved agent on your domain can tank deliverability for all your agents.
- Recovery is slow. Building domain reputation takes weeks. Destroying it takes hours.
Shared Domains vs. Custom Domains
When you're getting started, a shared domain (like agent@yourco.deadsimple.email) lets you send email immediately without any DNS configuration. The provider handles SPF, DKIM, and DMARC on the shared domain, and your emails go out with proper authentication from day one.
The tradeoff is branding and reputation isolation. On a shared domain, your reputation is pooled with other users. If someone else on the shared domain sends spam, it can affect your deliverability. Shared domains are great for development, testing, and low-volume use cases.
Custom domains (agent@yourdomain.com) give you full control. You build your own reputation, your emails look professional, and you're isolated from other users' behavior. The cost is setup time: you need to add MX, SPF, DKIM, and DMARC records to your DNS. With Dead Simple, this means adding a few DNS records and clicking a verify button — the platform generates all the values for you.
How Dead Simple Pre-Configures Everything
When you create an account on Dead Simple, here's what happens behind the scenes:
- Shared domain ready instantly. Your inboxes work on our pre-authenticated shared domain with no setup. SPF, DKIM, and DMARC are already configured and monitored.
- Custom domain in minutes. Add your domain, and we generate the exact DNS records you need. Add them to your registrar, click verify, and you're live. We handle DKIM key generation, rotation, and signing automatically.
- Dedicated sending infrastructure. Your emails are sent through IP addresses with established reputation. On higher plans, you get dedicated IPs that build reputation exclusively for your domain.
- Automatic warm-up. New domains and IPs need to build reputation gradually. We manage sending volume ramp-up automatically so you don't accidentally blast 10,000 emails on day one from a cold domain.
- Monitoring and alerts. We track bounce rates, spam complaints, and authentication pass rates. If something goes wrong, you know about it before it tanks your reputation.
Common Pitfalls When Self-Hosting
We built Dead Simple because we've seen (and experienced) every way email infrastructure can go wrong. Here are the most common mistakes developers make when trying to run their own mail servers:
- Forgetting to set up a reverse DNS (PTR) record. Many receiving servers check that your sending IP's reverse DNS matches your domain. Without it, you look like a spammer operating from a random VPS.
- Running on a blacklisted IP. Cloud provider IP ranges are frequently blacklisted because they're commonly used to send spam. Your brand new EC2 instance might already be on a blacklist before you send your first email.
- Not monitoring bounce rates. Sending to invalid addresses hurts your reputation. Without monitoring, you don't know it's happening until Gmail starts sending all your emails to spam.
- Skipping warm-up. Sending 5,000 emails on day one from a new domain is a fast way to get blocklisted. ISPs expect new domains to start small and ramp up gradually.
- Letting DKIM keys go stale. Best practice is to rotate DKIM keys every 6-12 months. Most self-hosted setups set it once and forget it forever.
- No DMARC reporting. Without DMARC reports, you're flying blind. You don't know if your authentication is working correctly until someone complains that your emails are landing in spam.
The Bottom Line
Email infrastructure is a solved problem — but it's a solved problem with a lot of moving parts. For AI agent developers, the calculus is straightforward: every hour you spend debugging DNS records, managing DKIM keys, and monitoring deliverability is an hour you're not spending on your actual product.
Dead Simple handles the infrastructure so you can focus on what your agent does with email, not how email works. Create an inbox, send a message, receive a webhook — and let us worry about whether your MX records are right.
Ready to skip the infrastructure headaches? Join the waitlist and give your AI agents email that actually gets delivered.