Email Authentication is the process by which emails are verified by the receiving server to be legitimately sent from the domain of the From Address which appears on the email. This helps to avoid spam and phishing emails from entering email recipients' inboxes by inspecting the domain's DNS records for authentication.
For example, when "email@example.com" sends an email from his regular email client and email server, this isn't an issue. However, if "firstname.lastname@example.org" sends a message using MessageGears, via Accelerator or API, that email is sent out through MessageGears's sending servers, not the "domain.com" server. The result is that receiving email servers want to verify that the owner of "domain.com" has granted official permission to these 3rd party servers to send emails on behalf of "domain.com" email addresses.
When a 3rd party email server doesn't have explicit permission to send on behalf of a domain, this is considered "spoofing". This is a common term for when illegitimate email is sent with a falsified From Address and often spammy content. Without Email Authentication records on your From Address domain, emails sent via a 3rd party like MessageGears are perceived as spoofed, and therefore not considered legitimately from you. This issue will almost always lead to those emails being bounced or sent to spam.
In order to ensure that your email content gets to your recipients, taking the steps to legitimize MessageGears as sending on your behalf is important. Another step beyond this would be to white-label, but setting up SPF and DKIM records are the first items to address.
SPF stands for Sender Policy Framework. SPF records list the designated sending server (or sending IPs) for outgoing mail from the domain. SPF is generally the simplest form of authentication, but it helps to prevent spoofing by indicating the legitimacy of messages sent through 3rd party senders by identifying them explicitly.
A typical SPF record is composed like this:
v=spf1 include:_spf.exampledomain.com -all
SPF is implemented as as single TXT record for the domain, and can contain up to 10 lookups. These records can also indicate a policy for how unlisted sending domains should be treated.
|+all||PASS||passes all sending domains, regardless of listing|
|?al||NEUTRAL||interpreted as no policy|
|~all||SOFTFAIL||using a tilde allows messages to be accepted but indicate that the sending domain isn't listed; this is best used as a debugging tool, to indicate a missing record without failing SPF|
|-all||FAIL||using a minus indicates that mail from a domain not listed in the SPF record should be rejected|
Implement SPF for sending with MessageGears
|(none) AND/OR subdomain selected for use as custom signing domain||TXT||v=spf1 include:_spf.messagegears.net -all|
DKIM stands for "domain keys identified mail" and it involves implementing a DNS record containing a public key for authenticating messages. "DKIM-Signature" is a main component of the email header and receiving servers can determine individually whether the email is trustworthy or fraudulent.
Open a Support ticket to request DKIM records to implement on your domain.
DMARC, which stands for Domain Message Authentication Reporting & Conformance, is a trickier issue when working with sending through MessageGears.
The idea behind DMARC is to prevent senders other than your own domain's email server from sending emails claiming to be from your domain. This prevents spoofing, where a malicious sender appears to be an individual at a known address or domain, but it also causes issues for anyone utilizing bulk or transactional ESPs outside of their normal email server.
Over the last several years, popular email service providers such as Yahoo!, AOL, and Gmail have implemented DMARC, which prevents aol.com, gmail.com, yahoo.com, and more from being used as From Addresses in 3rd party ESPs without having major deliverability issues. What this means is do not use any of these public domains in your From Address.
- Yahoo! on DMARC
- Gmail/Google Apps on DMARC
- AOL on DMARC
- Outlook (outlook.com, live.com, hotmail.com) on DMARC
If your domain has a DMARC policy in place, or you're planning to add one, it's necessary to take steps to authenticate your MessageGears emails correctly to ensure they can be delivered. Unlike a user of an email service like Yahoo!, private domains allow you to customize your DNS records to provide "permission" in a sense to ESPs you specify.
There are a lot of different factors which go into whether DMARC passes or fails, including how the record itself it set up, what records interact with it, issues of sending through a 3rd party and what their records are, etc. So in all DMARC cases we have to play things by ear, and try to cover all of the bases to best enable good deliverability.
With MessageGears, the best way to avoid issues with DMARC is to white-label your emails, which includes setting up SPF, DKIM, and a custom signing domain. This allows your emails to pass DMARC because authentication plus a custom signing domain provide the necessary domain alignment necessary.