SPF and DKIM
SPF and DKIM are two methods domain owners have of "authorizing" specific email servers to send mail on their behalf. They are both implemented via TXT records on the domain, though DKIM also adds public key cryptography.
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 include the following two sources:
This includes the mail subnet and the traditional server subnet (which is mainly to cover mgr2 and etrn). The only servers that should be regularly delivering offnet are out01, out02, out03, mgr2 and (under certain circumstances) etrn, but both subnets should be used to cover any future mail expansion or changes.
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:
@ IN TXT "v=spf1 a mx include:_spf.xmission.com ~all"
A note about forwarding (ie automatically redirecting mail from one account to another, not hitting the forward button):
Forwarding (under most circumstances) BREAKS 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.
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.
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, whatever. To enable this feature for a domain, two things will need to happen:
- The domain needs proper DNS for our domainkey key
- The domain needs to be added to our routing config as one with DKIM signing.
Add the following two txt records to the domain in question:
xmission._domainkey IN TXT "v=DKIM1; t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzWmoe0tzQkSUzMqliwcQQ5zY1HKk4z+Wgp+dRCRe7MmSBPftE9r5Lx1QfTfF/J8gl4k9tFsUvUBap0fk1VGMYUG/2LynVuzpkCI4JlUKF5fbx+MDNZrVi0aX73Edjd9trU6NKldVnhNg1RixDLa4aB04XJviy6+3P1h3IHNaZ0QIDAQAB" _domainkey IN TXT "t=y; o=~;"