DNS and Email Authentication

Understanding the foundation of email delivery

DNS: The Internet's Address Book

The Domain Name System (DNS) is the foundation of email delivery, translating human-readable domain names into machine-readable IP addresses. Understanding DNS is crucial for managing email infrastructure effectively.

Learn more about DNS →

Authentication Protocols: SPF, DKIM, and DMARC

Email authentication protocols work together to verify sender identity and protect against spoofing. Each protocol has unique strengths and weaknesses, and they're most effective when used together.

Compare authentication protocols →

DNS: The Internet's Address Book

What is DNS?

The Domain Name System (DNS) is a hierarchical and distributed naming system that translates human-readable domain names (like haply.co) into machine-readable IP addresses (like 192.168.1.1) that computers use to identify each other on the network. Think of DNS as the internet's phone book or address directory.

Why DNS Matters for Email

DNS is fundamental to email delivery for several critical reasons:

  • Email Routing: DNS MX records tell email servers where to deliver messages for a specific domain
  • Authentication: SPF, DKIM, and DMARC all use DNS TXT records to verify sender identity
  • Reputation: DNS helps establish domain reputation through consistent configuration
  • Deliverability: Proper DNS setup is essential for emails to reach their destination

The DNS Hierarchy

DNS is organized in a hierarchical tree structure, with each level in the hierarchy responsible for a different part of a domain name.

Domain Name Structure

mail.haply.co

SubdomainSecond-Level DomainTLD

Reading from right to left:

  1. Root Domain - Represented by a dot (.) at the very end of a domain name (usually invisible)
  2. Top-Level Domain (TLD) - The rightmost segment (.co, .com, .ca, etc.)
  3. Second-Level Domain - The name you register (haply)
  4. Subdomain - Additional segments you control (mail, www, etc.)

Types of Top-Level Domains (TLDs)

  • Generic TLDs (gTLDs): General purpose domains like .com, .org, .net
  • Country Code TLDs (ccTLDs): Country-specific domains like .ca (Canada), .uk (United Kingdom)
  • Sponsored TLDs (sTLDs): Specialized domains for specific organizations or purposes (.gov, .edu)
  • Infrastructure TLDs: Technical domains like .arpa used for internet infrastructure

Haply Robotics Domain Portfolio

Your company uses multiple domains:

  • haply.co - Your main domain (gTLD)
  • haply.ca - Canadian presence (ccTLD)
  • haplyrobotics.com - Brand protection (gTLD)
  • haply-robotics.com - Brand protection (gTLD)

This multi-domain strategy provides flexibility for different purposes, including separating mass email sending to protect your main domain's reputation.

How DNS Resolution Works

When you type a domain name in your browser or send an email, DNS resolution converts that domain name to an IP address through a series of steps:

The DNS Resolution Process

  1. DNS Query Initiation

    Your computer sends a query to a DNS resolver (usually provided by your ISP)

  2. Recursive Resolution

    If the resolver doesn't know the answer, it starts at the root servers

  3. TLD Server Query

    The root server directs the resolver to the appropriate TLD server (.co in your case)

  4. Authoritative Name Server Query

    The TLD server directs the resolver to the authoritative name servers for your domain (haply.co)

  5. IP Address Return

    The authoritative name server returns the IP address for the requested domain

  6. Caching

    The resolver caches this information to speed up future requests

DNS Caching and Time-to-Live (TTL)

DNS records have a Time-to-Live (TTL) value that determines how long they can be cached before a new query is required.

  • Short TTL (minutes): Useful when planning to make DNS changes soon
  • Medium TTL (hours): Good balance between performance and update speed
  • Long TTL (days): Best for stable records that rarely change

When making changes to DNS records that affect email delivery (like SPF, DKIM, or MX records), it's important to consider TTL values to understand how quickly changes will propagate.

DNS Record Types for Email

Several types of DNS records are crucial for email delivery:

MX Records

Mail Exchange (MX) records specify the mail servers responsible for accepting email for your domain.

haply.co. IN MX 10 aspmx.l.google.com.
haply.co. IN MX 20 alt1.aspmx.l.google.com.

The numbers (10, 20) indicate priority - lower numbers are tried first.

A and AAAA Records

Address (A) records map domain names to IPv4 addresses. AAAA records map to IPv6 addresses.

mail.haply.co. IN A 192.168.1.1
mail.haply.co. IN AAAA 2001:db8::1

These records are essential for mail servers to be reachable.

TXT Records

Text (TXT) records store text information in DNS and are crucial for email authentication.

haply.co. IN TXT "v=spf1 include:_spf.google.com include:spf.mailjet.com ~all"

TXT records are used for:

  • SPF: Specifies authorized mail servers
  • DKIM: Stores public keys for email signing
  • DMARC: Defines policies for handling authentication failures
  • Domain Verification: Proves domain ownership

DNS and Email Authentication

DNS plays a critical role in email authentication by providing a trusted, distributed database for storing verification information.

How DNS Enables SPF

Sender Policy Framework (SPF) uses DNS TXT records to list all servers authorized to send email on behalf of your domain.

Example SPF Record for Haply Robotics:

haply.co IN TXT "v=spf1 include:_spf.google.com include:spf.mailjet.com ~all"

This record authorizes both Google (your main provider) and Mailjet (for notifications and mass sending) to send emails on behalf of haply.co.

How DNS Enables DKIM

DomainKeys Identified Mail (DKIM) uses DNS TXT records to publish public keys that verify email signatures.

Example DKIM Record:

selector._domainkey.haply.co IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The "selector" is a unique identifier for the key, allowing you to use different keys for different email sources (e.g., google._domainkey.haply.co for Google and mailjet._domainkey.haply.co for Mailjet).

How DNS Enables DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC) uses DNS TXT records to publish policies for handling emails that fail SPF or DKIM checks.

Example DMARC Record:

_dmarc.haply.co IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@haply.co"

This record tells receiving servers to quarantine (send to spam) emails that fail authentication, and to send aggregate reports to dmarc-reports@haply.co.

DNS Best Practices for Email

DNS Management Tips

  • Use consistent TTL values across similar record types
  • Document all DNS changes with dates and reasons
  • Implement DNS Security Extensions (DNSSEC) for added security
  • Regularly audit DNS records for accuracy and completeness
  • Use a reliable DNS provider with good uptime and support
  • Set up monitoring for critical DNS records

Multi-Domain Strategy

For Haply Robotics with multiple domains, consider:

  • Using haply.co for business communications via Google
  • Dedicating haplyrobotics.com or haply.ca for mass sending via Mailjet
  • Implementing consistent SPF, DKIM, and DMARC across all domains
  • Setting up proper subdomain delegation for specialized services
  • Creating clear DNS naming conventions for all records

Email Authentication Protocols: Strengths & Weaknesses

Why Use Multiple Authentication Protocols?

Email authentication is critical for protecting your domain from spoofing and ensuring your legitimate emails reach the inbox. While SPF, DKIM, and DMARC each provide valuable protection on their own, they work best when implemented together as a comprehensive authentication strategy.

The Alice and Bob Analogy

Imagine Alice wants to send a letter to Bob, but there are imposters who might try to send fake letters pretending to be from Alice. How can Bob verify the letter is really from Alice?

SPF is like...

Alice telling the post office: "I only send letters through these specific mailboxes." The post office checks if the letter came from one of those mailboxes.

DKIM is like...

Alice using a unique wax seal that only she possesses. Bob can verify the seal hasn't been broken and matches Alice's known seal pattern.

DMARC is like...

Alice giving Bob instructions: "If the letter doesn't come from my mailboxes OR the seal is broken, please put it in the suspicious pile and let me know."

SPF: Sender Policy Framework

"SPF verifies the sender's IP address against a list of authorized sending servers."

Strengths

  • Easy to implement - Simply add a TXT record to your DNS
  • Straightforward verification - Directly checks if the sending server is authorized
  • Widely supported - Most email providers check SPF records
  • Reduces basic spoofing - Prevents the most common spoofing attempts
  • Low maintenance - Once set up, requires minimal updates unless sending infrastructure changes

Weaknesses

  • IP-dependent - Breaks if your sending IPs change frequently
  • Forwarding problems - Can fail when emails are forwarded
  • No content verification - Doesn't check if the email content was modified
  • Limited DNS lookups - Maximum of 10 DNS lookups per record
  • No enforcement mechanism - Doesn't specify what to do with failed checks
  • Header spoofing vulnerability - Can't detect if the "From" header is spoofed while the return-path is legitimate

SPF for Haply Robotics

With your setup using both Google Workspace and Mailjet across multiple domains, SPF is essential but challenging. You need to authorize both services in your SPF records for each domain:

haply.co IN TXT "v=spf1 include:_spf.google.com include:spf.mailjet.com ~all"

This allows both Google and Mailjet to send on behalf of haply.co, but SPF alone won't protect against all types of spoofing.

DKIM: DomainKeys Identified Mail

"DKIM adds a digital signature to verify the email hasn't been tampered with and comes from an authorized sender."

Strengths

  • Content integrity - Verifies email content hasn't been modified
  • Forwarding compatible - Signature remains valid when email is forwarded
  • Not IP-dependent - Works regardless of sending server's IP address
  • Cryptographically secure - Uses public-key cryptography for strong authentication
  • Reputation building - Helps establish domain reputation over time
  • Selective signing - Can specify which parts of the email to include in the signature

Weaknesses

  • Complex setup - Requires generating cryptographic keys and configuring email servers
  • Key management - Keys need to be rotated periodically for security
  • No policy enforcement - Doesn't specify what to do with failed checks
  • Header limitations - Only protects headers included in the signature
  • No sender authorization - Doesn't verify if the sender is authorized to use the domain
  • Vulnerable to compromised accounts - If an account is hacked, DKIM will still pass

DKIM for Haply Robotics

For your multi-provider setup, you'll need separate DKIM selectors for each service:

Google Workspace DKIM:

google._domainkey.haply.co IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GC..."

Mailjet DKIM:

mailjet._domainkey.haply.co IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GC..."

This allows both services to sign emails with their own keys, but DKIM alone doesn't provide policy enforcement.

DMARC: Domain-based Message Authentication, Reporting & Conformance

"DMARC builds on SPF and DKIM by providing policy enforcement and reporting for authentication failures."

Strengths

  • Policy enforcement - Specifies what to do with emails that fail authentication
  • Reporting - Provides feedback on authentication failures
  • Domain alignment - Ensures the From header matches the authenticated domain
  • Gradual implementation - Allows monitoring before enforcing strict policies
  • Combines SPF and DKIM - Uses both methods for more comprehensive protection
  • Visibility - Gives insight into how your domain is being used or abused

Weaknesses

  • Dependency - Requires SPF and/or DKIM to be implemented first
  • Complex reporting - Reports can be difficult to interpret without tools
  • Implementation challenges - Requires careful planning to avoid legitimate email rejection
  • Third-party senders - Can be difficult to configure with many third-party services
  • Subdomain management - Requires separate policies for subdomains unless inheritance is specified
  • Not universally checked - Some receiving servers may not check DMARC

DMARC for Haply Robotics

For your multi-domain setup, a phased DMARC implementation is recommended:

Phase 1: Monitoring (p=none)

_dmarc.haply.co IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@haply.co"

Phase 2: Quarantine (p=quarantine)

_dmarc.haply.co IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@haply.co"

Phase 3: Rejection (p=reject)

_dmarc.haply.co IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@haply.co"

This gradual approach allows you to monitor authentication results before enforcing stricter policies.

Why You Need All Three Together

Each authentication protocol addresses different aspects of email security, and they complement each other to provide comprehensive protection.

Security AspectSPFDKIMDMARC
Verifies sending server
Verifies email content integrity
Works with email forwarding
Enforces authentication policy
Provides authentication reporting
Verifies header alignment

The Complete Protection Strategy

For Haply Robotics, implementing all three protocols across your domains provides these benefits:

  1. SPF verifies that emails come from authorized servers, protecting against basic spoofing attempts.
  2. DKIM ensures email content integrity and works even when emails are forwarded, addressing SPF's limitations.
  3. DMARC ties everything together by enforcing policies, providing reporting, and verifying header alignment.

Implementation Recommendation:

For your multi-domain strategy, implement all three protocols on each domain, but consider using different DMARC policies based on each domain's purpose:

  • haply.co (main business): Strictest policy (p=reject) after careful testing
  • haplyrobotics.com (mass sending): Start with monitoring (p=none) and gradually increase
  • haply.ca and haply-robotics.com: At minimum, monitoring policy (p=none)