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 recipient@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.

Any domain which appears in the Return-Path header field must have a SenderID-compliant SPF record published.

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.

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.

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.

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.

Step 1: Use an online wizard to create the SPF/SenderID record, for example:

https://www.unlocktheinbox.com/senderid-wizard/

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 - check-auth@verifier.port25.com
• Sendmail Email Relay - sa-test@sendmail.net
• 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.

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;"

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; rua=mailto:dmarc-feedback@example.com; ruf=mailto:dmarc-forensic@example.com;"

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.

In detail, the individual parts of the record mean the following: