Setting up email infrastructure sounds like it should be straightforward. You pick an email service, configure a few DNS records, and start sending. In practice, the gap between a basic setup and one that consistently delivers to the inbox is enormous. Companies burn months of effort on email campaigns only to discover their infrastructure was undermining them from day one.
Getting your infrastructure right from the start saves you from the painful process of rebuilding trust with mailbox providers after deliverability has already tanked. Here is how to set everything up properly, whether you are building a new email program or fixing an existing one.
Choosing Your Sending Infrastructure
The first decision is how you will send your email. There are three main approaches, each with different trade-offs.
Shared infrastructure through an ESP. Services like Mailchimp, Brevo, ConvertKit, and Campaign Monitor handle the technical infrastructure for you. You send through their servers on shared IP addresses alongside thousands of other senders. The upside is simplicity: you do not need to manage servers, IPs, or MTA configuration. The downside is shared reputation. If other senders on your IP behave poorly, it can affect your deliverability. For most businesses sending under 50,000 emails per month, shared infrastructure from a reputable ESP is perfectly adequate.
Dedicated infrastructure through an ESP. Many ESPs offer dedicated IP addresses for higher-volume senders. You get your own IP address with its own reputation, separate from other senders. This gives you more control but also more responsibility. You need to warm up the IP, maintain consistent sending volume, and manage your reputation yourself. Dedicated IPs typically make sense when you are sending over 100,000 emails per month consistently.
Self-hosted infrastructure. Some organizations run their own mail transfer agents (MTAs) on their own servers. This gives maximum control over every aspect of the sending process. Open-source MTAs like Postfix, PowerMTA, and Postal are popular choices. Self-hosted infrastructure is complex to manage and requires significant expertise, but it offers the most flexibility for high-volume senders with specific requirements. Most companies do not need this unless they are sending millions of emails per month or have regulatory requirements that prevent using third-party services.
DNS Configuration: The Foundation
Proper DNS configuration is non-negotiable. These records tell the world that your email is legitimate and that you have authorized the servers sending on your behalf.
SPF Records
Your SPF (Sender Policy Framework) record lists every server authorized to send email from your domain. Start by identifying every service that sends email on your behalf: your ESP, your transactional email service, your CRM, your helpdesk, and any other tool that sends email using your domain.
Build your SPF record to include all of them. For example: v=spf1 include:_spf.google.com include:amazonses.com include:sendgrid.net -all
Important SPF considerations:
- The 10-lookup limit is real. Each include statement can trigger multiple DNS lookups, and SPF breaks if you exceed 10 total. Use flattening tools if you are hitting the limit.
- Use -all (hard fail) at the end, not ~all (soft fail). Hard fail tells receiving servers to reject unauthorized senders outright.
- Only include services that actually send email. Do not add providers you are evaluating but have not deployed yet.
- Test your SPF record after every change using tools like MXToolbox or dmarcian.
DKIM Configuration
DKIM (DomainKeys Identified Mail) requires generating a public/private key pair and publishing the public key in your DNS. Each sending service needs its own DKIM configuration.
Most ESPs provide you with a DKIM record to add to your DNS. The record is usually a CNAME or TXT record at a specific subdomain. For example, your ESP might ask you to create a CNAME record at selector._domainkey.yourdomain.com pointing to their DKIM key.
Key DKIM practices:
- Use 2048-bit keys. Some older guides mention 1024-bit, but 2048 is now the standard and provides better security.
- Configure DKIM for every service that sends email using your domain. If you miss one, those emails will fail DKIM checks.
- Rotate DKIM keys periodically, at least annually. This limits the impact if a key is compromised.
- Test DKIM signatures by sending emails to a testing service and verifying the signature is present and valid.
DMARC Policy
DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also enables reporting so you can see who is sending email using your domain.
Start with a monitoring policy: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
This tells servers to send you reports about authentication results without taking action on failures. Run this for 2-4 weeks while you review the reports and make sure all your legitimate sending services are properly authenticated.
Then tighten the policy progressively:
- Move to p=quarantine with a low percentage: p=quarantine; pct=10 (only quarantine 10% of failures initially)
- Increase the percentage as you confirm legitimate email is not being affected
- Finally move to p=reject when you are confident all legitimate email passes authentication
DMARC reports can be overwhelming in raw XML format. Use a DMARC report processing service like dmarcian, Postmark DMARC, or Valimail to make them readable and actionable.
Additional DNS Records
PTR (Reverse DNS): Your sending IP address should have a PTR record that resolves back to a hostname under your domain. This is configured through your hosting provider, not your DNS provider. Many mailbox providers check PTR records and may reject or filter email from IPs without valid reverse DNS.
MX Records: Even if a domain is primarily used for sending, it should have MX records configured so it can receive email. Domains that can send but not receive look suspicious. At minimum, set up a basic mailbox to handle replies and bounces.
BIMI (Brand Indicators for Message Identification): This is optional but increasingly valuable. BIMI lets you display your brand logo next to your emails in supported inbox providers. It requires a validated DMARC policy at p=quarantine or p=reject and a Verified Mark Certificate (VMC). The setup is more complex, but it improves brand recognition and trust signals.
IP Warming: Building Reputation From Scratch
If you are starting with a new dedicated IP, you need to warm it up before sending at full volume. A new IP has zero reputation, and mailbox providers will throttle or filter your email until they see a pattern of good sending behavior.
A practical warmup schedule for a new dedicated IP:
- Days 1-3: 50 emails per day, exclusively to your most engaged subscribers
- Days 4-7: 100-200 emails per day
- Days 8-14: 500-1,000 emails per day
- Days 15-21: 2,000-5,000 emails per day
- Days 22-30: 5,000-20,000 emails per day
- Day 30+: Gradually increase to full volume
During warmup, prioritize sending to subscribers who consistently open and click. High engagement during warmup establishes a positive reputation baseline. If you start seeing spam folder placement or bounces during warmup, slow down and investigate before continuing.
Monitor Google Postmaster Tools throughout the warmup process. It shows your domain reputation and IP reputation on a scale from Bad to High. You want to see both climbing to Medium or High before scaling to full volume.
Separating Your Email Streams
Different types of email should be sent from different infrastructure to protect their independent reputations.
Transactional email (password resets, order confirmations, account notifications) should use a dedicated sending domain and IP. Transactional email has naturally high engagement rates and should not be mixed with marketing email, which has lower engagement. Sending both from the same infrastructure lets marketing email's lower engagement drag down transactional email's reputation.
Marketing email (newsletters, promotions, product announcements) should use its own sending domain and IP. This isolates any deliverability issues from affecting your transactional email.
Cold outreach should use completely separate domains and infrastructure. Cold email carries the highest risk of complaints and reputation damage, so it should be fully isolated from your opt-in email programs.
A common setup for a mid-size company might look like:
- notifications.yourdomain.com for transactional email (via Amazon SES or Postmark)
- news.yourdomain.com for marketing email (via Mailchimp or similar)
- yourbrand-outreach.com for cold email (via a dedicated cold email platform)
Bounce and Feedback Loop Processing
Your infrastructure needs to properly handle bounces and spam complaints. This means configuring your systems to:
Process bounces in real time. When a message bounces, the address should be flagged immediately so it does not receive subsequent emails. Hard bounces should result in immediate suppression. Soft bounces should be tracked and the address suppressed after 3-5 consecutive failures.
Register for feedback loops. Major ISPs offer feedback loops (FBLs) that notify you when recipients mark your email as spam. Register for every FBL available: Yahoo, Microsoft, Comcast, and others. Gmail does not offer a traditional FBL but provides complaint data through Google Postmaster Tools.
Process FBL complaints automatically. When you receive a complaint through a feedback loop, the complaining address should be automatically suppressed. This needs to happen in near-real time. Sending additional emails to someone who has complained is one of the fastest ways to damage your reputation.
Testing Before You Send
Before launching any email from new infrastructure, test thoroughly.
Send test emails to seed lists. Seed lists are sets of test addresses across multiple mailbox providers (Gmail, Yahoo, Outlook, Apple Mail, etc.) that you control. Send your email to these addresses and check where they land: primary inbox, promotions, spam, or not delivered at all.
Check authentication headers. Open a received test email and examine the full headers. Look for SPF=pass, DKIM=pass, and DMARC=pass. If any of these show fail, something is misconfigured.
Test with email testing tools. Services like Mail-Tester, GlockApps, and Litmus can analyze your email for spam signals, authentication issues, and formatting problems before you send to your real audience.
Verify your domain is not pre-blacklisted. New domains sometimes end up on blacklists due to the previous owner's behavior or because they match patterns in predictive blacklists. Check your domain against major blacklists before sending.
Ongoing Maintenance
Email infrastructure is not something you set up once and forget. It requires regular attention.
- Review DMARC reports weekly to catch unauthorized senders or authentication failures
- Monitor sender reputation through Google Postmaster Tools and Microsoft SNDS
- Check blacklist status weekly
- Update SPF records when you add or remove sending services
- Rotate DKIM keys annually
- Review and clean your suppression lists quarterly
- Test deliverability with seed lists monthly
Good email infrastructure is invisible when it works and devastating when it does not. The time you spend setting it up correctly and maintaining it consistently pays for itself many times over in better deliverability, higher engagement, and fewer emergency firefighting sessions when things go wrong.