Difference between revisions of "SPF and DKIM"

From XMission Wiki
Jump to: navigation, search
(DKIM DNS)
(DKIM DNS)
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
SPF and DKIM are two important security methods domain owners have of "authorizing" specific email servers to send mail on their behalf. Besides providing greater deliverability of your messages, these mechanisms prevent fraudsters from sending spoofing emails as your domain.  
 
SPF and DKIM are two important security methods domain owners have of "authorizing" specific email servers to send mail on their behalf. Besides providing greater deliverability of your messages, these mechanisms prevent fraudsters from sending spoofing emails as your domain.  
  
These TXT records are entered by the domain owner wherever the domain's DNS record is managed, which may be with the registrar or hosting provider. DKIM also adds public key cryptography for deeper validation.
+
These TXT records are entered by the domain owner wherever the domain's DNS record is managed, which may be with the registrar or hosting provider. DKIM (Domain Key Identified Mail) also adds public key cryptography for deeper validation.
 +
 
 +
XMission advises all [https://xmission.com/zimbra Zimbra clients] to configure SPF & DKIM. It may sound a bit daunting but is really not very complicated. This document will walk you through it.
 +
 
 +
IMPORTANT NOTE ABOUT TXT RECORD ENTRY: Depending on the syntax requirements of your DNS system you may have to include or omit the quotation marks for the record to be properly enabled. Other DNS entries on your domain should provide quick visual guidance on protocol. XMission DNS systems do ''not'' use quotation marks.
  
XMission advises all [https://xmission.com/zimbra Zimbra clients] to configure SPF & DKIM.
 
  
 
= SPF =
 
= SPF =
 +
The following is the  most commonly applied SPF (Sender Policy Framework) record for XMission email customers but it is imperative you understand how and why this is applied. IMPORTANT: It is critical that you read and understand all SPF information below before applying the record to your domain as you could break email delivery.
  
The following is the  most commonly applied SPF record for XMission email customers but it is imperative you understand how and why this is applied. IMPORTANT: It is critical that you read and understand all SPF information below before applying the record to your domain as you could break email delivery.
+
{| class="wikitable"
 
+
! Host !! Record Type !! Value
<code><pre>
+
|-
@   IN TXT "v=spf1 a mx include:_spf.xmission.com ~all"
+
| @ (base domain) || TXT || "v=spf1 a mx include:_spf.xmission.com ~all"
</pre></code>
+
|}
  
 
== How It Works ==
 
== How It Works ==
 
 
Any SPF record is a string of one more more potential mail sources, prefixed by a character indicating the policy for mail source. An example of a common SPF record:
 
Any SPF record is a string of one more more potential mail sources, prefixed by a character indicating the policy for mail source. An example of a common SPF record:
  
<code><pre>
+
{| class="wikitable"
@     IN TXT "v=spf a mx ~all"
+
|+ Example Syntax
</pre></code>
+
|-
 +
! Host !! Record Type !! Value
 +
|-
 +
| @ (base domain) || TXT || "v=spf a mx ~all"
 +
|}
  
 
In this case, it says that the A and MX records for the domain are allowed to send, and all other mail fails (but with a "softfail", so that mail isn't actually rejected). "a", "mx" and "all", are all individual mail sources. The "~" prefixed to the "all" source is a policy denoting that mail from the source should be considered a "SoftFail".
 
In this case, it says that the A and MX records for the domain are allowed to send, and all other mail fails (but with a "softfail", so that mail isn't actually rejected). "a", "mx" and "all", are all individual mail sources. The "~" prefixed to the "all" source is a policy denoting that mail from the source should be considered a "SoftFail".
  
The sources are:
+
{| class="wikitable"
 +
|+ Sources & Definitions
 +
|-
 +
! Flag !! Source Type
 +
|-
 +
| a || DNS A record
 +
|-
 +
| mx || MX record
 +
|-
 +
| ptr || PTR record
 +
|-
 +
| ip4 || IPv4 address or subnet
 +
|-
 +
| ip6 || IPv6 address or subnet
 +
|-
 +
| include || The contents of another domain's SPF record
 +
|-
 +
| all || Any mail source (generally used at the end to provide a default policy)
 +
|}
  
* a - A DNS A record
+
{| class="wikitable"
* mx - An MX record
+
|+ Prefix Characters
* ptr - A PTR record
+
|-
* ip4 - An ipv4 address or subnet
+
! Prefix !! Definition
* ip6 - An ipv6 address or subnet
+
|-
* include - The contents of another domain's SPF record
+
| '''+''' || Pass (Valid for SPF)
* all - Any mail source (generally used at the end to provide a default policy)
+
|-
 +
| '''-''' || Fail (Invalid, and reject mail)
 +
|-
 +
| '''~''' || SoftFail (Invalid, but still accept)
 +
|-
 +
| '''?''' || Neutral (...whatever...)
 +
|}
  
The prefix characters are:
+
XMission Shared Hosting clients can [https://wiki.xmission.com/Adding/Managing_DNS_Records learn to manage DNS records here.]
 
 
* + - Pass (Valid for SPF)
 
* - - Fail (Invalid, and reject mail)
 
* ~ - SoftFail (Invalid, but still accept)
 
* ? - Neutral (...whatever...)
 
 
 
XMission shared hosting clients can [https://wiki.xmission.com/Adding/Managing_DNS_Records learn to manage DNS records here.]
 
  
 
== Valid SPF for XMission ==
 
== Valid SPF for XMission ==
 
 
Any SPF record for a domain sending through XMission should contain "include:_spf.xmission.com".
 
Any SPF record for a domain sending through XMission should contain "include:_spf.xmission.com".
  
Line 53: Line 76:
 
Note that the SPF record policy is a decision of the domain owner's. If they want to Fail or SoftFail on all, add other sources, etc., is up to them. We don't have a singular recommendation or requirement for SPF. If the customer '''only''' sends via XMission, the following SPF record is relatively safe:
 
Note that the SPF record policy is a decision of the domain owner's. If they want to Fail or SoftFail on all, add other sources, etc., is up to them. We don't have a singular recommendation or requirement for SPF. If the customer '''only''' sends via XMission, the following SPF record is relatively safe:
  
<code><pre>
+
{| class="wikitable"
@   IN TXT "v=spf1 a mx include:_spf.xmission.com ~all"
+
! Host !! Record Type !! Value
</pre></code>
+
|-
 
+
| @ (base domain) || TXT || "v=spf1 a mx include:_spf.xmission.com ~all"
'''Valid SPF for XMission with additional sending services'''
+
|}
  
SPF Record Merging
+
===Valid SPF for XMission with additional sending services===
  
Some customers have mailing list or other email sending requirement that require a number of  records be strung together in the SPF record. Fortunately the fairly lenient syntax of SPF records makes this easy to do, here is our default record compared to some merged records:
+
Sometimes it is necessary to have mailing list or other services that need to send emails so having multiple SPF records be strung together becomes necessary. Fortunately the fairly lenient syntax of SPF records makes this easy to do, here is our default record compared to some merged records:
  
Default XMission: "v=spf1 a mx include:_spf.xmission.com ~all"
+
{| class="wikitable"
 
+
! Hosts Generating Emails !! Example of Merged SPF Record
XMission plus Mailchimp: "v=spf1 include:_spf.xmission.com include:servers.mcsv.net ~all"
+
|-
 
+
| Default XMission || v=spf1 a mx include:_spf.xmission.com ~all
XMission plus Gmail, plus Constant Contact: "v=spf1 include:_spf.xmission.com include:_spf.google.com include:spf.constantcontact.com -all"
+
|-
 +
| XMission plus Mailchimp || v=spf1 include:_spf.xmission.com include:servers.mcsv.net ~all
 +
|-
 +
| XMission plus Gmail, plus Constant Contact || v=spf1 include:_spf.xmission.com include:_spf.google.com include:spf.constantcontact.com -all
 +
|}
  
 
== Forwarding ==
 
== Forwarding ==
 +
'''Important note''' about forwarding (ie automatically redirecting mail from one email address to another, not hitting the forward button):
  
A note about forwarding (ie automatically redirecting mail from one email address to another, not hitting the forward button):
+
Forwarding (under most circumstances) <em>BREAKS</em> SPF. If a domain has a "-all" ("reject all other mail" aka "Fail") policy in their SPF record, mail will be rejected by any servers respecting SPF after the server performing the forward. Users should keep this in mind when choosing a policy. This is why we suggest "~all" ("SoftFail") when you initially configure SPF.
 
 
Forwarding (under most circumstances) <em>BREAKS</em> SPF. If a domain has a "-all" ("reject all other mail" aka "Fail") policy in their SPF record, mail will be rejected by any servers respecting SPF after the server performing the forward. Users should keep this in mind when choosing a policy. This is why we suggest "~all" ("SoftFail") when you initially configure SPF.  
 
  
 
== Alias Domains ==
 
== Alias Domains ==
 
 
Domain aliases that are used for sending email with "From:" addresses will need SPF & DKIM records configured.  
 
Domain aliases that are used for sending email with "From:" addresses will need SPF & DKIM records configured.  
  
If you're only receiving mail from that aliased domain, then there is no need to configure SPF or DKIM records.
+
All customers are strongly encouraged to configure SPF & DKIM records for all alias domains and parked domains to prevent possible abuse.
  
 
= DKIM =  
 
= DKIM =  
 
+
DomainKeys Identified Mail (DKIM) is similar to SPF in that it uses a TXT record on the domain to define a sending policy for that domain. Where it differs is that it uses public key cryptography with this sending policy. A public key is added to that TXT record and any message that is signed with the private key (and thus validates with the public key) is then considered valid.
== How DKIM Works ==
 
 
 
DKIM is similar to SPF in that it uses a TXT record on the domain to define a sending policy for that domain. Where it differs is that it uses public key cryptography with this sending policy. A public key is added to that TXT record and any message that is signed with the private key (and thus validates with the public key) is then considered valid.
 
  
 
'''DKIM will break automatic responders, like ''Out of Office'' or ''Vacation'' replies.''' This is due to how DKIM verifies the sender, and how automated replies are generated and sent.  This is intentional, and is a consideration that needs to be made when limiting sending from your domain via DKIM.
 
'''DKIM will break automatic responders, like ''Out of Office'' or ''Vacation'' replies.''' This is due to how DKIM verifies the sender, and how automated replies are generated and sent.  This is intentional, and is a consideration that needs to be made when limiting sending from your domain via DKIM.
  
 
== Adding DKIM to an XMission Domain ==
 
== Adding DKIM to an XMission Domain ==
 
 
We have a single private key for XMission DKIM signing. We can sign DKIM with this key on any domain sending out through XMission. It works for Zimbra domains, virtmail, and SMTP relay. To enable this feature for a domain, two things need to happen:
 
We have a single private key for XMission DKIM signing. We can sign DKIM with this key on any domain sending out through XMission. It works for Zimbra domains, virtmail, and SMTP relay. To enable this feature for a domain, two things need to happen:
  
 
* The domain needs proper DNS for our domainkey key (see below)
 
* The domain needs proper DNS for our domainkey key (see below)
 
* The domain needs to be added to XMission routing config as one with DKIM signing.
 
* The domain needs to be added to XMission routing config as one with DKIM signing.
 
 
  
 
== DKIM DNS ==
 
== DKIM DNS ==
 +
Add the following two TXT records to the domain.
  
Add the following two TXT records to the domain and then [https://xmission.com/contact contact] support@xmission.com to have XMission add your domain to XMission's DKIM routing file:
+
'''Note''': Once added you must [https://xmission.com/contact contact] [mailto:support@xmission.com support@xmission.com] to add your domain to XMission's DKIM routing file and complete the process:
  
<code><pre>
+
{| class="wikitable"
xmission._domainkey IN      TXT "v=DKIM1; t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzWmoe0tzQkSUzMqliwcQQ5zY1HKk4z+Wgp+dRCRe7MmSBPftE9r5Lx1QfTfF/J8gl4k9tFsUvUBap0fk1VGMYUG/2LynVuzpkCI4JlUKF5fbx+MDNZrVi0aX73Edjd9trU6NKldVnhNg1RixDLa4aB04XJviy6+3P1h3IHNaZ0QIDAQAB"
+
! Host !! Record Type !! Value
_domainkey     IN      TXT "t=y; o=~;"
+
|-
</pre></code>
+
| xmission._domainkey || TXT || "v=DKIM1; t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzWmoe0tzQkSUzMqliwcQQ5zY1HKk4z+Wgp+dRCRe7MmSBPftE9r5Lx1QfTfF/J8gl4k9tFsUvUBap0fk1VGMYUG/2LynVuzpkCI4JlUKF5fbx+MDNZrVi0aX73Edjd9trU6NKldVnhNg1RixDLa4aB04XJviy6+3P1h3IHNaZ0QIDAQAB"
 +
|-
 +
| _domainkey || TXT || "t=y; o=~;"
 +
|}
  
 +
Reminder: XMission DNS systems do not require entry of the quotation marks on the records above. External DNS system may require quotation marks.
  
'''Multiple Email Hosts with DKIM'''
+
====Multiple Email Hosts with DKIM ====
  
 
It is possible to use more than one host with DKIM, though this is only possible if the DNS records used to announce the public key for the security handshake don't share subdomains with each other.
 
It is possible to use more than one host with DKIM, though this is only possible if the DNS records used to announce the public key for the security handshake don't share subdomains with each other.
  
 
[[Category: Email]]
 
[[Category: Email]]

Revision as of 15:33, 9 March 2023

SPF and DKIM are two important security methods domain owners have of "authorizing" specific email servers to send mail on their behalf. Besides providing greater deliverability of your messages, these mechanisms prevent fraudsters from sending spoofing emails as your domain.

These TXT records are entered by the domain owner wherever the domain's DNS record is managed, which may be with the registrar or hosting provider. DKIM (Domain Key Identified Mail) also adds public key cryptography for deeper validation.

XMission advises all Zimbra clients to configure SPF & DKIM. It may sound a bit daunting but is really not very complicated. This document will walk you through it.

IMPORTANT NOTE ABOUT TXT RECORD ENTRY: Depending on the syntax requirements of your DNS system you may have to include or omit the quotation marks for the record to be properly enabled. Other DNS entries on your domain should provide quick visual guidance on protocol. XMission DNS systems do not use quotation marks.


SPF

The following is the most commonly applied SPF (Sender Policy Framework) record for XMission email customers but it is imperative you understand how and why this is applied. IMPORTANT: It is critical that you read and understand all SPF information below before applying the record to your domain as you could break email delivery.

Host Record Type Value
@ (base domain) TXT "v=spf1 a mx include:_spf.xmission.com ~all"

How It Works

Any SPF record is a string of one more more potential mail sources, prefixed by a character indicating the policy for mail source. An example of a common SPF record:

Example Syntax
Host Record Type Value
@ (base domain) TXT "v=spf a mx ~all"

In this case, it says that the A and MX records for the domain are allowed to send, and all other mail fails (but with a "softfail", so that mail isn't actually rejected). "a", "mx" and "all", are all individual mail sources. The "~" prefixed to the "all" source is a policy denoting that mail from the source should be considered a "SoftFail".

Sources & Definitions
Flag Source Type
a DNS A record
mx MX record
ptr PTR record
ip4 IPv4 address or subnet
ip6 IPv6 address or subnet
include The contents of another domain's SPF record
all Any mail source (generally used at the end to provide a default policy)
Prefix Characters
Prefix Definition
+ Pass (Valid for SPF)
- Fail (Invalid, and reject mail)
~ SoftFail (Invalid, but still accept)
? Neutral (...whatever...)

XMission Shared Hosting clients can learn to manage DNS records here.

Valid SPF for XMission

Any SPF record for a domain sending through XMission should contain "include:_spf.xmission.com".

If you prefer a less identifiable entry then a minimum inclusion would have the following two sources:

  • ip4:166.70.13.0/24
  • ip4:198.60.22.0/24

Note that the SPF record policy is a decision of the domain owner's. If they want to Fail or SoftFail on all, add other sources, etc., is up to them. We don't have a singular recommendation or requirement for SPF. If the customer only sends via XMission, the following SPF record is relatively safe:

Host Record Type Value
@ (base domain) TXT "v=spf1 a mx include:_spf.xmission.com ~all"

Valid SPF for XMission with additional sending services

Sometimes it is necessary to have mailing list or other services that need to send emails so having multiple SPF records be strung together becomes necessary. Fortunately the fairly lenient syntax of SPF records makes this easy to do, here is our default record compared to some merged records:

Hosts Generating Emails Example of Merged SPF Record
Default XMission v=spf1 a mx include:_spf.xmission.com ~all
XMission plus Mailchimp v=spf1 include:_spf.xmission.com include:servers.mcsv.net ~all
XMission plus Gmail, plus Constant Contact v=spf1 include:_spf.xmission.com include:_spf.google.com include:spf.constantcontact.com -all

Forwarding

Important note about forwarding (ie automatically redirecting mail from one email address to another, not hitting the forward button):

Forwarding (under most circumstances) BREAKS SPF. If a domain has a "-all" ("reject all other mail" aka "Fail") policy in their SPF record, mail will be rejected by any servers respecting SPF after the server performing the forward. Users should keep this in mind when choosing a policy. This is why we suggest "~all" ("SoftFail") when you initially configure SPF.

Alias Domains

Domain aliases that are used for sending email with "From:" addresses will need SPF & DKIM records configured.

All customers are strongly encouraged to configure SPF & DKIM records for all alias domains and parked domains to prevent possible abuse.

DKIM

DomainKeys Identified Mail (DKIM) is similar to SPF in that it uses a TXT record on the domain to define a sending policy for that domain. Where it differs is that it uses public key cryptography with this sending policy. A public key is added to that TXT record and any message that is signed with the private key (and thus validates with the public key) is then considered valid.

DKIM will break automatic responders, like Out of Office or Vacation replies. This is due to how DKIM verifies the sender, and how automated replies are generated and sent. This is intentional, and is a consideration that needs to be made when limiting sending from your domain via DKIM.

Adding DKIM to an XMission Domain

We have a single private key for XMission DKIM signing. We can sign DKIM with this key on any domain sending out through XMission. It works for Zimbra domains, virtmail, and SMTP relay. To enable this feature for a domain, two things need to happen:

  • The domain needs proper DNS for our domainkey key (see below)
  • The domain needs to be added to XMission routing config as one with DKIM signing.

DKIM DNS

Add the following two TXT records to the domain.

Note: Once added you must contact support@xmission.com to add your domain to XMission's DKIM routing file and complete the process:

Host Record Type Value
xmission._domainkey TXT "v=DKIM1; t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzWmoe0tzQkSUzMqliwcQQ5zY1HKk4z+Wgp+dRCRe7MmSBPftE9r5Lx1QfTfF/J8gl4k9tFsUvUBap0fk1VGMYUG/2LynVuzpkCI4JlUKF5fbx+MDNZrVi0aX73Edjd9trU6NKldVnhNg1RixDLa4aB04XJviy6+3P1h3IHNaZ0QIDAQAB"
_domainkey TXT "t=y; o=~;"

Reminder: XMission DNS systems do not require entry of the quotation marks on the records above. External DNS system may require quotation marks.

Multiple Email Hosts with DKIM

It is possible to use more than one host with DKIM, though this is only possible if the DNS records used to announce the public key for the security handshake don't share subdomains with each other.