Sender Authentication refers to the different technologies that are used to make sure email content is legitimate and deliverable.
The following instructions will assist you in configuring and successfully deploying the various email authentication methods. We provide a number of resources and highlight some common problem areas as identified by the collective experience of hundreds of our customers.
- Why do I need sender authentication?
- Sender Policy Framework (SPF)
- DomainKeys Identified Mail (DKIM)
- Domain-based Message Authentication, Reporting & Conformance (DMARC)
- Configure SPF/SenderID
- Sending via Emarsys
- Sending via your own infrastructure
- Configuring DKIM
- Configure DMARC
- Further Reading
Why do I need sender authentication?
If you have no authentication, most freemail accounts refuse to accept emails from you. Emails are easy to spoof and criminals have identified spoofing as a reliable way to exploit user trust in well-known brands. Email recipients are often unable to differentiate between a real message and a faked one, and large freemail providers have to make very difficult (and often guesswork) decisions as to which messages to deliver and which messages to categorize as spam.
Sender authentication assists senders, email service providers and ISPs in their cooperation towards ensuring more secure emails, and helps to protect both email recipients and senders from painfully expensive abuse. Our policy is to ensure compliance with all authentication mechanisms, to help eliminate the risk to you by making sure your content is delivered without being flagged as suspicious.
Overview of Sender Authentication Technologies
Any domain which appears in the
From: field of an email must have a SenderID-compliant SPF record published.
Note: A domain is the entire value which follows the @ sign. For example, if you use email@example.com in the
From: field, then example.com must have either a SenderID or SPF record published. Depending on the provider you use for your email delivery infrastructure, you may not be able to control these domains directly, so make sure to discuss any issues with your provider as necessary.
It is important to remember that SPF records do NOT cover subdomains. A SenderID or SPF record for example.com would not cover campaign.example.com.
Sender Policy Framework (SPF)
Any domain which appears in the
Return-Path header field must have a SenderID-compliant SPF record published.
DomainKeys Identified Mail (DKIM)
DKIM is the successor of DomainKeys (DK), and is quickly gaining popularity amongst a wide variety of freemail providers, e.g. Yahoo! or GMail.
While SPF and SenderID authenticate the path a message takes, DKIM authenticates each individual message, no matter where it has travelled. Therefore, it is a way to determine who is responsible for a particular message.
This is achieved so by inserting a special signature header into the message itself. The sender of a message (you) is responsible for doing this; contact your email infrastructure provider to see if the software you are using is capable of including DKIM signatures.
Note: DK authentication alone is insufficient for sending with Emarsys. If you are still using this method, you should upgrade to DKIM as soon as possible.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC is an email authentication method created by a group of organizations, among them AOL, Google, Microsoft and Yahoo!. It allows senders to tell ISPs how to handle unsigned (non-authenticated) or failed (broken authentication) emails which use the sender’s domain name. For example, a DMARC record can indicate that such emails should be delivered, flagged as suspicious or deleted.
DMARC also provides a way for the ISP to send feedback to the sender about which messages passed and/or failed the tests. It is this reporting capability which make DMARC interesting. Senders can find out how many emails are coming from their domain (or claiming it), where they came from, and whether their SPF and DKIM policies are correctly authenticating them.
Note: Although the DMARC record is currently only a recommendation for the ISP, we do strongly recommend using it and expect this to become obligatory in the near future. DMARC does not provide reports on how ISPs actually handle the emails in question, but it does offer valuable reports on emails which have been received and which claim to come from the sending domain, along with the results of the SPF and DKIM checks.
Implementing email authentication mechanisms
In order to enable problem-free sending, we recommend to implement all of the authentication mechanisms described below.
The SPF/SenderID is an explicit list of your domains that you want to configure to be able to send mail from, and is a check that ISPs can use to confirm the legitimacy of your mail.
- Make a list of the domain(s) and subdomain(s) that you want to be able to send email on your behalf. For illustrative purposes, our examples below will use reply.example.com as the domain.
- Find out who controls your DNS (Domain Name System) servers as you will need their help to publish the email authentication records you are about to create.
- Make sure that you have access to your domain’s DNS entry, if in doubt ask your ISP to provide the key information and policy entries for your DNS entry.
Sending via Emarsys
Add one of the following SenderID entries to the TXT record of all your sender and reply domains:
- If you are sending to Germany and are CSA certified:
v=spf1 include:emarsys.net ~all
- For all other customers:
v=spf1 include:emarsys.us ~all
That’s it, you have now successfully configured SPF/SenderID for use. Please continue to the next authentication mechanism setup.
Sending via your own infrastructure
Step 1: Use an online wizard to create the SPF/SenderID record, for example:
Step 2: Publish your SPF/SenderID records
- Work with your DNS administrator to publish the email authentication records you have created.
- Place the SPD/SenderID records in your public-facing DNS record.
Step 3: Validate your SPF/SenderID records
Make sure your records are working correctly. Some of the many available testing options are:
- VAMSOFT (use the ‘show log’ function on the results page) - http://www.vamsoft.com/spfcheck.asp
- Port25 Email Tester - firstname.lastname@example.org
- Sendmail Email Relay - email@example.com
- Microsoft Outlook (Hotmail) - Send a testmail to an Outlook or Windows Live account, log in, view the message and view the header. Look for the "X-SIDResult:" line for the result of their SenderID check.
- GMail - http://gmail.com - Send a testmail to a GMail account, log in, view the message and view the header. Look for the "Received-SPF" line for the result of their SPF check.
- For Microsoft Outlook (Hotmail) and Windows Live Mail, the SenderID will fail if the PTR (Pointer) mechanism is included in the SPF record.
- Use of the pointer directives ‘?all’ or ‘+all’ is not sufficient to authenticate messages accurately. Emarsys deliverability standards do not require, but strongly encourage you to use the ‘–all’ directive whenever possible.
To configure DKIM, see SAP Emarsys DNS settings.
If you need custom DKIM, please contact Emarsys Support.
DMARC is a framework that ISPs use to help them know how to handle emails without authentication, or broken authentication, being sent from a specific domain.
For illustration purposes, our examples below will use example.com.
- Ensure you have access to your domain’s DNS entry. Ask your Domain Registrar / ISP to provide you the key information and policy entries for your DNS entry.
- An email address to which to send the feedback and information reports.
Note: Not every Domain Registrar interface is able to set the DNS entry required for DMARC, so you might need to contact their support for further assistance.
The DMARC record is a special subdomain to your domain called _dmarc, for example "_dmarc.example.com".
Add the following DMARC entry to the TXT record of all your sending domains:
_dmarc.example.com IN TXT "v=DMARC1; p=reject; adkim=s; aspf=r; pct=100;"
This tells receiving email servers to drop all emails from this domain in case of authentication failure.
Enable feedback You can receive DMARC feedback reports, choosing to receive aggregated reports (using the rua= switch) or forensic reports (using the ruf= switch), or both, as follows:
_dmarc.example.com IN TXT "v=DMARC1; p=reject; adkim=s; aspf=r; pct=100; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; rf=afrf;"
The above example tells the receiving email servers to drop all emails from this domain, and to send you an abuse report to the nominated email addresses.
Understanding the DMARC components
In detail, the individual parts of the record mean the following:
||The version of DMARC being used is "DMARC1"|
||ISPs should reject messages which fail to authenticate|
||Strict identifier alignment should be applied to DKIM checks|
||Relaxed identifier alignment should be applied to SPF checks|
||Policy is to be applied to 100% of messages|
||Aggregated feedback reports are sent via email to this address|
||Forensic information reports are sent via email to this address|
||Reporting format is the "Authentication Failure Reporting Format"|