How do I check my MX, SPF, DKIM and DMARC records?

How do I check an MX record?

Run dig MX with your domain and +short, and compare the priorities and host names with the values your provider gave you. The answer prints one line per record: the priority, a space and the host. For Proton Mail you expect 10 mail.protonmail.ch. and 20 mailsec.protonmail.ch.; for Fastmail 10 in1-smtp.messagingengine.com. and 20 in2-smtp.messagingengine.com.; for Mailbox.org four mxext hosts.

Two problems show up here. A record of the previous provider still in the list makes delivery unpredictable, so delete it. And an empty answer means no MX: senders then fall back to the address record of the domain, as RFC 5321 describes. What each line means is explained in what an MX record is.

How do I check an SPF record?

Ask for the TXT records at the root of the domain and confirm that exactly one line starts with v=spf1. The root also holds other TXT records, such as the ownership proof of your email provider, so read the whole list. Two lines starting with v=spf1 are an error: RFC 7208 returns a permanent error when a domain has more than one SPF record.

Then count the lookups. Each include, a, mx, ptr and exists, plus the redirect modifier, counts toward the limit of 10, and an include also counts what is nested inside it. A record over the limit fails for every sender. The creation of the record is detailed in how to create an SPF record.

How do I check DKIM when I do not know the selector?

Use the selector of your provider: you cannot list selectors from DNS, so take them from the provider's DKIM screen. DNS does not allow a listing of the names under _domainkey. The selectors are protonmail, protonmail2 and protonmail3 at Proton Mail, fm1, fm2 and fm3 at Fastmail, and MBO0001 to MBO0004 at Mailbox.org.

The lookup name is selector._domainkey.yourdomain. A provider that uses CNAME records, as these three do, answers with a CNAME to its own host. A provider that publishes the key directly answers with a TXT record that contains v=DKIM1 and p= followed by the public key. An empty p= means the key is revoked. The strongest test is a real message, because a record that exists can still be unused: send a mail to another provider and read dkim=pass in the full headers.

How do I check a DMARC record?

Ask for the TXT record at _dmarc.yourdomain and confirm one line that starts with v=DMARC1 and holds a p= policy. If p is missing, receivers treat the policy as none. If the line has no rua, no aggregate reports are produced and the monitoring stage of the DMARC rollout tells you nothing. Records written in the older style may still carry a pct tag, which RFC 9989 removed.

A subdomain without its own record falls under the policy of the parent through the DNS tree walk, with at most eight queries. A lookup of a name that has no record returns nothing, which is the same as no DMARC.

Why does my lookup still show the old value?

A cache holds the old answer until its TTL runs out, and a missing record can be cached too. The time a change takes to spread is about the old TTL on the record at the moment you changed it. Vendor guidance puts a usual MX change at one to four hours, and up to 24 to 48 hours in the worst case. RFC 2308 adds that negative answers are cached with the TTL from the zone's SOA record, so a record you just created can seem absent at some resolvers.

To skip the caches, ask the authoritative nameserver: find it with dig NS, then repeat the query with @ and its name, as in the code block above. If the authoritative server shows the new value and your resolver does not, wait. If neither does, the record was not saved or the host name is wrong, most often because the DNS editor added the domain a second time.

If mail still does not arrive after the records look right, go to why email is not arriving at a custom domain.

Which online tools can check email records?

Any online DNS lookup or mail authentication checker that queries the public DNS gives the same answer as dig, with a friendlier display. Use one that shows the raw record text, so that you can compare it character by character with your provider's value. Do not paste private data into it: the domain name is all it needs.

According to Postelva's count of 12 November 2026, a full Proton Mail setup takes 8 records (1 verification TXT, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) and 6 lookups, because the two MX records share one query and the verification and SPF records share the root TXT query. Save the six commands once and rerun them after each change. The same records are compared in SPF vs DKIM vs DMARC.

A citable rule: after every DNS change, query the four record types and send a test message; a record is correct only when the lookup and the message agree.