The subject can be quite difficult with all the new safeguards that have been implemented to combat email spam, address spoofing and actions of bad players.  There are three mechanisms (DKIM, SPF & DMARC) for insuring that an email message is legitimate and making them work together can be quite a task.  

I have created this document to explain, give examples and to attempt to take the mystery out of email.

---

Source Links

DKIM Explained

DKIM Records Explained

SPF Records Explained

DMARC Explained

---

DKIM

SendGrid automatically enables DKIM for all email to improve your email deliverability.

The purpose of DKIM  is to help verify the Sender Identity of your email.

When you enable DKIM you will be given the option of using automated or manual security.

When you select automated security, SendGrid will manage your DKIM and SPF records for you.

• This means that whenever you make a change to your account that could impact your deliverability, such as adding a new dedicated sending IP address, SendGrid will automatically update your DNS settings and your DKIM signature.

Setting up domain authentication

To set up domain authentication, you must submit the DNS records provided by SendGrid to your DNS or hosting provider.

To set up domain authentication:

• In the SendGrid UI, select Settings > Sender Authentication.
• In the domain authentication section, click Get Started.
• Next, add in information about your DNS host, and indicate whether you also want to set up link branding. Click Next. For more information about link branding, check out What is link branding?.
• Fill in the domain that you want to send from and add advanced settings as needed. Make sure that you only enter the name of your root domain. Do not include www or http://www in this field. Your domain needs to match the domain of your FROM address on the emails you are sending out. For example, if I am sending an email from example@sendgrid.com, I would set my domain authentication domain to be sendgrid.com. Click Next. For more information about advanced settings, see Advanced settings.
• Next, you need to add all of the CNAME records on this screen to your DNS host. This process varies depending on your DNS host. For videos on how to add your CNAME to some popular DNS service providers, check out these videos. If you don't have access to modify your companies DNS records, you can also email a request to a co-worker. This email includes a direct link to the CNAME records. This link does expire. The recipient doesn't need login access to your SendGrid account.

This is an example of the domain records you will have to enter in your DNS settings:

Below is an example of the CNAME values under the HOST column as they are displayed and how you will need to enter them into your DNS management with one of these providers:

• HOST/NAME em123.yourdomain.com . ENTER CNAME RECORD HOST/NAME AS: em123
• HOST/NAME s1._domainkey.yourdomain.com  ENTER CNAME RECORD HOST/NAME AS: s1._domainkey
• HOST/NAME s2._domainkey.yourdomain.com  ENTER CNAME RECORD HOST/NAME AS: s2._domainkey

Verifying your DNS

Once you add the CNAME records to your DNS host, return to the Sender authentication page and click Verify.

---

SPF

SPF attempts to ensure that the IP address from which a message was sent is approved to send email by a domain’s owner.  It also  prevents sender address spoofing.

An SPF record is implemented using a TXT DNS record.

The TXT record specifies which IP addresses are allowed to send email for the domain

The TXT record has several values:

• v=spf1
• INCLUDE
• A
• MX
• IP4
• IP6

How it works

1. The receiving email server retrieves the SPF record from the DNS records for the example.com domain.
2. The receiving server then checks the SPF record for all the IP addresses that are approved to send email on behalf of the domain.
3. If the SPF check passes, the receiving server can be confident the message was sent from an approved sending server and will continue processing the message.
4. If the SPF check fails, the message is likely illegitimate and will be processed using the receiving server’s failure process.

SPF Authentication

Each SendGrid account gets a unique SPF TXT record to authenticate their outbound mailings. An example of such a record is:

• >v=spf1 include:u123456.wl.sendgrid.net -all

Here we have a unique SPF record for the authorization of outbound mail for a SendGrid account.

NOTE:

A -all inclusion versus an ~all inclusion indicates that this SPF record is the only record used to authenticate mail for your domain. Make sure to include any other authorized sender into this SPF record if you need to authenticate mailings from other sources.

Changing an Existing record:

For example, say your existing record looks like this:

• >v=spf1 a mx include:\_spf.google.com include:spf.protection.outlook.com -all

You would need to add the SendGrid lookup at the end of the string, before the all mechanism, like so:

• >v=spf1 a mx include:\_spf.google.com include:spf.protection.outlook.com include:u826348.wl.sendgrid.net -all

You can also choose to give permission to a specific IP address to send mail for your domain

• >v=spf1 a mx include:\_spf.google.com include:spf.protection.outlook.com ip4:12.34.56.78 -all

If you wish to add multiple ip4 lookups (if you have an account that sends from multiple dedicated IPs, for example), add them to your record separated by spaces.

---

DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a standard for determining the authenticity of the person or service sending email on behalf of a domain.

DMARC is used to verify the authenticity of an email’s sender and prevent malicious senders from damaging your sender reputation.

Email spoofing is the practice of sending email with a forged From address.

DMARC relies on two authentication protocols to prevent spoofing: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

Why we need DMARC

DMARC is a framework for handling SPF and DKIM failures and reporting those failures to domain owners.

It gives the domain admin control over how to handle email delivery issues by having the receivers report back when there is a problem.

• DMARC allows domain owners to specify what should happen if either or both SPF and DKIM checks fail. Neither SPF nor DKIM provide this functionality on their own. This means that without DMARC a sender has no say in whether a failing message is bounced, sent to a spam folder, or handled in some other way.
• A sender receives no feedback about SPF and DKIM failures without DMARC, so senders have little chance to combat or even understand the delivery trends of their domain, often called a "reputation monitoring."
• SPF and DKIM are independent of each other, but neither provide thorough spoofing protection on their own.

DMARC addresses these issues by building on top of SPF and DKIM. DMARC adds the Reporting and Conformance piece on its own.

DMARC is implemented using a TXT DNS record.

DMARC Records

EXAMPLE DMARC RECORD

• v=DMARC1\;p=none\;rua=mailto:dmarc@sendgrid.com\;ruf=mailto:dmarc@sendgrid.com\;rf=afrf\;pct=100

A DMARC record contains several tags separated by semicolons, ;. Two of the tags are required, v (version) and p (policy).

VERSION TAG

The version, v=DMARC1, tells receiving servers that the DNS TXT record is a DMARC record.

POLICY TAG

The policy, p, can be one of three values, none, quarantine, or reject. DMARC policies are the mechanism domain owners use to specify how a receiving email server should handle SPF and DKIM failures.

1. p=none: No action should be taken. Even if a failure occurs, the message should be delivered. Though no action is taken on the message, the failure is included in reports sent to the domain owner.
2. p=quarantine: Failures should be quarantined. This usually means the message is sent to the spam folder. Again, the failure will be included in reports to the domain owner.
3. p=reject: Failures will be rejected. This usually means that the message will be deleted. The message may also be bounced to the Envelope From address.

REPORT AND REPORT-RELATED TAGS

Where do the failure reports go? The address assigned to rua= tells receiving email servers where to deliver aggregate reports. The address assigned to ruf= tells receiving email servers where to send forensic reports.

1. Aggregate reports are sent daily by default and don’t include detailed information about individual failures.
2. Forensic reports send detailed information about individual failures at the time of failure. The email address assigned to ruf must also use the domain on which the DMARC record exists.

The fo tag tells receiving servers what type of failures to report. There are four possible values for this tag.

1. fo=0: Send a report if both SPF and DKIM checks do not pass. This is the default value.
2. fo=1: Send a report if either SPF or DKIM checks do not pass.
3. fo=d: Send a report only if the DKIM check does not pass.
4. fo=s: Send a report only if the SPF check does not pass.

The ri tag sets the interval in seconds at which a domain owner wishes to receive aggregate reports. The default is, 86400—that’s 24 hours in case you don’t have your calculator out.

ALIGNMENT TAGS

There are tags for both SPF, aspf, and DKIM, adkim, alignment. Alignment is a way of qualifying how strictly DKIM and SPF values should be applied to pass a check. The options are either s for strict or r for relaxed.

• Strict: Only return-path domains that match the domain set in the SPF or DKIM record exactly will pass.
• Relaxed: Any return-path domain matching the root of the domain set in the SPF or DKIM record will pass. This allows CNAME addresses to pass a check.

SUBDOMAIN TAG

If a domain owner needs to specify different policies for subdomains, they can use the sp tag. Like the policy tag, p, the possible values for the sp tag are none, quarantine, and reject. This means you can, for example, apply a reject policy to your root domain and a quarantine policy for all its subdomains.

PERCENT TAG

The percent tag, pct, specifies the percentage of email to which your DMARC policy will be applied. The possible values are 1 through 100. For example, if your policy is set to quarantine, and your percent is set to 50, half of all failing mail will be quarantined. This tag value can be adjusted as you learn more about DMARC failures on your domain

How DMARC Applied to a Sender Identity

When sending email via a service provider such as SendGrid, you will be asked to authenticate a domain or verify a Single Sender. 

WHEN THE  RETURN-PATH MESSAGE HEADER IS NOT SENDGRID.

Because other providers use DMARC they will have issue when you send emails through SendGrid with a return path for other domains.  Inorder to do this successfully you will have to authenticating a domain that you do control.

The SendGrid domain authentication process provides CNAME records that you place on your own domain to approve SendGrid's IP addresses. SendGrid will automatically manage your SPF and DKIM records, protecting your domain’s reputation.

Many of the popular email providers implement DMARC, including:

• AOL
• Gmail
• Microsoft (Hotmail, MSN)
• Outlook
• Yahoo

Providers with DMARC policies may reject email with messages like, "521 5.2.1 : (DMARC) This message failed DMARC Evaluation and is being refused due to provided DMARC Policy".

If you see a bounce with one of these failure messages, the message has been discarded and tracked as a Block. You will need to adjust your From address field settings, and then try resending from your side.