DEV Community

Rijul Rajesh
Rijul Rajesh

Posted on

MX, SPF, DKIM, and DMARC: The DNS Stack Behind Every Email

#dns

If you have ever set up email for your custom domain, you’ve likely come across terms like MX records, SPF, DKIM, and DMARC. They sound technical, but together, they make sure your emails actually get delivered and not land in the spam folder.

What are MX Records?

MX stands for Mail Exchange. MX records tell the internet which mail server is responsible for handling email for your domain.

When someone sends an email to you@yourdomain.com, their mail server first looks up your domain’s MX records to find out where to deliver it.

You can think of MX records like the postal routing instructions for your domain. They don’t store or deliver mail themselves. They simply point to the servers that do.

How MX Records Work

Let’s take an example. Suppose your domain is example.com.

  1. A person sends an email to hello@example.com.
  2. Their mail server checks your DNS records for MX entries.
  3. The DNS reply says: 
   example.com.    MX    10    mail.example.com.
Enter fullscreen mode Exit fullscreen mode

This means that mail.example.com is responsible for receiving mail for your domain.

  1. The sending mail server then connects to mail.example.com via SMTP and delivers the message.

That’s how emails find their destination behind the scenes.

The Role of MX Priority

If your DNS has multiple MX records, each one includes a priority number. Lower numbers are tried first.

For example:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.
Enter fullscreen mode Exit fullscreen mode

Here, mail1 is the primary mail server, and mail2 is a backup. If mail1 is down, messages are sent to mail2 instead. This redundancy keeps your email service reliable.

Using Cloud Mail Services (Example: Amazon SES)

Most modern setups use a managed mail service like Amazon SES, Google Workspace, or Zoho Mail. These services handle the infrastructure so you can focus on your actual messages.

If you use Amazon SES for inbound emails, your MX record might look like this:

yourdomain.com.    MX    10    inbound-smtp.us-east-1.amazonaws.com.
Enter fullscreen mode Exit fullscreen mode

That tells other mail servers to send all incoming messages to Amazon’s mail server in the US East region. SES can then store, forward, or process your emails as you configure it.

Why MX Records Are Separate from A or CNAME Records

MX records are dedicated to email routing. Your A record or CNAME might point to your web server, while your MX record can point somewhere completely different for email.

This separation allows you to host your website on one provider (like Vercel or Netlify) and your emails on another (like Amazon SES or Google Workspace) without conflict.

Checking Your MX Records

You can easily check MX records using dig or nslookup:

dig MX yourdomain.com
Enter fullscreen mode Exit fullscreen mode

or

nslookup -type=MX yourdomain.com
Enter fullscreen mode Exit fullscreen mode

You’ll see the list of mail servers currently responsible for your domain.

The Bigger Picture: SPF, DKIM, and DMARC

MX records only tell the world where to send your email. But for sending mail, you also need to prove that your messages are legitimate. That’s where SPF, DKIM, and DMARC come in.

1. SPF (Sender Policy Framework)

SPF helps mail servers verify that the sender is authorized to send mail from your domain.

You add an SPF record as a TXT entry in DNS. It lists all servers allowed to send mail for your domain.

Example:

yourdomain.com.    TXT    "v=spf1 include:amazonses.com -all"
Enter fullscreen mode Exit fullscreen mode

Here’s what that means:

  • v=spf1 indicates the SPF version.
  • include:amazonses.com authorizes Amazon SES to send mail.
  • -all means any other source is unauthorized and should be rejected.

Without SPF, spammers could easily send fake emails pretending to be from your domain.

2. DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to your emails. This signature proves that the message hasn’t been tampered with and that it truly came from your domain.

When you enable DKIM (for example in SES), Amazon gives you a few CNAME records to add to your DNS. Those contain public keys that receiving mail servers use to verify your message’s DKIM signature.

It’s like sealing your letters with a unique wax stamp. The receiver can check that the seal matches your identity.

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails both checks.

A typical DMARC record looks like this:

_dmarc.yourdomain.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com"
Enter fullscreen mode Exit fullscreen mode

Breaking it down:

  • v=DMARC1 is the version.
  • p=quarantine means suspicious emails should go to the spam folder.
  • rua specifies where to send daily reports about who’s sending emails from your domain.

DMARC gives you visibility into how your domain is being used (or abused) in the email ecosystem.

Wrapping Up

Email delivery may look simple on the surface, but it relies on several key DNS components working together:

  • MX directs incoming mail.
  • SPF authorizes senders.
  • DKIM signs your messages.
  • DMARC enforces policy and reports misuse.

If you configure all four properly, your emails will not only be delivered successfully but also earn the trust of receiving mail servers.

If you’ve ever struggled with repetitive tasks, obscure commands, or debugging headaches, this platform is here to make your life easier. It’s free, open-source, and built with developers in mind.

👉 Explore the tools: FreeDevTools

👉 Star the repo: freedevtools

Top comments (0)