I run a few moderately sized corporate e-mail systems. SPF, DKIM, DMARC are all necessities, but unfortunately they don't guarantee delivery. We have much better success sending e-mail out via Mailgun or Sendgrid. Since Verizon swallowed up Yahoo Mail and @aol.com, it's very easy to get on their shadow ban list, and nearly impossible to get off. Good luck telling all the employees they can't email @yahoo.com and @aol.com for at least 2 weeks.
I see e-mail as another Internet service that is slowly centralizing, and if you operate outside of the big tech companies- for example, if you don't use Google/Yahoo/M365 e-mail, you're probably going to be in for a headache, even if you run perfect e-mail infrastructure.
Not centralizing -- these providers are colluding in a oligopoly. I think there is an argument to be made that these large providers are creating a situation where they set up barriers of trust that only allow email from each other to pass. Small independent senders are locked out simply by not being part of the trusted club, even if their email is valid and passes all of the standard hurdles (SPF, DKIM, etc).
They are doing that. But it doesn't seem to be in order to capture market share. It is because of the extreme spam abuse coming from so many unknown domains.
I actively work with and set up ~100 domains in SendGrid, and Yahoo and AOL are still, have have been, THE BANE OF MY EXISTENCE since I started working at this job 8 years ago. It's always been a black hole into any type of support. I always get the same answer back... "If you don't want to be seen as a spam bot, don't act like one".... OK, I'll just tell my client they can't send their 20k emails when they want (with a non insignificant going to Yahoo/AOL still). Honestly I don't know what else we can do better. We don't send newsletters and such, we only send transnational emails.
We are a small SaaS start-up with 4 engineers in total, I'm one of them. Being a senior person, I've to deal with all kinds of crap; SFP, DKIM, domain validation and what not.
Just when I relax content that things are in control I get a folder full of files which contain spaces in the file names that need to be processed.
I tried Mailgun about 5 years ago. I had a short term, low-volume need, but found that their free tier servers had poor reputations and I remember that Yahoo in particular would not deliver their email. Maybe that's to be expected: any free email sending service is going to be abused by spammers. But it wasn't a great first impression.
Mandrill has been reliable, but more expensive, when it comes to AOL Yahoo Hotmail and Outlook. (I work at an agency, we recently migrated off sendgrid to mandrill for all our clients due to deliverability issues)
Which is why it is so vital for anyone with at least minimal tech know-how to run their own email infrastructure. The Internet is only a meaningful concept if it consists of peers running standard decentralized protocols.
If all we had was a few giant corporations with proprietary apps and proprietary protocols, that's not the Internet.
As I post every time on these email discussions, the difficulty of running your own email infrastructure is vastly overstated on HN. The more people do it, the better off the Internet world is for all of us.
I have run my own email infrastructure for 3 years, for personal use (I was the only user). I have since moved to using fastmail due to my mail failing to be delivered to any microsoft email. Microsoft would accept the mail, but it would never appear in the mailbox, and neither would it arrive in spam. The mail just disappeared somewhere in their system.
I have spent many days debugging the issue, to no avail. Every other operator accepts my email, and my domain was never used to send out spam (I set up DMARC to make sure I am aware of all outgoing email). I imagine the IP might have been the issue, but I cycled through a few hosts without success.
Everything was configured correctly AFAICT, I could send email to all major providers, except microsoft. SPF, DKIM, DMARC were all set up. I tried many different configuration testers, and they all returned green on my domain.
Since migrating to fastmail (keeping the same domain), I haven't had any problem.
The thing is, I agree with you, the world would be a better place if everyone could host their own email. But at the end of the day, I need the ability to contact users using the major email providers, and so do I suspect many HN users.
I've been running my own email infrastructure since 1993, starting off with a UUCP feed to an Amiga over a 9600 baud modem. After that, I think I went Smail -> Sendmail -> Qmail -> Postfix on a variety of platforms (Linux, Solaris, FreeBSD.)
I'm running an email server for myself since 1998 and in addition some low traffic email servers for a few small companies that I administrate and we have had no delivery problems so far, not even with Google, although I have heard from other people that run their own email servers, that Google occasionally puts delivered emails in the Spam folder.
I always keep an eye if some of our IPs may appear on any of the well known abuse lists, but so far that never has happened. I would guess if once there's coming spam from your mail server IP, it is negatively branded forever.
I've had my setup running for so many years with minimal changes so don't have recent links handy but I'll give it a shot. This also points to the fact that while the initial setup will take some reading and effort, the ongoing maintenance year to year is basically zero.
Start with a good IP address (static, not residential ISP, not on any block list). Search for sites that will help check this. https://mxtoolbox.com/ has many useful bits but there are others, try them all. Set up DNS correctly, forward and reverse.
Set up postfix. Tons of guides out there, here's just one list: https://www.linode.com/docs/guides/email/postfix/
Read the various guides but most importantly read the postfix documentation in detail. It is very good and has everything you need to know. Configure postfix to enforce all sanity checks that it supports during the delivery connection phase. This alone will cut off nearly all spam!
Install a local MUA (mutt would be my favorite) and you're up and running and should be able to send and receive, so test that thoroughly. Probably ending up in spam at this stage but should work. Mark it not spam in recipient. Note that if you had to register a new domain name, it'll likely be penalized as too new for a good while.
Set up a cert (Lets Encrypt) for postfix.
Configure SPF correctly. Read online guides but also read the RFC. Again, use online tools to validate your work. SPF is great.
DMARC, DKIM are more controversial and less clear-cut useful than SPF. Read about them. I do set these as well. Set the notification email so you get reports (which aren't that useful but still). Use the online tools to validate.
Even using SendGrid, it will be a week or two and a few hundred emails to 'warm up' one of their mailserver's IP addresses and get reliable delivery. Like you, I found VZ to be the worst at trusting new servers.
The days of firing off an email from any ol' SMTP server are completely gone.
> The days of firing off an email from any ol' SMTP server are completely gone.
I'm not sure... I agree with the general vibe in this thread however my experience (within the last year) is that you can fire up a fresh one and send email to gmail at least, without SPF, DKIM or DMARC.
However as soon as you start doing any mass mailing of any kind you need all three of those things, SPF to not get outright blocked and get into the spam, and the other two to have their spam detection filters to even bother parsing your email content for the chance of getting into the inbox.
This is my experience from setting up systems that send automated status emails not marketing, so fairly low volume but frequent enough with same message content to be immediately classified as mass emailing.
I've never had issues with gmail, though I know a few people who did. But I think setting up SPF and DKIM will, for the most part, do the trick to allow communicating with gmail users.
The problem is the other provider. Yahoo, AOL, Microsoft. They're all a pain in the neck and much, much stricter. And sadly, they still amount to a not insignificant portion of the market.
I feel you 100%. The timing of this post is near perfect with what is happening in my life. I run my own web server with email hosting for clients. I’ve spent the last few years doing everything I can on the deliverability side but with no success. All the checkboxes have been checked but I still hit the spam folders. Just yesterday I gave up. I migrated all my clients to Office 365 and I did it knowing I was killing the soul of the Internet. But I was just too tired of dealing with clients who don’t understand why their emails end up in spam folders all the time. These clients also don’t have the same “values” when it comes to decentralization. They run small businesses and cannot afford this spam issue. I feel like there should be laws againsts what the tech giants are doing. Their spam filter rules are killing competition and the free internet.
Sadly I've found this to be the case both with perfectly configured personal email servers and when using privacy-preserving email providers like Tutanota. Do you think there's anything that can be done to counter this centralizing force?
On the side of centralization is a market worth unimagined billions, and perhaps seven providers that already routinely lobby to get what they want.
On the side of decentralization? Little guys who are already being bullied and don't have the resources. Politicians who have other extremely dangerous problems currently, including and especially those in their own industry. Don't expect their help for a long time. Smaller service providers who only want the chance to switch sides. And large independent organizations (businesses, schools, governments) who are really only interested in a cheaper bill for the same service quality.
Look, we have struggled to fix the MITM/plain text problem and spam/origin problem for well over 20 years, and the Internet Age is maybe 30? It's extremely likely that the only way to fix the core design problems with email is to have the service consolidate to a small consortium of services, have them improve the base design, and then fracture the monopolies. That's going to take decades.
And mail is still such a pain in the butt for a user document database. And the user experience is a joke! Asynchronous delivery, best effort failure? I mean, what? The average web page is orders of magnitude larger now! People complain about FAX and FTP.
The three protocols for email (SMTP/POP/IMAP) are all outdated really badly. People today needs more efficient, multiplexed and real time message RX/TX, and those tree just not going to cut it.
A new, chat-styled mail protocol can be designed to address all the problems above while reduce the risk of abuse. I wonder why nobody standing up to do it.
These configurements do not signal "This person sends good emails", they signal "This server is what it says it is". I can load up barracuda right now and show you plenty of pornbots that have figured out how to put in a passing SPF record... as well as legitimate businesses that don't validate email addresses put into their marketing funnels.
Unfortunately, we are back to the age old question. How can we have an ecosystem where anybody can email anybody without it being taken over by spam?
Dint proof of work originated as a way of fighting spam? I wonder though why it didn't become widespread. Instead of shadowbanning/blocking the providers like VRZ could just increase the required POW difficulty.
I am actually a bit more optimistic that the iron grip over email might be attacked from an unexpected direction. A lot of political parities over the world depend on email to operate internally, and the power demonstrated recently by cloud providers in the last few months are making people scared. It only take some publicity and some badly timed bans/lockouts from google before that risk seems much more real again.
Same. I run a 10/10 (mail-tester.com) mail server for myself personally on a VPS from Digital Ocean. Its IP address is on Charter's permanent blocklist and has been for years so I cannot email my mom. I set up a SMTP relay via a free-tier sendgrid and it worked for a while but then that relay got added to spamlists and I could basically only email my mom. Presumably the paid sendgrid setups allow a bit more resilience against getting on those lists.
My sister obviously thinks the “spam” button is the same as “delete email” button. Every once in awhile I get the Google apps for domains notification “tons of spam has been marked”.
Any high volume vps, vm, dedicated server, Colo hosting company is going to have this problem with ip space reputation.
The only place to fully self host your own email these days is on a more boutique isp where it's not possible for anyone with a credit card and a pulse to sign up as a customer in a fully automated process.
I moved my mail away from Google last year, and can no longer accept people's calendar invites. It seems that the "Yes"/"No"/"Maybe" links in the email body of a calendar invite cause Google's (or whoever's) servers to spoof an email in my name, which predictably fails if my SPF is set strictly. I have not been able to find a good workaround for this.
If you still have a google account that has the “calendar” feature enabled, this will lead to google sending invite acceptance emails.
Especially if you have a business account (which was my experience,) where you verified the domain.
The solution for me was to disable “calendar” as a service on the entire account.
Realize that “google calendar” and “google mail,” are technically distinct services. However that doesn’t seem to stop “calendar” from sending emails on your behalf.
I added them as neutral (the '?' character) rather than an allowed domain: I don't want to have to understand Google's mailing policy when assessing the risk of my site being downgraded.
The sad reality is that you should expect to be delivered into the recipients' spam boxes until you have managed to convince Google/Microsoft/Yahoo that you're not a spammer.
As far as I can tell, it simply is not possible to buy a new domain, pay for a email service and have mails delivered straight into people's inboxes. After all, if you would be able to do that then so could the spammers.
Ramp up volumes slowly. Make sure the recipients actually want the mails you send, and for all that is holy, educate your users that the "Junk" and "Trashcan" buttons are two very different things. People who repeatedly mark your mails as spam need to be blacklisted, no matter if they're paying customers. Period.
Oh, and handle abuse complaints right away. Don't be afraid to tell people they're not supposed to mark your mails as spam and to explain the consequences.
> educate your users that the "Junk" and "Trashcan" buttons are two very different things.
we have 97% reputation on sendgrid, and the only mail we send are a) customer requested password reset and b) customer requested notification for completed workflow jobs.
I don't know who that 3% is, but it is enough to get sometime filtered and I don't think we can ever win this
Sendgrid itself is a major source of spam, and simply using them can result in mails getting filtered. There are even Spamassassin rules (3rd party) that specifically add spam score to mails, if they are sent through Sendgrid.
The 3% may very well be ignorant users who are using the Junk button as a way to remove the mails from the inbox (yeah, people actually do that), but for good measure, things like signup forms and password reset forms really should be protected with a captcha, as any form able to send any form of email whatsoever will be abused by bots trying to send spam.
Definitely, and so are most free email services. Try blocking Gmail, on the other hand, and your users will be somewhat upset. Sendgrid doesn't have that kind of weight behind them.
Of course, but it very much a "do as I say, not as I do". i.e. google applies a zero tolerance policy to receiving spam from any domain, but is likely way above any absolute threshold they impose on incoming messages for the spam they emit.
I'm in favour of anti-trust action against Google and Microsoft for their outright anti-competitive anti-spam practices, but that's going to be a long and hard up-hill battle for anyone attempting it.
Meanwhile, the rest of us will have to accept things for what they are and deal with them as well as we can.
Doesn't really help when people's initial reaction to unexpected mails is to press "Junk". A random spambot entering a user's email address in a random form is enough to trigger a complaint. It's ridiculous but it is what it is.
Also, get a private IP from your email service. Don't use their public ips. Or you will cry as the IP they have you on will randomly get put on SpamCop.
Even with my private IPs I've had random anti-spam services just decide to list all Sendgrid IPs.
Yeah, no. Unless you're sending sufficiently high volume (ie millions of emails a week) or are sending B2B to exchange servers, getting a private IP is a waste of money and could negatively affect your sender reputation more than using a shared IP.
Spam filters have significantly advanced beyond simple IP checks.
We can agree to disagree here. You have no recourse when one of the Sendgrid shared IPs you are using gets put on Spamcop. Sendgrid might get around to working with them to remove it in a couple weeks. You also have no way to eliminate that IP from your pool of IPs. So in my case about 40% of reports I was sending out were getting blocked at the email server of the receiver.
Buying a private IP is your only recourse. Unless your emails don't matter, in which case it might be fine to lose 40% of them.
This is my experience as well. Submitted a support request, after a week got told "we're working on it" while my users were not receiving email address confirmation emails. Moved away from SendGrid very quickly after that.
I have some legacy IoT devices in the field that directly talk to sendgrid. Would be a big pain if I had to recredential them. So I stayed on sendgrid.
My newer devices get their email proxied through a proxy I host. It was a dumb mistake on my part to tie myself to so tightly to a SaaS vendor.
How much worse do you think it'd be if you had a static IP and were essentially having to manage your own sender rep yourself? Google and microsoft postmasters are unlikely to pay much attention to someone running an IP maybe sending a few thousand emails a day.
Just this last weekend I started moving clients off of the mail hosting services I've managed for years and onto Fastmail. I have self-hosted my email since around 2005, and had my first email address around 1994 or thereabouts. It has never been more broken than it is now, and I mean that without even the slightest hyperbole.
The first RBL showed up around 1998, operated by Paul Vixie of DNS fame. I was using a small ISP in the East Bay at the time and they hated the MAPS RBL, especially the idea that they had to deal with some third party to resolve mail transport issues. But, from 1998 until the early 2000s, RBLs proliferated and lots of mail services subscribed to one or more. The one thing they had going for them was that they were easy to query, so it took no effort to find out if you were on the list, and if you were, there was usually a living, breathing human being somewhere that you could contact to get the matter resolved. It was a pain in the butt, but it could be handled.
During this time, the responsibility for ensuring that a message was received shifted from the recipient to the sender. Beleaguered systems administrators soon found themselves in a situation where they were supposed to be responsible for both ensuring that no spam reached their customers and that all of their customers' email reached the intended recipients.
Gmail came along and decided that, because they were operating "at scale", they didn't need to play in the same ecosystem. Over the years, ensuring that a message lands in a Gmail user's inbox has turned in to an infuriating game of trial-and-error. Gmail can do this because they now manage between 40% and 60% of the internet's email traffic.
AT&T/SBCGlobal/Yahoo/whoever they are now seem to have recently penalized all of Linode's and DigitalOcean's IP space. I deployed several mail exchanges and didn't have any luck reaching any addresses managed by AT&T's network. And, again, there's nobody I can kibbutz with to resolve it.
AOL has been such a hot tire fire that I ended up blackholing any outbound traffic to them. I know that sounds drastic, but anytime a single AOL user clicked the "spam" button on an email from one of my customers -- who weren't spamming, newslettering, or anything else remotely skeezy -- it would generate an automated complaint from AOL to Linode, and Linode would threaten to suspend my account. I'd have to dig the relevant traffic out of the logs and respond back to Linode with a polite "AOL's full of shit, please stop listening to them". I explained the situation to the few people that were impacted by it and everybody got on with their lives.
Microsoft's outlookprotection.com filter has been a gigantic pain recently too. It's annoyingly capricious and, again, the tools just aren't there to resolve it.
Email delivery has been a bit tricky for several years, but the last year especially it has become impossible for small services. You have SPF, DKIM, DMARC, great, but it turns out that Gmail also dings you if you don't have ipv6 records arranged right or if you aren't transporting mail over ssl or or or or.
Email was designed as a cooperative system but the BigCos have carved it up and are working hard to ensure that if a message doesn't come from one of their networks, then it's immediately suspicious.
Sendgrid isn't much better in this regard. My network received a flood of spam from them, with legitimate traffic mixed in. I couldn't block them without complaints and I couldn't not block them without complaints. I wondered if I was the only, so I signed up for their service and routed some mail through them for a few days to see what it was like as one of their subscribers. Turns out that Comcast and half a dozen other service providers hate them just as much and deliverability was around 79%.
The things you and others are experiencing, and that I experienced, are going to keep getting worse. The bigger networks are going to keep squeezing customers out of the smaller ones, breaking email bit by bit in the process. I hope Fastmail is able to grow quickly enough to keep sitting at the table.
One of the most important things I learned about SPF records was that the entire record had to be under 256 bytes. We were sending out emails from multiple servers on one domain, and were having so many deliverability issues because the SPF record had too many entries in it and would be seen as invalid by some spam firewalls. Once I cleaned up the record and split some email out to subdomains our delivery rates went way up. But of course as others mentioned SPF is just the beginning. DKIM, DMARC, reverse records, etc are all very important as well.
> One of the most important things I learned about SPF records was that the entire record had to be under 256 bytes.
It sounds like this is a case of buggy implementations. You can have TXT and even SPF records longer than 255 bytes. The fundamental issue is that TXT records are composed of segments of up to 255 bytes each, where each segment has an 8-bit length header. As Resource Records (RR) individually, as well as DNS packets as a whole, have a maximum length of 65535 (because of 16-bit length headers), DNS supports TXT RRs of approx. 256 segments, 255 bytes each.
It's not too surprising implementations might be buggy in this respect. It's a rather esoteric aspect of the TXT RR specification. (If only because few people, including developers of DNS-related tools, bother actually reading the specification!) And unfortunately neither the popular rfc4408-tests.yml nor rfc7208-tests.yml test suites seem to have a test case for long TXT records. Even if a test had been included it likely wouldn't have caught many violators as it's actually a matter of the low-level DNS library providing the proper interface(s), many DNS libraries are deficient in how well they expose DNS record parsing or packet injection interfaces, and most SPF libraries would have likely integrated the test suite at a higher level that didn't involve actually making queries using a low-level DNS library, which can be difficult to do.
That said, RFC 4408 says that,
> SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier.
IME experience this limit is rather low and many, many SPF policies require more than 10 queries. (And if you need SPF policies larger than 255 bytes, you're probably skirting this or other similar limits.) When I was writing and deploying my own implementation I very quickly realized I needed to increase the minimum maximums, but choosing that value is a total crap shoot.
SPF records large than 256 bytes are pretty common. See e. g. aspmx.sailthru.com (1st what found right now). You just have to split text into multiple strings, but don't forget to add a space after or before a derective, because strings are joined without an extra spaces: https://tools.ietf.org/html/rfc7208#section-3.3
May be there are buggy implementations which don't understand this, but doubt they are common.
You can fix this by putting a single SPF entry for each envelope/returnpath domain. SPF scales smoothly that way without any need to overload a single top level record with entries. This will pass DMARC as well.
"We set a specific header in the email called Return-Path with all emails sent through our email service. If you take a peek at a raw email sent over OhMySMTP you’ll find that the return path ends in @mailer.ohmysmtp.com, and if you look this up in the DNS system, you’ll find an SPF record that points to our server IP address."
While this will mean that and mail sent will pass SPF, it doesn't play well with DMARC. The SPF pass domain won't align with the From header domain, so the SPF authentication will be ignored.
"But SPF alone doesn’t completely solve spam, we also need DKIM, and to a lesser extent DMARC. More on those later!"
Realistically, SPF doesn't do anything to solve spam, nor does DKIM or DMARC. All of these technologies address spoofing and give a greater confidence of the sender responsible for the email which can then be used in reputation engines.
Passing SPF/DKIM/DMARC say nothing about the message contents.
SPF, DKIM, DMARC are must have for today mail and yet many domain owners fail to make even the first and easiest step - publish a valid SPF record. Some mistakes I commonly see (don't do this):
* no space between directives: "v=spf1 ip4:192.0.2.0/24 include:example.org-all"
* space inside a directive: "v=spf1 ip4:192. 0.2.0/24 -all"
* bad mechanism: "v=spf1 ipv4:192.0.2.1 -all"
* no mechanism: "v=spf1 192.0.2.1 example.com"
* = instead of : "v=spf1 include=example.com"
* Unicode, mostly dashes (but I've seen zero-width spaces too): "v=spf1 —all"
* Two SPF records for the same domain: "v=spf1 mx:example.com -all", "v=spd1 include:example.net ?all"
Don't know where it coming from, but IMHO we see a generation of developers/admins raised by Google search: you can type a search query with mistakes and still get what you want. Or may be web browsers to blame - you can screw up HTML/CSS in dozens ways and they'll render content anyway. And they start to think that all IT systems forgive small mistakes and typos. They just don't get that sometimes you have to read RFC (or at least simplified how-to) and follow it exactly.
What you describe, adding the DNS TXT record for DKIM, is just the icing on the cake. It's way more work and complex at postfix (+rspamd to sign or whatever) level. Suggesting that you can just,
>Hostgator -> cPanel -> Email Authentication
...is ignoring 99% of the complexity and long term maintainance that DKIM implies.
And why bother? It's not like the mega-corp walled gardens care if you have the perfect mailserver implementation. They'll mark you as spam or blacklist you anyway, because they can, because it's easier, because it's a job someone's doing for profit and you don't effect that.
No. An SPF record is enough for determining if mail is legitimately from it's real mailserver. DKIM is cargo cult nonsense for most cases. A sacrifice to the google/microsoft/apple gods to hopefully earn their favor, but one that is almost always ignored anway.
In my case, the mailserver is only used to use a custom email address and forward the email, so deliverability was not an issue but other people using my domain name to send phishing emails. By making the fixes mentioned in the article the phishing attacks were stopped.
SPF asserts that a given IP address is authorized to send mail from a particular envelope sender domain (the user typically does not see this domain)
An email with a user visible From address of potus@whitehouse.gov can have passing SPF from evil.com
DKIM asserts that the message contents have been sent by a particular domain (or domains), that domain does not necessarily relate to either the envelope sender domain, or the domain the user sees in the From address.
Again, an email from potus@whitehouse.gov can have a perfectly valid DKIM signature from phisher.com
DMARC is a policy layer over the top of these, which ties the domain the user actually sees in the From address back to those used in SPF and DKIM.
This is where the potus@whitehouse.gov email starts getting blocked. Neither the SPF nor DKIM of the email are "aligned with" whitehouse.gov, and we can start to do something about the spoofing.
It's simplest terms, SPF allows you to prove (and equally importantly disprove) that a piece of mail comes from your domain based on IP address (there are a variety of mechanisms, but in the end it all boils down to IP). Basically SPF spells out specifically which hosts are allowed to send mail from your domain.
DKIM allows you to prove a message originates from your domain via a cryptographic signature. So any mailserver with the private key can send messages from your domain, it's not limited to a predetermined subset.
In different situations one can be more useful than the other. It's also recommended to implement both, as one or the other might fail for various reasons.
It's also worth noting you really should implement DMARC as well, which lets you spell out a policy for what recipients should do if SPF and DMARC fail, including if they should notify you and how.
Just please set up DMARC so it allows forwarding a mail... Have had this problem a number of times lately, companies sending mail to us that just vanish in thin air without any explanation. Turns out an alias adress is forwarding their mail to whoever is supposed to handle their mail at the moment and this is not allowed due to how they set up DMARC. The mail server just drops the mail without warning.
If forwarding is failing DMARC, that's on your system, not the senders. There is nothing the sender can do to help the situation.
Basically DMARC needs either DKIM OR SPF to pass to consider a message passing. Being no SPF record will ever include (forwarders aren't allowed to originate messages from the domain) that means DKIM has to pass.
DKIM works by signing the message body and selected headers with a private key, while the public key is published to DNS. This allows a receiver to fetch the public key from DNS and validate it was really sent by the sender. It should be clear at this point that you'll be able to forward a DKIM signed message as much as you want as long as you don't modify the message when sending. If on the other hand your forwarder modifies the headers (including subject) or the body DKIM will fail.
In other words, if your going to use a forwarder, make sure that forwarder will forward the message as is. You can add headers, but don't remove or modify any existing headers and don't modify the message itself.
O2's billing emails, and a well known bank have broken DKIM signatures as they are improperly forwarded.
No chance of getting through to their tech support, especially since these types of email are usually from a no-reply@ address and the people manning the phones are not the mail server admins anyway.
I've always wondered - what could have been done to the original specification for email that would have avoided this hellscape of spam and antispam measures?
Or does spam appear in any popular messaging system anyways because it is such a strong selective pressure?
People who send spam never think it is spam. They often think their UBE is somehow different from all the other stuff. They claim that the recipients want this bit of email, even if those same recipients complain about getting spam.
Apparently, having multiple A Records can cause problems with spf records. The founder of hanami.run, an email forwarding service, showed me how to fix mine.
I see e-mail as another Internet service that is slowly centralizing, and if you operate outside of the big tech companies- for example, if you don't use Google/Yahoo/M365 e-mail, you're probably going to be in for a headache, even if you run perfect e-mail infrastructure.