Skip to content

Cookie settings

Choose which kinds of cookies you allow. You can change your choice at any time via Cookie settings at the bottom of every page. Privacy statement

Necessary

Always on

Needed to log in, keep your cart and remember your choices. These are always on.

Which cookies?
  • weboke_sessie, weboke_klant, weboke_remember: your session and staying logged in
  • weboke_basket: your cart
  • wkBtwIncl: showing prices with or without VAT
  • wok_cookies: your cookie choice, 12 months

Measures which ad leads to a visit or order, so we do not pay for ads that do nothing.

Which cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), up to 90 days
  • OpenAI Ads, ads in ChatGPT
  • wok_aff: which partner referred you to us (affiliate programme), 60 days

4.6

Country and language

Each country has its own site, with prices and VAT for that country.

View

Module 8 · 8.3

Common mistakes

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

Learning objective: After this lesson, you can recognise the twelve most common email mistakes by their symptoms, explain why they go wrong, and fix them.

Key terms: duplicate SPF record, too many SPF lookups, DMARC set to reject too early, DKIM not enabled at a sending service, forwarding to Gmail, catch-all, visitor as sender, outgoing server without authentication, mail. server name without matching certificate, full mailbox, MX forgotten during a move, POP3 on multiple devices

How to use this lesson

Every mistake follows the same structure: what you see (the symptom, as a customer reports it), why it goes wrong, and how you fix it. The symptoms often look alike ("my mail isn't arriving"), while the cause is completely different. That's why each mistake also explains how you confirm it: what evidence to look for before you change anything. Don't guess, measure first (lesson 6.3).

You'll use the numbers in the exercise.

Mistakes in the DNS

Mistake 1: two SPF records.
You see: mail to Gmail and Outlook.com suddenly ends up in spam, since you connected a new service (Microsoft 365, a newsletter tool, an accounting package). The headers show spf=permerror.
Why: the service said "add this SPF record", and now there are two TXT records starting with v=spf1. According to RFC 7208, that's a permanent error: SPF stops counting altogether.
Confirm: look up your domain's TXT records and count the v=spf1 records.
Fix: merge everything into one record (lesson 4.2).

Mistake 2: more than ten SPF lookups.
You see: the same thing, spf=permerror, but there's only one record. Often after adding yet another include.
Why: every include, a, mx, exists and redirect costs a DNS lookup, including within the includes. Above ten, SPF becomes invalid.
Confirm: have an SPF check count recursively (exercise Z4.2).
Fix: remove services you no longer use, replace a and mx with ip4/ip6 if they're fixed, or have a service send via its own bounce subdomain (lesson 7.1).

Mistake 3: DMARC set to p=reject straight away.
You see: since a DMARC record was set, invoices from the accounting package or mail from the website no longer arrive. Recipients return 550 5.7.1 with a reference to DMARC.
Why: not all senders were accounted for. Anything that doesn't come through aligned SPF or DKIM is now rejected.
Confirm: the DMARC record and the reports (lesson 4.5): which sources are failing?
Fix: go back to p=none with a report address, fix all senders, then move step by step to quarantine and reject (lesson 4.4). That's also the recommended approach in this course.

Mistake 4: DKIM not set up at the sending service.
You see: newsletters increasingly miss the inbox at more and more recipients. In the headers: dkim=pass header.d= the service's domain, dmarc=fail.
Why: the service signs with its own domain, so DMARC can't pass via DKIM, and SPF isn't aligned either.
Confirm: the headers of a test newsletter (exercise Z7.1).
Fix: authenticate your domain at the service (DKIM via CNAME, lesson 7.1).

Mistakes with forwarding and addresses

Mistake 5: forwarding everything to Gmail.
You see: mail from some senders doesn't arrive at the Gmail address you forward your business mail to, or ends up in spam. Sometimes senders get a bounce from Gmail.
Why: when forwarding, the mail arrives at Gmail from your server, which isn't in the original sender's SPF. Without DKIM, or with a sender that has p=reject, DMARC fails. On top of that, forwarded spam looks to Gmail like spam that you are sending, which harms your reputation.
Confirm: the bounce or the headers at Gmail (spf=fail or softfail with your server as the source).
Fix: don't forward, add the mailbox to the Gmail app on your phone via IMAP instead (lessons 2.4 and 3.3).

Mistake 6: a catch-all.
You see: lots of spam at addresses that never existed (xyz123@example.com), and a full mailbox.
Why: a catch-all accepts mail for any conceivable address. Spammers try random addresses, and all of them get through. If you also forward the catch-all to the outside world, you get mistake 5 on a larger scale.
Confirm: check the mailbox to see which recipient addresses the spam was sent to.
Fix: turn off the catch-all, and create an alias or mailbox for every address that's actually used (lesson 3.3).

Mistake 7: using the visitor's address as the sender in a form.
You see: messages from the contact form sometimes arrive and sometimes don't, especially not from visitors with an address at a large provider.
Why: your website sends mail "on behalf of" the visitor's domain. If that domain has p=reject or p=quarantine, the recipient rejects or filters the mail (lesson 7.3).
Confirm: check which From address the form uses.
Fix: use your own address in From, and the visitor's address in Reply-To.

Mistakes with settings

Mistake 8: outgoing server without authentication.
You see: receiving works, sending doesn't. Errors such as "relay access denied", "authentication required" or 550 5.7.1. On the iPhone, often: the outgoing server fields left blank ("optional").
Why: an outgoing server only forwards mail for people who log in. Otherwise anyone could use it as a spam cannon.
Confirm: the outgoing server settings in the mail program.
Fix: turn on authentication, with the full email address and password, port 587 with STARTTLS or 465 with SSL/TLS (lessons 1.4 and 2.3).

Mistake 9: mail.<domain> as the server name without a matching certificate.
You see: a message about an invalid certificate or "cannot verify the identity of the server", or the connection doesn't work at all.
Why: the program checks whether the server name is listed in the certificate. mail.example.com might point to the server, but it isn't listed in the certificate. Or the name still points to the old provider after a move.
Confirm: have the mail ports checked with the server name (exercises Z2.1 and Z8.4).
Fix: use the server name given by the provider, and never just click "continue anyway" (lesson 2.1).

Mistake 10: a full mailbox.
You see: senders get a bounce with 452 4.2.2 or 552 5.2.2 (mailbox full). You notice nothing yourself, or only that no new mail is coming in.
Why: the mailbox has reached its quota. Often due to years of attachments, or a Sent folder and Trash that never get emptied.
Confirm: the mailbox usage in the panel or webmail.
Fix: clean up, archive, or increase the quota (lesson 3.2).

Mistakes when moving

Mistake 11: forgetting the MX during a move.
You see: after moving the website or the domain, no mail arrives any more, or it arrives somewhere nobody checks. Or the other way round: you've moved your mail to a new provider, but the MX still points to the old one.
Why: when you switch nameservers, the whole zone moves with it. If the mail provider's MX records aren't in the new zone, your mail points to the new web server. Or the MX was simply never updated.
Confirm: query MX at the authoritative nameserver (exercise Z8.2).
Fix: set the correct MX records in the zone that's actually active, and then copy the mail across once more (lesson 8.2).

Mistake 12: POP3 on multiple devices.
You see: mail is on the laptop but not on the phone, or the other way round. After replacing the laptop, years of mail are gone.
Why: POP3 fetches the mail from the server to one device and often deletes it there (lesson 1.3).
Confirm: the account type in the mail program.
Fix: switch to IMAP; first drag the mail that only exists locally into the IMAP mailbox.

What these mistakes have in common

Look at the list again. Almost every mistake happens because someone followed a single instruction ("add this record", "turn on forwarding") without seeing the bigger picture. The common thread running through this course:

  • know who sends mail on behalf of your domain (inventory, lessons 4.2 and 8.1);
  • change one thing at a time and check afterwards;
  • read the evidence: the bounce (lesson 6.1), the headers (lesson 1.5), the DMARC report (lesson 4.5), and the DNS at the authoritative server.

Summary

  • DNS mistakes: two SPF records, too many lookups, DMARC set to reject too early, DKIM not enabled at a sending service.
  • Address mistakes: forwarding to Gmail, catch-all, the visitor's address as From.
  • Setting mistakes: no outgoing authentication, a server name that isn't in the certificate, a full mailbox.
  • Moving mistakes: MX forgotten, POP3 on multiple devices.
  • Always confirm the cause with evidence before you change anything.

Quiz

1. A customer has spf=permerror in the headers. There's one SPF record with eight includes. What's the most likely mistake?



2. Sending doesn't work from a new iPhone, but receiving does. What do you check first?



3. A customer forwards all their business mail to Gmail. Some mail doesn't arrive. What's the best advice?



4. After a domain move, no mail arrives at Microsoft 365 any more. What's the most likely cause?



5. Why is clicking "continue anyway" on a certificate warning in your mail program a bad idea?



Exercise

Exercise Z8.3: Which error is it? You're given eight short scenarios, each with a symptom and a piece of evidence (a header, a bounce, a DNS answer or a setting). For each scenario, pick the number of the mistake (1 to 12). The program checks your answers against a fixed key and shows which piece of evidence you overlooked if you get it wrong.

Exercise Z8.3: Which error is it?

File for this exercise: casussen-z8-3.md

Open casussen-z8-3.md and choose the number of the error from lesson 8.3 for each case.









What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Further reading

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

One moment…

Set up your domains

For each domain, arrange the nameservers, the link to your hosting and who becomes the owner.

Loading your domains…