Add MX, SPF, DKIM, and DMARC Records

What You Will Learn

• What MX, SPF, DKIM, and DMARC records do and how they work together
• How to configure each record type for your is-pro.dev subdomain
• How to verify and test email deliverability after setup
• How to avoid common email authentication failures and pitfalls

Requirements

• An is-pro.dev subdomain with DNS management access
• Access to the is-cool-me dashboard
• A working email service provider (Google Workspace, Mailgun, SendGrid, AWS SES, etc.)

Background Information

Email authentication prevents your messages from landing in spam folders and protects your domain against spoofing and phishing attacks. When you send email from a subdomain like mail.yourname.is-pro.dev, receiving mail servers check your DNS records to verify that the message is legitimate and authorized by you.

Four DNS record types form the foundation of modern email authentication:

• MX records tell the world which mail servers accept incoming email for your domain.
• SPF records publish a list of servers authorized to send email on your behalf.
• DKIM records provide a public key that receiving servers use to verify a digital signature attached to each outgoing message.
• DMARC records tell receiving servers what to do when SPF and DKIM checks fail, and send you aggregate reports about authentication results.

Without these records, your email is more likely to be rejected, marked as spam, or forged by attackers. Major email providers including Gmail, Outlook, and Yahoo now require DMARC enforcement for bulk senders, making this setup essential for any domain that sends email.

Step-by-Step Setup

Step 1: Find Your Email Provider's DNS Requirements

Every email provider publishes specific DNS values you need to copy into your is-cool-me DNS dashboard. Before you start adding records, gather the following from your provider:

• MX server hostnames and priority values
• SPF include mechanism (e.g., include:spf.mailgun.org)
• DKIM selector name and public key
• Any provider-specific requirements for custom domain verification

Common providers and their documentation:

• Google Workspace: aspmx.l.google.com (MX), include:_spf.google.com (SPF), DKIM key generated in the Google Admin console
• Mailgun: MX hostnames and DKIM selector provided in the Domains tab
• SendGrid: SPF include:sendgrid.net, DKIM keys under Settings → Sender Authentication
• AWS SES: MX and DKIM values in the Verified Identities section, SPF via Easy DKIM or manual setup
• Cloudflare Email Routing: Destination MX provided in the Email → Routing tab

Step 2: Add MX Records

MX (Mail Exchange) records route incoming email to your provider's mail servers. In the is-cool-me dashboard, create one MX record per mail server hostname your provider gives you.

• Type: MX
• Name: @ (for the subdomain itself) or the specific subdomain prefix (e.g., mail if your email address is you@mail.yourname.is-pro.dev)
• Value: The provider's mail server hostname, e.g., aspmx.l.google.com
• Priority: A lower number means higher priority. Typically 10 for the primary server, 20, 30 for backups
• TTL: 3600 (1 hour) is a good default for MX records

Google Workspace, for example, requires five MX records at different priorities. Add all of them exactly as specified in the provider documentation.

Step 3: Add SPF Record

SPF (Sender Policy Framework) is a TXT record that lists every server allowed to send email from your domain. Receiving servers check this record and reject or flag messages from unauthorized senders.

• Type: TXT
• Name: @
• Value: v=spf1 include:your-provider.com ~all
• TTL: 3600

The include: mechanism delegates authority to your provider. You can chain multiple includes if you send through more than one service. The ~all qualifier means softfail — messages from unlisted servers are marked as suspicious but not rejected outright. Use -all (hardfail) only after you are certain all legitimate senders are covered.

Step 4: Add DKIM Record

DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign outgoing messages. Your email provider signs each message with a private key, and receiving servers look up the corresponding public key in your DNS to verify the signature.

• Type: TXT
• Name: default._domainkey (or your provider's specific selector, e.g., s1._domainkey, mailgun._domainkey)
• Value: The public key provided by your email provider, e.g., v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
• TTL: 3600

The selector name varies by provider. Google Workspace lets you choose a selector during setup. Mailgun uses the domain name as the selector by default. SendGrid generates a random selector. Your provider's setup wizard will tell you exactly what name and value to use.

Step 5: Add DMARC Record

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what policy to apply when authentication checks fail, and it requests feedback reports so you can monitor your email ecosystem.

• Type: TXT
• Name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
• TTL: 3600

Start with p=none to monitor without affecting delivery. Once you have confirmed legitimate email passes SPF and DKIM, move to p=quarantine (send failures to spam), and eventually p=reject (block failures outright).

DNS Configuration Table

Below is a reference table showing what your completed DNS configuration should look like for a typical email-sending subdomain using Google Workspace and a custom DKIM selector:

Verification

Once your DNS records are published, verify each one using command-line tools or online checkers.

Using dig (command line)

Run these commands from your terminal, replacing yourname.is-pro.dev with your actual subdomain:

# Check MX records
dig yourname.is-pro.dev MX +short

# Check SPF record
dig yourname.is-pro.dev TXT +short

# Check DKIM record (adjust selector as needed)
dig default._domainkey.yourname.is-pro.dev TXT +short

# Check DMARC record
dig _dmarc.yourname.is-pro.dev TXT +short

Using online tools

• MXToolbox — Comprehensive DNS lookup and email health checks
• Google Public DNS — Quick record inspection
• Mail-Tester — Send a test email and get a deliverability score

Send a test email

Send a message to a Gmail or Outlook address and inspect the full headers. Look for these lines:

Authentication-Results: spf=pass smtp.mailfrom=yourname.is-pro.dev
Authentication-Results: dkim=pass header.i=@yourname.is-pro.dev
Authentication-Results: dmarc=pass header.from=yourname.is-pro.dev

Troubleshooting

1. SPF permerror (too many DNS lookups). SPF has a hard limit of 10 DNS lookups including all nested includes. Each include: and redirect: counts. Use dig to count lookups or use an SPF validator. Consolidate includes or switch to a flattened SPF record if you exceed the limit.
2. DKIM signature mismatch. The public key in your DNS does not match the private key used to sign the message. Regenerate the key pair in your provider, publish the new public key, and wait for propagation before signing again.
3. DMARC policy too strict, blocking legitimate email. You set p=reject before all legitimate senders were authenticated. Temporarily revert to p=none, add the missing SPF includes or DKIM keys, and monitor reports before tightening again.
4. MX record pointing to wrong host. A typo in the MX value causes mail to be undeliverable. Double-check the hostname against your provider's documentation. Use dig MX +short to verify the response.
5. DNS propagation delays. New records may take minutes to hours to propagate depending on TTL and upstream resolver caching. Use dig @8.8.8.8 to query Google's resolver directly and bypass local cache.
6. SPF softfail vs. hardfail. ~all (softfail) marks unauthorized mail as suspicious; -all (hardfail) rejects it. Use ~all during initial setup and switch to -all only after confirming all legitimate sources are included.

Best Practices

• Gradual DMARC rollout. Start with p=none and a rua address to collect reports. Analyze the reports for at least one week, then move to p=quarantine, and finally p=reject. This ensures you do not break email delivery for legitimate senders.
• Keep SPF lookups under 10. Every include: mechanism counts toward the RFC-specified limit of 10 DNS lookups. If you exceed the limit, receivers return a permanent error and SPF fails for all your email. Use SPF flattening or macro expansion if needed.
• Rotate DKIM keys periodically. Most providers let you generate a new DKIM key pair. Rotating keys every 6–12 months reduces the impact of a key compromise. Publish the new key alongside the old one, switch signing to the new key, then remove the old key after the transition period.
• Monitor DMARC reports. Aggregate reports (rua) tell you which sources are sending email from your domain and whether they pass authentication. Forensic reports (ruf) contain copies of failed messages. Set up automated parsing with a service like dmarcian, Postmark DMARC, or URIports.
• Set appropriate TTLs before changes. Lower the TTL on your records to 300 (5 minutes) 48 hours before a planned migration or key rotation. This speeds up propagation and reduces the window where old and new records are inconsistent.

FAQ

What is the difference between SPF and DKIM?

SPF verifies the server that sent the message is authorized by the domain owner. DKIM verifies the message itself has not been tampered with by checking a cryptographic signature. They complement each other, and DMARC uses both to determine authentication status.

Can I have multiple DKIM records?

Yes. Each DKIM record uses a unique selector name. You can have as many selectors as you need. This is common during key rotation or when multiple services send email from the same domain.

How long does DMARC take to show results?

Aggregate DMARC reports are typically sent once per day by receiving providers, though the schedule varies. You should see your first reports within 24–48 hours of publishing a DMARC record with a valid rua address.

What happens if I have more than one SPF record?

Multiple SPF records cause an SPF permerror. Receiving servers cannot determine which policy to apply and will treat all email from your domain as unauthenticated. Merge all include: statements into a single TXT record.

Should I use ~all or -all?

Start with ~all (softfail) during setup and monitoring. Switch to -all (hardfail) only after you have verified that every legitimate email source is covered by your SPF record. Hardfail causes unauthorized senders to be rejected, which can break delivery if you miss a source.

Does DKIM require a specific key size?

RSA keys of 1024 or 2048 bits are most commonly used. Most providers generate 2048-bit keys by default. Some providers support Ed25519 keys, but RSA 2048 remains the safest choice for broad compatibility.

Can I use the same records for my apex domain and a subdomain?

Yes, but it is better practice to set up separate records for the subdomain. DMARC on the apex domain does not automatically apply to subdomains unless you use the sp= tag. Explicit subdomain records give you more control and prevent the apex domain's authentication status from affecting subdomain deliverability.

What is a DMARC forensic report (ruf)?

The ruf tag specifies an address to receive forensic reports containing copies of messages that failed DMARC authentication. These reports help diagnose spoofing attempts, but they can contain sensitive data. Use ruf only after confirming your report processor handles the data securely.

Related Guides

• Blog: Email on Subdomains — MX, SPF, DKIM Basics
• Guide: Lock Down CAA for Better Certificate Control
• Guide: Build a DNS Change Checklist for Teams
• Guide: Migrate a Subdomain Between Hosting Providers

Conclusion

Setting up MX, SPF, DKIM, and DMARC records for your is-pro.dev subdomain is a straightforward process that dramatically improves email deliverability and security. Start with the monitoring posture (DMARC p=none), verify that all your legitimate email sources pass authentication, then gradually tighten your DMARC policy to reject unauthorized messages. Regularly review DMARC reports and rotate DKIM keys to maintain a healthy email ecosystem.

With your DNS properly configured, receiving mail servers will trust messages from your subdomain, your recipients will see them in their inbox instead of spam, and your domain will be protected against spoofing and phishing abuse.

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.