Hi, After a minor incident of some phishing emails being sent purporting to be from bitfolk.com, on 3 June I tightened the SPF record of bitfolk.com from ~all to -all. This basically says that ONLY the hosts listed in the SPF record are permitted to use a bitfolk.com envelope sender on email, and that any other host trying to do so should be rejected. I have since noticed that some customers are using traditional server-side forwarding, e.g. on role addresses, to send BitFolk emails to a group of people, and some of those recipients are doing as asked and rejecting the email. More are probably silently discarding or filing the mails away in spam/junk folders. This happens because when your mail server forwards an email from e.g. billing(a)bitfolk.com through role(a)yourdomain.co.uk and out to joe.bloggs(a)example.com, your mail server is pretending to be billing(a)bitfolk.com. Since you do not match bitfolk.com's SPF record, the mail server for example.com rejects the email (unless configured otherwise). Unfortunately we can't go back on this configuration. It's just the way that email works in the 21st century. Server-side forwarding of email in this way is not something that can be expected to work any more, unless you control both the recipient address and every address it expands out to. So what can you do if you currently do forwarding of addresses like this? - The generic answer is Snder Rewriting Scheme: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme - A more limited answer is to run a real mailing list of some sort, so that, for example, billing(a)yourdomain.co.uk goes through a real mailing list manager like majordomo or Mailman, is rewritten and sent out to the people who should receive it. - If you control or have strong influence on all recipients, you can configure them to allowlist particular senders. - You can set up real mailboxes for your role accounts and have interested parties download the email by IMAP or POP. I'm sorry that this change has broken some previously-working forwarding setups. It isn't something we can revert though (and indeed, it will have to get stricter, with additional DKIM and DMARC to come). Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting