Improving Email Deliverability: The Role of DNS Records Explained
Discover how DNS records like SPF, DKIM, and DMARC enhance email security and deliverability, plus practical tools to verify your setup.
Domains and DNS Hosting
To establish an online presence, businesses typically start by purchasing or registering a domain name, like yourbusiness.com. This
process is managed by a Domain Registrar—the company responsible for registering or renewing domain names on behalf of
clients. When you register a domain, the registrar provides login details to a dashboard where you can manage various domain settings,
including renewals, billing details, and Name Servers.
Commonly used registrars in Australia include Crazy Domains, Melbourne IT, Namecheap, and GoDaddy.
DNS (Domain Name System) hosting, is responsible for translating this human-readable domain name into a
machine-readable IP address. Think of DNS hosting as the internet’s “directory service” for your domain. It stores and manages DNS records,
which direct web traffic and emails to the right destinations. Correctly setting up these DNS records is essential to ensure that people can
reliably access your website and receive your emails.
DNS Records
DNS records are instructions stored on DNS servers that define how a domain should behave, specifying where various services such as the
website and mail servers, are hosted. The following is a breakdown of the key DNS record types and how they contribute to website and
email functionality.
A Records
An “A” (Address) record points a domain to an IP address. For example, when someone visits yourbusiness.com, the A record tells the
browser which server to reach. Without an A record, users will be unable to access your website at all. This is foundational, as it connects
the domain name to its actual IP location on the internet.
HOST |
TYPE |
RECORD |
yourbusiness.com |
A |
192.168.1.1 |
In the example above, the A record directs the domain name “yourbusiness.com” to the IP address “192.168.1.1”.
CNAME Records
A "CNAME" (Canonical Name) record allows you to create an alias from one domain name to another. CNAME records point from one
hostname to another. The record must be a hostname and cannot be a specific IP address (as in an A record).
For example, you might want to direct “www.yourbusiness.com” to “yourbusiness.com” without specifying an IP address.
CNAME records are especially useful for pointing subdomains to other domains, simplifying domain management.
Host |
Type |
Record |
yourbusiness.com |
A |
192.168.1.1 |
www.yourbusiness.com |
CNAME |
yourbusiness.com |
TXT Records
TXT (text) records allow you to include text characters, rather than just an IP address or number, within DNS settings. TXT records
are commonly used for email security and spam prevention (e.g., SPF
and DKIM records), containing essential information
about the sender's servers to verify that emails are sent from authorized sources.
Services like Google and Microsoft often require you to add a TXT record as a verification method to prove domain ownership.
MX Records
MX (Mail Exchange) records determine where incoming email should be delivered. Setting up an MX record is essential to directing emails to
the appropriate email servers. Without the correct MX records, email sent to your domain will be undeliverable, potentially causing
communication disruptions.
Similar to Name Servers, multiple MX records are typically defined as fallbacks in case a message fails to send. MX records have a priority
(which defines the fallback order) and a hostname.
PRIORITY |
MX SERVER |
1 |
aspmx.l.google.com |
5 |
alt1.aspmx.l.google.com |
5 |
alt2.aspmx.l.google.com |
10 |
alt3.aspmx.l.google.com |
10 |
alt4.aspmx.l.google.com |
The example above shows Google Workspace MX records.
DNS Records for Mail Security
SPF, DKIM, and DMARC records play a crucial role in enhancing email security by verifying
the identity of organizations sending mail. Using all three methods together is considered best practice, as they complement each other to
provide comprehensive protection.
SPF Records
An SPF (Sender Policy Framework) record is a type of TXT record used to specify which servers (such as Gmail, Microsoft, a CRM, etc.) are
authorized to send emails on behalf of your domain. By listing trusted servers, SPF helps recipient servers verify that incoming emails are
authentic, reducing the risk of spam and phishing attempts.
SPF records start with the value "v=spf1", followed by terms separated by spaces. Each term defines a host or IP address
allowed to send mail from the domain. These terms consist of mechanisms and qualifiers:
-
Mechanisms: Define which hosts are allowed to send mail. Mechanisms include a, mx, ip4, ip6, exists, all, and include.
-
Qualifiers: Added before each mechanism, qualifiers specify whether to accept, reject, or flag messages:
- "+" is used to specify that a host is accepted (the default if no qualifier is specified).
- "-" is used to specify that a host is rejected.
- "~" is used to mark messages with a soft fail.
For example, an SPF record could specify that all A and MX records associated with the domain are authorized to send mail, while any other
servers should be rejected. Here’s what an SPF record might include:
HOST |
TYPE |
RECORD |
yourbusiness.com |
TXT |
v=spf1 a mx -all |
Each mechanism allows for specific configurations:
- Specify the IP version (usually ip4) and the IP address which is authorized.
- "include" allows you to reference third-party email services’ SPF records.
-
For example:
- Google Workspace: v=spf1 a include:_spf.google.com -all
- Office 365: v=spf1 a include:spf.protection.outlook.com -all
Finally, end the record with the "all" mechanism to specify the default action for any non-listed servers. Typically, "~all"
marks unlisted servers (soft fail), while "-all" outright rejects them.
For example, the following SPF record specifies that all A and MX records associated with the domain, Google’s servers, and a specified
IPv4 address are authorized to send mail on behalf of the domain. Any other servers attempting to send mail will be rejected.
HOST |
TYPE |
RECORD |
yourbusiness.com |
TXT |
v=spf1 a include:_spf.google.com ip4:xxx.xxx.xx.xx +mx -all |
Note: There should only be ONE SPF record.
DKIM Records
DKIM (DomainKeys Identified Mail) is an email authentication method that adds an encrypted digital signature to each outgoing email. This
signature is stored in the email header and helps mail servers detect any tampering, preventing spoofing attempts where someone tries to
send emails pretending to be from your domain.
The DKIM setup involves two keys:
- A private key, which is used by your domain’s email server to encrypt the signature in outgoing emails.
-
A public key, which is stored as a TXT record in your domain’s DNS. When an email is received, the receiving server
retrieves this public key to decode the signature and verify the email’s authenticity.
HOST |
TYPE |
RECORD |
selector._domainkey.yourbusiness.com |
TXT |
v=DKIM1; k=rsa; p=MIIBIfwNub8c4V-Very-Long-Set-Of-Characters; |
In the example above:
- "v=" Specifies the version of the DKIM record. This should always be DKIM1 and should appear at the start of the record.
-
"k=" Specifies the key type, which is almost always rsa, indicating that the DKIM record uses the RSA encryption algorithm.
-
"p=" Specifies the public key, generated alongside the private key as part of the DKIM setup. This should be a long string of
characters.
DMARC Records
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an advanced DNS record that builds on SPF and DKIM. It instructs
receiving servers on how to handle emails that fail SPF or DKIM checks.
DMARC policies can be set to monitor, quarantine, or reject
unauthenticated messages, giving businesses greater control over their email security.
DMARC records are published in DNS with a subdomain label "_dmarc".
HOST |
TYPE |
RECORD |
_dmarc.yourbusiness.com |
TXT |
v=DMARC1; p=reject |
In the example above:
-
"v=" Specifies the version of the DMARC record. This should always be DMARC1 and should appear at the start of the
record.
-
"p=" Specifies the policy. It defines how receiving email servers should handle emails that fail both SPF and DKIM checks.
-
p=none: The monitoring-only policy, which allows emails that fail SPF and DKIM to be delivered normally. This is useful
when first setting up DMARC, as it collects data without affecting email delivery.
-
p=quarantine: Directs unauthenticated emails to the recipient's spam or junk folder, keeping them out of the primary inbox
but still allowing delivery.
-
p=reject: Blocks unauthenticated emails entirely, preventing them from reaching the recipient. This is the strictest policy
and provides the highest level of protection.
Useful Tools to Check DNS Records and Email Deliverability
Using online tools can simplify the process of setting up and verifying your DNS records, making sure they’re properly configured for email
deliverability. Here are a few tools that can help:
-
MX Tool Box: Provides detailed lookups of your MX, SPF, DKIM, and DMARC records, helping
you troubleshoot configuration issues.
-
Dmarcian: Offers insights into your DMARC, SPF, and DKIM records, simplifying DMARC report analysis
and helping you enhance email security and deliverability.
-
Mail Tester: Quickly checks your email’s likelihood of landing in spam, providing feedback on
SPF, DKIM, and other settings that impact deliverability.
Leave a Comment