Summary
When setting up email sending subdomains, understanding the necessary DNS records is crucial for ensuring successful email delivery. This includes determining whether A records are essential and if SSL certificates are required for these subdomains. The consensus among email deliverability professionals is that while A records can serve a supporting role for transparency or redirection, they are not strictly necessary for email sending itself. Similarly, SSL certificates (TLS) are generally not required for email sending subdomains, as email encryption (TLS) happens during the SMTP connection, independent of HTTP-based SSL for web content. Instead, the focus should be on robust email authentication records like SPF, DKIM, and DMARC.
Key findings
- A records: A records are not strictly essential for email sending from subdomains. Email delivery relies primarily on MX records and other authentication DNS entries.
- SSL certificates (TLS): SSL certificates are generally not required for email sending subdomains. Encryption for email is handled by Transport Layer Security (TLS) during the mail transfer process, which is distinct from the SSL certificates used for securing web traffic on HTTP.
- Core DNS records: The most critical DNS records for email deliverability on subdomains include SPF, DKIM, DMARC, and MX records.
- Web presence: While not required for sending, setting up an A record to point a sending subdomain to a web server that redirects to your main website can be a friendly practice for transparency, as outlined in M3AAWG's Best Practices for Sending Domains.
- Subdomain purpose: Subdomains for email sending are typically used to segment email traffic and protect the main domain's reputation, as discussed in our guide on why to use subdomains for email marketing deliverability.
Key considerations
- Provider instructions: Always adhere to the specific DNS record setup instructions provided by your Email Service Provider (ESP), as they will detail the necessary SPF, DKIM, and DMARC configurations for their sending infrastructure.
- Security vs. deliverability: Distinguish between DNS records required for email deliverability (like SPF, DKIM, DMARC, MX) and those for web security (like A records pointing to HTTPS sites with SSL certificates). While both are important for a domain's overall health, they serve different primary functions.
- Cost of SSL: Be cautious of external IT providers suggesting costly wildcard SSL certificates for email sending subdomains, as these are typically unnecessary for email delivery itself and free options like Let's Encrypt exist for web servers if such a setup is desired for other reasons.
- Domain reputation: Proper DNS setup for email authentication contributes significantly to your sending domain's reputation, which directly impacts inbox placement.
What email marketers say
Email marketers often navigate the complexities of DNS records with a focus on practical implications for campaign performance. Their primary concern is ensuring emails reach the inbox without issues, which means prioritizing deliverability-critical records. While the technical specifics can be daunting, marketers generally rely on their ESP's guidance and aim to understand the 'why' behind each record type, especially concerning email authentication.
Key opinions
- ESP guidance is key: Marketers largely follow the DNS setup instructions provided by their Email Service Providers (ESPs) like Mailchimp or SendGrid, as these are tailored to their platforms' requirements.
- A records are secondary: Many marketers consider A records for email sending subdomains to be non-essential for actual email delivery, focusing instead on authentication records.
- SSL for tracking links: Some marketers acknowledge that SSL certificates might be relevant for tracking domains or redirect links associated with emails to ensure a secure user experience (HTTPS) when recipients click them, rather than for the email sending process itself.
- Authentication first: The priority for email sending is always on implementing correct SPF, DKIM, and DMARC records to prevent emails from landing in spam folders.
Key considerations
- Distinguishing requirements: It's important for marketers to differentiate between DNS requirements for email delivery versus those for web presence or click-tracking, which may involve A records and SSL.
- Avoiding unnecessary costs: Marketers should question requests for expensive SSL certificates for email sending subdomains if the primary goal is just deliverability, as these are rarely necessary.
- Subdomain purpose clarity: Clear communication with IT departments is vital to ensure subdomains are configured correctly for email sending, without overcomplicating the setup with extraneous records (like unneeded A records for email sending domains) or SSL certificates.
Marketer view
Marketer from Email Geeks asks about the correct DNS setup for email sender subdomains, including where they should point. They express a lack of familiarity with the technical details, relying on their IT department and their ESP (Mailchimp) for guidance on verification processes, particularly regarding A records for splitting or updating sender email addresses.
Marketer view
Marketer from Email Geeks suggests that their IT department is claiming they need to order expensive wildcard certificates for the domains, costing 159 euros per domain yearly. They question whether these wildcard certificates are truly necessary for sending emails from subdomains, indicating skepticism about the proposed costs and requirements.
What the experts say
Email deliverability experts consistently emphasize that authentication records (SPF, DKIM, DMARC) are paramount for email sending subdomains, far more so than A records or SSL certificates for the subdomains themselves. They focus on the practical mechanisms that influence inbox placement and sender reputation, often dispelling common misconceptions about what constitutes a necessary DNS configuration for email.
Key opinions
- A records are optional: Experts agree that A records are not a requirement for a subdomain to successfully send emails. The crucial elements are the proper mail exchange and authentication records.
- SSL is not for sending: SSL certificates are generally irrelevant for the direct act of sending email from a subdomain. Email transport layer security (TLS) is handled at the server level during SMTP connections, which is separate from securing web content or HTTP redirects (see our best practices for ESPs).
- Authentication is vital: The records that truly matter for email deliverability are SPF (for authorized senders), DKIM (for message integrity), and DMARC (for policy enforcement and reporting). These are TXT records that publish critical information about the sending domain.
- MX records are fundamental: MX records, which dictate where mail for a domain should be delivered, are foundational for any domain involved in email, even if it's a sending-only subdomain that doesn't expect to receive replies.
Key considerations
- Prioritize core records: When configuring DNS for sending subdomains, focus resources on accurately setting up SPF, DKIM, DMARC, and MX records first. These directly impact whether emails are accepted by receiving mail servers.
- Beware of unnecessary expenditures: Be vigilant against proposals for unnecessary services, like expensive wildcard SSL certificates, from IT teams that may misunderstand the specific requirements for email sending infrastructure, particularly on unique or shared email subdomains.
- Purpose of A records: If an A record is desired for a sending subdomain (e.g., for transparency), it can simply point to a standard web server that redirects to the main website, with or without a free SSL certificate like those from Let's Encrypt.
- Understanding ISP checks: ISPs and reputation providers primarily check email-specific DNS records, not necessarily A records or SSL for the sending subdomain itself, to determine sender legitimacy.
Expert view
Expert from Email Geeks confirms that A records are truly a side quest when setting up subdomains for email sending. They emphasize that other records, such as TXT records for SPF, MX records, TXT for DKIM, and TXT for DMARC, are far more critical for successful email delivery.
Expert view
Expert from Email Geeks clearly states that you do not have to have an A record to send emails. However, they stress that it is absolutely essential to have proper SPF, MX, DKIM, and DMARC configurations in place for email authentication and deliverability.
What the documentation says
Official documentation from DNS providers and email standards bodies clarifies the purpose and necessity of various DNS record types for email. These sources consistently confirm that email delivery primarily relies on MX records and authentication mechanisms like SPF, DKIM, and DMARC, rather than A records or SSL certificates associated with web presence. They provide the technical specifications that underpin email's functioning on the internet.
Key findings
- DNS record types: DNS documentation (e.g., Cloudflare Docs) lists various record types including A, AAAA, CNAME, MX, and TXT, each serving distinct purposes for domain resolution and service location.
- Email specific records: For email, MX records are fundamental for directing incoming mail, while TXT records are used to publish SPF, DKIM, and DMARC policies for outgoing mail authentication.
- SSL/TLS for transport: TLS (often colloquially referred to as SSL in this context) secures the connection between mail servers during email transmission (SMTP), but this is independent of an SSL certificate on the sending domain itself, which typically secures HTTP traffic.
- M3AAWG Best Practices:M3AAWG's Best Practices for Sending Domains recommends ensuring proper DNS records like MX, SPF, DKIM, and DMARC are configured for domains used in email, with an optional A record pointing to a web server for transparency.
Key considerations
- RFC compliance: Adherence to RFC standards (Request for Comments) for email (like RFC 5321 for SMTP, RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC) is fundamental for interoperability and deliverability. These documents don't mandate A records or web-SSL for email sending subdomains.
- DNS propagation: After making DNS changes for email subdomains, it's crucial to account for DNS propagation time, which can vary and impact when new configurations become active across the internet.
- Record placement: Documentation (e.g., Squarespace Help Center) often specifies exactly where to add MX, DKIM, DMARC, and SPF records within a DNS management interface, typically as TXT records (except for MX) at the subdomain level or higher, depending on the setup.
Technical article
Documentation from Cloudflare Docs provides comprehensive information about various DNS record types, including A, AAAA, CNAME, MX, and TXT records. It explains their roles in managing DNS on their platform, serving as a foundational reference for configuring domains and subdomains for different internet services, including email.
Technical article
Documentation from Squarespace Help Center guides users on how to set up email resource records, specifically detailing the process for adding MX, DKIM, DMARC, and SPF records to domains managed through their platform. This highlights the practical steps required for proper email authentication and routing.
Related resources
8 resources
Related pages
How to set up DMARC, DKIM, and SPF for emails from a web server and manage bounce responses?
Does a subdomain used for sending emails need its own SPF record?
Where should SPF, DKIM, and DMARC records be placed for email authentication?
Is an A record needed for email sending domains?
Why use subdomains for email marketing deliverability?
A simple guide to DMARC, SPF, and DKIM
What are the best practices for DNS lookups, SPF records, and subdomain usage for email deliverability?
What are PTR records and are they essential for email deliverability, along with other DNS records like A and MX?
Best practices for using unique or shared email subdomains across multiple sending tools?
Is DMARC required for mail sending domains?
