DNS for email: records, setup and deliverability

Home » Python » DNS for email: records, setup and deliverability

Email relies much more on DNS than most people realize. Every time you hit Send, a whole chain of DNS lookups quietly decides whether your message reaches the inbox, lands in spam, or gets blocked entirely. If your DNS for email is misconfigured, even the best campaign or the most important transactional message can simply vanish.

If DNS feels mysterious or overly technical, you’re not alone. Many experienced IT pros still think website hosting and email must live on the same server, when DNS actually lets you split services any way you like. The good news: once you understand the core DNS records for email—MX, SPF, DKIM, DMARC, and a few others—you can build a solid, secure, and highly deliverable email setup that mostly runs itself.

What DNS is and why it matters for email

DNS (Domain Name System) is the internet’s address book. Humans like names such as yourcompany.com, but computers talk using IP addresses like 203.0.113.10 or 2001:db8::1. DNS converts the domain into those numeric addresses so browsers, apps, and mail servers know where to connect.

When you type a domain into a browser, a DNS lookup starts a small journey. Your device asks a recursive resolver (usually run by your ISP or a public DNS like Google or Cloudflare), which may already have the answer cached. If not, the resolver walks a chain of servers: the root nameserver, then the TLD nameserver (for .com, .net, .org, etc.), and finally the authoritative nameserver for that particular domain. That last server holds the DNS records that tell the internet how to handle traffic for the domain.

Exactly the same thing happens when email is involved. Sending servers query DNS to figure out three big things: where to deliver mail for a domain, which servers are allowed to send from that domain, and whether messages are authentic or forged. If those DNS records are missing, wrong, or incomplete, you’ll see bounced messages, spam-folder placement, or a damaged sender reputation.

How email flows through DNS

Every outgoing email kicks off at least one DNS lookup. When someone sends a message to user@yourcompany.com, the sending mail server asks DNS: “Which server handles mail for this domain?” It looks for MX records first. If they exist, they point to the domain names of the receiving mail servers. If MX records don’t exist, most systems fall back to the domain’s A or AAAA record, but that’s not recommended for a professional setup.

Deliverability and security require more than just knowing where to send the mail. Modern receiving servers also query DNS for SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and optionally DMARC (Domain-based Message Authentication, Reporting & Conformance). These records tell the recipient whether the message really comes from an authorized source and how to treat suspicious messages.

Behind the scenes, several different server types cooperate to move messages. Outbound mail usually leaves via an SMTP server (Simple Mail Transfer Protocol), which works with a Mail Transfer Agent (MTA) to push the message across the internet. On the receiving side, users fetch mail using either POP3 (which typically downloads and removes mail from the server) or IMAP (which keeps messages on the server and syncs across devices). All of these components rely on DNS records to know which hostnames and IPs to contact.

Core DNS record types you must know for email

Not all DNS records affect email directly, but a handful are absolutely essential for routing, authentication, and spam filtering. Others play a supporting role in reliability and trust.

A and AAAA records: mapping your domain to IP addresses

The A record connects a domain to an IPv4 address (for example, 93.184.216.34). Without at least one valid A record, your domain effectively doesn’t exist on the internet. Many services also rely on it when an MX record is missing or misconfigured—something you want to avoid by publishing correct MX records.

The AAAA record is the IPv6 counterpart of the A record. It maps the domain to an IPv6 address, which is increasingly important as IPv4 space runs out. While A and AAAA don’t define where mail should be delivered, they tie your domain to real infrastructure and can be used for fallback mail routing if MX records are absent.

MX records: telling the world where to deliver mail

MX (Mail Exchange) records are the cornerstone of DNS for email. They declare which servers accept incoming messages for your domain. Each MX record contains a priority (a number where lower is more preferred) and a hostname (not a raw IP) of the mail server. Receiving servers sort MX records by priority and try them in order, giving you built-in redundancy.

A domain can use just one MX record, but multiple records are strongly recommended for resilience. Many hosted email solutions, like Microsoft 365 or Google Workspace, provide a single primary MX value, but large infrastructures often publish several MX entries with different priorities so that if one server is down, another can still accept mail.

When you configure MX records, your DNS provider won’t invent the values. Your email host gives you the exact hostnames, priorities, and any special requirements. In your DNS control panel you typically set: a host or name (often @ for the root domain), a priority number, the mail server hostname (like smtp.provider.com), and a TTL (time to live), which controls caching.

TXT records: the container for modern email security

TXT records store arbitrary text attached to your domain. Email systems heavily use them for policies and authentication data. SPF and DMARC live inside TXT records, and DKIM often does as well (though some providers expose DKIM via CNAME instead).

Because TXT records can hold anything, they’re also used for domain ownership checks (for example by ESPs, web services, or SSL providers), as well as for advanced features like opportunistic encryption hints and BIMI brand indicators. For email senders, the three key TXT-based mechanisms are SPF, DKIM, and DMARC.

SPF: authorizing the servers that can send mail for your domain

SPF is an email authentication framework that answers one question: “Is this IP or server allowed to send mail using this domain in the From address?” You publish your policy as a TXT record that normally starts with v=spf1 and ends with a qualifier such as -all, ~all, or ?all.

A simple SPF policy might allow mail only from your domain’s own MX hosts. An example looks like this: “v=spf1 mx -all”. That line tells recipients to accept mail from IPs used by your MX records and treat all other sources as unauthorized. If you also send via newsletter tools, CRMs, or cloud services, you extend the policy with include statements for each provider’s SPF domain.

Typical multi-service SPF policies chain several includes into one record. For instance, if you send from your main provider plus a helpdesk platform and a transactional email service, you might end up with something like: v=spf1 a mx include:service1.com include:service2.com ~all. Your email platforms will usually supply the exact strings and syntax you must add.

It’s important to maintain a single SPF TXT record per domain. Stacking multiple SPF records at the same DNS name can break validation. Instead, merge all required mechanisms into one carefully managed policy, and update it whenever you add or remove sending services.

DKIM: signing messages with a cryptographic fingerprint

DKIM (DomainKeys Identified Mail) provides a tamper-evident signature on outgoing messages. Your sending system uses a private cryptographic key to create a hash based on certain headers and sometimes the body of the message. This signature goes into a special email header field.

The corresponding public key lives in DNS. A DKIM selector (a small label like mail or mlsend2) plus the domain form the hostname for the public key record, often something like selector._domainkey.yourcompany.com. When a receiving system gets an email, it looks at the DKIM header, queries DNS for that selector, fetches the public key, and checks whether the signature is valid and the content hasn’t been altered.

DKIM can be published either as a TXT or a CNAME record. Many providers give you a large TXT value beginning with v=DKIM1 and a long p= field containing the base64-encoded public key. Others ask you to create a CNAME pointing from your selector hostname to one they host, which lets them rotate keys centrally without you editing DNS every time.

Each sending domain typically has at least one DKIM selector, and different services may each use their own. That’s perfectly fine; you can have multiple DKIM records as long as their selectors differ. Your email providers will show you exactly what to add, and implementation is usually just copy-and-paste into your DNS panel.

DMARC: tying SPF and DKIM together with a policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It doesn’t authenticate messages directly; instead, it checks whether they pass SPF and/or DKIM and whether those results align with the visible From domain. Then it applies a policy you define to say what should happen if checks fail.

A DMARC policy lives in a TXT record at the special hostname _dmarc.yourcompany.com. The record starts with v=DMARC1 and includes tags like p= (policy: none, quarantine, or reject) and options for reporting addresses. With DMARC you can instruct receivers to simply monitor (no enforcement), to send failures to spam, or to outright block them.

DMARC’s reporting features are a hidden gem for security and deliverability. By specifying addresses in rua and ruf tags, you ask receiving providers to send you aggregate or forensic reports about authentication outcomes. These reports help you discover unauthorized senders, misconfigured services, or domains being abused for phishing.

Other DNS records that influence email

Beyond MX, SPF, DKIM, and DMARC, a few more DNS record types impact whether your mail is trusted and successfully delivered. They may not be strictly required, but they often show up in deliverability checklists and anti-spam logic.

PTR (reverse DNS): validating the sending IP

A PTR record performs the reverse of a normal DNS lookup. Instead of mapping a domain name to an IP address, it maps an IP address back to a hostname. This reverse mapping is called reverse DNS or rDNS.

Receiving mail servers routinely check the sending IP’s reverse DNS. If there’s no PTR record, or the hostname it returns doesn’t reasonably match the domain in the email headers, some providers treat the message as suspicious. That can trigger errors like “Reverse DNS failed” or cause mail to be rejected with codes referencing missing PTR.

In practice, you rarely manage PTR records in your regular DNS zone. They’re controlled by whoever owns the IP range—often your ISP, hosting provider, or email platform. For dedicated mail servers, you usually request that the provider set up a PTR pointing to your chosen hostname, and then ensure that hostname also has a matching A or AAAA record.

SRV, NS, and SOA: supporting infrastructure for consistent delivery

SRV (Service) records describe the host and port for a specific protocol. For email, they can point clients to the correct SMTP, IMAP, or POP servers and ports. While they don’t control deliverability directly, SRV records help automatic configuration tools discover correct endpoints.

NS (Name Server) records define which nameservers are authoritative for your domain. These servers store and answer with your DNS data. If NS records are wrong, inconsistency between DNS providers can lead to unpredictable mail behavior, since some senders might see outdated or incomplete records.

The SOA (Start of Authority) record identifies the primary nameserver for the zone and provides details like the serial number of the zone file and timing values used for caching and refresh. It doesn’t control email logic directly, but correct SOA configuration is essential for reliable replication and propagation of your mail-related changes.

BIMI and TLSA: advanced trust and encryption signals

BIMI (Brand Indicators for Message Identification) lets you show your logo in compatible inboxes. Technically, it uses a TXT record that points to an SVG image of your logo and, in many cases, depends on verified brand certificates and an enforced DMARC policy. While BIMI itself won’t fix deliverability issues, it’s a visual trust signal and can improve engagement once your authentication is already solid.

TLSA records support DANE (DNS-based Authentication of Named Entities), which binds TLS certificates to DNS names via DNSSEC. For email, TLSA can harden STARTTLS connections between mail servers by specifying which certificates are valid. This helps prevent man-in-the-middle attacks on SMTP, though in practice it requires DNSSEC and is still less common than SPF/DKIM/DMARC.

Configuring DNS for your email provider

Most of the heavy lifting is done by your email host, which supplies the exact DNS entries you must add. Your job is to copy those values into the right record types at your domain registrar or DNS host and double-check for typos.

Step-by-step: adding and verifying MX records

To point your domain’s email to a specific provider, start with MX records. After signing up for a hosted email or cloud platform, look for their documentation on “DNS settings” or “mail exchanger records.” They’ll list hostnames and priorities you must use.

In your DNS management console, locate the option to add a new record and select type MX. For the host or name, domains typically use @ to represent the root (for example, yourcompany.com). Paste the mail server hostname as the value, set the priority they require, keep the default TTL unless advised otherwise, then save. Repeat for any additional MX records they provide.

Once MX records are saved, there will be a propagation period. DNS caches around the internet need time to expire old data. Expect anywhere from a few minutes to several hours—sometimes up to 24-48 hours—for the new mail routing to be visible everywhere. During this window, some senders might still deliver to the old destination.

Publishing SPF in your DNS

After mail routing is set, publish SPF to declare who’s allowed to send on behalf of your domain. Your primary email service, marketing platform, and any transactional systems should all be represented in a single SPF TXT record.

Most providers show you the exact SPF snippet you need. For example, a sending platform might say: “Add a TXT record with name @ and value v=spf1 include:_spf.example.com ~all.” If you already have an SPF record, merge the new include into it rather than creating a second record at the same name.

Choosing between -all and ~all affects how strictly receivers treat failures. A hard fail (-all) says that any sending source not explicitly listed should be rejected, while a soft fail (~all) typically lets messages through but may mark them as spam. Many organizations start with soft fail while they audit all their sending systems, then move toward stricter policies over time.

Adding DKIM keys from your providers

DKIM setup is usually straightforward once you find the right screen in your provider’s dashboard. Look for sections labeled “domain authentication,” “DKIM,” or “email signing.” You’ll see one or more selectors and either TXT values or CNAME targets.

If your provider gives a TXT record, create a DNS entry at the selector hostname (for example, selector._domainkey.yourcompany.com) and paste the long DKIM string they provide. If they ask for a CNAME instead, you’ll point your selector hostname to theirs, effectively telling the world to fetch the key directly from your provider’s DNS.

Many services require you to click a “Verify” or “Check DNS” button after you’ve added DKIM. This triggers a lookup from their side; once they see the correct key, they’ll start signing outgoing mail. Until that verification passes, messages might be sent without DKIM, weakening your authentication story.

Rolling out DMARC policies safely

DMARC deployment is best done in stages. Start with a policy of none, which asks receivers to report on failures but not to block anything. This lets you see who’s sending on behalf of your domain and whether SPF and DKIM are aligned properly.

A basic DMARC record might look like a TXT at _dmarc.yourcompany.com with a value such as v=DMARC1; p=none; rua=mailto:reports@yourcompany.com. After analyzing reports and fixing any gaps, you can raise the policy to quarantine (sending suspicious mail to spam) and eventually to reject if you want maximum protection against spoofing.

Many email clients, especially large providers, now expect domains sending significant volumes to have DMARC in place. Combined with correctly configured SPF and DKIM, a strong DMARC policy is one of the clearest signals that your domain is well managed and not a source of abuse.

DNS-based spam prevention and sender reputation

Modern spam filters heavily rely on DNS data to judge whether to trust an email. They look at MX, SPF, DKIM, DMARC, PTR, and even the consistency of A and NS records when deciding what to do with each message.

When SPF, DKIM, and DMARC all line up correctly, your domain builds a positive reputation. Over time, ISPs see that authenticated mail from you results in low complaint rates and consistent engagement. Conversely, missing or broken DNS records are a red flag: mail may still arrive, but it’s far more likely to be delivered to spam or blocked entirely.

DNS also helps protect your recipients from phishing and spoofing. Attackers love to pretend to be well-known brands or internal staff by forging From addresses. With SPF, DKIM, and DMARC, you make that much harder. Receivers can safely discard or quarantine messages that pretend to be from your domain but fail the published policies.

Deliverability isn’t only about DNS, of course. Content quality, sending volume, list hygiene, complaint rates, and engagement all matter. But without a solid DNS foundation, even perfect content can’t overcome the suspicion caused by unauthenticated or misconfigured mail.

Troubleshooting common email issues caused by DNS

When mail fails, DNS is often the culprit. The symptoms vary—from hard bounces with numeric SMTP codes to messages silently disappearing into spam—but in many cases the root cause lies in a missing or invalid DNS record.

Email bouncing or being rejected outright

Hard bounces with codes like 550, 554, or errors mentioning invalid domains usually point to DNS configuration problems. Two frequent offenders are missing MX records and SPF policies that don’t include the actual sending IP or service.

If the error complains about “no A or MX record” or an “invalid mailer domain,” review your zone. Confirm that the domain in the From address has a working A record, at least one MX record pointing to a resolvable hostname, and that those hostnames themselves have valid A or AAAA records. Any typo in hostnames can break the chain.

Rejections referencing reverse DNS failures or blacklisted IPs often trace back to PTR records. Check whether your sending IP has a PTR that resolves to a hostname you control, and that this hostname in turn has a matching A record. If not, open a ticket with your email or hosting provider and ask them to correct the reverse DNS.

Messages constantly landing in spam folders

If your messages deliver but consistently hit junk, look at your authentication stack first. Use online tools to verify SPF, DKIM, and DMARC for your domain. Any fails or warnings are clues that receiving mail systems don’t fully trust your traffic.

Check that the domain in the visible From address aligns with your SPF and DKIM. For SPF, the envelope sender (Return-Path) domain should be authorized. For DKIM, the d= value in the DKIM header should be a domain you own and, ideally, match or align with the From domain. DMARC then evaluates that alignment when deciding how to score the message.

User behavior also feeds into spam algorithms. If many recipients delete messages without reading, never open them, or mark them as spam, your reputation will decline no matter how pristine your DNS is. Combining strong DNS authentication with good sending practices is the winning formula.

Web forms or applications sending mail that never arrives

When website contact forms or apps appear to “send” email but nothing arrives, SPF is often misconfigured. The web server’s IP or the platform’s mailer might not be included in your SPF record, so recipients treat the messages as suspicious or reject them outright.

If your site sends mail using the domain of your main mailbox provider, confirm that the actual sending server (for example, your web host or a transactional ESP) appears in the SPF policy. In some cases it’s better to use a dedicated subdomain and configured ESP rather than relying on the web host’s default mail function.

Dealing with DNS propagation delays

Any time you change MX, SPF, DKIM, or DMARC records, give the internet time to catch up. DNS works on caching: resolvers remember answers for the length of the TTL, which can be minutes or hours. During this period, some senders see the new configuration while others still use the old one.

If you’re planning a major email migration, lower TTLs a day or two in advance. Reducing TTL to something like 300 seconds on key records makes future changes propagate faster. After the cutover is stable, you can raise TTLs again for performance and fewer queries.

Testing from multiple networks and using external DNS lookup tools helps confirm when propagation is effectively complete. Don’t rely only on your local resolver, which might cache aggressively or be configured in unusual ways.

Bringing it all together, DNS for email is less about magic and more about carefully coordinated records. When MX, SPF, DKIM, DMARC, PTR, and supporting entries are accurate and consistent, your domain becomes a trustworthy sender in the eyes of mail providers. That trust, paired with clean lists and thoughtful content, is what keeps your messages in the inbox and your brand out of spam folders.