On Friday morning, we became aware that a significant amount of email to Microsoft-run mail systems was being rejected. This included mail to hotmail.com and outlook.com.

The messages were being rejected with the following message:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records

We checked our logs, and found that we’d seen this message over 500 times on Thursday, but not once before that.

The affected messages all had completely valid SPF and DKIM, but did not have a DMARC record. We added a DMARC record with a “none” policy to some of the affected domains, and sure enough, mail was then accepted again. A quick fedi-survey confirmed that we were not alone.

DMARC records are a way of publicly stating what you want recipients to do with email that claims to be from your domain, but which doesn’t pass verification checks (DKIM or SPF) and thus is potentially forged. Your DMARC policy can be one of the following:

• reject – recipients should reject mail that doesn’t pass DKIM or SPF. This is the real purpose of DMARC: if you’re confident that all legitimate outbound mail is properly authenticated, you can tell recipients to assume that anything else is forged, and bin it.
• quarantine – recipients should treat such mail as suspicious.
• none – your domain has no policy on what to do with mail that doesn’t pass DKIM or SPF.

Publishing a policy of none is effectively the same as not publishing a policy at all.

Microsoft are now rejecting mail without a DMARC policy, but accepting mail with a policy of none. This is a massive and pointless change in their policy for incoming mail, made with no notice whatsoever.

Last year Microsoft, introduced a policy that required domains sending more than 5,000 messages per day to have a DMARC record. This change was announced in advance. This latest change appears to be completely unannounced, which makes us wonder if it was even intentional. Of course, trying to contact Microsoft in order to resolve mail issues such as this is futile.

Update: apparently it wasn’t intentional, but they haven’t figured out how to roll it back yet.

We’ve just applied p=none DMARC records to a large number of our customers’ domains. We generally try to avoid making unsolicited changes to DNS zones, but in this case we feel that it is the best option.

If you’re in contact with Microsoft users affected by this, please encourage them to complain to Microsoft; it’s very likely that they are losing other legitimate email from other providers because of this unannounced change. Better still, encourage them to move to an email provider that is pro-active in investigating email deliverability issues.

As explained in our pricing policy, we don’t believe in introductory discounts. We prefer to charge a fair, sustainable price from the outset, with no unpleasant surprises on renewal.

We do believe in offering the best possible price for our customers, so if a domain registry gives us an introductory discount, we’re going to pass that on.

Nominet, the UK domain registry, have offered us a discounted price for the first year of new UK domain registrations during the month of November, so during this month, we’ll be charging £2 + VAT for the first year of new UK domain registrations.

This applies to .uk, .co.uk, .org.uk and .me.uk domains.

It’s been a busy week at Mythic Beasts, thanks to the very highly publicised PHP vulnerabilities that were announced earlier this week.

Dealing with urgent security updates is completely routine for us. We’re constantly monitoring and reviewing security announcements, and every week we’ll push out multiple fixes for packages that we consider to be “0-day worthy” – that is, a fix for a vulnerability that is serious enough that it needs patching immediately and so gets puts through our “0-day” process rather than waiting for the next scheduled upgrade window.

We have tooling that allows us to quickly find all managed servers where a given package is installed, send out notifications and automatically apply the updates.

What made this PHP issue so bad?

The main answer is ubiquity. PHP is installed on a large proportion of our managed servers, including our shared hosting servers where we offer multiple different versions of PHP.

Simply pushing out the updates as soon as they were available would take some time, and we were concerned that this would provide enough of a window to start seeing exploit attempts.

We therefore took the decision to take PHP-based sites on our shared hosting servers offline from the time of the announcement (3pm UK time on Wednesday) until the patches were applied. We took this decision in our incident planning meeting on Wednesday morning, but were pleased to see the NCSC including this approach in their list of recommendations.

Although many sites experienced a short, precautionary outage, the vast majority of servers under our control were fully patched and back in full service in well under an hour from the initial announcement.

The long tail

We try hard to keep servers on a current operating system version, and with a very strong preference for only installing software from operating system packages. This incident demonstrates why we do this, as fixing vulnerabilities becomes a straightforward task of upgrading an operating system package.

PHP is a bit of a special case, as a lot of PHP software targets PHP versions that are newer than those available in stable operating systems. There’s also software that’s well behind the curve and needs older PHP versions.

Fortunately, on Debian and Ubuntu at least, this is largely solved by the tireless efforts of Ondřej Surý to provide supported packages for multiple versions of PHP. The fix for this vulnerability has been back-ported as far as PHP 5.6, which formally went end-of-life in 2018!

Unfortunately, the world isn’t perfect, and we have a decent number of servers under our management that, for a variety of reasons, were more complicated than a simple package upgrade, and working through this long tail of systems has kept us very busy.

Some updates were also delayed because the Ubuntu infrastructure that the Sury Ubuntu PHP packages rely on couldn’t cope with the load, and we were up late ensuring that these packages were rolled out to all affected servers.

Extra support

The vulnerability hitting the front page of BBC News resulted in quite a few customers emailing us to ask if they were affected. The BBC were a bit late to the game, so we were happy to be able to respond to most of them confirming that it had been fixed the day before! We were less impressed by an obviously LLM-generated support query with a long list of questions to answer, which received the terse response that it deserved.

We’ve also been receiving lots of enquiries from customers of other hosting providers who experienced extended outages due to the issue.

What’s the lesson here?

Perhaps unsurprisingly, the mainstream news coverage mostly missed the real issue. The story made the news because high-profile organisations, including government organisations, took their websites offline, in some cases for an extended period of time. Predictably enough, news stories focused on the (overstated) role of LLMs in discovering the vulnerability, and not on the question of why these organisations didn’t have a better process in place for dealing with an entirely foreseeable event.

We have seen a significant increase in the number of serious vulnerabilities being reported, and customers with managed servers will have noticed an increase in the frequency of emails notifying of urgent updates to packages installed on their servers.

If you don’t already have a process for handling critical vulnerabilities in the packages that your service depends on, you may wish to talk to us about server management.

Ready for the next one?

Although it’s been a very long week for many of our staff there are definitely some positives coming out of this.

It’s often hard for us to persuade customers of the importance of having security support for their systems. It’s very easy to put off upgrading and then find out the hard way that you can’t respond quickly to a security vulnerability. The high profile of this incident, coupled with the NCSC’s “if you can’t patch it, switch it off” advice is actually very helpful.

And naturally, we’re reviewing what we can do to further streamline our processes ready for the next one.

We’re pleased to announce that we now support WebAuthn/FIDO2 security keys as an option for two factor authentication (2FA). Customers have quite reasonably been requesting this feature for some time, but as we’re sure you’ll understand, this type of development work needs to be tackled carefully.

Security keys are physical devices – typically a small USB key – that can securely store digital credentials. When logging into a site, rather than typing a code from an app or sent to your phone via SMS, your browser will talk directly to your key, usually requiring you to tap a button to approve the authentication. Some systems also provide a compatible software token store, such as Apple Keychain (or Windows Hello, but we’ve not tested that).

Aside from being more convenient than typing a code, security keys are far more phishing-resistant than other methods. Convincing forgeries may trick humans into typing 2FA codes into fake sites, but WebAuthn ensures that credentials from a security key are only provided to the site for which they are intended to be used.

To set up security keys on your account, please visit the “Two-factor authentication” page in the control panel.

Use of security keys is entirely optional, and we will continue to support our existing 2FA methods. If you do want to use a hardware security key, you’ll need to purchase one if you’ve not got one already. Most of our staff are using Yubikeys, but any FIDO2 device should work.

We strongly recommend that you have at least two working 2FA methods, and make sure that they’re not tied to the same device; having SMS and TOTP on the same phone won’t help if you lose your phone.

We take account security seriously, and if you lose your access to your 2FA device, we will not reset your access by email alone as this would completely undermine the additional security provided by 2FA. (You can reset your password by email, so this would make email a single factor.)

We also know that many of our customers don’t trust SMS-based 2FA, so if you have chosen not to enable SMS-based 2FA, we won’t reset your 2FA that way either. Getting access to your account after losing all your 2FA methods is slow and tedious. This is a feature, not a bug.

We strongly recommend printing some recovery codes and filing them somewhere safe as a fallback method.

We are committed to providing support delivered by real humans. We know how frustrating it can be to have to fight your way past chatbots and virtual assistants that can’t help you in order to get to a human that can.

In fact, when you contact us, your message will be dealt with not only by a human, but by one of our technical staff who, on other days of the week, will be managing our routers, running our DNS servers, developing our control panel and maintaining all our other infrastructure.

LLMs break processes designed for humans

Modern Large Language Models (LLMs) are very impressive, and we know that many people find them useful in spite of their inherent and well-documented unreliability. One of the downsides of LLMs is their ability to produce large quantities of text that can overwhelm processes that are built to deal with human input. This is being seen in many places, from bug bounty programmes being DoSed by LLM-generated submissions, to schools unable to cope with a huge increase in the volume and size of complaints from parents.

We’ve now started to see this in our support queries. Fortunately, the volume is not yet problematic, but we have had cases where we’ve spent a disproportionate amount of time dealing with LLM-assisted ticket submissions. This includes time spent trying to decipher what the question actually is thanks to LLM-induced obfuscation, and also time spent answering tickets that are just much longer than they would have been had they been written by a human.

Dealing with LLM-generated support queries

Our target is to respond to all support queries within one working day. Providing a 100% human support response on this basis simply doesn’t work if support requests are being generated automatically. Therefore, we have amended this target to exclude queries that we believe have been generated by an LLM; if you submit a support request which we believe has been made harder or more time consuming to answer by the use of an LLM, we may reject it and ask you to resubmit a human-authored request instead.

If you want to use an LLM to help solve your query yourself that’s great. But if that’s unsuccessful, please don’t send us your LLM output as a support query; send us your input – your prompt – instead.

We’ve posted previously about our refreshingly boring approach to domain pricing – we take the price that our supplier charges us, add a little bit more than it costs us to provide the service and sell them on.

We’re pleased to say that we’ve recently crossed the top volume threshold with our biggest domain supplier, meaning that the price that we’re charged for many domains has gone down. So, we’ve run the script, regenerated our price list and have reduced our prices for the vast majority of Generic TLDs (gTLDs) and non-UK Country Code TLDs (ccTLDs). For example, .com domains have dropped in price from £14.50+VAT for one year registration/renewal/transfer to £13.50+VAT.

We’re proud to provide a sustainable, no-nonsense approach to pricing. We don’t mess around with loss-leading first year pricing that needs to be clawed back through inflated renewal pricing or a hard sell on add-on services that you don’t really need.

The new prices apply to renewals and transfers as well as new registrations, and to new and existing customers alike. Our new prices can be viewed at mythic-beasts.com/domains.

Constant pestering to review every online transaction is rapidly overtaking cookie banners as the most annoying feature of the modern internet.

We’re committed to making the internet less annoying. We don’t have a cookie banner on our website – we don’t need one because we don’t track you – and we also won’t hassle you to review us every time you interact with us.

But review sites exist, and we know that many people do look at them, so we’re very grateful to the customers that have left us some truly wonderful reviews on TrustPilot and elsewhere.

Unfortunately, the flipside of not constantly nagging our customers to review us is that the volume of reviews that we receive is relatively low, and a small number of negative reviews can have a big impact on our overall score.

After a five-year run of nothing but 5* reviews on TrustPilot, we recently received a couple of suspiciously similar 1* reviews within the space of a week. The reviews are light on details, and the reviewers have not responded to our request via TrustPilot for more context for the reviews.

Various aspects of the reviews make us believe that these reviews are not from people who have had any genuine experience of Mythic Beasts but have in fact been commissioned by a disgruntled third party. You can see the details, and our response, on our TrustPilot page. You can also see the significant impact that it has on our overall score, which is amplified by the weighting that TrustPilot give to more recent reviews.

We have flagged the reviews and provided TrustPilot with details of why we believe that these reviews cannot be genuine, and why we believe that they are “incentivised”, both of which are against TrustPilot’s Ts&Cs, but despite the reviewers’ refusal to provide any details to validate their reviews, TrustPilot have thus far elected to let the reviews stand and have only provided us with automated or templated responses.

We are now an Accredited .ie Registrar, meaning that we can offer our no-nonsense approach to domain registrations on all .ie domains.

Are you fed up with companies that offer discounted initial registrations followed by inflated renewal prices or a hard sell on extras that you don’t need? Transfer your .ie domain to us today.

Our .ie domain registrations include all of our usual domain registration features including:

• DNS hosting, with easy zone import and export
• Powerful DNS API
• DNSSEC support
• Dynamic DNS support
• No lock-in
• Great support

… and of course, our refreshingly boring pricing.

Residency requirements

.ie domain registrations do require that registrants have a “Connection to Ireland”. Being a resident, or having a registered Irish company immediately ticks this box, but there are other ways to qualify.

We currently handle new domain registrations manually. You can order via our website, and we’ll be in touch with any details needed to prove your connection to Ireland.

Transfers

.ie domain transfers are really fast and simple:

1. Get the auth code from your current registrar.
2. Make sure your domain is unlocked.
3. Go to transfer domain on our website.
4. Enter your domain name.
5. Choose how long you want to renew for (between 1 and 9 years).
6. Enter your auth code.
7. Give us some money.

The domain transfer should complete immediately.

As with most domains, the period that you select when transferring is added to your current expiry date, so the transfer doesn’t really cost anything, you just pay for your renewal early.

Pricing

.ie domains are one of the few TLDs where we do charge less for new registrations than renewals, but that’s only because the .ie registry charges us less.

We charge £15.50+VAT for a one year registration, and £21+VAT for a one year renewal or transfer. There are some decent multi-year discounts available: a ten year registration costs just £101+VAT, and a nine year renewal/transfer costs £123+VAT.

A recent Google support article has quietly announced plans to drop POP3 support from Gmail in January 2026. On the face of it, this is no big deal. For most purposes, POP3 has been pretty much replaced by IMAP anyway, but there’s a more important change buried in the article.

The issue is confused by the fact that Google use the “Gmail” name to refer to two completely different things:

• The Gmail mobile app that lets you read email on your phone and tablet.
• The Gmail web interface that lets you read email in a browser on your computer.

The Gmail mobile app lets you connect to multiple different mailboxes, and will continue to do so, just not with POP3. IMAP is much better for this purpose, as it supports mail folders, and properly supports access from multiple different devices, so the removal of POP3 support here is no big deal. If you use the Gmail app to read mail in a mailbox hosted with Mythic Beasts, it’ll continue to work just fine.

The significant change is this one:

• The option to “Check mail from other accounts” will no longer be available in Gmail on your computer.

“Gmail on your computer” is Google-speak for “the Gmail web interface”. The “Check mail from other accounts” option is a feature that allows you to pull in mail from other mailboxes and drop them straight into your Gmail inbox. It behaves as if you had just forwarded mail from your other address to your Gmail address, but with one crucial difference – it works reliably.

As we discussed in a recent blog article, efforts to make it harder to spoof email have also made it much harder to forward email reliably, and until now, the “check mail from other accounts” feature has been our recommended way to “forward” mail to your Gmail inbox.

Hopefully Google will contact users to tell them about the change, but we are also doing some log analysis and will be contacting customers who appear to be relying on this feature to collect mail from their Mythic Beasts mailboxes.

Customers who are currently using this feature will either need to revert to simply forwarding emails to Gmail — with the associated risk that Gmail may reject some of your legitimate email – or switch to a different webmail platform. And on that last point, we’re working on a refresh of our own webmail platform that we’ll be announcing in the near future.

After careful consideration, we have reluctantly taken the decision that the use of Cloudflare will not be supported on our Web and Email Hosting service. First two clarifications:

• This only applies to our Web and Email Hosting services. It does not, and will not, apply to virtual servers (VPS), dedicated servers or Raspberry Pi servers.
• We have never formally supported or encouraged the use of Cloudflare with our Web and Email service. Until now, we have generally discouraged it, but we’ve tried to accommodate users who chose to use it.

The problem

As we’ve written about previously, we’ve seen a huge increase in the amount of abusive bot traffic hitting our web servers — much of it badly behaved AI scrapers — and frequently the volume of traffic is such that it overwhelms the server, and makes websites unavailable. At times we’ve seen over 95% of traffic coming from AI scrapers. Our Web and Email Hosting service is what’s often referred to as “shared hosting” meaning that we have websites for many customers on a single server. This is a very cost effective way to provide web hosting, but it does mean that any load issues caused by traffic to one website can affect other sites on the same server.

Our primary tool for dealing with abusive traffic is to identify the source of traffic and block the IPs that it’s coming from.

Cloudflare provides a service that seeks to protect websites by blocking abusive traffic. It does this by operating a “reverse proxy”; rather than web traffic arriving directly at the web server, it is instead sent to Cloudflare’s servers. Cloudflare inspects the traffic, filters out the abusive traffic, and then forwards the legitimate traffic to the actual web server. This has the effect that all traffic arriving at the web server appears to come from Cloudflare’s IP addresses, rather than the actual client IPs.

Some of our customers have chosen to front websites hosted on our shared hosting servers with Cloudflare. The problem is that Cloudflare isn’t perfect; it doesn’t succeed in filtering out all abusive traffic. This is particularly true of the free tier that we tend to see used in conjunction with our Web and Email Hosting service.

Unfortunately, when we see a large volume of abusive traffic arriving via Cloudflare, we are faced with a choice: either we block Cloudflare’s IP addresses, knowing that this will take all websites using Cloudflare completely offline, or we accept the traffic, which potentially has an impact on all websites hosted on that server. With the growth in volume of abusive traffic, we are being forced to make this choice increasingly often.

We have now taken the decision that we will treat Cloudflare’s IPs like any other IPs: if we see abusive traffic from them, we will block them. In the future, we may introduce a permanent block, or redirect traffic to a support page on our site that explains why Cloudflare is not supported on the service in order to avoid customers inadvertently using an unsupported configuration, but we will contact customers who appear to be using Cloudflare prior to taking this step.

FAQs

Obviously these questions are not frequently asked as this is the first announcement of this change, but whatever; here are some questions and answers:

What have you got against Cloudflare?

None of this is a criticism of the service that Cloudflare provides. The same would apply to any reverse proxy service placed in front of our servers that prevents us from seeing the actual source IP, thereby removing our ability to effectively filter traffic ourselves.

We do have concerns about any service that breaks the end-to-end encryption of web traffic, but that’s unrelated to this issue. Cloudflare (and any other such service) relies on terminating the TLS connection from the client on their servers, inspecting the traffic, and then making a new secure connection to the target web server.

Why do you think you’re better at this than Cloudflare?

We’re not, but when a particular attack is affecting our ability to provide our web hosting service to hundreds of customers, we’ve got a much stronger incentive to resolve it quickly.

Cloudflare definitely has some very impressive technology, but we suspect that much of it isn’t provided in the free tier of their service. Upgrading to a paid-for tier, or careful configuration of the free tier, might yield better filtering, but in our case, we’re affected by the most permissive configuration; it only takes one customer to point Cloudflare at our server with minimal filtering and we’ve got a mix of legitimate and abusive traffic arriving from the same IPs and we’re back where we started.

Cloudflare includes the client IP address in an HTTP header – why don’t you filter on that?

Filtering based on the source IP address of a TCP/IP connection can be done very efficiently because you only need to look at the packet header. Filtering based on an HTTP header requires accepting the connection, setting up a TLS connection and decrypting the content, and then parsing the headers, which is a significant overhead, and in extreme cases, the load from doing this is prohibitive.

Can I use Cloudflare on my VPS or dedicated server?

Yes, absolutely. The issues described here that make Cloudflare such a problem for our Web and Email Hosting service don’t apply to VPSs and dedicated servers, so if you want to put Cloudflare — or any other reverse proxy — in front of your server, you are free to do so. Of course, dealing with any abusive traffic that slips through is your responsibility.

Can I use Cloudflare on my managed server?

If you have a managed server with us then we will attempt to resolve any load issues caused by abusive traffic as part of this service. Please do not install Cloudflare (or similar) in front of your managed server without discussing it with us first, as it will hamper our ability to respond to any incidents. A special case is our WordPress Shared tier of managed WordPress hosting. As the name suggests, this is implemented on our shared hosting platform, and so we cannot support the use of Cloudflare with this service.