SPF
Sender Policy Framework
EnableSPF
This setting enables Sender Policy Framework processing for received email.
Sender Policy Framework processing involves verfiying incoming email are coming from the servers designated as being allowed to send email from the sender's domain.
This can help verify the identity of senders,
and therefore ensure that forged or spoofed email can be eliminated at the earliest opportunity.
It must look up special SPF DNS entries for ALL email received and so there may be some latency introduced when receiving email with SPF enabled.
For further information please consult the SPF homepage:
http://new.openspf.org/Introduction
on
Soft Fail
A softfail means that SPF check did not produce a specific failure, but neither
was the IP completely authorized for sending email from the sender domain.
Typically such results come from test SPF records
that domain owners have setup during the testing period or early phase of SPF.
It can be useful to quarantine these messages using the Block option for further inspection:
currently very few domains have full/strict checking in place so receiving a full failure is unlikely, and
a soft failure is indicative that the email originated somewhere unintended by the domain owner.
You SHOULD NOT reject these email outright as that goes against the RFC recommendation for SPF, and during this
early phase of the implementation of SPF some domain owners may be making mistakes with their records.
However, you are ALLOWED to reject these email if you wish, according to the RFC.
Full failures are automatically rejected, and full Pass results are accepted.
Accept, Weight, Mark, Block, Reject
Block
Fail
A fail means that SPF check produced a specific failure, the IP was not authorized for sending email from the sender domain.
It can sometimes be useful to quarantine these messages using the Block option for further inspection:
currently a few domains have incorrect SPF records in place so a full failure can sometimes occur unintentionally.
You CAN reject these email outright however as the domain owner/sender should receive a non delivery report from the server trying to send to Hexamail.
Ignore, Weight, Mark, Block, Reject
Reject
Check MIME From addresses
This setting enables Sender Policy Framework processing to also take place on the MIME From address shown on the email by email clients (similar to Microsoft Sender ID).
This can help prevent spoofing. Sender Policy Framework processing involves verfiying incoming email are coming from the servers designated as being allowed
to send email from the sender's domain. This can help verify the identity of senders, and therefore ensure that forged or spoofed email can be eliminated at
the earliest opportunity. It must look up special SPF DNS entries for ALL email received and so there may be some latency introduced when receiving email with
SPF enabled. For further information please consult the SPF homepage:
http://new.openspf.org/Introduction
NOTE: SPF is intended to operate on the SMTP Envelope sender address not the displayed MIME From address, however it can be extremely useful to also check the displayed MIME
From domain against the SPF record in order to prevent spoofing. The end-user can only see the MIME From address in their email client, so it is useful to have verified it in some way
and to this date there is no dedicated standard for doing so, so SPF is the only available method.
off
Soft Fail
A softfail against the MIME From field means that SPF check did not produce a specific failure, but neither
was the IP completely authorized for sending email from the sender domain.
Typically such results come from test SPF records
that domain owners have setup during the testing period or early phase of SPF.
It can be useful to quarantine these messages using the Block option for further inspection:
currently very few domains have full/strict checking in place so receiving a full failure is unlikely, and
a soft failure is indicative that the email originated somewhere unintended by the domain owner.
You SHOULD NOT reject these email outright as that goes against the RFC recommendation for SPF, and during this
early phase of the implementation of SPF some domain owners may be making mistakes with their records.
However, you are ALLOWED to reject these email if you wish, according to the RFC.
Full failures are automatically rejected, and full Pass results are accepted.
Accept, Weight, Mark, Block, Reject
Weight
Fail
A fail against the MIME From means that SPF check produced a specific failure, the IP was not authorized for sending email from the sender domain.
It can sometimes be useful to quarantine these messages using the Block option for further inspection:
currently a few domains have incorrect SPF records in place so a full failure can sometimes occur unintentionally.
You CAN reject these email outright however as the domain owner/sender should receive a non delivery report from the server trying to send to Hexamail.
Ignore, Weight, Mark, Block, Reject
Block
Skip check for IPs
This setting allows you to bypass SPF checks for email originating from the listed IP addresses. IP addresses can include wildcards and ranges.
Use this list to list any secondary MX servers that are used if your primary MX fails. Email from those MX servers cannot have their originating IP checked reliably against SPF records, as the IP is masked
by the secondary MTA (queuing) server, and received from headers can be spoofed. In these cases SPF checks must be bypassed and the email processed in other ways to determine spam content.
Often MTAs hosted by large ISPs should alerady perform SPF checks so disabling SPF checking for secondary MX servers is an acceptable solution.
Skip check for Addresses
This setting allows you to bypass SPF checks for email from specific email addresses.
NOTE that without an SPF check you cannot depend on the email address being used by a legitimate sending server,
so in doing this you may allow email from spoofed sender addresses to bypass SPF checks.
They will stil be checked for spam using other measures though.
*@domain.com,specific@domain2.com