DNS Records for Email: The Complete Guide to MX, SPF, DKIM, and DMARC

DNS records for email are specific entries within your domain's Domain Name System that dictate how email should be handled, ensuring proper delivery, authentication, and security for both incoming and outgoing messages.

For anyone engaged in email marketing, sales outreach, or even just professional communication, understanding and correctly configuring these records is not optional—it's foundational. Misconfigured or missing DNS records can lead to low deliverability rates, emails landing in spam folders, and a damaged sender reputation. This guide provides a complete reference for MX, SPF, DKIM, DMARC, BIMI, and MTA-STS records, crucial for robust email deliverability, especially in the demanding world of cold outreach.

What are DNS Records for Email and Why Do They Matter for Cold Email?

DNS (Domain Name System) is often called the "phonebook of the internet." When you send an email, the recipient's mail server consults your domain's DNS records to verify the sender's legitimacy and determine how to route the message. For cold email, where trust is paramount and initial engagement is low, these verifications are critical. Proper email DNS setup ensures your messages bypass spam filters and reach the inbox, directly impacting your open rates, reply rates, and overall campaign success.

Without correct DNS for cold email, your messages are highly susceptible to being flagged as spam or outright rejected. This not only wastes your efforts but can also lead to your domain being blacklisted, making future outreach even harder. Key records like SPF, DKIM, and DMARC are authentication mechanisms that prove your emails are genuinely from your domain and haven't been tampered with.

MX Record Setup: Guiding Incoming Mail to Your Server

An MX (Mail Exchanger) record is a fundamental DNS record that specifies which mail servers are responsible for accepting email messages on behalf of your domain and where to route them. When someone sends an email to your domain (e.g., [email protected]), the sender's mail server queries your domain's MX records to find the correct server to deliver the message to.

How MX Records Work

MX records consist of two main parts: a priority number and a mail server hostname. The priority number indicates the preference for delivery when multiple MX records exist; lower numbers have higher priority. This allows for backup mail servers in case the primary one is unavailable.

Configuring Your MX Records

Most email service providers (Gmail, Outlook, Zoho, etc.) will give you specific MX records to add. You typically need to add multiple records, each with a different priority. You can check your MX records to ensure they are configured correctly.

Example MX Record Configurations

Here are common examples for popular DNS providers:

General MX Record Structure

Record Type: MX
Name/Host: @ or yourdomain.com
Value/Points to: mail.yourserver.com
Priority: 10 (or as specified)
TTL: Auto or 3600 seconds

Google Workspace (Gmail) Example

If you're using Google Workspace for your domain's email, you'll typically have records like these:

Record Type: MX
Name/Host: @
Value/Points to: ASPMX.L.GOOGLE.COM.
Priority: 1
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT1.ASPMX.L.GOOGLE.COM.
Priority: 5
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT2.ASPMX.L.GOOGLE.COM.
Priority: 5
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT3.ASPMX.L.GOOGLE.COM.
Priority: 10
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT4.ASPMX.L.GOOGLE.COM.
Priority: 10
TTL: Auto

Cloudflare Example (Adding MX Records)

In Cloudflare, you'd navigate to your DNS settings and add these records:

Type: MX
Name: @
Mail server: ASPMX.L.GOOGLE.COM
Priority: 1
TTL: Auto

Type: MX
Name: @
Mail server: ALT1.ASPMX.L.GOOGLE.COM
Priority: 5
TTL: Auto
... (and so on for other Google Workspace MX records)

GoDaddy Example (Adding MX Records)

In GoDaddy's DNS management, you'd add new MX records:

Type: MX
Host: @
Points to: ASPMX.L.GOOGLE.COM
Priority: 1
TTL: 1 Hour
... (and so on for other Google Workspace MX records)

SPF Record: Authorizing Your Senders and Preventing Spoofing

An SPF (Sender Policy Framework) record is a TXT record that lists all the IP addresses and domains authorized to send email on behalf of your domain. Its primary purpose is to prevent email spoofing, where malicious actors send emails pretending to be from your domain.

How SPF Works

When a receiving mail server gets an email from your domain, it performs an SPF check. It looks up your domain's SPF record and compares the sending IP address to the list of authorized senders. If the IP address isn't listed, the email might be marked as spam or rejected. For cold email, a valid SPF record is crucial for establishing initial trust and improving deliverability.

SPF Record Syntax and Mechanisms

An SPF record starts with v=spf1, followed by various "mechanisms" that define authorized senders and an "all" mechanism that defines the policy for unauthorized senders.

• v=spf1: Specifies the SPF version.
• a: Authorizes the IP address of the domain's A record.
• mx: Authorizes the IP addresses of the domain's MX records.
• ip4 / ip6: Authorizes specific IPv4 or IPv6 addresses/ranges.
• include: Includes the SPF record of another domain (e.g., your email service provider).
• exists: Authorizes based on an A record lookup.
• redirect: Points to another domain's SPF record.
• all: Defines the default policy for senders not matched by previous mechanisms.
  • -all (Hard Fail): Emails from unauthorized senders should be rejected. Recommended for strong enforcement.
  • ~all (Soft Fail): Emails from unauthorized senders should be accepted but marked as suspicious. Common for initial setup.
  • ?all (Neutral): No policy is specified. Rarely used, as it offers no protection.

Common SPF Pitfalls

• Multiple SPF Records: A domain should only have one SPF TXT record. Multiple records will cause authentication failures.
• Too Many Lookups: SPF records have a 10-lookup limit. Each include, a, mx, ptr, and exists mechanism counts as one lookup. Exceeding this limit will cause SPF to fail.
• Missing Senders: Forgetting to include all your sending services (e.g., your cold email platform, transactional email provider, CRM) will lead to legitimate emails failing SPF.

Example SPF Record Configurations

You can check your SPF record to identify issues.

Basic SPF Record (sending from your web server)

Record Type: TXT
Name/Host: @ or yourdomain.com
Value/Points to: "v=spf1 a mx -all"
TTL: Auto or 3600 seconds

SPF for Google Workspace

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:_spf.google.com ~all"
TTL: Auto

SPF for SendGrid

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:sendgrid.net -all"
TTL: Auto

Combined SPF (e.g., Google Workspace + SendGrid + Postigo)

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:_spf.google.com include:sendgrid.net include:postigo.net -all"
TTL: Auto

Note: Always aim for -all (hard fail) once you are confident all your legitimate sending sources are included. Start with ~all (soft fail) during testing.

DKIM Record: Digitally Signing Your Emails for Integrity and Authentication

DKIM (DomainKeys Identified Mail) is another critical email authentication method that allows the sender to digitally sign outgoing emails. This signature is verified by receiving mail servers, confirming that the email hasn't been altered in transit and that it genuinely originates from the claimed domain.

How DKIM Works

When an email is sent, the sending server generates a unique cryptographic signature based on the email's content (headers and body). This signature is added as a header to the email. The public part of the cryptographic key is published in your domain's DNS as a TXT record. The receiving server uses this public key to decrypt the signature and verify its authenticity. If the signature matches, the email is authenticated; if not, it suggests tampering or spoofing.

Configuring Your DKIM Records

Unlike SPF, you usually don't manually create the DKIM key. Your email service provider (ESP) or cold outreach platform (like Postigo.net) will generate a unique DKIM key (a long string of characters) for your domain. You then add this key as a TXT record in your DNS settings. Each DKIM record uses a "selector" (e.g., s1, default, or a unique string provided by your ESP) which is part of the record's name.

Example DKIM Record Configurations

General DKIM Record Structure

Record Type: TXT
Name/Host: selector._domainkey.yourdomain.com
Value/Points to: "v=DKIM1; k=rsa; p=MIGfMA0GC...[long alphanumeric string]...IDAQAB"
TTL: Auto or 3600 seconds

Google Workspace DKIM Example

Google will provide you with a specific selector (e.g., google._domainkey) and a long key.

Record Type: TXT
Name/Host: google._domainkey
Value/Points to: "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[long key provided by Google]...QIDAQAB"
TTL: Auto

SendGrid DKIM Example

SendGrid usually provides two CNAME records for DKIM setup, which simplify the process by pointing to SendGrid's own DKIM keys.

Record Type: CNAME
Name/Host: s1._domainkey.yourdomain.com
Value/Points to: s1.domainkey.uXXXXXXX.wlX.sendgrid.net
TTL: Auto

Record Type: CNAME
Name/Host: s2._domainkey.yourdomain.com
Value/Points to: s2.domainkey.uXXXXXXX.wlX.sendgrid.net
TTL: Auto

Replace uXXXXXXX.wlX with the specific values provided by SendGrid during your domain verification process.

DMARC Record: Policy Enforcement for Email Authentication

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds upon SPF and DKIM by allowing domain owners to specify what receiving mail servers should do with emails that fail SPF or DKIM checks, and to receive reports on authentication results.

How DMARC Works

DMARC provides instructions to receiving mail servers on how to handle emails that claim to be from your domain but fail SPF or DKIM authentication. It also introduces the concept of "alignment," meaning the "From" header domain must match the domain authenticated by SPF or DKIM. For cold outreach, DMARC is crucial for protecting your brand's reputation and gaining insights into potential spoofing attempts.

DMARC Policy Types

• p=none: Monitor mode. Receiving servers should take no action on failed emails but send reports. Ideal for initial deployment to gather data.
• p=quarantine: Receiving servers should move failed emails to the spam folder. This offers a balance between protection and potential false positives.
• p=reject: Receiving servers should outright reject failed emails. The strongest policy, recommended once you are confident in your SPF and DKIM setup.

DMARC Reporting

DMARC records include reporting addresses (rua for aggregate reports and ruf for forensic reports), which provide valuable data on who is sending email from your domain and how it's being authenticated.

Implementing DMARC

A typical DMARC implementation strategy involves:

1. Start with p=none to monitor and ensure all legitimate sending sources pass SPF/DKIM.
2. Gradually move to p=quarantine (e.g., 5-10% of emails) after analyzing reports.
3. Eventually implement p=reject (100% of emails) for maximum protection once you have high confidence (typically 95-100% of legitimate emails passing SPF/DKIM).

Example DMARC Record Configurations

Basic DMARC (Monitor Mode)

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"
TTL: Auto

Replace [email protected] with an actual email address to receive reports.

DMARC with Quarantine Policy

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
TTL: Auto

pct=100 means 100% of emails failing DMARC will be quarantined. You can use a lower percentage (e.g., pct=10) for a gradual rollout.

DMARC with Reject Policy

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=reject; rua=mailto:[email protected]"
TTL: Auto

Beyond the Core: BIMI and MTA-STS for Enhanced Trust

While MX, SPF, DKIM, and DMARC are essential, BIMI and MTA-STS offer additional layers of brand trust and security, particularly valuable for professional email communication and cold outreach.

BIMI (Brand Indicators for Message Identification): Displaying Your Logo

BIMI allows your brand's logo to appear next to your email in supporting inboxes (like Gmail, Yahoo!, Apple Mail). It significantly enhances brand visibility and recipient trust, making your cold emails stand out. To implement BIMI, your domain must have a DMARC policy of p=quarantine or p=reject, and your logo needs to be a Verified Mark Certificate (VMC) issued by a trusted certificate authority.

Example BIMI Record Configuration

Record Type: TXT
Name/Host: default._bimi.yourdomain.com
Value/Points to: "v=BIMI1; l=https://yourdomain.com/your-logo.svg; a=https://yourdomain.com/your-vmc.pem"
TTL: Auto

l points to your SVG logo file, and a points to your VMC certificate file. The VMC is required for the logo to display in most major inboxes.

MTA-STS (Mail Transfer Agent Strict Transport Security): Encrypted Email

MTA-STS is a security standard that ensures email sent between supporting mail servers is always encrypted, protecting against eavesdropping and man-in-the-middle attacks. It works by having a DNS TXT record that announces your domain's support for MTA-STS and points to a policy file hosted on your web server via HTTPS.

Example MTA-STS Record Configuration

First, create a policy file (e.g., mta-sts.txt) and host it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: yourdomain.com
mx: mail.yourdomain.com
max_age: 604800

Then, add the following DNS TXT record:

Record Type: TXT
Name/Host: _mta-sts.yourdomain.com
Value/Points to: "v=STSv1; id=202308151030"
TTL: Auto

The id value should be a unique string (e.g., a date and time) that changes whenever you update your mta-sts.txt policy file.

Comparison of Email DNS Records

Understanding the distinct roles of each record is key to a robust email DNS configuration. Here's a quick comparison:

Best Practices for Email DNS Configuration and Cold Outreach

Implementing these DNS records correctly is a continuous process, especially for high-volume sending like cold outreach. Follow these best practices to maintain optimal email deliverability and sender reputation:

1. Verify All Sending Sources: Ensure every platform that sends email on behalf of your domain (your ESP, CRM, marketing automation tool, cold outreach platform like Postigo.net, etc.) is included in your SPF record and has its own DKIM configured. Missing even one can lead to deliverability issues.
2. Monitor DMARC Reports Regularly: DMARC reports (sent to your rua address) provide invaluable data on who is sending email from your domain and how it's authenticating. Use a DMARC analytics tool to easily interpret these XML reports. Aim for 100% legitimate emails passing SPF and DKIM.
3. Start DMARC with p=none: Never jump straight to p=reject. Begin with p=none, analyze reports for several weeks or months, and only then gradually increase your policy to p=quarantine and finally p=reject once you're confident there are no legitimate failures.
4. Keep SPF Records Concise: Adhere to the 10-lookup limit for SPF. Consolidate include statements where possible. If you have many services, consider a dedicated subdomain for some sending.
5. Use a Dedicated Subdomain for Cold Email: For cold outreach, consider using a separate subdomain (e.g., outreach.yourdomain.com) with its own set of SPF, DKIM, and DMARC records. This isolates any potential deliverability issues from your primary domain (yourdomain.com), protecting your main brand reputation.
6. Implement BIMI for Brand Trust: Once your DMARC policy is at p=quarantine or p=reject, pursue BIMI. The visual trust signal of your logo in the inbox can significantly boost engagement for cold emails.
7. Regularly Check Your Records: DNS propagation can take time (up to 48 hours), but it's crucial to verify your records are live and correct. Use tools like Postigo's MX checker, SPF checker, and other email tools to ensure everything is in order.
8. Monitor for Blacklisting: Even with perfect DNS, your domain can be blacklisted due to content or sending practices. Regularly use a blacklist checker to ensure your domain remains clean.

Key Takeaways

Properly configured DNS records for email, including MX, SPF, DKIM, and DMARC, are non-negotiable for achieving high email deliverability and protecting your sender reputation. For marketers and sales professionals leveraging cold outreach, these configurations are the bedrock of successful campaigns, ensuring your messages reach the inbox and build recipient trust rather than being flagged as spam. Regularly review and update your email DNS settings to adapt to new sending services and evolving email security standards.