# Cold email infrastructure: domains, authentication, sending and monitoring Canonical URL: https://www.martechdevs.com/blog/cold-email-infrastructure By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo) Data Engineer and Co-founder, martechdevs Published: 2025-03-25 Last updated: 2026-09-14 Cold email infrastructure is the system that controls sender identity, authentication, delivery, replies and suppression for an outbound programme. A workable setup needs appropriate provider terms, accurate recipient selection, SPF, DKIM, DMARC, functioning opt-outs and operational monitoring. Buying more domains or warming more inboxes does not establish permission to send or guarantee inbox placement. A campaign can show “sent” while the receiving provider rejects the message, places it in spam or accepts it into an unmonitored mailbox. Infrastructure work follows the message through each of those stages and makes the result visible to the person responsible for the programme. ## Establish the sending policy before buying infrastructure Document the audience, countries, source of contact data, relevance of the offer, opt-out process and sending provider. Legal permission and provider permission are separate tests. A technically authenticated message can still violate a provider's acceptable-use policy. Google's Gmail policy prohibits spam and unsolicited commercial mail. Microsoft says Exchange Online is not suited to bulk-mailing scenarios and directs legitimate bulk senders towards appropriate services. Do not choose a mailbox platform solely because its published limit looks generous. [Gmail programme policy](https://support.google.com/mail/answer/16734397?hl=en), [Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits). The legal rules also vary. The US CAN-SPAM framework covers B2B commercial messages; UK guidance distinguishes corporate subscribers from sole traders and some partnerships, with data-protection obligations still relevant. These are jurisdiction-specific starting points, not a worldwide permission rule. [FTC business guidance](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business), [ICO B2B guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/business-to-business-marketing/). [Martechdevs' GTM engineering service](https://www.martechdevs.com/gtm-engineering) connects recipient rules, sending systems, CRM state and reporting. The [Clay versus Apollo guide](https://www.martechdevs.com/blog/clay-vs-apollo) covers tool selection; the infrastructure must still work whichever sequencer you choose. ## Design the domain and mailbox ownership clearly Use domains and sender names that clearly identify the business. Keep registration, DNS and mailbox administration in company-controlled accounts with named owners and renewal records. An agency can manage the setup without owning the assets permanently. Separating transactional, support and promotional streams can help operations and diagnosis. It does not create a complete reputation firewall, and a subdomain should not be treated as a way to escape the parent domain's sending history. Avoid lookalike identities, invented employees and misleading reply-thread subjects. Recipients should understand who contacted them and be able to verify the business. A working website and monitored reply address are basic parts of that trust. For each sending stream, record the visible From domain, envelope sender or return-path domain, DKIM signing domain, sending provider and reply destination. Those fields explain authentication failures more precisely than a list of purchased inboxes. ## SPF, DKIM and DMARC solve different problems **SPF** lets a domain specify which sending hosts are authorised for its envelope identity. Publish one applicable SPF policy at the domain being checked, incorporating the legitimate senders. Multiple independent SPF records at that name can cause a permanent error. SPF also limits DNS-querying mechanisms, so nested includes need attention. [SPF specification](https://www.rfc-editor.org/rfc/rfc7208.html). **DKIM** adds a cryptographic signature using a sending domain and selector. Publish the provider's public key or CNAME exactly as instructed and activate signing in the provider. A DNS record alone does not prove messages are being signed. **DMARC** connects authentication to the domain recipients see in the From address through alignment. A passing SPF result for an unrelated provider domain is not sufficient by itself; aligned SPF or DKIM is needed for DMARC to pass. Start by identifying all legitimate sources and reviewing authentication results. A monitoring policy can help reveal missing senders before moving to stricter enforcement. Do not copy a reject policy into production without checking invoices, support tools and other legitimate mail streams. ## Verify an actual message, not just the DNS records Send a test to accounts you control and inspect its full headers. Check `Authentication-Results`, the DKIM `d=` domain and selector, the return path, the visible From address and any forwarding involved. An illustrative diagnostic record might read: ```text Visible From: person@example.com Envelope domain: bounce.mail.example.com DKIM signing domain: example.com SPF result: pass DKIM result: pass DMARC result: pass Reply destination: monitored company mailbox ``` These are example values, not a DNS configuration to paste. Use the domains and records supplied for your own service. Test every sending route. An email sent manually from a mailbox can authenticate correctly while a sequence sent through a different service does not. Repeat the check after changing providers, domains or signing keys. ## Understand the major receiving-provider requirements Google's requirements for personal Gmail recipients include authentication, valid DNS, TLS and low complaint rates. Bulk senders have additional SPF, DKIM, DMARC alignment and one-click unsubscribe requirements for marketing and subscribed messages. Google's guidance recommends staying below a 0.1% reported spam rate and avoiding 0.3% or higher. [Gmail sender guidelines](https://support.google.com/mail/answer/81126?hl=en). Google's bulk-sender classification aggregates traffic from the same primary domain, including subdomains. Splitting traffic across subdomains does not turn one bulk sender into unrelated small senders. Read the current FAQ for classification and enforcement details. [Gmail sender FAQ](https://support.google.com/mail/answer/14229414?hl=en). Yahoo requires stronger authentication and easy unsubscribe for bulk senders, with spam complaints below 0.3% and opt-outs honoured within two days. Its complaint denominator is based on mail delivered to the inbox, which may differ from your sending platform's totals. [Yahoo sender requirements](https://senders.yahooinc.com/best-practices/). Microsoft's Outlook.com consumer-service announcement covers high-volume domains and requires SPF and DKIM to pass, with DMARC at least `p=none` and alignment. Its April 2025 update specifies rejection of noncompliant messages from the May rollout. This is distinct from Exchange Online's outbound limits. [Microsoft's announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730). ## Implement unsubscribe as a system-wide state A footer link and a reply saying “stop” should both lead to a reliable suppression process. Record the address, relevant person or account identifier, scope, timestamp and source. Propagate the state to every active sequence and future import. For standards-based one-click unsubscribe, RFC 8058 uses the `List-Unsubscribe` and `List-Unsubscribe-Post` headers, an HTTPS endpoint and DKIM coverage of those headers. The endpoint must work without requiring a login or additional recipient action. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). Test the full path with a controlled address. Unsubscribe it, confirm the queued next step is cancelled, then reimport the same record. It should remain suppressed. A new CSV should not erase a person's earlier choice. Separate necessary service communications from promotional subscriptions, with an explicit policy for each. Labelling a sales message “transactional” does not make it a service notice. ## Sending limits are ceilings, not delivery targets Mailbox, recipient, tenant and API limits measure different things. A message with several recipients may consume more than one recipient unit. Delegated sending and shared infrastructure can also affect which account's limit applies. Microsoft now documents a tenant-level external recipient limit alongside mailbox limits. Therefore, multiplying inbox count by a per-mailbox limit can overstate capacity. Inspect the current tenant report and selected service's rules. [Exchange Online sending limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits). Set a programme volume based on eligible recipients, relevance, operational capacity and observed delivery health. A sequencer's “unlimited” setting does not override the sending provider or the receiving provider. If messages are rejected or deferred, inspect the reason and pause the affected flow. Adding new domains to continue the same unwanted traffic does not repair its cause. ## Warmup is not a certification New sending infrastructure should be introduced gradually with legitimate, expected communication and close monitoring. There is no universal number of days after which a domain becomes safe for any audience or volume. Some tools sell automated warmup that exchanges messages within a network. A high score from that network describes its own observations. It does not establish how real prospects or Gmail, Yahoo and Microsoft will treat your campaign. Evaluate the method against provider terms and the data it can access. Do not grant a warmup service unnecessary access to customer conversations. Keep the decision focused on actual authentication, recipient feedback and delivery evidence. ## Model capacity and cost with explicit assumptions Suppose a fictional programme has 400 eligible new contacts per month and sends an average of 1.8 messages per contact after replies and opt-outs stop follow-ups. That creates 720 campaign messages. Add 180 genuine reply-handling messages and the planning volume is 900, or 45 per working day across 20 days. That calculation describes demand. It does not establish a safe daily allowance or tell you to buy a particular number of inboxes. Check it against the chosen provider's permitted use and the team's capacity to respond. For a budget, suppose two managed mailboxes cost an assumed $12 each, sending software $50, verification $20 and domains $24 annually. The illustrative recurring subtotal is $96 a month after spreading the domain cost over 12 months. Add setup, monitoring and operator time. These are planning inputs, not current vendor quotes. If one qualified conversation takes three hours of research and follow-up, saving $10 on software may have little effect on the real cost. The [GTM engineering guide](https://www.martechdevs.com/blog/what-is-gtm-engineering) explains how to measure useful outputs rather than raw sending activity. ## Build a monitoring loop that leads to action ![Eligible recipients pass through an authenticated sending route; delivery responses, replies, complaints and opt-outs update CRM and suppression records before health and volume reviews.](https://www.martechdevs.com/assets/blog/cold-email-infrastructure.svg) Track acceptance, hard bounces, temporary deferrals, authentication failures, complaints, opt-outs and qualified replies separately. “Delivered” often means the receiving server accepted the message, not that it reached the primary inbox. Use Google Postmaster Tools where sufficient data is available, Yahoo's feedback mechanisms and Microsoft sender diagnostics as appropriate. Low volume can leave some dashboards sparse. Missing data is not proof of perfect reputation. Keep provider response codes with timestamps and sending domains. A sudden rise in invalid-recipient bounces suggests a different problem from a DMARC failure or policy rejection. Route each to the person who can fix it. Treat open rates cautiously. Image handling and privacy features can distort them, and Google explicitly says it cannot verify third-party open-rate accuracy. Use reply quality and commercial outcomes alongside delivery health. ## Launch checklist - [ ] The audience and sending method meet applicable rules and provider terms. - [ ] Domains, mailboxes and DNS are owned by the company. - [ ] Sender identity and reply handling are accurate and monitored. - [ ] Every sending route passes the intended authentication checks. - [ ] One-click unsubscribe and visible opt-out routes work where required. - [ ] Suppression survives imports and cancels queued follow-ups. - [ ] Volume accounts for messages, recipients and tenant-level constraints. - [ ] Monitoring distinguishes acceptance, inbox placement and response. - [ ] A named owner can pause sending and investigate failures. - [ ] Costs include verification, operations and follow-up work. At Martechdevs, we build prospecting workflows with clear eligibility, controlled execution and documented handover. Start with the [free martech AI audit](https://www.martechdevs.com/martech-ai-audit), or explore an [AI assistant built around your approved workflows](https://www.martechdevs.com/custom-martech-ai-agent). ## Frequently asked questions ### Should we use Google Workspace or Microsoft 365? Choose based on the company's normal collaboration needs and the permitted sending use case. Neither is a blanket bulk-outreach service. Review current acceptable-use terms and sending limits, and use an appropriate provider for legitimate bulk communication. ### How many emails can one inbox safely send each day? There is no universal safe number. Technical limits, provider policy, recipient expectations, message quality and reputation all matter. A conservative-looking number copied from a forum is not a guarantee of delivery or permission. ### Do we need a separate domain? Separate streams can make ownership and diagnosis clearer, but they add assets to maintain and do not guarantee reputation isolation. Use an identity that transparently belongs to the business. Do not use domain rotation to avoid responding to complaints or blocks. ### What is the cheapest setup? The cheapest useful setup is the smallest one that supports the approved audience, reliable replies, authentication and suppression. Extra domains and inboxes create recurring costs and maintenance. Validate the offer and process before expanding infrastructure. ### Are Reddit warmup and deliverability recommendations reliable? They can suggest issues to investigate, but results depend on provider, audience and current rules. Verify technical claims against provider documentation and actual message headers. Treat guaranteed-inbox claims and fixed warmup timelines as claims to test, not established facts. ## Sources 1. [Gmail programme policy](https://support.google.com/mail/answer/16734397?hl=en). Accessed 14 September 2026. 2. [Exchange Online limits](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits). Accessed 14 September 2026. 3. [FTC CAN-SPAM guidance](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business). Accessed 14 September 2026. 4. [ICO B2B marketing guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/business-to-business-marketing/). Accessed 14 September 2026. 5. [SPF specification](https://www.rfc-editor.org/rfc/rfc7208.html). Accessed 14 September 2026. 6. [Gmail sender requirements](https://support.google.com/mail/answer/81126?hl=en). Accessed 14 September 2026. 7. [Gmail sender FAQ](https://support.google.com/mail/answer/14229414?hl=en). Accessed 14 September 2026. 8. [Yahoo sender requirements](https://senders.yahooinc.com/best-practices/). Accessed 14 September 2026. 9. [Microsoft Outlook.com sender requirements](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730). Accessed 14 September 2026. 10. [One-click unsubscribe standard](https://www.rfc-editor.org/rfc/rfc8058.html). Accessed 14 September 2026.