Email Authentication is the process used by mailbox providers to verify an email is being sent legitimately by the domain used in the From Address. The receiving provider inspects the domain's DNS records for specific entries that indicate the mail is properly authenticated, which helps to prevent phishing and other malicious emails from reaching their users.
For example, when "john@domain.com" logs into his primary webmail account and sends an email, this isn't an issue. However, if john@domain.com sends a message using MessageGears, via Accelerator or API, that email is sent out through MessageGears' mail servers instead of 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 mail 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 an 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 such as MessageGears are perceived as spoofed and are highly likely to be rejected or routed to a spam or quarantine folder.
In order to ensure that your email content gets to your recipients, taking steps to authorize MessageGears to send on your behalf is important.
SPF
SPF stands for Sender Policy Framework and is generally considered the simplest form of authentication. It helps prevent spoofing by explicitly identifying the IP addresses of 3rd party senders who are allowed to send mail on behalf of a domain.
A typical SPF record is composed this way:
v=spf1 include:_spf.exampledomain.com -all
SPF is implemented as a single TXT record for the domain, and can contain up to 10 lookups. These records should also indicate a policy for how mail from IP addresses not in the SPF record is supposed to be treated.
| Policy Modifier | Result | Meaning |
| +all | PASS | passes all sending domains, regardless of listing |
| ?all | 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 |
Sample SPF record for sending with MessageGears
| Type | Value |
| TXT | v=spf1 include:_spf.messagegears.net -all |
DKIM
DKIM stands for "Domain Keys Identified Mail" and it allows receiving servers to verify the body content of a message has not been altered since the message was originally sent. This helps prevent attacks in which a malicious entity might copy a legitimate message and inject harmful content while retaining the original message headers.
Implementing DKIM involves adding a DNS record containing a public key for authenticating messages. Each outbound message then includes a DKIM signature in the email header, which includes cryptographic hashes of the header and body along with the location of the public key DNS record. These hashes (along with the public key) are generated using the private key, which only the domain owner can access. Mailbox providers compare the DKIM signature to the public key to authenticate the message.
If you’d like to implement DKIM for your domain, reach out to our Support Team to get started.
DMARC
DMARC (Domain Message Authentication Reporting & Conformance) is not exactly an authentication method, but instead provides rules for mailbox providers to follow when they receive mail that fails SPF and DKIM authentication. DMARC records include a value that indicates how the receiving server should handle mail that fails both protocols:
|
DMARC policy |
Meaning |
|
p=none |
all mail is accepted, even if authentication fails; most commonly used when evaluating a new DMARC policy |
|
p=quarantine |
mail that fails authentication is flagged for additional scrutiny; the receiver decides what this means but could be spam folder, delaying for review, etc |
|
p=reject |
mail that fails both SPF and DKIM (or is not properly domain-aligned) is rejected or bounced |
DMARC also introduces a concept known as Domain Alignment, which requires that the domain used in the From Address must match the one used for authentication. As a result, it can cause issues for anyone utilizing bulk or transactional ESPs.
Over the last several years, popular email service providers including Yahoo and Gmail have implemented DMARC at p=reject on their own domains. Because of this, any sender who uses aol.com, gmail.com, yahoo.com, etc as a From Address via an ESP will see their mail rejected by many receivers. To avoid these types of issues, you should not use any domain not under your direct control in your From Address.
If your domain has a DMARC policy in place, or you're planning to add one, it may be necessary to take additional steps beyond simply adding an SPF or DKIM record. You’ll need to be sure your domains are aligned, which typically requires implementing whitelabeling for mail sent through MessageGears. This helps ensure your authentication and sending domains are aligned and DMARC-ready.
If you’re considering setting up DMARC and have questions, check out the resources at DMARC.org for more information. If you’re ready to get started, our Support Team can help you confirm your authentication is properly configured and ready for DMARC implementation.
Comments
Article is closed for comments.