When a domain lacks MX (Mail Exchange) records, email systems typically fall back to the domain's A or AAAA record. This default behavior can cause unwanted SMTP traffic to your web server. Consider this scenario:

example.com.    IN  A     203.0.113.45
; No MX records present

In this case, senders will attempt delivery to 203.0.113.45 on port 25, forcing your web server to handle SMTP rejection.

RFC 7505 introduced the Null MX record specifically for this purpose. It explicitly states that a domain cannot receive email:

example.com.    IN  MX    0 .

The key components:

• Priority value 0 (though any value works since there's only one record)
• The target is a single dot (.), representing the DNS root

Here's how to implement it in common DNS systems:

BIND Zone File

$ORIGIN example.com.
@       IN  MX  0 .

PowerShell for Windows DNS

Add-DnsServerResourceRecordMX -Name "@" -ZoneName "example.com" -MailExchange "." -Preference 0

Terraform for Cloud DNS

resource "aws_route53_record" "null_mx" {
  zone_id = aws_route53_zone.example.id
  name    = "example.com"
  type    = "MX"
  ttl     = 3600
  records = ["0 ."]
}

Verify with dig/nslookup:

dig +short MX example.com
; Should return: 0 .

Or test SMTP behavior using swaks:

swaks --to user@example.com --server mx.example.org
; Should immediately receive "550 No MX for domain"

For domains that may receive email in the future but currently don't, consider these alternatives:

; Option 1 - Temporarily reject with custom message
example.com.    IN  MX  10 mail.example.com.
mail.example.com. IN  TXT  "This domain currently doesn't accept email"

; Option 2 - Redirect to a honeypot
example.com.    IN  MX  10 spam.example.org.

---

When you need to definitively state that a domain doesn't handle email, the proper DNS configuration is to create an MX record pointing to . (a single dot). This is the DNS standard way to indicate "no mail service exists for this domain".

example.com. IN MX 0 .

Without this explicit declaration, mail servers may:

• Fall back to trying the A record
• Queue messages unnecessarily
• Generate backscatter when rejecting mail

Here's how this would look in different DNS configuration formats:

BIND Zone File Syntax

$TTL 86400
@ IN SOA ns1.example.com. hostmaster.example.com. (
  2023080101 ; serial
  3600       ; refresh
  900        ; retry
  604800     ; expire
  86400 )    ; minimum

@ IN NS ns1.example.com.
@ IN MX 0 .

Cloudflare API Request

{
  "type": "MX",
  "name": "@",
  "content": ".",
  "priority": 0,
  "ttl": 3600
}

After implementation, verify with dig:

dig MX example.com +short
.

While the null MX is the standards-compliant solution, some administrators use:

• A dedicated "blackhole" MX record pointing to 127.0.0.1
• Explicit SMTP rejection policies
• SPF records with "-all" qualifier

However, these alternatives have drawbacks including potential delivery delays or configuration complexity.