Email on Subdomains: MX, SPF, and DKIM Basics

Why Email on Subdomains Matters

Running email on a subdomain (like mail.yourname.is-pro.dev or using a custom subdomain for a transactional email provider) is a best practice that offers several advantages over sending from your root domain.

Reputation separation: Your root domain's email reputation is protected. If your transactional email subdomain gets flagged for spam (e.g., a user marks a password reset email as spam), it does not affect the deliverability of your personal or team emails from the root domain. Each subdomain builds its own sending reputation independently.

Easier management: You can delegate DNS control of a subdomain to a different team or service provider without giving them access to your root domain's DNS. This is common when using services like Mailgun, SendGrid, or Amazon SES.

Flexible provider switching: Switching email providers for a subdomain only requires changing DNS records for that subdomain. Your root domain's MX, SPF, and DKIM records remain untouched, so your main email keeps working during the transition.

Targeted authentication: You can have different SPF, DKIM, and DMARC policies for different subdomains. Marketing emails from newsletter.example.com can have a more permissive SPF policy than transactional emails from billing.example.com.

MX Records Explained

Mail Exchange (MX) records tell the internet which servers are responsible for receiving email for your domain. When someone sends an email to user@yourname.is-pro.dev, the sending server queries DNS for MX records at yourname.is-pro.dev and delivers the message to the specified mail servers.

MX Record Format

yourname.is-pro.dev.  MX  10  mail1.yourname.is-pro.dev.
yourname.is-pro.dev.  MX  20  mail2.yourname.is-pro.dev.

Each MX record has three components:

• Priority (preference): A number from 0 to 65535. Lower numbers are preferred. The sending server always tries the lowest-priority MX first. If that server is unreachable, it tries the next priority.
• Mail server hostname: The fully qualified domain name of the mail server. This must resolve to an A or AAAA record. It cannot be a CNAME alias per RFC 2181 (though many providers allow it in practice).
• TTL: Standard DNS TTL controls how long the MX record is cached.

Multiple MX Records and Load Balancing

Multiple MX records with the same priority distribute load across servers. Sending servers randomly choose among equal-priority servers. Different priorities create a failover chain. A common pattern is:

yourname.is-pro.dev.  MX  10  primary.yourname.is-pro.dev.
yourname.is-pro.dev.  MX  20  secondary.yourname.is-pro.dev.
yourname.is-pro.dev.  MX  30  tertiary.yourname.is-pro.dev.

Sending servers attempt delivery to primary first. If it is unavailable, they try secondary, and so on. This provides resilience without complex load balancing.

SPF Records Explained

Sender Policy Framework (SPF) is a DNS TXT record that lists the IP addresses and domains authorized to send email on behalf of your domain. Receiving mail servers check SPF to verify that incoming messages claiming to be from your domain actually originated from an authorized source.

SPF Record Structure

yourname.is-pro.dev.  TXT  "v=spf1 include:mailgun.org include:_spf.google.com ~all"

Key components:

• v=spf1: Identifies this as SPF version 1.
• include:domain: Authorizes the specified domain's SPF policy. This delegates authorization to another domain's SPF record.
• ip4:1.2.3.4: Authorizes a specific IPv4 address.
• ip6:2001:db8::/32: Authorizes an IPv6 range.
• a: Authorizes the domain's A record IP.
• mx: Authorizes the domain's MX server IPs.
• ~all (softfail): Treat unauthorized sources as suspicious but accept the message. -all (hardfail): Reject unauthorized sources. +all: Accept everything (never use this).

The 10-DNS-Lookup Limit

SPF has a hard limit of 10 DNS lookups per evaluation. Each include:, a, mx, ptr, and exists mechanism counts as one lookup. If you exceed 10, SPF returns a permanent error (permerror), and receivers treat the message as if no SPF record exists. This is the most common SPF configuration mistake.

DKIM Records Explained

DomainKeys Identified Mail (DKIM) provides a way for the sending server to cryptographically sign outgoing emails. The signature is verified by the receiving server using a public key published in your DNS. This proves the email was not tampered with in transit and genuinely originated from your domain.

DKIM Record Structure

DKIM uses a subdomain format with a selector:

mailgun._domainkey.yourname.is-pro.dev.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb4DQEBAQUAA4GNADCBiQKBgQC..."

Breaking this down:

• mailgun is the selector, chosen by the email provider. You can have multiple selectors for key rotation.
• _domainkey is a required subdomain label.
• v=DKIM1 identifies the DKIM version.
• k=rsa specifies the key type (RSA is standard; ed25519 is newer).
• p= contains the Base64-encoded public key.

Selector Management and Key Rotation

Selectors allow you to publish multiple DKIM keys simultaneously. This is critical for key rotation without downtime:

1. Publish a new DKIM record with a new selector (e.g., google2026._domainkey).
2. Configure your email provider to sign outgoing mail with the new selector.
3. Wait for all cached DNS records to expire (at least the TTL of the old selector).
4. Remove the old DKIM record.

This zero-downtime rotation ensures that emails signed with the old key are still verifiable until the old record expires, while new emails use the new key.

DMARC Records Explained

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM. It tells receiving mail servers what to do when SPF or DKIM authentication fails and provides reports about authentication results.

DMARC Record Structure

_dmarc.yourname.is-pro.dev.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourname.is-pro.dev; ruf=mailto:forensics@yourname.is-pro.dev; pct=100"

Key tags:

• p=: Policy for authentication failures. none (take no action, just report), quarantine (mark as spam), reject (reject the email outright).
• sp=: Policy for subdomains (inherits from p if not set).
• rua=: Address for aggregate reports (XML summaries sent daily).
• ruf=: Address for forensic reports (individual failure details).
• pct=: Percentage of messages to filter (useful for gradual rollout).
• adkim=: DKIM alignment mode. r (relaxed) allows subdomain matches; s (strict) requires exact domain match.
• aspf=: SPF alignment mode, same options.

DMARC Alignment

DMARC requires either SPF or DKIM to "align" with the domain in the From header. Alignment means the domain checked by SPF/DKIM matches the domain the user sees in the email's From address. Without alignment, even a passing SPF check does not satisfy DMARC.

Step-by-Step Configuration Example with Mailgun

Here is a complete walkthrough for setting up email on mg.yourname.is-pro.dev using Mailgun:

1. Add MX Records

mg.yourname.is-pro.dev.  MX  10  mxa.mailgun.org.
mg.yourname.is-pro.dev.  MX  10  mxb.mailgun.org.

2. Add SPF Record

mg.yourname.is-pro.dev.  TXT  "v=spf1 include:mailgun.org ~all"

3. Add DKIM Record

Mailgun provides a DNS hostname and TXT value in their dashboard. Typically:

mailgun._domainkey.mg.yourname.is-pro.dev.  TXT  "k=rsa; p=MIGfMA0GCSqGSIb..."

4. Add DMARC Record (Optional but Recommended)

_dmarc.mg.yourname.is-pro.dev.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourname.is-pro.dev"

5. Verify DNS Propagation

Check each record using dig or nslookup:

dig mg.yourname.is-pro.dev MX +short
dig mg.yourname.is-pro.dev TXT +short
dig mailgun._domainkey.mg.yourname.is-pro.dev TXT +short
dig _dmarc.mg.yourname.is-pro.dev TXT +short

6. Test Sending

Send a test email from Mailgun and inspect the headers. Look for:

• Authentication-Results: spf=pass
• Authentication-Results: dkim=pass
• Authentication-Results: dmarc=pass

How to Test Email Authentication

After configuring DNS records, verify everything works:

• Send a test email and check headers: Most email clients allow you to view the full message source. Look for the Authentication-Results header added by the receiving server.
• Use online tools: Mail-Tester gives you a score and highlights issues. DMARCly Checker validates your DMARC configuration. DNS Institute SPF Query checks SPF syntax and lookup count.
• Google Postmaster Tools: If you send to Gmail users, Google Postmaster Tools provides delivery and reputation data.

Troubleshooting Common Email DNS Issues

SPF Permerror (Too Many Lookups)

Your SPF record exceeds 10 DNS lookups. This commonly happens with nested include: statements. For example, including both Google Workspace and Mailgun in the same SPF record can quickly exceed the limit if those providers themselves include multiple services.

Fix: Audit your SPF includes. Consolidate IP ranges where possible. Use ip4: and ip6: mechanisms instead of include: when you know the exact IP addresses. Consider splitting email sending across fewer providers, or use a subdomain per provider.

DKIM Key Rotation Without Downtime

When rotating DKIM keys, the most common mistake is deleting the old DKIM record before the new one is verified. Emails signed with the old key become unverifiable, causing DMARC failures.

Correct procedure: Add the new DKIM record with a new selector. Wait at least one TTL period. Switch your email provider to sign with the new selector. Wait another TTL period. Then delete the old DKIM record.

DMARC Aggregate Report Analysis

DMARC aggregate reports (RUA) are XML files sent daily by receiving mail servers. They contain data about how many messages passed or failed authentication, from which IP addresses, and from which domains.

Most people do not want to parse raw XML. Use a DMARC analysis service:

• DMARCly
• dmarcian
• URIports

These services parse the XML and present a dashboard showing authentication pass rates, top failing IPs, and alignment issues. Start with p=none to collect data for a week, analyze the reports, then move to p=quarantine and eventually p=reject.

"My Emails Are Going to Spam" — Real Scenario

You set up mail.yourname.is-pro.dev with Mailgun. You add the MX record but forget the SPF record. You send a test email and it lands in the Gmail spam folder. You check the headers and see:

Authentication-Results: mx.google.com;
       spf=neutral (google.com: 203.0.113.10 is neither permitted nor denied by SPF for domain mail.yourname.is-pro.dev)
       dkim=pass header.d=mail.yourname.is-pro.dev;
       dmarc=fail (p=none dis) header.from=mail.yourname.is-pro.dev

SPF is neutral because no SPF record exists. DMARC fails because SPF did not pass. The absence of a published SPF policy causes many receiving servers to treat the email as suspicious, even if DKIM passes.

Fix: Add the SPF record "v=spf1 include:mailgun.org ~all" for mail.yourname.is-pro.dev. After DNS propagation, resend the test email. The headers should now show spf=pass and dmarc=pass, and the email should land in the inbox.

Recommended Progressive DMARC Rollout

1. Monitor: Publish p=none with an RUA address. Collect reports for 1-2 weeks to understand your email sending patterns.
2. Analyze: Check the reports for unauthorized sending sources. Update your SPF record to include legitimate sources and exclude unauthorized ones.
3. Quarantine: Move to p=quarantine for a week. Monitor for false positives—legitimate emails that get quarantined.
4. Reject: Move to p=reject. This is the strongest protection against email spoofing and domain impersonation.

Deployment scenario from operations

A small team enabled new mail routing but SPF and DKIM stayed inconsistent across providers, causing partial delivery failures.

Common mistakes

• Publishing SPF records with duplicated `v=spf1` declarations.
• Enabling DMARC reject policy before alignment is validated.
• Rotating DKIM selectors without updating all sending services.

How to verify it works

1. Query MX/SPF/DKIM/DMARC records with `dig` and verify expected values.
2. Send test mail to external providers and inspect authentication headers.
3. Confirm DMARC aggregate reports reflect pass outcomes before tightening policy.