Verifying DNS for Email: MX, SPF & DKIM Explained for Receiving
To verify DNS MX SPF DKIM settings, first separate two questions: where should incoming mail go, and who is authorized to send? MX answers the first. SPF and DKIM help receivers authenticate the sender; adding them to your receiving domain does not repair its incoming route. Inboxto's reviewed custom-domain flow asks for an MX record and a separate ownership-verification TXT record. Check those records, inspect the app's verification results, and finally send a harmless test message.
1. Give Each Record One Job
| Record | What it does | What it does not prove |
|---|---|---|
| MX | Names the mail servers for a recipient domain, with preference numbers | That a particular mailbox exists or a message reached it |
| SPF, usually TXT | Lists authorized sending hosts for an SMTP envelope-sender domain; SPF can also check HELO | That this domain's incoming mail goes to Inboxto |
| DKIM, usually selector TXT | Publishes a key used to verify a message's domain signature | That its recipient address is configured or its content is safe |
| Ownership TXT | Carries a service-specific value to verify domain control | SPF authorization or a DKIM signature |
SPF does not simply authenticate the visible From address. DKIM verification uses the signature's d= domain and s= selector, looking up selector._domainkey.domain. DMARC adds alignment rules for the visible From domain; it is not a substitute for MX either.
A receive-only recipient domain does not need its own SPF authorization or DKIM signing key merely to accept incoming mail. The receiving service may still evaluate those mechanisms on senders' domains. If you also send using your domain, follow your actual sending provider's authentication instructions separately.
2. What We Observed in Inboxto
First-hand public implementation review, October 9, 2026: we inspected the deployed Inboxto web app, including its domain-setup and domain-detail bundles. This was a review of public controls and client logic, not an authenticated account session, a DNS change, or a completed delivery test.
The setup flow displays Add MX record to your DNS with type MX, name @, the configured mail-server value, and priority 10. A second step, Add TXT record for verification, displays name inboxto-verify and a domain-specific verification value. These are different records with different purposes.
The Verify DNS action handles mxRecordVerified and txtRecordVerified separately, alongside isVerified. Record both results rather than treating a general badge as a complete diagnostic. The ownership TXT is not an SPF record just because both use TXT. Copy current values from your own setup screen, not a token or endpoint from an old tutorial.
For the full prerequisite workflow, use the custom-domain setup walkthrough.
3. Query the Exact Domain You Added
Start with an unused dedicated subdomain where supported, such as inbox.example.com, rather than replacing a working business domain's MX records. Save the existing configuration and a rollback plan before editing. A subdomain's MX records are not inherited from the parent.
These read-only examples use reserved documentation domains. Substitute your actual registered domain; the commands do not configure anything:
dig inbox.example.com MX
dig inboxto-verify.inbox.example.com TXT
nslookup -type=mx inbox.example.com
nslookup -type=txt inboxto-verify.inbox.example.com
If you added example.com instead, query example.com and inboxto-verify.example.com. In a DNS zone for example.com, the record name for the former subdomain's verification is commonly inboxto-verify.inbox, not just inboxto-verify. Provider interfaces differ: inspect the final fully qualified owner name they create.
Keep the normal dig output initially. The status, answer section, TTL, and responding server distinguish an absent answer from a failed lookup. An empty +short result alone does not explain whether you queried the wrong name or encountered a DNS problem.
4. Read MX Preference and Hostnames Correctly
Lower MX preference numbers are tried before higher ones. Priority 10 is not a universal requirement for all email services, but it is what the reviewed Inboxto setup displays. Copy the current screen and inspect all existing MX records at the same name.
An old provider with a lower number can remain preferred. Multiple providers are not an automatic mirrored-inbox arrangement. Do not delete records blindly; first determine which service should own incoming mail and whether production users depend on the old route.
MX targets are hostnames, not IP addresses, URLs, or email addresses. In zone-file syntax, a trailing dot makes a name absolute; without it, a relative name may have the zone appended. Web dashboards may normalize this automatically. Check the published result for an accidental repeated suffix rather than adding or removing dots on guesswork.
5. Separate Caching From Misconfiguration
After saving a record, compare what the authoritative DNS server publishes with what your usual recursive resolver returns. An authoritative server answers for the zone; a recursive resolver may still hold a cached older answer. Previously absent names can also have negatively cached answers.
Find the zone's nameservers with dig example.com NS, accounting for any delegated subdomain. Query an identified authoritative server using dig @server-name inbox.example.com MX, replacing server-name with that server's real hostname. Check the TXT name the same way.
If authoritative data is wrong, fix the owner name, value, or delegation. If authoritative data is correct but a resolver is stale, allow the relevant cached TTL to expire and retry. Lowering TTL after an old answer was cached does not retroactively shorten that cache's lifetime. There is no reliable universal five-minute propagation promise.
6. Use a Four-Gate Acceptance Checklist
Our editorial troubleshooting worksheet separates four gates that are often collapsed into one “verified” label:
- Published DNS: the intended MX and ownership TXT appear at the exact fully qualified names.
- Service verification: use Verify DNS and inspect both MX and TXT results. If one fails, investigate that record first.
- Recipient configuration: create or select an address you can monitor. A domain route alone does not create every mailbox.
- Observed delivery: send a harmless message from an independent provider with a unique subject. Confirm it appears in the intended inbox; record the time and any bounce. This is a proposed reader test, not a result we claim to have obtained.
If the domain verifies but mail is absent, check the recipient and any sender-side bounce before changing unrelated SPF records. The developer guide to programmable receiving explains the broader workflow. For missing confirmation messages, see verification-email troubleshooting.
7. Keep Routing, Persistence, and Trust Separate
After a real registered address works, decide whether you need catch-all routing for unregistered names. Catch-all changes which recipients may be accepted; it does not prove DNS correctness or create separate private mailboxes for each name.
Inboxto offers persistent addresses and Premium custom domains, but continued access still depends on your account, domain renewal, DNS configuration, and service availability. Persistent addresses do not mean every ordinary message is retained forever. Nor does owning a custom domain guarantee that another platform accepts it or that every sender's message is delivered.
Authentication is also not a clean-content certificate. Authenticated mail can still be unwanted or malicious. Treat suspicious links cautiously and use the email-privacy guide alongside your routing checklist.
8. Sources and Your Next Step
The technical distinctions follow SMTP routing, RFC 5321, SPF, RFC 7208, and DKIM, RFC 6376. Product observations describe the public implementation reviewed on the date above, not an independent guarantee about backend behavior.
Open Inboxto, copy your current custom-domain DNS instructions, and run the four gates in order. Stop at the first failed gate: publish the right records, verify them, configure a recipient, then prove delivery with a non-sensitive test.