A 202 from your provider and a passing DKIM check say nothing about whether anyone can reply to you. The four DNS records, and how to verify each one properly.
Your provider returns 202. The dashboard shows delivered. DKIM passes, DMARC passes, test messages land in Gmail with no warning banner. Every signal you have says email is working.
Meanwhile, every reply anyone sends you is bouncing, and you will not find out from any of those signals.
Sending email and receiving email are two unrelated systems that happen to share a domain name. Verifying one tells you nothing about the other, and the checks people run almost always cover only the first.
The four records, and what each one is for
- SPF, a TXT record, lists who is allowed to send as your domain. Receivers use it to judge your outbound mail.
- DKIM, usually CNAMEs pointing at your provider, lets your provider sign outbound mail with a key published in your DNS. Also about outbound.
- DMARC, a TXT record at
_dmarc, tells receivers what to do when SPF and DKIM do not line up, and where to send reports. Still outbound. - MX says which server accepts mail addressed to you. This is the only one of the four that has anything to do with receiving.
Three of the four records are about being trusted when you send. Exactly one is about being reachable. A domain with perfect SPF, DKIM and DMARC and no MX record sends flawlessly and cannot be written to at all.
That configuration is easy to arrive at by accident, because setting up a transactional provider walks you carefully through the first three and never mentions the fourth. You published everything the wizard asked for. The wizard was not asking about inbound.
Why nobody notices
The absence of inbound mail is silent by construction.
Outbound failures come back to you: a bounce, a 500, a red line in a dashboard. Inbound failures happen on the sender's machine, to a person who is not you. They see a delivery failure, and they conclude you are ignoring them, or that they mistyped the address. Your monitoring sees nothing, because nothing happened.
So the published address on your contact page, your support address, the reply-to on every notification you send, and the address on your invoices can all be black holes for weeks while every test you run comes back green.
If you publish an address, test it by sending mail to it from an account you own, on a provider you do not control. That is the only check that covers the path your customers actually use.
Check against the authoritative nameserver
A DNS answer from your laptop went through at least one cache, and caches are wrong in both directions at the worst possible times.
A record you added ten minutes ago can look missing, because a negative answer is cached. A record you deleted can look present. Both mistakes send you debugging the wrong layer, and the second is worse, because you will conclude the record is fine and go looking elsewhere.
Ask the nameservers that actually hold the zone. Find them, then query them directly:
dig +short NS example.com gives the authoritative servers. Then dig +short @ns1.example-dns.com MX example.com gives you the truth rather than a copy of it.
Run the same pattern for each record: MX example.com, TXT example.com for SPF, TXT _dmarc.example.com, and CNAME on whatever selector your provider gave you for DKIM.
Empty output from dig +short means the record does not exist. It is easy to read an empty line as "fine" when scanning a terminal quickly, and that misreading is how this class of problem survives a review.
The subtleties worth knowing
A missing SPF record is not the same as a neutral one. With no SPF record at all, SPF cannot pass, and a DMARC policy of quarantine or reject then rests entirely on DKIM alignment. That can work, and it is one signature away from all of your mail going to spam.
DMARC reports go nowhere useful by default. The rua address in your DMARC record is where receivers send aggregate reports about mail claiming to be from you. If it points at an address you do not read, or one with no MX behind it, you have switched on the reporting and will never see a report.
Subdomains are separate. Mail from mail.example.com is covered by that subdomain's records and the DMARC policy you set for subdomains, not automatically by the parent's.
An alias is not an inbox. Forwarding addresses provided by your registrar frequently break DKIM alignment on the way through, so forwarded mail can be judged as spoofed by the final destination.
A ten minute audit
For every domain you send from or publish an address on:
- Query MX on the authoritative nameserver. Empty means nobody can email you.
- Send a message to each published address from an outside account, and confirm it arrives in something a human reads.
- Confirm SPF exists and names every service that sends as you, including the forgotten ones, such as your invoicing tool and your CRM.
- Confirm DKIM selectors resolve, and that the signing domain aligns with the From domain.
- Confirm the DMARC
ruaaddress is one you can actually receive and will actually read. - Reply to one of your own notification emails. The reply-to address is the one most likely to be wrong and the least likely to be tested.
It is a short list, it takes one sitting, and it covers the gap that every provider onboarding flow leaves open: they verify that you can send, and you need to know that people can reach you.