Difference between revisions of "SPF and DKIM"

From XMission Wiki
Jump to: navigation, search
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. 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 also adds public key cryptography for deeper validation.
Line 5: Line 5:
 
= SPF =
 
= SPF =
  
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.
+
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.
  
 
<code><pre>
 
<code><pre>
Line 13: Line 13:
 
== 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>
 
<code><pre>
Line 33: Line 33:
 
The prefix characters are:
 
The prefix characters are:
  
* + - Pass (Valid for spf)
+
* + - Pass (Valid for SPF)
 
* - - Fail (Invalid, and reject mail)
 
* - - Fail (Invalid, and reject mail)
 
* ~ - SoftFail (Invalid, but still accept)
 
* ~ - SoftFail (Invalid, but still accept)
Line 40: Line 40:
 
== Valid SPF for XMission ==
 
== Valid SPF for XMission ==
  
Any SPF record for a domain sending through XMission should include the following two sources:
+
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:166.70.13.0/24
 
* ip4:198.60.22.0/24
 
* ip4:198.60.22.0/24
  
You can include the above either with the two sources listed above, or by including XMission's spf record with "include:_spf.xmission.com".
+
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>
 
<code><pre>
Line 55: Line 55:
 
== Forwarding ==
 
== Forwarding ==
  
A note about forwarding (ie automatically redirecting mail from one account 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") 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.
 
 
 
  
 +
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.
  
 
= DKIM =  
 
= DKIM =  
Line 67: Line 65:
 
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 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 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, relay. To enable this feature for a domain, two things will 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
+
* 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.
  
Line 80: Line 78:
 
== DKIM DNS ==
 
== DKIM DNS ==
  
Add the following two txt records to the domain in question:
+
Add the following two TXT records to the domain:
  
 
<code><pre>
 
<code><pre>

Revision as of 16:36, 7 March 2022

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.

SPF

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.

@    IN 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:

@     IN 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".

The sources are:

  • a - A DNS A record
  • mx - An MX record
  • ptr - A PTR record
  • ip4 - An ipv4 address or subnet
  • ip6 - An 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)

The prefix characters are:

  • + - Pass (Valid for SPF)
  • - - Fail (Invalid, and reject mail)
  • ~ - SoftFail (Invalid, but still accept)
  •  ? - Neutral (...whatever...)

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:

@    IN TXT "v=spf1 a mx include:_spf.xmission.com ~all"

Forwarding

A 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.

DKIM

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.

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:

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