The Fundamental Difference: Receiving vs Sending
MX records and SPF records serve opposite but equally important purposes in email delivery. The simplest way to remember the difference:
- MX records control who can send email TO your domain (incoming).
- SPF records control who can send email FROM your domain (outgoing).
One handles delivery to your inbox. The other protects your domain from being used by spammers and phishers. Both are essential for a complete email infrastructure.
Quick Reference Table
Feature | MX Records | SPF Records
-----------------|-------------------------------|-----------------------------
Purpose | Receive email TO your domain | Authorize sending FROM your domain
Direction | Incoming | Outgoing
DNS Record Type | MX | TXT (with spf1 syntax)
What It Contains | Mail server hostnames + priorities | Authorized sending IPs/hostnames
Missing Result | Cannot receive email | Emails go to spam or rejected
RFC Standard | RFC 5321 (SMTP) | RFC 7208 (SPF)How MX Records Work: The Receiving Side
When someone sends an email to `user@yourdomain.com`, here's what happens:
- The sender's email server queries DNS for your domain's MX records.
- DNS returns your mail server hostname (e.g., `aspmx.l.google.com` for Google Workspace).
- The sender connects to that mail server and transfers the email.
- Your mail server accepts the message and delivers it to the recipient's mailbox.
What MX Records Do NOT Do
- MX records do NOT prevent spam: Spammers can still send email to your domain. MX records just accept the email. Spam filtering happens separately.
- MX records do NOT control outgoing email: They have no effect on whether your outbound emails are accepted by recipients.
- MX records do NOT authenticate senders: Anyone can send email to your mail server. MX doesn't verify identity.
Example MX Record Configuration
# Google Workspace MX records (receiving)
yourdomain.com. IN MX 1 aspmx.l.google.com
yourdomain.com. IN MX 5 alt1.aspmx.l.google.com
yourdomain.com. IN MX 5 alt2.aspmx.l.google.comThese records tell the world: "Send all email for @yourdomain.com to Google's servers."
How SPF Works: The Sending Side
When you send an email from `user@yourdomain.com`, here's what happens:
- You compose an email and click send. Your email client connects to your SMTP server.
- The recipient's email server receives your message. Before accepting it, the recipient checks your SPF record.
- The recipient queries DNS for your domain's SPF record (a TXT record starting with `v=spf1`).
- SPF record lists authorized IP addresses or hostnames that can send email for your domain.
- If the sending server's IP matches the SPF record, authentication passes. If not, the email may be rejected or marked as spam.
Example SPF Record Configuration
# SPF record authorizing Google Workspace to send for your domain
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com ~all"This record tells the world: "Emails claiming to be from @yourdomain.com are only legitimate if they come from Google Workspace servers. Otherwise, mark them as suspicious (softfail)."
Common SPF Mechanisms
- `include:` Authorize another domain's SPF records (e.g., `include:_spf.google.com`).
- `ip4:` Authorize a specific IPv4 address or range.
- `ip6:` Authorize a specific IPv6 address or range.
- `a:` Authorize the IP address of your domain's A record.
- `mx:` Authorize IP addresses of your domain's MX records.
SPF Qualifiers (What to Do with Unauthorized Senders)
- `+all` (pass): ANY server can send as your domain. NEVER use this—it disables SPF protection.
- `-all` (fail): Reject emails from unauthorized servers. Strictest.
- `~all` (softfail): Mark as suspicious but accept. Recommended for most domains.
- `?all` (neutral): No opinion. Avoid this.
Why Both MX and SPF Are Essential for Email Health
MX and SPF serve different purposes, but together they form a complete email picture. Here's why you need both.
Scenario 1: MX Only (No SPF)
Configuration: Correct MX records, but no SPF or incorrect SPF.
Result: You can receive email perfectly. However, spammers can forge emails from your domain because you haven't authorized any sending servers. Recipients may see "via" addresses or spam flags. Your legitimate outgoing emails may go to spam folders.
Scenario 2: SPF Only (No MX)
Configuration: Correct SPF, but no MX records.
Result: You can send email, and recipients will trust it because SPF passes. But you cannot receive email at all because no mail server is configured to accept it.
Scenario 3: Both Configured Correctly (Best Practice)
Configuration: Valid MX records AND valid SPF (plus DKIM and DMARC).
Result: Your domain can send AND receive email reliably. Outgoing emails are trusted; incoming emails arrive correctly. Your domain is fully email-capable.
The Complete Email Authentication Stack
For modern email deliverability, MX is just the starting point. The complete stack includes:
- MX records: Where to send incoming email.
- SPF (Sender Policy Framework): Authorizes outgoing email servers.
- DKIM (DomainKeys Identified Mail): Cryptographically signs outgoing email.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Tells receivers what to do with emails that fail SPF/DKIM.
- BIMI (Brand Indicators for Message Identification): Displays brand logos in supporting email clients.
How to Test Both Configurations
Test MX (receiving): Send a test email to a working address at your domain. If it arrives, MX is correct.
Test SPF (sending): Send an email to `check-auth@verifier.port25.com`. It will respond with a detailed authentication report showing SPF pass/fail status.