In This Article
- SPF and DKIM Authentication
- Set Up SPF and DKIM for Your Sending Domains
- Validate SPF and DKIM for Your Sending Domains
- Verify Your Sending Domain
- DMARC
Note
You'll need to add SPF and DKIM records and verify ownership of your sending domains before you can send email through your account. Transactional Email will not send any email from unverified domains or domains without valid SPF and DKIM records, including public domains like gmail.com, yahoo.com, and more.
A message that is rejected with the reject reason unsigned indicates that the sending domain hasn't been properly set up, and that your account is unable to send and authenticate email from that domain.
Learn more about SPF and DKIM and domain verification, or manage sending domains in your Transactional Email account.
SPF and DKIM Authentication
Authentication is a way to prove an email isn't forged. Transactional Email automatically authenticates all emails sent through our servers, but by adding DNS records to your domain, Transactional Email can send on your behalf and digitally 'sign' your emails.
If you've ever received an email claiming to be from your bank, PayPal, or a company you do business with, but it's really from someone else, then you've seen first-hand how easy it is to forge email. Authentication helps legitimate senders prove that their email isn't forged, and can help receiving servers like ISPs and corporate email servers control inbound spam.
There are many authentication methods, but there isn't a single one that's the best. SPF and SenderID allow a domain owner to add a file or record on the server that the recipient server cross-checks. These are easy to implement, but some suggest they aren't as secure. DKIM and DomainKeys embed information within the email, making it harder to forge (but they can also be harder to implement for senders and receivers).
Since there are pros and cons to the various methods, Transactional Email automatically adds authentication for all of the methods mentioned above. By default, email is authenticated for the mandrillapp.com domain, but all Transactional Email accounts support DKIM for your domain so you can authenticate as your domain instead. We can also ensure that all messages sent from our IPs pass SPF checks.
Authentication and sending reputation
When you add authentication information to your domain, an added benefit is that many ISPs use authentication to track sending reputation. With authentication handled by your domain, reputation with the receiving ISPs is influenced by your domain and the emails sent on behalf of your domain. This means you maintain control over the emails that affect deliverability for your domain. A positive reputation for your domain builds trust and improves deliverability, affecting whether your emails are caught by spam filters and how quickly the receiving servers will accept mail from your domain.
Set Up SPF and DKIM for Your Sending Domains
Now that you've added a new sending domain, you can also add the appropriate records to your domain's DNS settings. To add the SPF and DKIM records for your sending domains, you'll need to add records of type 'TXT' through your hosting provider, domain registrar, or DNS provider. We recommend referring to your provider's help documentation for specific information on adding TXT records.
SPF
If you don't have an SPF record yet, you'll need to add one for your domain. At a minimum, the value should be the following if you're only sending mail through Transactional Email for that domain:
v=spf1 include:spf.mandrillapp.com ?all
If you already have a TXT record with SPF information, you'll need to add Transactional Email's servers to that record by adding include:spf.mandrillapp.com
in the record (before the last operator, which is usually ?all
, ~all
, or -all
).
DKIM
Add a new TXT record with the name mandrill._domainkey.yourdomain.com
(just replace yourdomain.com with the domain you're setting up).
The value for the record should be one of the options listed below. There are two options because the record contains semicolons. Some DNS providers escape semicolons for you while others require you to do it when you set up the record.
With semicolons escaped:
v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB\;
With semicolons unescaped:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB;
Validate SPF and DKIM for Your Sending Domains
Before Transactional Email can authenticate emails for your domain, you need to validate the SPF and DKIM records for your sending domain in your Transactional Email account or using the Transactional API.
To validate SPF and DKIM records for your sending domain in the Transactional Email web interface:
- Go to Settings in your Transactional Email account.
- From the Domains menu at the top of the page choose Sending Domains.
- Click the Test DNS Settings button to check the DNS settings for your sending domain.
- Once the test is complete, click the View DKIM Settings and View SPF Settings links for more detailed information about your current settings and any suggested changes.
Troubleshoot SPF and DKIM
After you add the appropriate DNS records, it can take up to 24 hours for the changes to take full effect. If there's an error validating your records, view the error details in Transactional Email for additional information. There are also some third-party resources you can use to check your records or for other details if needed:
-
Verify your SPF record using an online SPF record testing tool. Enter your domain name in the first text box and click Get SPF Record (if any) for a diagnostic of your SPF records.
-
Check whether your DKIM record is valid using the DKIMCore validator. Enter mandrill as the selector and your domain name.
-
Transactional Email's SPF validator looks for a TXT record with the appropriate SPF information. If your domain has an SPF type record only, you'll need to add a matching TXT record for compatibility.
-
If you already have an SPF record, edit that record instead of adding a new one. The specs for SPF require that there only be one TXT record with SPF information.
-
If you've added the DKIM record and are still seeing that it's missing, your DNS provider may require the record be formatted differently. The DKIM record Transactional Email provides has semicolons escaped with a backslash, so the record starts with this:
v=DKIM1\; k=rsa\;
and ends like this:\;
. -
Some DNS providers don't require semicolons be escaped. If you're seeing issues, try removing the backslashes right before semicolons at the beginning and end of the record.
-
Some DNS providers take longer than others to publish and push the record. If you're adding a completely new record, those often validate within 10-15 minutes. Changing records can take longer, but can vary based on your DNS provider and TTL for the record.
Verify Your Sending Domain
When you add SPF and DKIM records for your domain, you also need to verify that domain. Domain verification is a required step to confirm ownership of a domain. After you verify a domain in your account, any other Transactional Email user that wants to sign with that domain will also need to go through the verification process. If they don't verify the domain, the email will still be delivered, but will be signed with a generic mandrillapp.com signature. Learn how to verify a domain.
DMARC
Transactional Email doesn't currently validate DMARC records for your sending domains, but you're welcome to use DMARC in addition to SPF and DKIM. How you implement DMARC is independent of your using Transactional Email. For details on setting up DMARC for your domain, we recommend using a guide like this one from Google or Kitterman.
We recommend running DMARC in notification mode only (with p=none in the DMARC record to indicate that mail that fails should be delivered normally) to get an idea for how much mail would be affected by switching to a stricter policy.