Checklist: getting your email in order

Module 8: Moving and getting your domain in order · Reading time: 13 minutes

Learning objective: After this lesson, you'll be able to use a fixed checklist to check your own domain's email from start to finish, explain the results and build an action list in the right order.

Key concepts: checklist, receiving (MX, mail server, null MX), connecting (TLS, certificate, ports 993/465/587), sending (SPF, DKIM, DMARC), the sending server (PTR, FCrDNS, blocklists), encrypted delivery (MTA-STS, TLS-RPT, DANE), mailboxes and addresses, security, action list, periodic maintenance

Why a fixed order?

You've seen many separate pieces in this course. In practice they're all connected: a DMARC policy is pointless if SPF is invalid, and a nicely configured SPF record doesn't help if the MX points to a server that doesn't exist. That's why you work through the checklist from the bottom up along the chain: first whether mail can arrive at all, then whether you connect securely, then whether your sent mail can be trusted, and only after that the fine-tuning.

The DNS course has a checklist for the whole domain (registration, nameservers, website) in lesson 8.5. This checklist goes deeper into email alone.

For each point you'll find: what you're checking, how (with a tool or a DNS lookup) and when it's correct. In the final exercise, the program runs the same checks automatically and puts the result alongside what you found.

Part A: can mail arrive?

A1. MX records. Look up MX <domain>. It's fine if there's at least one MX, and the host with the lowest number has an A or AAAA record. An MX pointing to a name with no address means mail won't arrive.
Special case: 0 . is a null MX (RFC 7505). This says "this domain doesn't receive mail". That's correct for a domain that never receives mail, such as example.com, and wrong for your business domain.

A2. The mail server responds. The first MX host accepts connections on port 25. At home you often can't test this yourself, because many internet providers block outgoing traffic on port 25. An online tool or the final exercise will do it for you. It's fine if the server gives a 220 greeting and offers STARTTLS.

A3. Test mail from outside. Send a mail from an address outside your domain. Does it arrive, and not in your spam folder?

Part B: can you connect securely?

B1. IMAP on port 993 with the server name you use in your mail program. It's fine if the TLS connection succeeds, the certificate is valid, the server name is included in it, and the certificate doesn't expire within 14 days.

B2. SMTP for sending: port 465 (direct TLS) and/or 587 (STARTTLS). It's fine if at least one of the two works with a valid certificate for the server name, and the server only offers login (AUTH) after the connection is encrypted.

If you get an error here, first check whether you're using your provider's server name rather than your own mail.<domain> without a certificate (lesson 2.1 and error 9 in lesson 8.3).

Part C: can your sent mail be trusted?

C1. SPF. Look up TXT <domain>. It's fine if:

• there's exactly one record with v=spf1;
• it ends in ~all or -all (never +all or ?all); for beginners, ~all is the recommendation, -all if you're certain all senders are included;
• the recursive count of lookups (include, a, mx, ptr, exists, redirect, also within each include) doesn't go above 10, and at most 2 lookups come back empty.

C2. DKIM. One selector per sender (your mail server, Microsoft 365, your newsletter service, your webshop). You'll find it in the headers of a mail from that sender (s= and d= in the DKIM-Signature, lesson 1.5). Look up TXT <selector>._domainkey.<domain> (possibly via a CNAME). It's fine if there's a non-empty p=, with a key of 2048 bits or more for RSA (or an ed25519 key).

C3. DMARC. Look up TXT _dmarc.<domain>. It's fine if there's exactly one record with v=DMARC1, with a valid p= (none, quarantine or reject) and a reporting address (rua=mailto:...). The recommended approach: start with p=none and read the reports; only once all senders are aligned do you move to quarantine and then reject (lesson 4.4). p=none without a reporting address is a missed opportunity: then you see nothing.

C4. Alignment in practice. Send a mail from each sender to a Gmail or Outlook.com address of your own and read Authentication-Results: dmarc=pass?

Part D: the sending server

D1. Reverse DNS. In the headers of a mail you sent yourself, find the IP address of the server that handed the mail to the outside world (the bottom Received line that comes from outside your own device, lesson 1.5). Look up the PTR (dig -x <ip>). It's fine if there's a name, and that name points back to the same IP (FCrDNS, lesson 5.1). Your domain's MX servers should also have a proper PTR.

D2. Blocklists. Have that sending IP (and the IP of your MX) checked against the known blocklists. It's fine if it isn't listed anywhere. If it is listed: first find and fix the cause, then delist (lesson 5.2). On shared hosting, this is a task for your provider: pass on the IP and the error message.

Part E: fine-tuning (optional)

E1. MTA-STS and TLS-RPT. TXT _mta-sts.<domain> and TXT _smtp._tls.<domain>. Not mandatory. If you have MTA-STS, the policy file must be reachable at https://mta-sts.<domain>/.well-known/mta-sts.txt and must match your MX (lesson 5.4).

E2. DANE. Only if your domain and the MX are signed with DNSSEC: TLSA records at _25._tcp.<mx-host>. Your mail provider usually arranges this for their own MX.

Part F: mailboxes, addresses and security

No program can check this for you, but it's still part of it:

• F1. No catch-all; only aliases and forwards you use deliberately; no forwarding to Gmail or other external addresses (lesson 3.3).
• F2. No mailbox above 80% of its quota (lesson 3.2).
• F3. Everyone uses IMAP, not POP3, on multiple devices (lesson 1.3).
• F4. Strong, unique passwords in a password manager; no old devices with old passwords; no unknown forwarding rules in the mailboxes (lesson 3.4).
• F5. Website forms send via SMTP with your own address as From (lesson 7.3); newsletters via a service with its own DKIM (lesson 7.1).

From result to action list

After the check, you'll have green, amber and red points. Work through them in this order:

1. Red in part A or B: mail doesn't arrive or you can't connect securely. Fix this first.
2. Red in part C: SPF invalid (two records, more than ten lookups), DKIM missing for a sender, two DMARC records. This determines whether your mail arrives.
3. Red in part D: no PTR or a blocklist listing. Usually a task for your provider.
4. Amber: p=none without reports, ?all, a 1024-bit key, a certificate that's about to expire.
5. Part E and F: improvements and maintenance.

Then plan maintenance: redo the checklist every quarter, and always after connecting a new service or moving house. Read your DMARC reports monthly, or have a reporting service alert you when a new source appears.

In practice: tools

You can use various tools for these checks. At WebOké, for example, these are the free Email check and Domain health check (also for domains not hosted with WebOké); independent tools such as the email test at internet.nl and MXToolbox carry out similar checks. No single tool sees everything: you'll almost always have to supply a DKIM selector yourself, and you'll need to get the sending IP from your own headers.

Summary

• Check in the order of the chain: arriving, connecting, trust, sending server, fine-tuning, maintenance.
• Arriving: MX with an existing host, null MX only for domains without mail.
• Connecting: valid certificate on 993 and 465/587 for the server name you use.
• Trust: one SPF within ten lookups with ~all/-all, DKIM per sender, one DMARC with rua, and alignment in practice.
• Sending server: PTR with FCrDNS and no blocklists. Build an action list in order and repeat the check every quarter.

Quiz

Exercise

Exercise Z8.4: Final exercise: your own domain. Enter your own domain (if you don't have one, use internet.nl as an example), the server name you use in your mail program, the DKIM selector(s) you found in your headers, and the IP address of your sending server. For each point in parts A through E, fill in what you found yourself. The program runs each sub-check itself and shows green, amber or red next to your answer for each point, with a link to the lesson. Afterwards, write your action list (maximum five points, in order).

Exercise O8.4: Check part F. Answer the five questions from part F for your own mailboxes and note down what you're going to change.

Further reading

The steps in these articles apply to WebOké's control panels; it works in a similar way with other providers.

• WebOké manual 5.17: Domain and email health: checking and fixing
• WebOké manual 6.7: The Set up email card (MX, SPF, DKIM, DMARC)
• Internet.nl checklist
• Website or email not working after a move or DNS change: check your domain
• Free DNS course 8.5: Checklist for your own domain
• Internet.nl, test your email: https://internet.nl/test-mail/