Test DNS query?

Anything NextDNS is blocking will always be blocked by provididing a resolved IP address of IP address 0.0.0.0, which is understood in DNS software clients as having access blocked. Blocked IPv6 AAAA responses will also be given as empty all zero responses, often times represented via IPv6 abbreviation as simply " :: ", a short way of representing 0000:0000:0000:0000:0000:0000:0000:0000.

These are all the exact same number in IPv6. 

::
::0
0::0
0000::0000
0000:0000:0000:0000:0000:0000:0000:0000

Anything like that, and you know it's being blocked. You can read more on IPv6 shortening here, that explains how the above numbers are all multiple ways to represent the same number.

If you want to see additional DNS lookup types in the logs like MX and PTR,  you can click on the settings icon at the top of the Logs table from the Logs page of your NextDNS policy, and toggle the setting to show "Raw DNS logs".

What is your thought process by wanting to have an SMTP server utilize filtered DNS responses?

I'm asking these questions because I have some experience in this area, and can tell you if you're handling mail, using filtered DNS is a bad idea. The reason is that you want your mail server to be able to perform common antispam and policy functions such as PTR reverse hostname lookup - to ensure the forward A/AAAA matches the reverse PTR value. A non-matching value is frowned upon and generally considered less reputable. If you use DNS filtering, you can interfere with your mail servers ability to perform basic inbound antispam and anti-spoofing checks. Regarding outbound mail, you could potentially cause emails to not be able to be relayed and delivered if at any time a domain is on or is added to a blocklist used by your policy. Since the lists you may subscribe to via NextDNS are 3rd party controlled, you could find yourself suddenly having issues if a given domain is added even momentarily to an upstream blocklist.

What I'd recommend for mail servers is to create a separate policy just for them, and disable ALL security, privacy, and category filtering. Let the mail servers do their PTR reverse IP to hostname checks unfiltered, and let them reach out to other mail servers without interruption. Antispam functionality aside (ie: DNSBL, DNS RBL), you want the mail server to be able to correctly assess the reputation of communicating endpoints and reach outbound destinations using it's own logic, without interference.

What I do is create an overall policy for all infrastructure that has my filtering applied, and then for my mail servers I create a separate policy that applies zero filtering and only effectively functions as a logging service, allowing me to view logs and see what the mail servers are connecting to as well as get an idea of what IPs and domain names are being used to send mail to my mailserver.

As far as RBL and DNS RBL, don't use NextDNS for this, as they won't properly respond to and handle DNSBL/DNSRBL functionality since they aren't designed to be used as DNSBL/DNSRBL data provider sources.

If you want a domain name to use for testing, you can use 

InternetBadGuys.com

OpenDNS via Cisco own and use this as a test domain name. You can add it to your custom blocked domain names and then use it for testing. After adding it to your block list, attempt access from a client and then view your NextDNS logs page to see if it was filtered or not.

Filtered responses will show a red icon next to them, which you can hover over the icon to get an explanation as to why it was filtered on your policy.

FYI You can block any domain name you want and test it the same way. It doesn't have to be the above example domain name.