Visual RFC.
ALL RFCs / RFC 7505
Read the RFC ↗
RFC 7505 / NULL MX

Keep DNS integrity and service scope distinct

05

Null MX is ordinary DNS data. It can receive DNSSEC protection, but it is not a firewall or a guarantee about unrelated services.

DIAGRAMRead RFC section 5 ↗
RFC 7505 · § 5EXAMPLE
3 / 3
Keep DNS integrity and service scope distinctNull MX is ordinary DNS data. A separate optional DNSSEC example assumes successful validation of the record, protecting DNS data integrity and authentication rather than encrypting mail or authenticating users. A final service comparison keeps the same domain web address usable while mail software stops its own SMTP fallback. The record is not a network firewall.Protect the DNS data; keep service scope clearnomail.example. MX 0 .nomail.example. A 192.0.2.80mail client: address fallbackMail routing stops on this no-service resultseparate website trafficA declaration, not a network firewall
03
Keep the website and no-mail decision separate.

The same example domain can have MX 0 . and an A record for web traffic. Mail routing stops, while the illustrated website service remains a separate use of the address.

Source for this drawing: RFC 7505 · Read RFC section 5 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 5321 SMTP RFC 1035 DNS wire RFC 5322 Email message format

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
DNSSEC
DNS Security Extensions: authentication and integrity protection for DNS data.
Service scope
The particular service and domain to which a declaration applies.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

A no-mail declaration has a specific domain and purpose.

  • Within DNS, null MX is an ordinary MX record. RFC7505 introduces no new DNS security mechanism; DNSSEC can protect it as it can other DNS records.
  • DNSSEC protection concerns DNS data integrity and authentication. It does not encrypt mail, establish a user’s identity or turn an application declaration into a network firewall.
  • An explicit no-mail result stops SMTP address fallback for that destination. A separate A/AAAA record can still support a website; other services keep their own routing and security rules.
DETAILS

DNSSEC is optional in RFC7505’s security discussion. The validation picture assumes successful validation under the usual DNSSEC rules, not that a signature icon proves correctness or that all names are signed. DNSSEC setup, key chains, negative proofs and failure processing belong to their own specifications. Names, addresses and lookup results throughout this guide are fictional examples.

Read the RFC section ↗

All chapters in RFC 7505

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗