In simple words, authentications are ways to show to the MBPs (MailBox Providers) that Splio has the authorization to send messages, using your "credentials". In practice, authentication exists to associate a domain name to a message, validate the author or origin of a message, validate the content of a message, and create a reputation. It can also help prevent phishing.
We strongly recommend creating a sending sub-domain dedicated to Splio. It must be different from the one you use for internal and corporate communications, or other emails you might be sending with other providers. This way, Splio could have clear visibility on the reputation and deliverability. Also, the main domain usually involves corporate email box, website hosting, third part configuration, etc. and there’s no reason to interfere with those.
Best practices and tips
- Use a sub-domain of your main domain name (the one that links to your internet website). By focusing on your primary domain instead of registering a new domain name specifically for email delivery, you reduce the confusion that recipients may feel, while also reducing the risk of misappropriation.
- For example, news.example.com indicates a direct relationship with example.com, while news-example.com does not. There is nothing to prevent a malicious party from registering info-example.com.
- Use a different sub-domain depending on the type of email sent (based on whether the email is commercial, transactional, relational, etc.).
You can read more about it in this Best Common Practices published by M3AAWG.
Most used entries for email authentication
- SPF (Sender Policy Framework) record: it is a TXT record that publishes the list of servers allowed to officially use a domain name in the “HELO” (or “EHLO”) and “envelope MAIL FROM” (not the “Visible From:” header field) steps of the SMTP transaction. Simplifying: it is a list of authorized email servers, for a given domain.*
You cannot have more than 1 SPF record. But you can merge the different pieces of information into a single one!
- DKIM (DomainKeys Identified Mail) record: this record publishes a series of “public keys” that can be used by anyone to verify a cryptographic signature that Splio will include in your message headers. If the signature cannot be successfully verified, it could mean the headers or the content of the message have been tempered with.**
- DMARC (Domain-based Message Authentication, Reporting and Conformance) record: this record is built on the widely deployed SPF and DKIM protocols ("Visible From:" + SPF + DKIM), adding a reporting function that allows senders and receivers to improve and monitor protection of the domain from fraudulent email.***
- MX (mail exchanger): this entry directs email to a mail server. The MX record must point to Splio’s server so we can manage the asynchronous bounces, and emails sent to abuse@ and postmaster@ email addresses (such as complaints or reports).
You cannot have MX records with the same priority pointing to servers operated by different organizations. Otherwise, it may cause conflicts and emails could be lost.
- Google Postmaster Tool: Google Postmaster Tools is used to follow reputation and other behavior related to your (DKIM-signing) sending domain.
This resource is exclusively related to Google, so other mailbox providers may have a different opinion of your sending.****
- BIMI: it is a protocol that allows brands to choose which logo to display in the webmail, instead of letting the MailBox Providers choose. For the moment, only Yahoo and AOL support this feature for free. Gmail requires purchasing a Verified Mark Certificate (VMC) which costs around 1000 USD. You can find more details here.
Each MBP has its own rules, some providers check all items, others just a few. For this reason, it is strongly recommended to keep all entries implemented to mitigate any possible issue.