>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.
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 [email protected] 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 [email protected] 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.
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.
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.
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 recently wrote a short article on those, a tldr for setting up basic email authentication and anti-spam: https://www.usertrack.net/blog/stop-others-use-your-domain-e...