MX records tell the internet where to deliver email for your domain. SPF records tell receiving mail servers which systems are allowed to send email for your domain. That is the short version, and it matters because one broken DNS value can stop mail delivery or make your messages look suspicious. Google’s admin guidance describes MX records as the DNS settings that direct your domain’s email to mail servers [source: Google].

TLDR: MX records handle incoming email, while SPF records help verify outgoing email. For example, a company using Google Workspace might use an MX record pointing to ASPMX.L.GOOGLE.COM and an SPF record such as v=spf1 include:_spf.google.com ~all. In a 25-person business, even one wrong MX value can block all inbound mail, while a missing SPF record can push a noticeable chunk of outbound messages into spam. Treat MX and SPF as a pair: one gets mail delivered to you, the other helps your mail get trusted by others.

What Are MX Records?

An MX record, short for Mail Exchange record, is a DNS record that tells the world which mail server accepts email for a domain. If someone sends a message to alex@example.com, the sender’s mail server checks the DNS for example.com. It looks for MX records. Those records say where the message should go.

Think of MX records as the delivery address for your domain’s inboxes. They do not store email. They do not create mailboxes. They simply point mail toward the right email provider.

A basic MX record includes:

• Name or host: Usually your root domain, such as example.com.
• Mail server: The destination server, such as mail.example.com.
• Priority: A number that ranks servers. Lower numbers are tried first.
• TTL: How long DNS resolvers should cache the record.

Here is a simple example:

example.com.  3600  IN  MX  10  mail.example.com.

The number 10 is the priority. If there are multiple MX records, a mail server tries the lowest number first. If that server is unavailable, it may try the next one.

MX Records vs SPF Records: The Core Difference

MX records receive mail. SPF records authorize senders. That is the cleanest way to separate them.

An SPF record, short for Sender Policy Framework, is also stored in DNS. But it serves a different purpose. It lists the servers and services allowed to send email using your domain name. Receiving mail servers check SPF to help decide whether a message is legitimate.

For example, if your business sends newsletters through Mailchimp and regular mail through Microsoft 365, your SPF record may need to include both services. If it does not, some messages could fail authentication. That can lead to spam placement or rejection.

How MX Records Work in Real Life

Say you own brightdesk.com and use Microsoft 365 for email. Your DNS zone contains MX records supplied by Microsoft. When someone sends mail to sales@brightdesk.com, the sender’s mail server asks DNS, “Where should I send mail for this domain?” DNS replies with the MX destination.

The message is then handed to the mail server listed in the MX record. From there, Microsoft 365 sorts it into the right mailbox, checks spam rules, scans attachments, and applies policies.

If your MX record points to the wrong provider, mail may never reach Microsoft 365. It might bounce. It might sit in a queue. It might go to an old mail host. Honestly, it feels like DNS control panels hide the important bits one click too deep, so this mistake happens more often than it should.

How SPF Records Work in Real Life

Now flip the direction. Your company sends an invoice from billing@brightdesk.com. The receiving server checks the message and sees that it claims to come from brightdesk.com. Then it checks the domain’s SPF record.

If the sending server is listed, SPF passes. If not, SPF can fail. A failed SPF check does not always mean instant rejection, but it adds risk. Spam filters use SPF along with other signals, such as DKIM, DMARC, IP reputation, and message content.

A typical SPF record looks like this:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

This record says that Microsoft 365 and Mailchimp can send mail for the domain. The ~all part means a soft fail for everything else. A stricter version may end with -all, which tells receivers that all other senders should fail.

Why You Need Both MX and SPF

Some domain owners set up MX records and stop there. That is risky. Your inbox may work, but your outgoing mail may still look untrusted.

You need MX records so customers, partners, and staff can send messages to your domain. You need SPF so other mail systems can check whether your outgoing messages came from approved servers. They solve different problems.

Here is the practical split:

• MX records help people reach you. Without them, inbound email breaks.
• SPF records help your messages pass trust checks. Without them, outbound email may look forged.
• MX records point to receiving mail servers. They are about destination.
• SPF records list sending sources. They are about permission.

Common MX Record Mistakes

MX problems can be painful because the symptom is simple: mail stops arriving. The cause may be buried in DNS settings that nobody has touched in months.

• Wrong priority values: The backup server may be tried before the main server.
• Old provider records: Domains often keep stale MX records after a mail migration.
• Missing trailing dots: Some DNS editors handle this for you, others do not.
• Pointing MX to an IP address: MX records should point to hostnames, not raw IPs.
• Slow DNS changes: High TTL values can make fixes feel delayed.

The catch is that a tiny typo can waste hours. A domain may look fine at first glance, while one character in the mail server hostname breaks delivery.

Common SPF Record Mistakes

SPF errors are sneakier. Mail may still send, but delivery quality drops. You may see more spam-folder placement, failed DMARC reports, or random rejection notices from strict receivers.

• Too many DNS lookups: SPF has a limit of 10 DNS lookups.
• Multiple SPF records: A domain should have one SPF record, not several.
• Missing services: Newsletter tools, CRMs, and invoice platforms often need to be included.
• Overly loose rules: +all allows almost anything and is a bad idea.
• Forgotten vendors: Old platforms may remain authorized long after use ends.

How MX and SPF Fit With DKIM and DMARC

MX and SPF are not the whole email DNS story. Most domains also need DKIM and DMARC.

DKIM adds a cryptographic signature to outgoing messages. It helps prove that the message was not changed after being sent. DMARC tells receiving servers what to do when SPF or DKIM checks fail. It can also send reports, which are useful when you want to see who is sending mail as your domain.

A healthy email DNS setup usually includes:

1. MX for inbound delivery.
2. SPF for approved sending sources.
3. DKIM for message signing.
4. DMARC for policy and reporting.

Quick Setup Checklist

Before changing DNS, confirm your email provider’s exact values. Do not guess. Providers change formats, and copy-pasting from an old blog post can break mail.

• Find the official MX records from your email provider.
• Remove old MX records unless your provider says to keep them.
• Add one SPF record that includes every approved sending service.
• Check for duplicate SPF TXT records.
• Set up DKIM and DMARC after MX and SPF are stable.
• Use a DNS checker to confirm public results.
• Send test mail in both directions.

Final Takeaway

MX records and SPF records are both DNS records, but they do very different jobs. MX records tell senders where your mailboxes live. SPF records tell receivers which systems can send mail as your domain. If you mix them up, you can end up with lost inbound mail, rejected outbound messages, or a domain that looks easy to spoof.

For most businesses, the smartest path is simple: set MX first, then SPF, then DKIM and DMARC. Keep the records clean. Review them after every email tool change. Your future self will be grateful when the next “email is broken” ticket takes five minutes instead of half a day.